Software that works.
In production.

Fast and accurate: testing the same contract two ways

A Javalin-based REST server for a Gold Mine game, demonstrating a test architecture that runs the same tests both in-memory and over the network.

Two kinds of developers

I have worked with a lot of developers over the years. Over the years, I have noticed a pattern. Some developers light up when they talk about the internals of a programming language. A new feature in the type system, a clever way to handle concurrency, an elegant pattern they discovered. The technology itself is what drives them.

Other developers are different. They care less about how the language works under the hood. What gets them going is the customer's problem. They want to understand what hurts and build something that makes the pain go away. The programming language is a tool. A means to an end.

Testing in 2026: more relevant than ever

Coding assistants generate code faster than ever. A feature that used to take a day can be roughed out in hours. The typing is nearly free.

You might wonder why you should still bother with tests. If the assistant can produce code that fast, surely it gets it right. That misses the point entirely. Tests were never about catching typos. They are about defining what the software should do and making sure it keeps doing it.