This is Part 2 of a two-part series on Blameless Postmortems. The previous article went into why blameless postmortems are so effective; this second part goes into detail on how to build your own postmortem process and kick it into overdrive. Read Part 1 here. So you've read our first installment and recognized the value of the blameless postmortem for efficiency, culture, and output. Now you're ready to get off the blame train and kickstart a blameless postmortem process of your own. Where to begin?
This is Part 1 of a two-part series on Blameless Postmortems. Today, we'll discuss why blameless postmortems are so important and their implications for your team; the second part will go into detail on how to set them up as a process and make them successful. Somebody wise may have once told you that how we handle adversity shows our character. Being able to acknowledge and admit mistakes is the first step towards learning - it's a key part of success both in personal relationships and in large companies.
Large-scale software projects don't care how many unit tests you put into your code. Or how sophisticated your CI/CD pipeline is. Or how robustly you run blue-green deployments to ease into newly-deployed code. These projects will inevitably find themselves subjected to your users, who will uncover bugs your team didn't catch and didn't even think to test for.
Choosing a JavaScript framework for a new project can be a daunting task. There’s always a new one getting hype from the community, while the established players still have a lot to offer. So you need to do your homework and make sure the framework you choose is the right one for your specific requirements. Popularity alone is never the best indicator, but a review of the most widely-used options should help you decide which way to go.
