Measuring An Engineering Organization
- Will Larson tl;dr: "There is no one solution to engineering measurement, rather there are many modes of engineering measurement, each of which is appropriate for a given scenario. Becoming an effective engineering executive is adding more approaches to your toolkit and remaining flexible about which to deploy for any given request." Will provides a template to work off of.featured in #378
Which Meetings Should You Kill?
- Camille Fournier tl;dr: "I fear that the culprit is a surprising new factor, one that started before the pandemic but has gotten even more out of hand in the world of remote work: 1:1s." Camille discusses how group discussion topics have turned into 1:1 topics in the remote work era.featured in #378
Code Ownership And Software Quality
- Abi Noda tl;dr: "Ownership is negatively correlated with the number of bugs, and the more shared the file ownership the higher the likelihood that it will contain code defects. This trend is also supported by the fact that for all projects studied, the number of contributors is positively correlated with the number of bugs." Abi provides 4 management recommendations.featured in #377
5 Ways To Increase Velocity By Removing The Bottlenecks In Your QA Process
- Kirk Nathanson tl;dr: With a recession looming and many companies freezing their hiring plans, savvy teams can look at other levers to increase velocity and improve product quality. Here are five cost-effective changes you can make.featured in #377
featured in #376
featured in #376
Incident Categories I’d Like To See
- Lorin Hochstein tl;dr: If you’re categorizing your incidents by cause, here are some options for causes that I’d love to see used. These are all taken directly from the field of cognitive systems engineering research: (1) Production pressure. (2) Goal conflicts. (3) Workarounds. (4) Automation surprises.featured in #376
Writing Docs Well: Why Should A Software Engineer Care?
- Lorin Hochstein tl;dr: Lorin recently gave a lecture in a graduate software engineering course on the value of technical writing for software engineers. There are 3 goals when writing: (1) Building shared understanding. (2) A tool for your own thinking. (3) Influence in a larger org when you’re at the bottom of the hierarchy. Lorin also advises on how to improve technical writing.featured in #374
Removing Uncertainty: The Tip Of The Iceberg
- James Stanier tl;dr: "You reduce uncertainty until the software exists. You reduce uncertainty by doing: prototyping, designing, writing code, and shipping. Each of these actions serve to reduce the uncertainty about what is left to build." James discusses different methods of reducing uncertainty across a project, at various stages.featured in #373
featured in #372