What I learned in over 10 years as a developer

2 hours ago 2
2025-06-17 12:12 CEST

It's crazy how time flies. I still think about the start of my career quite often. I just slipped into development, and I really, really like to develop software. As a rookie, you think you know everything, but that's not true. I had to learn many things over the years. Here is my short list of things I learned over the years.

Simplicity is the key to good software

"Clever" code is cool, but not "good"

Cool, you wrote in one line where others need 20 lines for. Nice, now only you understand the line. To be fair, you don't know what you've done, too. Now, there is this "clever" code in the project, which nobody understands and nobody will touch it for the next 30 years.

Gatekeeping is my passionate hate

Why the fuck do you intentionally don't write documentation or teach your coworkers how things work?! Are you scared that you lose your job?! I hate it - just to get it off my chest...

You're valuable

You're always valuable. It's just simple statistics: Sometimes someone is better than you, and sometimes you are better than someone else. It's statistically impossible that you're not valuable for the company.

Know your tools and the basics

Know how a computer works, know at least a low-level language (just the basics), and know the tools you use. It helps you to understand and determine specific bugs. Many developers are just googling error messages, and they paste the solutions they found. Don't be like them, try to understand the errors and you'll be able to fix the issues by yourself. This currently gets significantly worse through AI. You will be always ahead, if you take the extra mile to understand the issues.

Know the background

Customers don't know shit. It happened to me countless times that some user or customer wrote to me that he wants a function, followed by an exact documentation, how I should implement it. Mostly it was jack shit. Just explain what you want to achieve, and we'll do the rest. The user doesn't know the database, the programming language, and so on, don't trust them! The same belongs to user input :)

You can't know everything, it's ok to suck at some things

Many young developers are worried if they come to a new position. There are so many others, which just know "everything" or are better. Please set it in relation:

  • First things first: https://en.wikipedia.org/wiki/Impostor_syndrome - you are not alone, everyone thinks this about theirselfs at some time
  • You need time to learn. At first, you always know nothing at a new job.
  • Set it in relation: I met someone who just knew everything. He wrote better code than I, gave better answers in reviews, pointed out issues in seconds, and so on. He just was an insanely good developer. Someone I would never beat as a developer. He was just the 10x guy I would never outperform. After 1 year, I got to know him better personally. He just lives for this shit. He reads every paper he could find, he goes to meetups about programming, he has no friends, and he goes not out partying - he just lives for this profession. To know these things helped me a lot. E.g. I'm a father, have a wife, have a dog, have friends, family, and obligations. Next to my full-time job, I run a small company. Do you see the difference? I don't want to brag about money or my family or so on, I just want to point out that we live lifes that couldn't be more different. In fact, I could and will never outperform this guy because I simply do not have the time and, to be fair, do not want to spend the time this guy spends.

Reinventing the wheel is not bad

Timewise, yes, you should not reinvent the wheel, but you learn new things, and it's your code, you've written, and you know. So if you need new features, you could easily add them, and you must not read the code of others.

Sometimes, money is not everything

It happened to me two times. I changed my employer because another company offered me more, just to find out that my old employer was a better fit and the additional money I make at the new job does not pay the hassle off. Don't get me wrong, a change is mostly better for your career, but always calculate if the new wage is enough to even out a maybe uncool job or stupid coworkers.

Don't start your project with performance in mind

I built so many side projects. I couldn't count them anymore. A job platform, a document management system, a notification sender for new software releases, a wiki (offline desktop app), a social media platform, a gaming news site, and many, many more. Every time you think that's it, that's the final idea that works. But to be fair, maybe only 1% of your ideas have the potential to start through. Just build a small app that does what you want without 1000 microservices. Just build a small, simple app that you can work on at any time, and that brings you joy. I hear so often, "But what if your app gets big and you have performance issues?". Then fucking rebuild it, I mean then you have the money?!

Use the tools you already know

Every day on HN, I read about developers who evaluate every database and programming language to be the perfect fit for the project. I think that's not a good practice. Use the language and database you're already familiar with. The possibility is pretty high to get more issues with a complete new programming setup. If you want to tinker with a new programming language, that's perfectly fine.

No programming framework or language is "dead"

You've maybe seen articles that went like "Programming language XY is dead, learn XY instead". That's absolute BS. No programming language is dead. E.g. I worked for years with Coldfusion. You'll find nearly no one who is learning Coldfusion today as a new language/framework. I listed Coldfusion as experience in my freelancer profile, and I got really desperate offers. They wanted to pay me anything to keep their project alive. Or take a look at COBOL. COBOL is used heavily in the finance and logistics sector. IBM makes great numbers by selling their mainframes with native COBOL support, even today.

If you work remotely, give your coworkers a sympathy bonus

I have been working since 2021 full-time from home, and I'm quite happy with it. But I found out that I should give coworkers a sympathy bonus. It happened to me a few times, where I thought, "OMG this guy is such a jerk", only to find out that this exact person is very friendly and good to work with. Keep in mind that remotely you interact with people in very short time windows, and therefore you get their current mood. You don't know if they have private issues, if they feel sick, or many other reasons.

Set borders

At the beginning of my career, I had on my private phone always access to all of my work data. Emails, Chat, Trello - you name it. If you have these apps on your phone, then you are reading the messages. Keep your work away from your personal life, or you will always think about work, and at some point you will feel like you don't have any free time.

Documentation is great but hard to master

I heard very frequently the code is the documentation... I'm now at a company that offers many interfaces to different shop systems to automatically create invoices for orders. Sounds simple? I only say tax... We have so many different if statements and flags to calculate the tax. Now, try to read the code. It's simply not possible to understand what the code does because you must also understand WHY the code was written. I think documentation is really easy. I follow these simple rules if I write documentation:

  • Write documentation as exact as you can. Even if you think you piss off engineers because you wrote it too specific. Always think of yourself! If you already know something, then you skip a section, but if you need answers, and you don't get them, then you are pissed.
  • Include links you used to research things
  • Write things down you discussed with coworkers
  • AI is the key - I can't believe I'm saying this, but yes. E.g. notion, everything you write in notion is askable via their AI, and this works shockingly well.

Open source (FOSS) is cool but sometimes very toxic

Again, set borders. Users don't care if your software is free, they want to fix a problem, and they will constantly try to get you into free labor. Be very direct to them. Even if you produced a bug, you don't owe anyone anything - except they paid for it—but even then, you fix it if you have time.

Don't be afraid of servers

They don't bite. If you have just a basic understanding of Linux or, better said, hosting software, you're just so much more valuable. It just opens many doors for a reasonable time to learn in this field.

Read Entire Article