I Should Start a Blog

I Should Start a Blog

Twenty years in software — it was time to write some of it down

By Roger Rajaratnam 26 March 2026

I’ve said “I should start a blog” more times than I’d like to admit.

For years it existed as a vague intention — something I’d get around to once I had more time, once I had the perfect thing to write about, once I’d figured out exactly what my “niche” was. The usual excuses. The usual friction.

The thing is, I’ve been doing this job for over twenty years. I’ve worked across fintech, media, non-profits, and everything in between. I’ve mentored engineers, taught at bootcamps, led teams through big architectural decisions and painful rewrites. Somewhere along the way I accumulated a lot of opinions, patterns, and hard-won lessons — and almost none of it has been written down anywhere anyone else can read it.

That bothers me now more than it used to.

What changed

Teaching did it, honestly.

Running bootcamp sessions for The Jump Digital School forced me to take things I’d internalised and make them legible. When you have to explain why something works, not just that it works, you understand it differently. You catch the gaps in your own thinking. You realise how much of what you “know” is actually just vibes and pattern recognition that you’ve never had to articulate out loud.

Those sessions reminded me that I like explaining things. I like finding the clean way through a confusing concept. I find it genuinely satisfying when something clicks for someone.

A blog is that, scaled up slightly.

The other thing that pushed me over the line is AI. Not because I think it makes writing less relevant — quite the opposite. The more capable these tools become at generating code, the more important it becomes to understand what good code actually looks like, and why. AI amplifies whatever understanding you bring to it. An engineer who can’t evaluate the output is just a faster way to ship the wrong thing. The knowledge worth preserving isn’t the mechanical kind. It’s the judgement. And that has to come from somewhere.

What I want this to be

Not a content calendar. Not a personal brand exercise. Not SEO-optimised articles with H2s engineered for search intent.

I want this to read like how I actually talk to other engineers — direct, with opinions, willing to say “this is complicated” rather than flattening nuance into a listicle. More like a long conversation than a documentation page.

The topics will mostly come from wherever my head is at. Engineering. Architecture. Technical leadership. The weird in-between space of being someone who codes and also has to communicate about code to people who don’t. Occasionally something completely unrelated if it feels worth writing.

I won’t pretend I’ll post on a schedule. That’s historically not how I work. But I will actually post, which is already an improvement on the previous arrangement.

How this will be different

A lot of engineering blogs stop at the code. Here’s the snippet, here’s the library, copy and paste. There’s nothing wrong with that — but it doesn’t explain the thinking that led there.

I’m more interested in the decisions. The trade-offs. Why this tool over that one, and what you give up either way. What the design is actually trying to communicate, not just how to implement it. When the clean abstraction is worth the added indirection, and when it’s just complicating something simple.

That’s because writing clean code is only part of what it means to be a good engineer. The rest is judgement — knowing what to build, how to structure it, when to push back, and how to bring other people along with you. That part rarely gets written down. It tends to stay locked in the heads of people who’ve been around long enough to have made the same mistakes a few times.

So that’s what I’m aiming for here. Less “here’s how to do the thing” and more “here’s why this is the thing to do, and here’s what it cost us to find that out.”

The site itself

I built this with Astro — partly because it’s genuinely excellent for content-focused sites, and partly because I wanted an excuse to use it properly. It’s fast, it renders mostly static HTML, and the content layer is exactly as flexible as I needed it to be. No regrets there.

It’s also pleasingly simple to maintain. The posts live as Markdown files in a collections/ folder. There’s no CMS, no database, no admin panel. Just files, which is how I like it.


Anyway. Hello. I’m Roger. I’ve been in software for a long time and I’ve finally decided to write some of it down.

Let’s see how this goes.

Free · No spam · Unsubscribe any time

Get new posts in your inbox

When the next article drops, I'll send a short note — a link and a summary, nothing else. One email per post.

Did you find this useful?

Comments

Loading comments…

Leave a comment