I’ve been programming for over 20 years. What has changed, and what has stayed surprisingly much the same

If you develop software for long enough, you eventually collect technologies that were once considered the future and now only turn up in old project folders.

Development environments disappear. Frameworks become indispensable and later become “legacy”. Programming languages rise in importance, fade away or make a surprising comeback years later.

In many ways, software development today looks completely different from the work I started my career with.

And yet a surprising amount has stayed the same.

Many things have become faster

The most obvious difference is the tools.

Today, I can set up a project, install dependencies, run tests and produce a build in a matter of minutes. Version control, automated builds and package management have become standard practice.

The toolchain now handles many tasks that used to be manual work.

That is enormous progress.

Finding information has changed too. Books used to sit next to the monitor. Today, documentation, source code, forums and now AI assistants are only seconds away.

As a result, the distance between an idea and a first working prototype has shrunk dramatically.

That does not automatically mean good software is created faster, though.

We can build mistakes faster

This may be one of the less romantic lessons from many years of development.

Tools make developers more productive. They do not automatically make us wiser.

Modern frameworks let you build impressive applications in a very short time. They also let you create an architecture just as quickly that nobody wants to touch six months later.

Productivity multiplies bad decisions too.

The more powerful the tools become, the more important it is to distinguish between a quick solution and a good one.

And sometimes the quick solution really is the good one.

Architecture is still about consequences

Technologies change. The fundamental questions of architecture change surprisingly little.

Where do responsibilities lie?

Which parts may depend on one another?

Where is data stored?

What happens when something fails?

Which decisions can still be changed later, and which will become expensive?

You can use modern terminology for this and draw impressive diagrams. In the end, it always comes down to consequences.

To me, an architecture is not a work of art. It is a collection of decisions that make future changes easier or harder.

Little has changed about that.

Users are not a testing department

That is timeless too.

Software that works technically can still be bad software.

A dialogue can be programmed correctly and still be confusing. A process can meet every requirement and still take ten clicks too many.

Developers inevitably see applications differently from their users. We know the data model. We know why a button is there. We understand what an option means.

The user knows none of that.

Taking that perspective was important then, and it still is today.

Perhaps even more so, because modern software has more and more features, giving it more opportunities to become complicated.

Boring code wins surprisingly often

I used to be fascinated by particularly clever solutions.

These days, I am more often pleased by code I can reopen after six months and understand immediately.

That is probably a fairly typical progression.

Clever abstractions feel good during development. Understandable structures feel good during maintenance.

And software usually spends considerably more time in maintenance than in its initial development.

That is why “boring” code has earned a pretty good reputation with me.

Trends are useful, but they are not an architecture decision

The IT industry loves new terminology.

Every few years, technologies appear that supposedly solve almost every problem. Then come conferences, books, consulting services and, of course, architecture diagrams with a great many arrows.

Some of these developments really do change a lot.

Others mainly solve problems that smaller projects do not even have.

Experience may not make you less curious, but it makes you more selective.

I want to understand new technologies. That does not mean I have to use them everywhere.

To me, the most interesting question is not: is this modern?

It is: what specific problem does it solve here?

Error handling remains unpopular and important

The happy path is usually quick to program.

Open a file. Load data. Start processing. Save the result.

Things get interesting when the file is locked. When the network fails. When a process is cancelled. When data comes from an older version.

These cases were a nuisance twenty years ago, and they still are today.

Only users’ expectations have risen.

Good software may react in complex ways internally. On the outside, it should remain calm.

This is another of those things that hardly anyone notices as long as it works.

AI is new. Responsibility is not.

AI tools are changing software development very noticeably right now.

They can explain code, generate alternatives, suggest tests and greatly speed up routine tasks.

I find that exciting.

But they do not change one fundamental thing: somebody has to decide whether a solution makes sense.

Producing code was never the only part of software development.

Understanding requirements, assessing consequences, designing architecture, considering security and taking responsibility for decisions are just as much a part of it.

The tools are getting better.

The responsibility remains.

Experience does not mean knowing everything

Over the years, you learn more patterns. You recognise some problems earlier and have probably made a few mistakes yourself that you can warn others about.

At the same time, you become more aware of how vast the field really is.

Nobody has mastered “software development”.

There are too many platforms, languages, domains and specialisms for that.

To me, experience therefore shows less in having an immediate answer.

It shows in asking the right questions earlier.

The fundamental questions remain

When I look at the changes of the past few decades, I actually find that reassuring.

We have better editors, better libraries, better infrastructure and now tools that would have sounded like science fiction just a few years ago.

Yet good software development still begins with fairly simple questions.

What problem are we solving?

For whom?

What really needs to work?

What complexity is necessary?

What happens when something goes wrong?

And will somebody else still understand this code later?

The answers change.

The questions change surprisingly little.