About This Article

This is a follow up to a twitter thread that I started long time ago.

This is a Living Document
What you are reading is a living document.
Ill update this article whenever I get a similar question that has not entirely been addressed by what I have here.

I tried to keep the suggestions here as much field-agnostic as I can to make it beneficial to you no matter what part of “the stack” you are interested in.

What Stack?!
I also honestly believe that there is no such thing called “the stack”, and the boundaries between the layers of “the stack” have vanished long time ago, so it is a “mesh”—if anything—rather than a stack, but that’s the topic of another article 🙂.

How To Read This Article

Do not just scan this article as if you are scanning through your birdsite news feed. I am not going to be humbe here: This article it is the accumulation of years and years of experience. So, give it the time and concentration it deserves.

While you are reading, you’ll find links to other useful materials, such as this one. Do not skip them: They are as important as the article itself.

With that said, let us begin, shall we?

Introduction

People continuously ask me variations of the following questions at least a couple of times a week:

“I am a self-educated-developer/programming-enthusiast/you-name-it.
I can write code; however, when I dive into complex codebases, I get lost.”

Or, something like that:

“People assume that I know JavaScript, and I confess: I am a JavaScript developer who doesn’t know how to develop.”

I even got this one 😄:

“Help me Obi-Wan Kenobi; you’re my only hope.”

Since answering the same question over and over again is not the best use of the opportunity cost of my time, I wanted to answer them here, once and for all.

Is It the “Impostor’s Syndrome”?

Although there’s a hint of impostor’s syndrome in those questions, there also exists a deep concern that waits to be addressed.

All of these questions translate to the following:

  • “How do I leap to the next level in my field of expertise?”
  • “How do I become the next possible version of myself?”

These questions require a much well-thought-out answer than a “It’s easy; you see: Learn React and MongoDB, and you are good to go.” answer.

So here it goes.

Ask Questions, Doubt Everything, Trust in Evidence

If you forget everything else you read here, take this “red pill”, and you’ll be fine:

Ask Questions. Doubt everything. Trust in evidence.

☝️ That is the ultimate way to become a great developer: The rest is just trivia.

Let me give you a related formula:

  • Ask questions.
  • Take initiative.
  • Move out of your comfort zone.

Here is how it goes:

Ask Questions

As long as there are people around and you know that there are things that you don’t know: Ask them out.

There are naïve questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. However, every question is a cry to understand the world. There is no such thing as a dumb question.

Carl Sagan—The Demon-Haunted World: Science as a Candle in the Dark
  • Ask dumb questions.
  • Ask scary questions.
  • The more you ask, the better.

While you are at it, learn how to ask smart questions and digest the fact that there are no dumb questions.

Take Initiative

After asking as many questions as you possibly can, it is time to take the reins into your hand because after asking enough questions, you’ll eventually run into a set of problems that your coworkers, your friends, and your colleagues don’t know how to solve either.

Trust me; this is very easy 😉.

What you’ll do next is even easier:

  • Decide that you will figure out and solve this unsolvable problem anyway.
  • Then solve it.

Voila!

You have solved a domain-specific problem that nobody else has an answer to.

Move Out of Your Comfort Zone

The more you program, the more issues you’ll find that…

  • You don’t know.
  • Your colleagues don’t know.
  • Google doesn’t know.
  • And you’ll have to figure out (as if your job depends on it—’cuz it does 😉).

Try to challenge yourself to move out of your comfort zone.

Screw everything. Get your pieces together. Focus and solve that problem.

Rinse and repeat this process, and you’ll be a domain expert in no time 🤓!

I’m not kidding. And it’s not that hard.

Share Your Knowledge with the Community

Share your knowledge: Help others.

Software engineering is not a path that you walk alone. Learning to share your knowledge with the community is as important (if not more) than learning something new.

There’s a vast community of developers who are willing to help each other: Be one of them.

Don’t shy away: You don’t have to be a guru to share your knowledge. Opening yourself up, sharing your experience, asking others’ opinions takes you a long way.

You Are not Your Code

“You” and “your code” are orthogonal to each other.

There is no shame in sharing your code.

Share every semicolon you type on your IDE in GitHub (or a similar open source code repository of your choice).

  • Whenever you discover something new: share it.
  • Whenever you have a problem: yelp for help.
  • Whenever you write code: put it to GitHub or create a Gist.

Code Is Nothing

Don’t be afraid to put the code you write out in the open.

Don’t be ashamed of your code.

You know what? Code is nothing.

Trust me; it took a hell lot of years to digest that fact. And it is true:
Code is nothing.

  • What you create with your code is everything.
  • The way you share your knowledge is everything.
  • The value you add to the community is everything.
All great fighting is the same, Eragon, even as all great warriors are the same. Past a certain point, it does not matter whether you wield a sword, a claw, a tooth, or a tail. It’s true, you must be capable with your weapon, but anyone with the time and inclination can acquire technical proficiency.

To achieve greatness though, that requires artistry. That requires imagination and thoughtfulness, and it’s those qualities that the best warriors share, even if, on the surface, they appear entirely different.

Christopher Paolini—The Inheritance Cycle

Code, in itself, is nothing. It is just a tool.

Code is just a tool: Sharing your code, and asking other’s feedback about your code will improve you a lot as a developer.

With that kept in mind, here are a few developer communities that you might want to join and share your code.

This List is Just a Starting Point
The list of communities I shared here is, by no means, a definitive or conclusive list: A google search around your favorite programming language, or your favorite framework, or your favorite toolchain will reveal at least a dozen of quality developer groups that you can join in a heart beat.

Stack Exchange

Stack Exchange is an absolute must as a programmer community site for anyone who is serious about development and programming.

Don’t just read it. Be a part of it. Participate in its discussions. Add value to it.

Mozilla Developer Network

If you’re at all interested in the modern web and the technology stack around it Mozilla Developer Network (MDN) is the community to join.

MDN also provides a ton of information about all of Mozilla’s products and how to use them properly.

FEDs on Slack

No, they are not the feds that you are thinking about 🙂.

FEDS on Slack is a helpful community for top-notch front-end developers.

Join there, and actively contribute to the discussions.

Reddit

There are also some subreddits such as /r/programming and /r/learnprogramming that you might want to follow.

Though reddit is its own universe, don’t get lost in it 😉.

dev.to

This one is so obvious; it almost hurts that there are people who don’t know it:

dev.to is a capable, friendly, and vibrant community of coders.

If you haven’t joined yet, what are you waiting for?

Hashnode

Hashnode is the easiest way to start a developer blog on your personal domain for free and connect with the readers through our global dev community. Like, dev.to, this community is pretty vibrant and helpful too.Read the Source, Luke

If you are planning to become a developer, you are going to be really intimate with the source. And that’s coming up next.

Read the Source, Luke

Read the source, Luke.

Related to sharing your code openly:

Indulge in open source and read as much code as you can.

Explore Without Fear
Make “looking ‘under the hood’ of the open source project you like” a habit.

Do. Or do not. There’s no try.

Initially, reading other’s code will feel painful, daunting, even. You’ll feel yourself like an alien in somebody else’s backyard. It’s difficult to think from someone else’s point of view, observe how they approach the task at hand, analyze how they solve a particular problem, and more importantly why they chose that particular approach instead of a different one.

Reading others’ code takes time, dedication, and practice: And blimey—it’s a time well spent.

Reading Others’ Code
Reading others’ code is just like reading finance: It will feel weird. At first, it’ll feel difficult. And the more you do it, the more comfortable you’ll get at it.

The more you read, the better you’ll get the hang of the logical constructs, the terminology, the concepts, and the overall program flow.

In addition to all these, reading open source code teaches you how to write by using the conventions and idioms of the language.

Add Value to The Community

As a follow-up to the above “Share Your Knowledge with the Community guideline, the more you add value to the community, the more value you receive.

The least you can do to add value is to contribute to open source community.

By adding value to the open source community you’ll…

  • Improve your existing skills.
  • Find mentors to help you.
  • Be a mentor and help others.
  • Build public artifacts that help you gain visibility.
  • Better visibility often means better career opportunities too.
  • You’ll get better at people skills.

More importantly, You’ll feel empowered 💪:

You’ll gain self-confidence, which will help beat the inner impostor out of you (more on that later).

Being a Full StackOverflow Developer is Okay

Don’t be afraid to search: Even the most experienced developers search the most uncomplicated things all the time, that’s not a shame.

Here’s a recent tweet that I shared on the topic:

Don’t believe me? Then listen to the other experts who feel the same:

Looking things up is not a shame.

To Learn, “Learn to Learn” First

With one caveat though: Do not apply the knowledge you acquired without learning about the details.

Don’t just copy and paste things. Learn the “why”s and “how”s of the knowledge before using it in your code.

Don’t just memorize, “learn to learn” instead.

You’ll see more about “learning to learn” down below: Just 🐻 with me.

Know How Your Wetware 🧠 Works

Your “wetware” is not good at memorizing: So, don’t memorize those software design patterns, or those interview questions and algorithmic puzzles.

Don’t Memorize What You Can Look Up
There is no reason to memorize anything as long as you can look it up.

On the other hand, your wetware is a Yoda-level-master at pattern recognition.

Expose your wetware to as many patterns and variations as you can, and let your subconscious do the rest of the job.

That’s why one of the best ways to learn something is to copy what others have done before you:

Imitation Is Learning
Imitate people you admire to be, to be like them.

You Learn by Imitation

You learn by imitation: Learning software is no exception to that.

Learning how to name variables, or how to create a folder structure, or how to couple different modules of your code together, how to document your code… is much easier when you imitate how others have done the same thing before you.

Stand on the Shoulders of the Giants
Learn from the cumulative experience of developers before you.

Even if you want to reinvent the wheel first look at what others have done already, before doing it your way.

About that Wheel…
The “wheel” is, ironically, the most re-invented tool so far 🙂.

Since the day we are born, we learn by imitating. Our brains are wired to recognize patterns, copy, mimic, imitate, and mirror.

The same applies when learning how to code, too:

  • Read others’ code.
  • Copy and replicate what you see.

In time, you’ll understand how different patterns tie together:

You’ll see the “why”s behind those “what”s.

And the way to reach there is to…

  • First, imitate others,
  • Then understand how the thing you imitated works,
  • And only then start questioning why that code is implemented that way,
  • And, finally, think about how to write it differently,
  • Then, think about if writing it differently solves your problem more elegantly.

Take Your Time

Learning by imitation is a slow and gradual process: It requires a lot of time and patience. I’m sorry and there are no shortcuts to speed it up. Though, as in anything, practice makes perfect.

The more you read others’ code, the better you’ll get at it: It’s worth the time and energy you invest in.

Hint
For starters, you might want to start reading the source code of the open source frameworks that you love: The transition will feel much easier then.

After you get used to the codebase, it’ll start to feel familiar, and then can you find a chance to dig in further.

When you feel you are familiar enough with the codebase, fork the project on your development environment, then build it, and then debug it to understand how its different pieces of the code interact with each other.

Do this exercise regularly, every single day, and one day you’ll wake up and utter:

“I know kung-fu.”

Don’t Hang onto a Single Paradigm

Whatever you do, don’t stick to a single language, or a single paradigm.

Embrace change, embrace different languages, embrace different approaches.

Don’t Have Firm Opinions on Anything
There is no single correct solution to any problem. Most of the time, there is more than a single truth. More often than not, those truths coexist.

The more languages you know, the broader spectrum of paradigms you’ll be exposed to. Knowing more than one language will help you shape the way you think. You’ll approach problems differently. And that is good.

When you expand your horizon, and when you get out of your comfort zone, you will be able to combine seemingly unrelated facts with each other to come up with a solution—That is the very definition of creativity.

With enough accumulated creativity and artistry, you will eventually be the one to find a solution to “that” problem even Google has no answer to.

There Are No Shortcuts

Related, somewhat ironically, to the above quote, we are not in the Matrix.

Anything that claims you to “teach X language in Y weeks” is a big honking lie.

Take it easy.

Learn gradually.

Give the time your brain deserves to internalize what you have learned.

Learning requires:

  • Repetition
  • Routines
  • Habitualization *
  • Dedication
  • A hell lot of perspiration
  • And repetition
* “Habitualization” is just a big fancy word for creating habits based on stimulation in your environment.

Moreover, once you dedicate yourself, you’ll be amazed at the progress you make.

The only difference between you and the role model that you want to be will be the amount of time you regularly dedicate yourself to your kung-fu and the number of things you sacrifice on the way.

Learning is a means: It’s not the end.

Surprise: Learning Never Ends
If you are in this industry, you will continuously learn forever, be ready for that.

Beat the $#!% Out of the Impostor in You

From time to time, you may feel that you are lagging behind, or you don’t know as much as your colleagues—That is a well-documented psychological phenomenon called the impostor’s syndrome.

You might get a feeling that you are just lucky to be in your place. You might feel that you don’t deserve your place.

You know what? That’s complete and utter 🐴 💩.

Here’s why:

  • Nobody knows everything.
  • Nobody is perfect.
  • Everyone has a unique set of skills.

You are priceless in what you bring to your environment, and nobody can add the values you specifically add.

Important
It is the union of the individual skills of the people that make the team more prominent than the sum of its contributors.

Most people experience moments of doubt, and that’s normal. The important part is not to let your uncertainty control your actions.

Yeet the Impostor Out of You
Here’s a stupid trick that works: If you tell yourself you’ll never feel like an impostor, guess what? You’ll never feel like an impostor.

Just accept the fact that not knowing everything is normal. You’ll learn things when you need to learn things—That’s okay.

You don’t have to learn that new API, or that new cool framework.

Also, even if you do have to, you don’t have to learn all of it… like… right now 😁—Cut yourself some slack. Give yourself the time you deserve.

If you are still not sure how to act like that, this article gives a couple of tips an tricks on how to beat the impostor in you.

After the fact that you are better than you think you are is set straight, we can move on to the more technical parts of the equation.

Be a Good Software Craftsman

To be a good software craftsman is to read what others have to say about it.

There is so much material about the subject that giving a digestible summary here is practically impossible. So, I’ll provide a list of bedtime reading material instead.

I recommend you read the following the resources that I’ve listed here in Resources Every Developer Must Read—No Exceptions cover to cover, twice.

  • Once: Before you begin your programming journey.
  • Next: After you have been coding for several years, and you have learned more than one programming language well.

A heads up: It’s a relatively long list, and it might take a while: Take your time.

What’s common in all of those resources is that they don’t talk about how to use a specific programming language, they talk about things that are bigger than code.

They are essential. I can go as far as advising you to read them before you even start learning to code.

Why?

If you want to be a good software craftsman, code is of secondary importance. “Code is nothing”, remember?

Don’t give code more value than it deserves.

Know Your Tools Well

What tools you choose will depend on what you want to achieve. This section will introduce a few common paths that you might want to explore. Though, don’t take is as an end-all be-all reference.

You Know Where You Want to Go Better
You know where you want to go better than I do, and it’s virtually impossible for me to cover every possible niche. Instead, the areas I list below will be mostly the ones that I’m interested in and regularly exploring. I’ll add more resources here as I create more content.

For example, if you want to get better at JavaScript in particular and Front-End Development in general, Learn Your JavaScript the Unconventional Way can be a great starting point. While at there, it would be good to remind yourself that Knowing JavaScript Is Not Good Enough. And for an unorthodox take on the subject matter, you might even want to Learn Haskell First to Learn JavaScript Better.

Or maybe you want to follow the path of an User Experience Designer. In that case, on Usability and User Experience, I’ve gathered quite a few resources in Don’t Make the User Think that might pique your interest.

How About Software Design Patterns?


A quick advice about studying Software Design Patterns is, don’t try to fit everything into a “pattern”. Go with the flow.

Experimenting with design patterns the first time is like playing paintball the first time: It’ll be fun, but it sure will be messy and it will hurt a lot.

Design patterns are good, and you should read about them; however, keep in mind that they are guidelines, don’t take them as gospel.

They are more guidelines than actual rules.

Don’t try to fit every problem you have into a pattern.

Yes, there are specific sets of problems that fit well with certain software architecture patterns. One the other hand, forcing patterns into every single problem set will be counterproductive, at the very least.

How About Those “Interview Prep” Books and Code Banks?

For books like “Cracking the Coding Interview”, and for websites like “Leetcode”, well, I have mixed feelings.

If you want to pass an interview, sure thing, go ahead and read them.

If you are prepping for an interview, not studying those resources is illogical: If that’s how the game is played, you should play it by the rules unless you are confident that you can set your own rules.

About Competitive Programming Challenges

If you want to work for a company as a software developer, and if that company prefers asking competitive programming questions instead of seeking for a diversified and complementary mixture of creative human beings, then you have no other option but study those interview prep books and websites.

From my anecdotal observation, that’s how the majority of the Silly Cone Valley companies are right now. There are exceptions, but it’s very rare. And from the looks of it, it’s not about to change anytime soon.

Though, I have a sliver of hope that, if you have read this article thus far, you have a strong belief that you are meant to be more than just a walking scientific calculator that can backtrack a maze, or reverse a binary tree 🙂.

For mastering of your craftsmanship, interview prep books and websites are not worth your time.

I mean, do buy those interview prep books, and do solve the question in those “programming interview questions code bank” websites; however, treat them as “side dishes”, not as the main course.

Don’t let a stupid recursive array manipulation interview question dictate how good a software craftsman you are.

Flex Your Algorithmic Muscle

Though, don’t get me wrong here. Learning algorithms; learning when, why, and how to use them is priceless. Memorizing algorithms, on the other hand, to pass a technical interview is a waste of time. This is a a subtle, yet importance difference.

Don’t learn data structures and algorithms for the sake of studying for interviews. Learn them because it makes you a better programmer.

Regardless, studying competitive programming questions will help you in your programming interviews. There are even shortcuts (like websites like leetcode) that help you practice your algorithmic chops.

Yet, that’s not the point. Do not take shortcuts.

Spend time to understand a broad spectrum of data structures and algorithms: Learn when to use them, how to use them, when not to use them.

Learn what the benefits of a particular type of algorithm are.

Learn what the liabilities of using specific data structures are.

Here are two excellent (and free) resources to learn your algorithms:

Aside from them, I’d suggest reading these two books cover-to-cover, not skipping anything. Genuinely ingest everything in them:

There are other books too, and you can investigate them on your own. Though, these two books will cover all your algorithm bases.

Learn to Learn

Before even beginning your learning adventure, you need to know two things:

  • You should know how you learn: What type of learner you are.
  • You need to “learn to learn”.

That might sound “too meta”, so let me elaborate:

Learning to learn is easier said than done because to “learn to learn”, you have to know yourself first—you have to have an idea of what type of a learner you are: There is no “one size fits all” solution in learning.

“Every fighter has a different way of eating yogurt.”
— Turkish proverb

Are you an inductive learner who starts with the foundation and understands the bigger picture by connecting pieces together.

Alternatively, are you a deductive learner who likes to see a working system as a whole, only to split it into is building blocks recursively, and understand each piece until there is nothing left to split apart.

Are you a visual learner? Do you use flashcards? Do you want to draw things on a whiteboard? Do you want to look at things “from a different perspective” to “get the hang of it”. Do you understand things best when you have a “clear picture” in your mind?

Learn How You Learn

Do you like watching videos to learn things, or are you more comfortable when you read books and articles and then apply the concepts you read at your own pace?

Do you learn by playing toy projects?

Do you learn by reading others’ code?

There’s no exact answer to the “how do I learn?” question.

If you’re not sure, I’d suggest you try a variety of different approaches and see which ones fit the best for you.

Caveat
An unrelated cautionary note: Most people don’t fit perfectly into a single learning-style category, so it’s highly likely that you will be better off using a mixture of learning styles and techniques.

Watch yourself, and be more aware of what styles of learning you prefer the most.

Don’t Rush

Learning to code is no different from learning any other skill: It’s a slow, painstaking, and gradual process. The more you practice, the better you’ll get.

Take “reading others’ code” for example. Do you have a problem reading others’ code? Then attack the problem right at its heart:

  • Pick a few open source projects from GitHub.
  • Read the code in there until your eyes bleed.
  • Then read some more.

It is a slow and gradual process: Be patient.

Before You Begin Programming…

No matter what you want to learn, if you aspire to be a good developer, you will need the following skills. So I encourage you to learn them sooner than later.

After you are comfortable with them, you can continue your programming journey from where you left off.

Here is a short list of skills that you’ll likely need for starters:

  • A basic-level of terminal knowledge.
  • Ability to write simple shell scripts.
  • Basic knowledge of git and GitHub.
  • And knowledge about how to ssh into a server.

Where to Go From Here

There are a handful of articles that I keep on writing to augment this roadmap. Here are some of those that you might find interesting:

On Innovation and Creativity

On Software Craftsmanship

On JavaScript and Friends

On Go Programming

On Design and Typography

On User Experience and Usability

Conclusion

If you have been patient enough to read to the end of this article without skipping anything, you are better than 75% the world already. Congratulations.

Learning is a never-ending journey. And learning is also a way to find yourself. Finding yourself—finding your core idenity—has never been an easy task.

Of course there will be times you’ll stumble upon. In those times, make sure you are surrounded by a welcoming community to support you and push you forward.

I’ll write a follow-up article, focusing on a more technical roadmap, especially focusing on the path of becoming a developer.

Until next time… May the source be with you 🦄.