On the art of learning and the imposter syndrome

With this post, I would like to address how I learn, how I teach and how I deal with anxiety around the "imposter syndrome".

Always learning

Every developer, certainly in modern times, spends a lot of time learning new things. Improving and adding skills to your skill-set, adding new tools to your tool-belt and deepening your technical knowledge.
You might feel, like me, that you're behind; all of the time.
Despite popular though, this is true for everyone. I have more than 10 years of development experience and I constantly need to learn new things. Not only because new technology stacks and/or frameworks pop up constantly; but also because it takes a while (and a lot of effort) to become a true "expert" in any subject.
Unlearning stuff is also just as important. Patterns you develop might not be up-to-date, or just plain wrong.

“Half of wisdom is learning what to unlearn.” -Larry Niven

The road to success is always a never ending cycle, for juniors and seniors alike:

I can imagine that this can seem a bit daunting. Maybe even create some anxiety, especially among the younger readers. But learning new things should also be fun! If it isn't, you are most likely doing it wrong, working in a wrong environment or (let's hope not!!) started a career as a developer without fully understanding what that actually means.

Ways to learn

We all learn differently. Some like to take the biggest (I imagine) book they can find and start ploughing trough thousands of pages of technical specs.
Others like to listen to podcasts or view tutorials online on platforms like Pluralsight.
And then others got to conferences, read blogs, do research or just hack through something until they hit a concrete wall thick enough that they simply have to defer to the manual.

In learning there is no correct way, but there is a correct way for you. Most likely it will be a combination of the things listed above. It is, however, really important that you learn ways to formalize your learning process. If you want to get better, you have to find ways to continuously improve your skill-set. Think of it of a Continuous Integration framework for your learning process!  

Times to learn

Figure out the time when you are most productive. For me this is mostly in the morning and early afternoon. I tend to do most of my complex programming tasks in that time window, leaving administrative and repetitive tasks for the afternoon.

Remember that, even though it might feel that it is absolutely vital to know a certain technology by a certain point in time, setting deadlines might be contra-productive. It's entirely possible that you have extended periods where you are able to work late into the evening, or even into the night.
But remember, your body should always come first. It does not listen to deadlines. When you are tired, or simply not in the mood, obligating yourself to work through technical documentation or difficult code bases can have a negative effect. Leaving you with a feeling of defeat. Sometimes it is better to allow your body to recover, to let yourself energize for the road ahead. Because there certainly will be times where you will just have to work through everything to reach a certain point.
But hopefully you can limit that to the absolute minimum. For me, taking time to get "unconnected" is absolutely vital; that's the time I need to recharge my batteries.

Try to listen to and respect your body and mind. If you treat yourself with respect, the return of investment will be a great reward.

The "imposter syndrome"

Let go of the feeling that you have to know everything about everything. You can't, it's as simple as that. There are so many different tools, frameworks and technologies around making it impossible for you to know them all. This goes for everyone.

Once you get the feeling that your colleagues know more than you; and you just nod along with the technical gibberish that comes out of their mouths, you're experiencing something we call the "imposter syndrome".
The anxiety you experience around being exposed as an imposter; a somehow "lesser" developer than other members of your team/company.

If you do feel like most of the words you hear from you colleagues are absolute gibberish (and are afraid to ask them to explain them), simply write them down and research them later. It takes a while; but you will get there. Remember; we all experience it! Speaking and asking for an explanation can be challenging; but it can be rewarding too. It's one of the ways we learn; and grow; as a person.

Remember, everyone experiences it. The only real difference is that; once you have enough experience; the anxiety will not be as big of a deal. It might never go away completely, but the more you believe in yourself, the less afraid you'll become.

As a general rule: it is always better to start with a broad knowledge base (knowing what something is without ever having come in touch with it) than a deep knowledge base (knowing a technology backwards and forwards).

Final words

You should regard your knowledge base as something ever changing. Like a computer, which tends to be a good metaphor, since most of my readers are IT minded ;).

Your memory has both RAM and SSD storage. Your job is to load as lot of knowledge in your RAM as you possibly can, but only regarding topics you're working on at that moment. If you use a certain technology, pattern or tool a lot; that RAM gets placed into you SSD. Even this knowledge will fade away over time; but not as quickly. If you don't use the 'data' enough, it will be erased for newer things.  
But developers should be (and not always are) respected for their compute value. Their CPU Power if you will. The power that combines your memory with the skills to write good code, to research new things and learn new specs quickly.

And, if you are a PC tweaker like I am, one general rule of thumb: Don't ever let your system overheat ;).

Photo by Nick Morrison on Unsplash