Many senior programmers feel nervous allowing their project’s design to evolve in the hands of their co-workers. This article shows one specific example of how a useful abstraction and a small type hierarchy can evolve by following simple design guidelines that anyone can learn.

A software contract is not a legal contract, so let’s not treat it as one.

If you write a Spock test, but forget to subclass from Specification, then you might not notice the mistake.

Doing (test && commit) || revert amounts to doing TDD very carefully, as an étude. If you already routinely take tiny steps, then you already almost do TCR, but something significant might change if you do it exactly. This remains to discover. Join me.

I have a new Linux laptop and I wanted to run C# code. I had no idea where to start. I last wrote C# for money in 2004. It took me over an hour of hunting to figure out how to run a single test, so I decided to write a tutorial that could help someone else go from zero to NUnit with Visual Studio Code.

I got myself into trouble by installing rvm incorrectly. Reading a single article did not suffice to get myself out of trouble, so let this become the single article that you can use to get yourself out of trouble.

Programmers cling to integrated tests in part because of a feeling of security. I consider this a false sense of security, but it only seems fair to answer the common question of how I keep contract tests and collaboration tests aligned.

When it comes to organizing collaboration and contract tests, I don’t do anything special: I mostly follow the two elements of simple design.

I decided to learn some sed, because of its ubiquity and its power.

Every year I work with programmers who overcomplicate dependency injection. This causes stress and it influences other programmers to not even try this technique at all. I’d like to put your mind at ease with some advice to keep things simple.