Seven years of code — and why it gets better every year
A short, honest checkpoint: what changed in my engineering day-to-day since 2017, what I do differently from 19, and what I keep telling beginners.
In 2017 I was 19 and writing Minecraft plugins that almost never worked when I wasn't looking at them. Today, seven years later, I write software that runs without me. Between the two sit not just experience — but a handful of habits I wish I had picked up earlier.
What I underestimated most
At 19 I thought the difference between a good and a bad developer was knowledge. Whoever knows more frameworks wins. Today I know it lives in writing style — in whether you can write code so the person reading it in two years (usually you) doesn't need an hour to figure out what it does.
Sounds banal. But it's what I write in almost every code review now.
Three habits that changed everything
One: I write tests before refactoring. Not TDD in the strict sense — more like a safety net. Before I touch a larger change, I build a test that locks in the existing state. Then I'm allowed to break whatever I want. That tripled my refactoring speed and cut my refactoring fear to zero.
Two: I write Architecture Decision Records. One markdown file per load-bearing decision, three paragraphs: context, decision, consequences. I need that note four years later — when I or another developer sits in the codebase wondering "why did they build it this way?". The answer is right there.
Three: I ask "do you really need this?" more often. At 22 I would have built every wish a client expressed. Today I look at the requirement, think about maintenance over the next two years, and sometimes say: "We can build this. But do you really want to? Here's a smaller version that solves 80% of the problem with a third of the code." That question has built more trust than any technical demo I've ever given.
What I tell beginners
If someone starts at 19, the way I did, the most important lesson is: ship something that works, and ship it early. Don't wait for the perfect stack, the perfect setup, the perfect understanding. Ship a plugin that does one thing. Ship a one-page website. Ship a pull request with one commit.
The people you want to learn from aren't the ones who know a lot — they're the ones who have shipped a lot.
And once it's shipped: write about it. Even if only three people read it. Writing forces understanding. Those three paragraphs that feel awkward now are, two years from now, what brings you a lead you would never have gotten otherwise.
Why it gets better every year
At 26 I'm only really finding software development interesting. The first few years were endless catching up — new languages, new frameworks, new patterns. Today a lot feels familiar, and exactly because of that I can stop being the permanent beginner and start choosing what I bring into a project.
That's the difference between a junior who installs every new tool and an engineer who knows why he skips 80% of the hype stack. Both write code. Only one leaves behind a codebase that's still maintainable in five years.
On to the next seven.