If your team is open to it, by all means, start doing retrospectives. But if you sense resistance, here are some reasons to start with postmortems.

DevOps is a big topic, and simply knowning where to start can be a mystery. I have two suggestions for how you can start with DevOps today.

It feels like we're still in the folk-medicine days of IT, debating the efficacy of animal dung ointments and bloodletting with leeches. But one practice that's proven effective in improving software quality is code review.

Every team is different, but one thing is the same: all want to build the best product in the shortest time. There are different ways to achieve this.

In this episode, Luca Ingianni helps me tackle the question: Does DevOps make sense for embedded systems software?

The only time less typing is more important than readability is on the command line. When writing code, readability wins by a mile.

You might hire a golf coach who watches you to discover your "bad habits", then convert them into explicit knowledge so they can be corrected. It's no different in business.

How much of what you do on a daily basis would you struggle to explain to someone as step-by-step instructions?

I've grown tired of the constant bickering about Kubernetes or no. But this article is more an informative case study in the viability of one alternative.

How many of your team members do you need to lose before your team can become productive?

How many of your team members could you suddenly lose without jeopardizing your project?