You don't need to have a retrospective meeting. But you do need to retrospect!

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!

My wife and I recently started re-watching Star Trek: The Next Generation. One episode in particular jumped out at me as demonstrating some really bad engineering management practices. I decided to turn my thoughts into a YouTube video, and a postmortem. I hope you enjoy. All feedback is welcome!

One habit that I think every software developer, if not practically every professional in any field, can benefit from is that of solving every problem twice. Watch my video on this topic, too! I remember first reading about a similar concept in Joel Spolsky’s blog, Joel on Software, where he wrote back in 2007: Fix everything two ways Almost every tech support problem has two solutions. The superficial and immediate solution is just to solve the customer’s problem.

I’ve been thinking a lot lately about how DevOps scales. DevOps, and related practices, get a lot of attention when it comes to scaling up at large organizations like Google and Netflix. But what about the other extreme of very small teams? This is a list of DevOps practices I use on the tiny scale: Solo projects. While most of these practices offer an immediate benefit, even for a single-person team, in most cases, the benefit grows as the team grows.