On Self-Teaching and Becoming a Developer

Hey, my name's Leo, and I'm currently one of the mods and contributors to The Odin Project (TOP), a free full-stack curriculum supported by a passionate open-source community.

In October of 2018, I landed my first web-development role. Prior to this, I had graduated with two Masters degrees in Counseling Psychology from an Ivy League institution (lolsob @ my student loans), working mainly in social services and advocacy. Now, I'm with a reputable, international company located right outside of Washington, D.C, where people love running, ride e-scooters in traffic like they aren't going to die, and still think Chipotle is good food.

I wanted to take a minute to share some thoughts I have about being a self-taught programmer. I can't promise the insights will be revolutionary, but I hope it'll add context to the ins-and-outs of that process, and otherwise serve as a gentle reminder. Let's dive in.

Step back from the race

When I realized that I might be able to take coding from a hobby to a career, I spent some time looking for inspiration and seeing what the experiences was like for other folks that transitioned from "non-traditional" backgrounds. Unfortunately, the results were more anxiety-provoking than anything.

In my search, I found stories that recounted attaining success within time-frames that ranged from reasonable (12 months) to outright blasphemy (3 months!), the latter most likely having traded their soul to some questionable entity.

If you're like me, you might start telling yourself that you can do it, and you've gotta go fast.

Stop. Turn around.

At The Odin Project, we have a saying: "Time is an illusion." It's really not, but bear with me.

The only thing these success stories can definitively tell you is that getting a job as a self-taught developer is 100% possible. The rest, especially the timeframe, is relative, subjective, and arbitrary.

Sure, you can set a goal to be gainfully employed as a professional developer. That can be helpful in tracking your development. Certain personal and/or life circumstances may even push you to self-impose a hard deadline.

Given all these points, though, the path to becoming a developer relies less on a title and more on a process during which you hopefully cultivate a mindset and attitude that hopefully separates you from other developers during and after your future job search. You become a good developer when you commit to continued learning and honing of your craft. There is no actual finish line when it comes to technology and programming, save for the heat death of the universe. Being employed means nothing if you can't keep the job due to bad habits you've picked up along the way.

So, sure, set an employment goal if you must. But aim to be a "employed (good) developer" rather than just an "employed developer". The deadline can be important, but less so than the learning process and the good habits you develop along the way.

One way to do that is to feed your curiosity for code.

Be curious

When I accepted my current position, my team leader at the time told me that they had done so partly because, as a self-taught developer, I had exhibited the ability to independently pursue and learn things that interested me.

As you go through your learning, you'll often come up against topics and ideas are presented simply, but seem to be more complicated. Take note of them. Maybe you're reading about a secondary topic that is "beyond the scope" of the primary topic. Maybe something appears too magical to be true. Keep a running list of topics you want to dive deeper into. You aren't responsible for the things you don't know that you don't know, but you are responsible for the things you know you don't know know.

Now the hard part: prioritize that list. If you dive into every little rabbit-hole, you'll never get anywhere. Knowledge gaps are okay. Even Dan Abramov admits to them, and to me that's a relief. If you feel anxious about having to learn everything, take a humongous breath and let it out. Focus your time and energy for those moments you come across a topic that truly sparks joy and curiosity.

Lean into these curiosities when they come, and celebrate your progress. Do you finally understand how JavaScript Promises work? Do you know how Rails polymorphic associations work under the hood? Come share with us in TOP's Discord server.

Remember, this shouldn't be a race, but priorities are still important. Feed your curiosities without getting bogged down. Materialized views in SQL, algorithms and space/time complexity, bash scripting, etc.: you've got the basics (or not), it's not immediately relevant, so maybe take a deeper look later? That's totally fine.

You're not doing this because you have to, anyway. You're doing this because you love challenges, you love computational thinking, you love computers and the internet, and you want to Instagram a picture of your IDE and tell everyone you're a coder (you're allowed to do this once in your lifetime).

Be consistent

Achievements and progress require consistency, especially when you are self-taught. Plenty of people have the means to attend coding bootcamps where structure, guidance and mentorship come hand-in-hand with learning (though even that is debatable).

That wasn't an option for me. I had too many financial obligations and no savings to live off of for however long these bootcamps require full-time enrollment. Heck, I worked in social services; I barely survived.

I chose TOP primarily because it is 100% free. The kicker is that it is entirely self-paced.

Here's the deal: if you want to be successful as a self-taught developer, in whatever way that means, you must be consistent. There is a significant, long-term difference between "I think I'll do some coding today" and "I'm setting aside 1 hour to code today". You want to be in the latter group.

Additionally, don't binge 8 hours on one day, and skim for 30 minutes on the next. Balance your work and breaks. Pursue other hobbies and interests. Talk to people! Counter-intuitively, I believe that if programming becomes a consistent and balanced part of your week, it affords more flexibility. The habit of consistency means that you can get right back onto the horse if life happens and you need to step away from programming for a bit.

Honor your curiosities. You deserve them, and you owe it to yourself to consistently pursue them.

Be helpful

Gatekeeping is a natural side-effect of being established, whether as an institution, an industry, or a community. That doesn't mean you have to like it. I certainly don't.
Programming can get so cerebral that it is easy for us to thinking highly of ourselves if only because we understand some topics better than others. We're tempted to flex a little.

I'd like to suggest a different route: be ridiculously helpful.

Being helpful provides a tremendous learning opportunity. It's an active way to engage and exercise your understanding of a topic. It might event open you up to corrections from others, too, and that's valuable and okay. Remember, learning is continuous, so you'll never get it right 100% of the time. But you can improve, and that's a win-win in my book.

At the end of the day, at least at TOP, "self-taught" is more or less a lie. TOP runs well because of volunteer contributors, moderators, and overall ridiculously helpful folks that make sure everyone has access to a positive learning environment and experience. A significant portion of TOP's value comes from the community itself. I myself never felt that learning was a solo effort, and I wouldn't want you to feel that way either.

The more you come to understand, learn, and practice, I hope you'll take a minute to pull up the folks that are in the position you were in, however long ago, trying to grok how a for loop works in JavaScript (true story, they are the reason I quit and took a 6 month hiatus), or struggling to understand flexbox. I think helping others learn is a great measure of success.

Wrapping up

Slow down. Be curious. Be consistent. Be helpful. You'll get to where you want to be.