Henrik Jernevad

A note to self and whoever needs to hear it.

If you’re building a service that will eventually run multiple instances, this article is for you.

Ever been handed a legacy system whose dependencies haven’t been touched in a decade—and then been asked to upgrade it?

Software survives by being easy to replace.

Would you consider these behaviors professional?

A good architect builds the system that the client needs, not the one they want to build.

AI-generated code often looks impressive at first, but then it drifts: it ignores conventions, duplicates logic, breaks architectural constraints, and assumes things that aren’t true.

AI promises to speed up software development by taking away the grunt work, making us all 10x programmers.

The goal of software architecture isn’t to specify all the details, but to describe a solution space in which teams are free to move.1 It is similar to how a nautical chart provides sailors with the information needed to navigate safely toward their desti…

General relativity is Einstein’s theory that describes gravity not as a force but as the curvature of spacetime caused by mass and energy.

I’m working on a new ad for OpenAI’s new AI browser.

I recently read a pitch for AI-supported, spec-driven development.

This is my now page where I give semi-regular updates on what is going on in my life.

Have you ever solved a problem, only to face it again six months later—familiar, but with no memory of the solution?

Do you enjoy long, rambling texts that take forever to get to the point?

I’m a recovering perfectionist.

A team needs some spare capacity to deliver at full potential.

Software projects often suffer from silos—frontend and backend teams working in isolation, discovering mismatches only late.

Does your team work on many things but finish few?

I believe a team works better with a “sense of purpose” than a “sense of urgency”.

How can you write technical documentation that is clear, informative, and even fun?

When handed a problem to solve, do you allow yourself to explore different solutions?

Let’s say you’ve just finished a major software project that took a year to complete.

Argh!

You have an idea for a blog post.

Last week, I found myself stuck in a “code hole”.

Everything you do, no matter how perfect it may be, will sooner or later cease being perfect and eventually be worthless.

I believe that all systems eventually collapse under their own weight.

Hi, my name is Henrik and I am a perfectionist.

Reading Lars-Christian Simonsen’s blog, I stumbled upon the following comment by Rachel J.

These are my answers to the blog questions challenge, inspired by Glyn and Lars-Christian.

To write is human, to edit is divine.

If you’re giving feedback, be descriptive, not prescriptive.

For a long time, I’ve had a preference for expressions that result in a value over statements that cause a side effect.

Kotlin is a very nice language to write backend code that is expressive and concise, yet clear and readable.

I’ve been reading the book On Writing Well by William Zinsser.

This post will go through my favorite technical questions to choose from when interviewing software developers for a “backend-ish” role.1 They are not a checklist of things that the candidate must know (nobody knows everything), but a way for me to get a…

Lutefisk, a dish made from dried fish cured in lye, is often served on Christmas in Sweden.

Developers are very good at finding solutions to problems.

One year ago, I decided to start blogging again.1 Why?

I wonder how many people participants in the popular coding competition Advent of Code have Copilot turned on.

Over the the last months, I’ve been learning Go through a hobby project called Laebel.1 I recently reached a point where it was more or less finished.

This year, I’m participating in Advent of Code for the first time.

I want to talk to interesting people (like you).

Here’s a recent insight I had about unit testing.

I’m a big notebook fan.

Replacing real dependencies with test doubles1 is a helpful tool when building unit tests.

I’ve been developing software for a pretty long time.

Sometimes when you make a change, it ends up changing you.

I like to treat every support issue as bug.