Why do great teams with sufficient data still make bad decisions, miss incidents, and seem unresponsive? How should you slice your data to ensure a quality customer experience?
An opinion column for developers. Brutally honest, no pulled punches.
Why do great teams with sufficient data still make bad decisions, miss incidents, and seem unresponsive? How should you slice your data to ensure a quality customer experience?
Why do writing more code and working more hours fall short of delivering more value? What should engineers be doing?
Which software terms are so offensive that we should change them? How do you choose a good alternative to an offensive term?
What are the four measures in a balanced scorecard? Why must you pay attention to all four?
How much and when should you reduce debt and invest in infrastructure? Can you get proper credit at review time?
Why do services need forward and backward compatibility? How should you roll out changes?
How should customer expectations drive quality? Can faster release cadences for betas, websites, and cloud services impact our approach to quality?
Should you have a dedicated SE team or should the core team code and test updates? How do you prevent the core team from being randomized?
What is the basis of success for all large engineering projects? Which five practices prevent all software problems?
Why is it better to recover than simply crash and report failures? How can asserts be unintentionally evil?