20
loading...
The 10 Most Valuable Lessons I Learned As A Developer
This article was originally published on my personal blog.
I've developed software for over 21 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.
Especially at the beginning, I thought I could learn everything, and I thought this for a good portion of my developer career. But each time I learned something new, a whole new world of other 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.
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, 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'll see that you can get things done way faster than before, and you'll perhaps even enjoy it more.
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 clue what I did back then anymore. 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 actually 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'll 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 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.
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'll 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 put yourself under pressure. 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.
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.
Technology is such a large field that you'll 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.
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.
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'll probably notice how your performance degrades more and more before you take that break. When you return after your break, you'll notice that you're 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 stuff done. It turns out I would have finished way faster if I would've 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.
At the beginning of my professional career, I believed that I'd get rewarded if I put enough work in. 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 early 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 a connection.
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.
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 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 all 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.
I'd love to count you as my ever-growing group of awesome friends!
20