20 Years in Software: What Stuck, What Faded, What Matters

I have been writing software professionally for over twenty years. I have seen frameworks rise and fall, languages gain and lose popularity, and methodologies cycle in and out of fashion. Some things stuck. Some faded. A few principles stayed constant. Here is what I would tell my younger self.

Code Is Communication

The most important function of code is not what it does for the computer. It is what it communicates to the next developer. Whether that developer is you in six months or a teammate you have never met.

I have spent hours debugging code that "worked" but did not explain itself. Cryptic names. Logic buried in nested conditionals. "Why did they do it this way?" with no comments, no tests, no history. The code ran. It was also a liability.

Write code that tells a story. Name things clearly. Structure logic so the flow is obvious. When someone asks "where does X happen?", the answer should be easy to find. Tests help. Good names help more.

Simplicity Wins

Every year, I find myself reaching for simpler solutions. The most maintainable systems I have worked on did less, with clear boundaries and explicit behavior. The ones that hurt did more: clever abstractions, generic frameworks, "flexible" APIs that could handle any case. Flexibility often means complexity. Complexity means bugs.

A concrete example: we had a reporting module that could generate "any report" through a generic engine. Config-driven. Powerful. It took three people to add a new report type. We replaced it with a handful of simple, report-specific classes. Each did one thing. Adding a report became a few hours of work, not a week.

Cleverness is the enemy of reliability. Simple code is easier to reason about, easier to test, and easier to change.

People Over Process

The best engineering teams I have worked with succeeded not because of their process, but because of their culture. Trust, psychological safety, and shared ownership matter more than any methodology.

I have seen Scrum implemented badly. Standups that dragged. Retrospectives that nobody took seriously. Sprints that felt like arbitrary deadlines. The process was "correct." The team was miserable. Compare that to a team that had no formal process but communicated constantly, helped each other, and took ownership of failures. The latter shipped more and broke less.

Process can help. It can also get in the way. Start with the people. Add process only when it removes friction, not when it adds it.

Learn to Say No

The hardest engineering skill is not a technical one. It is the ability to say no to features that do not serve the core product. Every feature has a maintenance cost that extends far beyond its initial development. It needs tests, docs, and support. It can block refactors. It can confuse users.

I have said yes to features that seemed quick. A "small" toggle. A "simple" export. They piled up. The codebase became harder to change. Saying no is uncomfortable. Saying yes to everything is expensive.

When a stakeholder asks for a feature, ask: does this align with our goals? Who will use it? What do we give up? Sometimes the answer is yes. Often it is "not now" or "not like that." Push back. It is part of the job.

Open Source Is a Superpower

Contributing to open source has been the single most impactful career decision I have made. It built my network, sharpened my skills, and gave me opportunities I could not have imagined when I started.

I did not plan it. I had a problem, solved it, and shared the solution. Others used it. They reported bugs, asked for features, and sometimes sent pull requests. I learned to write clearer docs, design better APIs, and handle feedback. The projects grew. So did the opportunities.

You do not need to maintain a huge project. A small library, a niche plugin, or a few solid patches to existing projects can be enough. Consistency matters. Ship something useful. Keep it maintained. The rest follows.

Stay Curious

The engineers who thrive over decades are the ones who never stop learning. Not just new technologies, but new problem domains, new perspectives, and new ways of thinking about old problems.

I have seen senior engineers who stopped learning. They knew their stack. They refused to try new tools. When the stack faded or the problem changed, they struggled. The ones who stayed curious adapted. They learned new languages, new paradigms, new domains. They stayed relevant.

Curiosity does not mean chasing every trend. It means being willing to understand. To read, to experiment, to ask "how does this work?" and "why did they do it that way?" That habit compounds.

What Faded

A lot of tech faded. jQuery dominated frontends; now we have React, Vue, Svelte. PHP was "just for scripts"; now it has types, async, and a mature ecosystem. Java applets, Flash, CORBA? Gone. The specific tech changes. The ability to learn new tech does not.

Methodologies fade too. Waterfall gave way to Agile. Agile gave way to "whatever works." The next thing will come. The principles (ship iteratively, get feedback, reduce risk) tend to stick.

What Stuck

Readable code. Testing. Clear names. Simple designs. Separation of concerns. These ideas were around twenty years ago. They are still right. The tools changed. The principles did not.

Collaboration. Communication. Empathy. Technical skill gets you part of the way. Working well with others gets you the rest. I have seen brilliant engineers who could not work in a team. I have seen solid engineers who elevated everyone around them. The latter built more.

Looking Forward

I am more excited about software engineering today than I was when I started. The tools are better. The communities are stronger. The problems are more interesting. AI is changing how we write code. Remote work is normal. The industry keeps evolving.

The engineers who will thrive are the ones who keep learning, keep shipping, and keep helping others. Twenty years from now, the tech will be different again. The principles will still matter.