DevOps is built on the timeless principle of cooperation. Whether the term remains, the concepts driving DevOps are here to stay. The only question is this: in what new ways will we apply these principles?

Common break-even calculations for TDD are wrong when experienced TDD devs are involved becuase TDD makes development faster.

Something has gone terribly wrong. You and all the king’s men have risen to the occasion, and put Humpty Dumpty together again. What next? You’ve heard of postmortems, and you think doing one could help you, but where to begin? This guide is for you! With literally no preparation, you should be able to run a successful postmortem. Even if you found this via google after assembling in the conference room!

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.

For more content like this, buy my in-progress eBook, Data Serialization in Go⁠, and get updates immediately as they are added! The content in this post is included in my in-progress eBook, Data Serialization in Go, available on LeanPub. I’ve done a lot of JSON handling in Go. In the process, I’ve learned a number of tricks to solve specific problems. But one pattern in particular I find myself repeating ad infinitum.

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.