20 Years of Code — What I Have Learned

A Look Back

Twenty years ago, I wrote my first professional code. PL/I on an IBM mainframe, at a bank in Austria. The editor was green on black, deployment cycles took days, and “agile” was a word nobody knew. Today I build AI-powered development environments and work with language models daily. Between these two points lie two decades full of mistakes, insights, and a few genuinely good decisions.

Here are the five most important lessons I have learned along the way.

Lesson 1: The Language Does Not Matter, the Thinking Does

Over my career, I have worked with PL/I, COBOL, C#, Java, JavaScript, TypeScript, Python, and various other languages. And the most important insight is this: the programming language is a tool, not an identity.

In my early years, I defined myself as a ”.NET developer.” I was active in C# forums, read C# blogs, spoke at conferences about C#. When someone mentioned Python or Java, I turned up my nose.

That was foolish.

The best developers I know do not think in a language. They think in concepts: data structures, algorithms, architecture patterns, system design. The language is the syntax they use to express these concepts. And learning a new syntax takes weeks, not years.

When I switched from C# to TypeScript, the hardest part was not the language — it was the ecosystem. npm instead of NuGet, Express instead of ASP.NET, different tooling. But the concepts? They were the same. Dependency injection is dependency injection, whether in C# or TypeScript.

My advice: learn concepts, not languages. And when you need to learn a new language, see it as a chance to expand your horizons, not as a threat.

Lesson 2: Ship Early, Iterate Fast

In my first job at the bank, a release cycle lasted six months. We planned for months, implemented for months, tested for weeks, and then deployed with bated breath. Most of the time, something went wrong.

Later, when I worked in the events industry, I had to learn to deliver quickly. Events have fixed dates — if the system is not running on festival day, there is no extension. That taught me to identify the minimum that must work, build it, and then iterate.

This lesson changed my entire thinking about software. Today I am convinced: the greatest danger in software development is not shipping something incomplete. It is shipping too late.

Every week I spend working on a feature without showing it to users is a week I might be running in the wrong direction. Feedback is the compass of product development, and without feedback I am navigating blind.

This does not mean quality is unimportant. It means the definition of “done” needs to change. Version 1 does not have to be perfect. It has to work, and it has to be in front of users quickly. Perfection comes through iteration, not through planning.

Lesson 3: Complexity Is the Enemy

When I look back at projects that failed — and there are some — they all had one thing in common: they were too complex. Not complex in the sense that the problem was complex, but complex in the sense that the solution was unnecessarily complex.

I remember a project in the logistics industry where we were supposed to build a simple tracking system. We implemented a microservices architecture with event sourcing, CQRS, and a custom message broker. For a system that was essentially a database and a few REST endpoints. The project took twice as long as planned and was barely maintainable.

The lesson: every architecture decision has costs. Microservices solve real problems, but they also bring real complexity. Event sourcing is elegant, but it makes debugging hell. CQRS is powerful, but it doubles the amount of code.

Today, for every architecture decision, I ask: “What is the simplest solution that works?” Not the most elegant, not the most scalable, not the trendiest — the simplest. And then I build that. If I need to scale later, I still can. But I do not build today for problems I might have tomorrow.

Lesson 4: DevOps Is Not a Job, It Is a Mindset

Early in my career, there were “the developers” and “the admins.” We wrote code and threw it over the fence. The admins deployed it and got up at three in the morning when it crashed. That was the model, and nobody questioned it.

Then DevOps came along, and at first I thought it was just a new name for system administration. It took years before I understood that DevOps is a fundamental change in mindset.

DevOps means that as a developer, I take responsibility for my code — not just that it compiles, but that it runs, scales, can be monitored, and can be recovered. It means deployment is not an event but a process. It means infrastructure is code.

This mindset has made me a better developer. Not because I can write Terraform files now, but because when writing code I already think about deployment, monitoring, and error handling. I write better code today because I know how it runs in production.

Lesson 5: AI Does Not Replace Developers, It Amplifies Good Ones

This lesson is the most recent, and I learn a little more of it every day. Since working with AI coding agents, I have noticed: the quality of output is directly proportional to the quality of input. A good developer gets brilliant results from an AI agent. A poor developer gets poor results and does not even notice.

Why? Because a good developer knows which questions to ask. They can specify the architecture, provide the context, evaluate the results, and steer the agent in the right direction. They use AI as a multiplier of their own abilities.

A developer who does not understand the fundamentals cannot judge whether the AI output is good or bad. They accept code that works at first glance but has security vulnerabilities, does not scale, or is unmaintainable.

My conclusion after twenty years: invest in your fundamentals. Understand data structures, algorithms, system design, security. Learn to think clearly and communicate clearly. These skills will never become obsolete, and with AI they become more valuable than ever.

What I Hope for the Next 20 Years

When I look back at this article in twenty years, I hope I can say: the best years were still ahead of me. Software development is a field that constantly reinvents itself, and that is exactly what makes it so fascinating. From mainframes to cloud, from waterfall to agile, from manual programming to AI-assisted development — each era has opened up new possibilities.

I am excited about what comes next. And I am grateful for every lesson I have learned along the way.