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.

Not everything can be automated. Or at least not yet. What can you do? Use a checklist!

Yesterday I expressed my view that we should “automate all the things”, especially tasks that have the potential for serious errors. What about driving? Self-driving cars are still under active development, and expert opinions vary, but I suspect that soon (probably within a decade), they’ll be much safer than human-driven cars. I might be wrong about that, but for the sake of argument, let’s imagine that I’m right. Let’s imagine that a wholesale switch to self-driving cars (if this were logistically possible) could cut car accidents in half.