I often see recommendations on Twitter about how to deal with impostor syndrome. It is almost always something like “just convince yourself that you’re not an impostor”. It is hard to do if you have a conscience.

Introduction

The first time I was hired when I was just 18 and I was given a salary that was higher than my father’s salary. My knowledge of software development was close to zero. I wasn’t a genius - I was just an average guy who managed to read a couple of books (we didn’t even have Internet to learn so you can imagine).

Did I have importor syndrome? Hell, yeah!

Only many years later I managed to see how many working hours the software I created have saved. At the company I was working at, we managed to deal with the business having only 2 accountants while in the other division of the same company they had 6 for the same work. So my salary must be as of those 4 absent accountants, right?

It was a very naive logic, but it helped me to understand how a software developer can influence the company’s cost efficiency and where the money I receive are coming from, and why I actually deserve some of the money.

But.

It is much harder to understand how a software developer deserves money nowadays. Most of us are writing software that influences many people instead of directly saving on staff headcount. Very little amount of developers is aware of how exactly much money they made to earn their salary.

Impostor syndrome is rampaging.

Someone got his/her first salary and feels anxiety. “Did I do everything right? Do I deserve it? How do they believe in me?” My employer is convinced, but my conscience is not.

Because.

I know that I am not a professional.

Look at blogger X, HE is a professional.
Look at those smart guys who wrote the library I am using!
The book author!
Professors!

How can I compare myself to the people who actually know the stuff, and how can I earn the gigantic salary (thanks to my manager’s illiteracy)?

The way out

I am afraid that I will be hated after having this article published. It is a very mentally hot topic.

I will be very clear: I’m not trying to shame anyone, nor I am trying to make anyone guilty. After all, I was in the same position myself.

The way out is HARD.

Having conscience is always hard, but most of us do not want to discard it that easy. Being able to stay proud in any condition is priceless. Even if your company will lose serious money because of your fault, that will not be because you didn’t do your homework. Consider the hard way to be the price for having your conscience clean.

The way out of impostor syndrome is to become a true professional.

True professional knowns the stuff. So you have to learn.

Unfortunately, having an education is not enough. If we had an education system that actually teaches that would be really nice. I would stop seeing “impostor syndrome” in my Twitter and anxiety level amongst developers would drop. Maybe we also could have better software.

Don’t worry - you don’t have to learn the useless stuff you do not need. That’s the key point. Instead of learning the stuff you don’t need, the right thing to do is to learn the stuff you need.

The way out is hard, but at the same time, it is extremely rewarding.

How to learn

“Becoming decent at programming took 20 years more than I expected” – Internet

Knowledge, in its fundament, is certainty.

In the practical field without complete manuals that you can just remember, repetitive practice is the only way to earn certainty and knowledge.

Press the button, will it work? Press it again! And again! After some time you will be sure that pressing this button will yield to the same result. This is certainty.

When the button breaks - you open it up and explore why it did break. You fix it, and now, when you’re pressing it you definitely know why and how it works.

We don’t have to break things to gain knowledge, but it is just the most obvious way to demonstrate the idea.

Poke your finger into every bump and see what gets broken and why.

Learn to unlearn

Technologies rise and fall every month.

If you learn a specific way to solve a problem be sure that one-three years later such solutions will be outdated and can very likely be considered as a bad practice.

Normally, a developer with 5 years of experience in a field can be 5 times faster than he/she was 3 years ago just because of constant practice and learning.

The opposite can also be true - if you start applying a new technology it can lead to bloated code and hard to predict results. That’s why it is recommended to give each new technology a trial period in a small and less important project before bringing it to a big project.

If a developer learns a specific way of solving problems but lacks critical thinking and self-criticism (never unlearns), he will very likely become slower than he/she was 3 years ago, while being sure in his/her superiority.

Hype cycle

You can often hear about Hype cycle and when you google it, there is a graph showing that after “Disillusionment” it comes “Enlightenment” and “Productivity”.

This graph is a lie.
Technologies die and gone.
This is the natural cycle.

Who cares about Perl in 2020? Looking at the Hype cycle you may think that it must be in its peak of productive usage now. Look at the real stats - it is 60 times less popular than Python.

Do not buy hyped technologies - try them and if they smell then drop them as fast as possible.

Languages, libraries, patterns, frameworks - everything will perish without a trace. This is a given. This will happen many times during your career. A language will be outdated in 10-20 years, a framework will be outdated in 5-10 years, a library’s life cycle is 1-3 years.

Start preparing to change your job title in 5 years after you started. Accept the natural cycle or follow dinosaurs.

Do not be afraid of stackoverflow.com

It is a priceless modern resource for having examples and for troubleshooting. I regret I didn’t have it during my early career.

Nobody will expect that you have all the answers to all the problems you face upfront.

It is a mental disease to endlessly waste time trying to prepare for all possible scenarios never actually trying to do anything.

I am pointing my finger to the modern education system. We waste 10-17 years of our lives and when we finally get a job in most cases we have to learn from scratch (except reading and arithmetics). This approach of “premature learning” simply does not work, especially in software development.

So relax and google it when it comes.

Learn to solve real problems, not imaginary.

Learn how the machine works

Nothing gives more certainty than understanding the machine. It is the machine that will execute what you created. It is the machine who needs to understand your code. So you need to understand the machine too.

Start a debugger and execute your app in steps, observing how variables change. You have to spend a lot of time looking at how your code gets executed under the debugger to be always able to tell what exactly will happen during runtime.

Find a “How a CPU works” video on YouTube, the most hardcore one you’re able to understand. It must be a video as close to bare metal as possible. If you weren’t around when self-assembled computers were a norm, find a PC and learn how it is composed.

Premature optimization

“Premature optimization is the root of all evil” – Donald Knuth

Write and run benchmarks. Many of them. Do it to prove that an optimization is needed. Or the opposite - that it is not needed.

We always hear that “we’re doing it this way because it is faster this way”. If they cannot tell how many nanoseconds it saves, they are just lying. They do it because they cannot unlearn.

It is common knowledge that premature optimization does not worth additional effort, nevertheless we see many developers write many-many lines of code to increase their code performance a tiny bit, but it will never get noticed by users, nor give the company any money.

Terms

Do not close your eyes on technical terms. Just go and find easy to understand explanations.

Every time you see a term it usually means that it was important enough so somebody gave it a name. It is not always the case - there are areas where terms are getting created out of thin air, so you have two choices - find the term’s explanation or drop the article.

Reading through articles without understanding the words is the same as trying to pour water into a bucket with a hole in it.

Runtime feedback

Collect your application feedback from real devices. If there is a way to get logs remotely - it is priceless. Having confidence in his/her app is the core characteristic of a professional.

Opensource

Take a library you’re using and check its source code. You may discover that it was created by a genius and you will learn a lot. The opposite may also be the truth, so you will have a reason to switch to a library with a lesser amount of potential issues.

Some libraries may be so hardcore that you will not even hope to understand them at your current level. Do not push yourself here, there is time for everything. Some libraries you don’t even want to understand. Who cares about how encryption is implemented? If you are not trying to be a security expert there are better ways to spend your learning time.

Learn from official examples, but do not forget that your experience is more valuable than one thousand examples provided by the most expensive developers on Earth. The people who work at large companies and write the examples do often also have impostor syndrome and their understanding of programming principles can be really bad.

Exercises

Rewrite some real code using a new thing you’ve just learned.

I often rewrite code trying to make it shorter (fewer lines of code) or trying to make it easier to understand. If both goals can be achieved at the same time - this is the best. Mind that the code will most likely be read by other people or by yourself much later. Those people do not understand the flow of thought you had while writing the code, so it should be obvious from the code itself.

Do not use comments do describe what code does - programming languages are designed in a way that code could be human-readable. Reserve comments to tell why the problem was dealt with in an unusual way.

Accept the idea that the code you wrote will look stupid. Even after becoming an expert you will not stop learning. If you see the code you wrote two years ago and you do not know how to make it better it means that you didn’t learn enough. If you look at your old code and start crying in shame it means you’ve leared a lot and you must be proud of yourself.

Learn a functional language

Usually, modern developers are taught to use OOP languages the most, completely putting FP languages out of the picture.

A functional language is a language that relies on immutable data and allows code composition using function references. On the contrary, an object-oriented language is a language that relies on mutable variables and code composition using groups of functions attached to the variables.

It is important to know the value of OOP. But without knowing the values of FP the developer’s understanding of software principles will be lacking. While two approaches are seemingly incompatible, they go together quite well. Most of modern OOP languages are incorporating FP elements into them and becoming hybrid. Development culture adapts to changes very slowly and without additional learning, it is impossible to properly utilize FP in hybrid programming languages.

I recommend to learn a non-academic modern functional language and make a pet project with it. Such languages are: Clojure, Elixir, ReasonML.

It is very important to understand how to write your application using the minimum amount of mutable variables and data flows.

Learn more

http://wiki.c2.com/ has many discussions and articles about programming patterns and theory. It is an invaluable resource to understand how different patterns work, what downsides they have and when to use them.

Advanced: Rich Hickey fan club.

Learn how GC works. Find a primitive algorithm explanation and understand it.

Learn how multithreading works, what is a race condition and how to prevent it. How a race condition can happen when dealing with I/O and with mutable variables.

Databases - what transaction is and how it works. What are the current types of databases (key-value storage, SQL, Object database, etc) and when to use them.

And the most important of all the references: The Kiss Principle.

Never stop learning

Add your own items to the list.

Learning can be even more fun you decide what to learn yourself.