Coding Practices —2 min read
Making a mockery of mocking

Unit testing and TDD are all the rage. This is a good thing! Not long ago, most conversations I had about testing turned into a battle of philosophy about whether testing should happen. Nowadays, it seems that battle has been largely won. But as soon as you solve the big problem, the smaller problems start to show up. And that brings me to today’s “small problem”: The mockery that is “mocking”.

Coding Practices —1 min read
Tabs vs. Spaces

Tabs or spaces? I like to ask this cliché question during technical interviews. How would you answer? Most people nerviously laugh, and then try to lightly defend tabs, hoping I’m not a spaces guy. Or the other way around. The truth is, I don’t care about tabs or spaces (although spaces are clearly superior!) In my book, the correct answer is, “Don’t argue about it. Use a linter.” This, and so many other style debates, are just a waste of time.

Coding Practices —1 min read
Comments are like apologies to the next programmer

Comments are like apologies to the next programmer. — Unknown I saw this quote today in an online forum. I love it! I have long reeled against comments in code. That’s not to say they’re never useful. It’s just that 95% of code comments are worthless, or even worse. But if this is true, then what are comments apologizing for? Hard-to-read code. // Determine the shipping rate var s = 15; if ( p >= 100 || q >= 5 ) { s = 0; } A little refactoring can avoid the need to apologize with a comment:

Coding Practices —1 min read
Why bother with "git hygiene"?

I’m a big fan of meaningful commit messages. commit ef4d5ce5b6f13a3cc07f8941449bcaf445111cbf Author: Jonathan Hall <> Date: Thu Feb 11 10:35:34 2021 +0100 bugfix just doesn’t cut it. I’m also a big fan of git rebase instead of git merge, fixup and ammend, and a whole host of other git tricks to keep my git history pristine and readable. But why? I rarely find myself doing git archeaology, so why fuss with all this?

Coding Practices —1 min read
Reducing “value”

How much value does your code provide? And how closely is that value related to the amount of code?

Coding Practices —11 min read
6 ways to RUIN your logging

Edited by Mitchell de Rijcke I’m knee-deep in some log refactoring on my current project, which is something that I’ve done now on several projects. This is one of my favorite ways to become familiar with a new code base, since it typically touches all of the code. As I do this on new projects, I’m consistently faced with many of the same frustrations, which I have decided to catalog here.

Go Programming —13 min read
How to Use Nancy to Improve Your Go Application Security

Nancy, as you may know by reputation, is a detective. She uses Sonatype's OSS Index to check for vulnerabilities in your Go dependencies.

Coding Practices —8 min read
Reader Question: TDD Reading List

This post was edited by Taavi Kivisik A reader recently sent me this question: I'm getting quite serious with programming. I finished reading Clean Code and am doing a course about design patterns, nerding out on Node.js, etc. I have to say it's quite amazing to realize the level of sophistication and effort involved to make quality software. It makes me really appreciative working with engineers who are capable of working on that level.

Software Delivery —9 min read
These Days Proper CI is Table Stakes

There is a lot of variety when it comes to Continuous Integration and Continuous Deployment (CI/CD) configurations. But I am constantly amazed by how many projects fail to even implement the absolute minimum CI configuration. In this article, I outline what I believe to be the absolute, bare minimum automated continuous integration tests that should exist on practically every project. These are table stakes. You ought to be embarrassed if your project doesn’t do these things.

Coding Practices —8 min read
Say Farewell to Forgotten Cleanups

How often do you find some code like this in your production code base? form.submit(function(event) { console.log("Submit hit"); var formData = { It’s obvious case of stray debugging code that never got cleaned up during code review. Or have you ever seen something like this, perhaps in your CI config? script: # - npm install # - npm test - ./script/ This one is especially dangerous. It appears that someone commented out the core functionality of the automated test stage of CI!

Go Programming —10 min read
Simple Go Mocks

Go’s interfaces and “duck typing” makes it very easy to create simple mock or stub implementations of a dependency for testing. This has not dissuaded a number of people from writing generalized mocking libraries such as gomock and testify/mock, among others. Here I want to describe a simple alternative pattern I frequently use when writing tests for an interface, that I think is generally applicable to many use cases. No Silver Bullet Of course neither this approach, nor any other, is a one-size-fits-all solution.