Why I Started Writing After 13 Years in Software Development

Introduction

Thirteen years is a long time to do anything.

Long enough to watch JavaScript go from "that thing for dropdown menus" to the backbone of production backend systems. Long enough to see monoliths get broken into microservices, then watch teams quietly stitch some of them back together. Long enough to understand that the most important engineering decisions are rarely about the code itself — they are about the tradeoffs you accept and the consequences you inherit.

After more than a decade of building, debugging, refactoring, and shipping software, I started writing.

Not because I ran out of things to build. But because I realised how much engineering knowledge never makes it out of Slack threads, late-night debugging sessions, and post-mortems that only five people read.

What 13 Years Actually Teaches You

In the early years, the focus is on learning the tools.

You learn the syntax. You learn the frameworks. You learn how to get something working. You measure progress by whether the feature ships.

Over time, something shifts.

The questions change.

You stop asking "does this work?" and start asking "what happens when this breaks at 3am under ten times the expected load?"

You stop choosing a technology because it is popular and start choosing it because you understand what it costs you — in complexity, in team knowledge, in operational overhead — not just what it gives you.

You learn that the systems that cause the most pain in production are rarely the ones written badly. They are usually the ones written for a reality that no longer exists.

That kind of understanding does not come from documentation. It comes from experience — and experience is only useful if it is shared.

Why I Started Writing

Most engineering knowledge is buried.

It lives in undocumented production decisions. In architecture diagrams that never made it out of someone's notebook. In the reasoning behind a database schema that three teams have since worked around without knowing why it exists. In the lessons learned from an outage that only the people who were on-call that night will ever fully understand.

When engineers leave companies, that knowledge leaves with them.

When teams scale, context gets diluted.

When junior developers join, they inherit systems without the history that explains them.

This blog is my attempt to change that — at least for the knowledge I can put into words.

I write about the things that took me years to fully understand. The things I wish someone had written down clearly when I was starting out. The things that make the difference between software that holds up and software that slowly becomes everyone's problem.

What This Blog Covers

The focus is practical engineering — not theory for its own sake, but concepts connected directly to how systems behave in the real world.

That includes:

System design and architecture — how to think about structure before you write a line of code, and how to evolve that structure as requirements change
Backend and API development — building services that are reliable, observable, and maintainable under real conditions
Full-stack application design — how the frontend and backend decisions affect each other more than most people plan for
Infrastructure and deployment — because how you run software matters as much as how you write it
Technical tradeoffs — the honest conversation about what you gain and what you give up with every major decision
Production lessons — what actually happens when systems meet real users, real load, and real failure

Some posts will be deep technical dives with diagrams, code walkthroughs, and step-by-step breakdowns. Others will be shorter reflections on engineering decisions and the reasoning behind them. All of them will be written with one goal: to be genuinely useful to someone building real software.

Who This Is For

If you are early in your engineering career, this blog will help you build mental models that go beyond syntax — the kind of thinking that separates engineers who can write features from engineers who can design systems.

If you have been in the industry for several years, you will probably recognise the situations I write about. My hope is that seeing them analysed and written down clearly adds something useful — a new angle, a sharper framework, or simply the reassurance that the hard problems you are dealing with are not unique to you.

If you are a senior engineer or architect, I welcome the pushback. Engineering is a field of tradeoffs, not absolutes. The best conversations are the ones where experience meets disagreement.

What You Can Expect

Consistency over volume.

Each post is written to be worth the time it takes to read — structured, specific, and grounded in real systems rather than idealised examples.

The content will evolve as the field evolves. Software engineering in 2026 is not the same as it was five years ago, and it will not be the same five years from now. This blog will reflect that.

There will be technical deep dives. Architecture breakdowns. Honest retrospectives on decisions that worked and decisions that did not. And practical explanations of concepts that matter in production but rarely get explained clearly in official documentation.

A Final Thought

The engineers I have learned the most from were not the ones who knew the most. They were the ones who could explain what they knew clearly — and who were honest about what they did not know.

Writing forces that kind of clarity. You cannot hide vague thinking behind confident delivery when the words are sitting on a page.

So this blog is also, in part, a discipline. A commitment to thinking carefully about what I know, how I know it, and whether I can explain it in a way that is actually useful to someone else.

If even one post helps you make a better architecture decision, avoid a production mistake, or understand a concept that was previously fuzzy — that is enough.

Thanks for reading. I hope you come back.