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”.

Until recently, I was using the wrong definition of Continuous Integration. You probably are, too. This is a bit of an embarassing mistake, at least for me, because I’ve heard the proper definition many times. And I talk about, and advocate for, CI, all the time. If you had asked me, I probably would have said something like “Automatically test your code, before it’s merged.” Interestingly, the simplest definition of continuous integration says nothing about testing—automatic or otherwise.

I’ve been writing computer programs since I was 8 years old. That’s more than 80% of my life. As such, I often dismiss certain tools or techniques as “beneath me”. Excel? That’s silly! I can write a CRUD app! AWS? Pfft! I can run my services on a pool of Raspberry Pis in my attic! Yesterday I set up Zapier for the first time. It’s definitely one of those “beneath” me tools.

Fellow reader Anita Kalmane asked: “What’s your opinion on having a separate team who is fixing bugs?” I want to share my response, slightly edited for brevity: I think it’s a terrible idea, except maybe as a VERY short term measure in an emergency. The three biggest reasons: It teaches the team producing bugs that “bug fixing is someone else’s problem.” It has the bugfix team working without proper context. Usually companies that do this put the “least skilled” (however they determine that) people on the maintenence/bugfix team.

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.

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:

I’m a big fan of meaningful commit messages. commit ef4d5ce5b6f13a3cc07f8941449bcaf445111cbf Author: Jonathan Hall <flimzy@flimzy.com> 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?

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

Any time you hear the word "DevOps" in a sentence, phrase, or title, replace it with the word "Cooperation" and see if it still makes sense.

If agile works for SpaceX, surely it can work for whatever big, complicated project you're on.

Don't take resistence to your great ideas personally. It could mean that you're onto something.