I was recently talking to the head of engineering at an IT infrastructure company. During the conversation he casually said “We don’t believe in automating processes that could result in serious errors.” My jaw dropped. To my mind, his approach is utterly backwards. All else being equal, critical processes—those where errors are potentially the most catastrophic—should be the first to be automated. Why? Because humans make mistakes all the time. (Working) computers never do.

Today I want to let you know that I'm changing the format of my mailing list.

Not long ago, the idea of a one-button software build was novel. Now it seems blasé and continuous deployment takes that concept to the next level.

Yesterday Kief Morris published a thought-proviking article, Why your team doesn’t need to use pull requests. The central thesis is that pull requests introduce a harmful human delay into the software delivery process, and that there are better alternatives. This promise excited me, as I read the introduction to the piece. But I found that the proposed solutions left me with more questions than answers. The post generated a lot of knee-jerk reactions on Twitter, my own among them:

Kuberentes is all the rage. All the cool kids are doing it. It’s the hot newness for scaling enterprise-scale applications to unbelievable heights. But does it make sense for smaller teams? In the words of every professional consultant everywhere: “It depends.” Kubernetes absolutely can be a big win for many small teams (even solo projects). But that doesn’t mean it’s right for everyone. Here I touch on the most important drawbacks to Kubernetes, as well as the most important benefits, to help you weigh the decision for your own team.

I have a funny habit. Well, I guess it’s a funny habit. I never thought of it as funny. Then people started pointing it out to me, and asking why I did such a funny thing. A little over a hear ago, this funny habit came up during a job interview: “It’s funny how you make pull requests for your own projects on GitHub.” Yes. That’s right. My funny habit is that, even on solo projects (and yes, even the private ones I never publish), I create pull requests.

Your GitHub profile is the centerpiece of any modern engineering CV. Here are some tips to help make yours stand out.

Kent Beck is a very accomplished software engineer, with seminal contributions to the industry since the mid 1990’s. He’s credited with inventing (or re-discovering) Test-Driven Development (TDD). He’s the creator of jUnit, and several other xUnit suites. He’s the creator of extreme programming (XP) and the author of the authoritative book on the subject: Extreme Programming Explained, as well as many other books. Yet with all of these accomplishments, any one of which could make the average programmer envious, he claims he’s not a great programmer.

There are countless configuration file formats. Some are custom-designed for a specific application, such as those used by the Apache web server or BIND. But more commonly these days, new applications use some sort of standardized configuration file format, such as YAML, JSON, XML or INI. Some applications, such as WordPress even use executable code as configuration files. Most modern languages have libraries that will let you read (and in some case write) to a wide variety of configuration formats.

Edited by Mitchell 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. Most projects I see make at least several of these mistakes, some make all of them.