How freeCodeCamp Is Helping Me Become a Better Programmer

By: Amy M Haddad

Judging by the title, you may think this article is about the programming content on freeCodeCamp. You’d be partly right. But it’s also about something bigger.

Before we get to that, I need to share some details with you.

The Technical Path

It was a rainy November day when I submitted my first article to freeCodeCamp. I’d written about my experience learning to program. I was hopeful the article would get published, but wasn’t banking on it. Rejection is common in the world of writing.

A few days later I was sitting in the library in Cambridge, Massachusetts, where I was living at the time. After finishing my programming work for the day, I checked my email. To my surprise, I got a message letting me know that my article was published. I was thrilled! I continued to write more articles for freeCodeCamp as the months rolled on.

But things took another surprising turn just over a year after my first freeCodeCamp article was published.

On a Monday afternoon in February, I was on a video call with Quincy Larson, the founder of freeCodeCamp. He asked my thoughts on writing articles that would be much more technical in nature.

I thought to myself, “Technical articles? Me? On freeCodeCamp?!”

Up to that point I’d only contributed articles on the process of learning to program, such as how to get unstuck and solving problems versus exercises.

I’m a pretty expressionistic person. So I’m sure Quincy could see the mix of shock and excitement come across my face. If he did, he didn’t waver. He seemed to think that I’d rise to the challenge.

Getting Better: One Article at a Time

Writing forces you to think and communicate clearly. Technical writing takes it up a notch.

Little did I know how much I’d gain as a programmer from writing technical programming articles for freeCodeCamp. The process has done more for my coding skills than I ever imagined.

Writing about Python, JSON, CSS, and JavaScript has taught me the importance of “technical communication,” as Will Sentance, CEO of Codesmith, calls it. That is, using precise technical language when talking about code. Or in my case writing about it.

Oftentimes programmers will use terms like “arguments” and “parameters” interchangeably, for example. However, these terms have different meanings. When teaching others about a topic you’ve got to be precise. The details matter. And, as it turns out, training your mind and eye to pay attention to the details pays dividends when coding.

Technical writing also sends you digging through the dense technical documentation for deeper understanding. Likewise, I regularly find myself referring to documentation for a language or technology when coding; writing technical articles just got me a bit more comfortable with it.

Then, the challenge becomes making something complex simple. This is hard to do, as any writer of code or prose can attest. There’s a lot of truth to the statement: “easy reading is hard writing.”

Above all, you’re dealing with ambiguity. Inevitably there are nuances you need to learn about along the way while writing, much like when you come across something new when coding.

As you can see, many of the skills you’d use to write technical articles are the same ones you’d use to program. Same skills, different context. Think of it like cross-training: you’re attacking some of the core competencies you use daily as a programmer from a different angle.

There’s something more. Writing technical articles for freeCodeCamp has given my confidence as a programmer a boost. I have Quincy and the team at freeCodeCamp to thank for that.

The Future Generation of Programmers

freeCodeCamp lives out its mission: “to help people learn to code for free.” This is admirable. Sure enough you’ll find tons of content designed to help people learn to code on its website.

Equally important, however, is that it provides opportunities for contributors, like myself, to share their programming knowledge and ideas. This opportunity, in turn, sharpens tangential programming skills and fosters confidence, which is a large part of helping people to code.

I must elaborate on this critical point. freeCodeCamp could follow the footsteps of so many companies today, which often only look for senior software engineers. Instead, freeCodeCamp seems to think outside of this mold, and realizes that qualifications come in a variety of flavors.

However, I was prepared when the opportunity at freeCodeCamp presented itself. I’m a self-taught programmer and technical writer at a software company.

These themes—breaking the mold and being prepared—form the two calls to action that follow: one for businesses and one for programmers.

A Call to Action for Businesses

If you’re established in your field, whether you’re a company owner or hiring manager, be open-minded: think outside the mold.

One programmer I know, let’s call him “Ed,” applied to tons of programming jobs and got his share of rejections. He was self-taught and had years of freelance work under his belt. There was just one problem: he didn’t fit the mold.

Despite Ed’s lack of formal credentials, he was an exceptional programmer with stellar problem-solving skills. He could learn technical topics quickly and communicate clearly from his many years of management.

One company looked outside of the mold and saw his potential. Like freeCodeCamp, it was open-minded to how Ed forged his path. He landed the job and got the “official” title he needed.

To be clear, Ed wasn’t just given something for free. He had the necessary programming skills and knowledge. He just needed the opportunity to apply them.

Then, when the opportunity came, he rose to the challenge. He had a thriving career during his tenure. Now he’s a principal engineer at another company. Several years on, Ed still credits his success to the company that “took a chance on me.”

Time and again I’ve seen people rising to the occasion—when given the opportunity. It happens all of the time in athletics. One of my favorite stories involves The Ohio State University (OSU) football team during their 2014 season.

OSU’s star quarterback got hurt at the beginning of the season. Then, in an unbelievable turn of events, his replacement got hurt late in the season. Two quarterbacks suffered season-ending injuries.

So the third-string quarterback, Cardale Jones, stepped in as the starting quarterback. And when he did, he rose to the challenge: he led the Buckeyes to a national championship that year.

“Unfortunately both guys got hurt,” Jones later said in response to the 2014 season, “and luckily enough I was prepared to try to take advantage of the situation.”

Jones’s response brings us to the second call to action. This time it’s for programmers.

A Call to Action for Programmers

If you’re a programmer looking for your break into the field, here’s your call to action: be prepared.

You could say that Jones got a lucky break. Lucky or not, Jones was undeniably prepared. He’d put in the work to do great things. When his time came, that’s exactly what he did: he led the team to a championship.

To me, being prepared means honing your programming skills so you can contribute immediately. Only you know if you’ve honestly put in the time and effort to learn a particular language or technology. While you don’t need to be the top-most expert, you need to be ready.

I knew of a budding programmer who routinely asked other programmers for a job at a meetup I used to attend. He routinely got the same answer: to improve his problem-solving skills. For a long time he ignored the feedback (though I last heard that he’s enrolled in a bootcamp). The point is: he was looking to get handed a job without being ready. Don't do this.

You’ve got to put in the work; there’s no way around it. Then, when ready, put yourself out there.

Yes, freeCodeCamp published my article on that fateful November day. But I got that article published because I put myself out there and opened myself up to rejection in the process.

I’m very grateful to be a freeCodeCamp contributor. I hope the articles I’ve written have helped other programmers as much as the process has helped me.

I’m equally grateful to contribute to an organization that’s true to its mission. Others ought to take note of this remarkable organization and how it’s doing a whole lot of good for future generations of programmers—not only in the content it provides, but also the opportunities it offers.