Oliver Jumpertz
hero image

The 10 Most Valuable Lessons I Learned As A Developer - 23 Years Of Programming Experience Distilled

Share this post to:

I have developed software for over 23 years now, which is way over half of my lifetime, both professionally and as a hobby.

Here are some of the most valuable lessons I learned along the way.

1. You will never know everything

Especially in the beginning, I thought I could learn everything, and I thought this for a good portion of my career. But each time I learned something new, a whole new world of different concepts and techniques opened up.

It may seem tempting to try and learn it all, but it’s a never-ending endeavor. There will always be another library or framework and another cool thing you could also learn.

The only thing that happens is that you slowly start to burn out because you seem never to reach your goal. Better settle on what you know well and learn on-demand when you really need to learn something new. This keeps you sane and your motivation up.

You can also transfer this to any other domain. It’s possible to be effective without knowing everything. Use this to your advantage, learn along the way when necessary.

2. A good team doesn’t scale your capabilities linearly but exponentially

Working on your own is fine, but it also leaves you in your own capacity.

A good team, however, that you can always talk to and discuss with, can leverage your thought process a lot. Issues become easier to solve and problems better to tackle. The effect is usually exponentially and not only linearly in my experience.

There is a threshold, though, at which a team becomes too large. In my experience, this threshold depends on the people involved.

Try to surround yourself with amazing people you can get along with pretty well, also on a personal level. You will see that you can get things done way faster than before, and you will perhaps even enjoy it more.

3. Code should be written for humans

There was a time I felt so clever to write highly optimized code that ran as fast as possible. Whenever I revisited this code after a long while, I had no more clue what I did back then. It always took me a good portion of my time to get back into the code before doing the work I actually came for. Even worse: 99% of the time, those optimizations were unnecessary.

Code should first and foremost be written for humans to read and understand. If you believe that a certain code path might be a performance bottleneck, then test it. Add metrics to measure the execution time for the paths in question and analyze them later.

You will usually find out that the code in question is actually not the problem. More often than not, you find that the problem is something completely different.

If some code is really the issue, please add as many comments as necessary to explain why this code is optimized. If you need to explain what your optimization does, do it.

You will often catch comments from people stating that you should never state “what” code does. Here is my take: If you can’t make it more understandable and know that other developers will need help understanding it, add those comments.

You can either listen to people evangelizing against this approach and spend more time and money on a future issue, or ignore them and ensure that everyone has a chance to get into and work on it. Teams are individual. Act accordingly.

4. Patience is your best friend

There was a time I wasn’t patient, and I still suffer from this sometimes.

It regularly takes time to solve a bug or complete a feature. And often, learning something new takes longer than anticipated.

If you really feel the need to hurry, you should ask yourself what the reason for this feeling is.

Is it yourself? Please stop it. You can still finish tomorrow or the day after tomorrow. Then, the next time you have to solve a similar issue, you will be faster.

If it’s your employer, you should definitely think about whether this is the right company for you.

There are many managers out there who think the faster software is delivered, the better. They set unrealistic deadlines and expect too much from their developers. Those managers have understood nothing about how software development works.

Sometimes you are confronted with something completely new. It takes time to come up with an idea. The more experience you get, the better you become at dealing with such situations.

Try to stay patient and don’t pressure yourself. You work better when you can stay calm and order your thoughts to develop an idea. And it will definitely benefit your mental health.

It can be the most difficult thing on earth to not pressure yourself, and you won’t always keep yourself from doing it. That’s okay. You should still do your best to prevent yourself from doing it, though. It can harm you for a long time.

5. Consistency is key

Doing something consistently over and over again is what helps you to become proficient in it. It’s not about putting 20 hours in once. It’s about 15 minutes or an hour each day you put in.

The repetition you do over and over again is what makes you better at what you do. You first look up things frequently, and slowly but steadily, you have to look up less and less. This is your brain slowly learning patterns and saving them for later use.

Even after you have learned something, you can’t allow yourself to become less consistent. Not all knowledge is like riding a bike (and never fades). Some knowledge just fades over time, especially if you don’t use it regularly. If a certain piece of information is important for your job but you just don’t need to use it often, you will have to spend some time regularly to make sure to revisit it.

6. There is always someone better you can learn from

Technology is such a large field that you will never learn everything.

Other developers have learned different things than you. This puts them at a knowledge advantage in certain things. Use this to your own advantage.

Your colleagues might be better at backend, CSS, or low-level stuff than you while you have your own strengths. You can learn from them, and they can learn from you.

This is never something you should be jealous about or take to your heart. It’s actually awesome that you can make connections to people that can enrich your knowledge. You get years of experience you can profit from to increase your knowledge. And you also get years of failure to learn from, so you don’t have to make the same mistakes.

7. Networking is important

Get out and find people to connect with. This is so important today.

I thought that having a great CV would open all the doors for me, but boy was I wrong.

If people don’t know you, they will judge you based on a piece of paper. But if people know you, they are probably aware of your strengths and weaknesses. This makes it so much easier to get your next job or contract. And it always opens up opportunities for learning, work, and interaction.

Especially today, you are more likely to get a job through personal connections than through sending your CV to a random company. Often, these personal connections make the interview process easier, because they can vet for you.

If you don’t like being employed, networking can still help you. Often, you find quite a few customers by connecting with people without any intent. By simply speaking with them, you usually find out that they have a few problems you can solve for them (either with a product, or with a service you offer).

8. Frequent breaks make you more effective

As long as you don’t hit “the tunnel”, that state where you can simply go on coding or working without even noticing time passing, your brain will need frequent breaks.

A break helps your brain to recharge and process the information it previously consumed. You basically enable it to catch up. Do something completely different. Go, get a coffee, take a short walk, but at least somehow leave your work desk.

You will probably notice how your performance degrades more and more before you take that break. When you return after your break, you will notice that you are back at it. You can perform again until your next break.

There were times I didn’t take care of breaks because I wanted to get my work done or whatever I was doing. It turns out I would have finished way faster if I would have let my brain rest for a little every once in a while.

A good rule of thumb is at least a 5-minute break each hour and a longer one of up to 30 minutes after 4 hours. Even better: Listen to your body and adjust your breaks accordingly.

If you begin to feel tired, see your performance degrade, or have problems concentrating, take a break.

9. If you want to advance further in your career, you need to be a people person

At the beginning of my professional career, I believed that I would get rewarded if I put in enough work. As it turned out, at least for me, this was not the case. No one came to me to offer me a promotion or more money. I felt I simply went on unnoticed.

The moment I became vocal about my work and started to interact more with my peers and managers, my career took off. If there was a problem that somehow suited me, I could be sure to get the task assigned. I became known for certain things and was frequently asked for support, and I got promoted. I didn’t have to make a lengthy list of my accomplishments for my yearly performance review anymore. My manager already knew everything.

Why? Because I talked about work with my colleagues and managers frequently. I never bragged. I made statements and openly helped my colleagues. And I also talked a lot with people on a private level. We got to know each other better and formed connections.

At least for me, it worked out perfectly. Your experience might differ because it highly depends on the company and culture, but it might be worth a try.

10. Most companies are not what you expect them to be

When I finally got to work professionally, I had unrealistically high expectations of how it would be. I imagined working with top-tier engineers, technologies, and always on awesome problems. As it turned out, I was wrong.

Don’t get me wrong, the engineers were still awesome, but simply not how I had imagined them to be. The technologies we worked with were nearly boring. The problems were not so awesome.

I learned that all engineers make mistakes and don’t know everything. They are human, after all. And the technologies were usually exactly the right ones to tackle the problems we worked on.

The more boring a technology is, the better it helps to solve certain problems.

Software is made to solve problems. Some of those are more boring than others. Not every developer can constantly work on software that is going to change the world. Often, that small frontend that makes someone’s life a little easier or the API that moves files from A to B is what makes your employer money.

The important thing to realize is that not all companies can work at a scale that FAANG companies do. And even there, problems are tackled that sometimes seem boring.

Another important takeaway: There are many developers like you out there. You will make your impact, and not all your colleagues will be as top-tier as you imagine them to be. They are normal developers who do an insanely good job and know as much as you do.

Share this post to: