/Process

The 11 Types Of Toxic Pull Requests (According To 4.5 Million Code Branches)

tl;dr: "Half of all PRs are idle for at least 50% of their lifespan." The article identifies four root problems in PR management: (1) No formal process for getting PRs assigned. (2) No standardization or best-practice guidance for PR size. (3) Teams treat all PRs with equal importance despite different risk levels. (4) Lack of visibility into PR context or how long it will take to review until opened. To address these issues, the article suggests two potential solutions: pair programming and continuous merge.

featured in #445

Akin's Laws Of Spacecraft Design

- Matt Rickard tl;dr: The article presents 45 laws by David Akin, Professor of Aerospace Engineering, including: (1) Engineering is done with numbers. Analysis without numbers is only an opinion. (2). To design a spacecraft right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong. (3). Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time. (4). Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment. (5). Three points determine a curve.

featured in #443

How Games Typically Get Built

- Gergely Orosz tl;dr: Insights into the world of game development, contrasting it with traditional software development. Game development involves programmers, designers, artists, animators, writers, and sound designers. Games typically undergo a prototype stage, followed by full production, where multiple teams work in parallel, often leading to integration challenges. The game development life cycle consists of three main phases: pre-production, production, and release. Gergely emphasizes that while game development borrows practices from software development, such as TDD and agile methodologies, it requires adaptations to fit the unique challenges of the medium.

featured in #442

Building Software The Swarmia Way

- Hugo Kiiski tl;dr: We all know that there’s no single right way to build software. But because we love learning about how other high-performing software organizations approach team composition, rituals, technology choices, and more, we figured why not return the favor and open up our own workflow.

featured in #439

Bottlenecks vs Bandpass

- Andrew Bosworth tl;dr: To avoid bottlenecks in product development, horizontal teams should establish clear guidelines and standards, allowing vertical teams to work efficiently. This frees up time for horizontal experts to focus on complex issues and enables faster progress in the future.

featured in #429

Pull The Andon Cord

- Taylor Pearson tl;dr: The Andon Cord was a rope that hung in Toyota factories that instantly could stop all work on the assembly line, which workers were encouraged to pull when they saw an issue. Once pulled, a manager came down to look the issue but the worker who pulled the rope was the one that came up with the solution. This process had 2 benefits: (1) It made workers feel trusted and part of the company’s output. (2) It dramatically increased quality as workers had a lot of tacit knowledge that managers didn’t.

featured in #401

Automating Safe, Hands-Off Deployments

- Clare Liguori tl;dr: “In this article, we walk through the steps a code change goes through in a pipeline at Amazon on its way to production. A typical continuous delivery pipeline has four major phases - source, build, test, and production. We’ll dive into the details of what happens in each of these pipeline phases for a typical AWS service, and provide you with an example of how a typical AWS service team might set up one of their pipelines.”

featured in #401

Diagnose Engineering Process Failures With Data Visualization

- Ian Johnson tl;dr: Ian shows us how data visualization helps productivity and processes in the following: (1) Detecting flaky tests (2) Pull Requests (3) Monitoring e.g. CPU usage, latency, errors, etc...

featured in #253

Every Team Should Have A Retrospective Practice

- Tim Casasola tl;dr: (1) "Learning as a team builds psychological safety: the feeling of being able to say what you mean without fearing judgment or negative consequences." (2) Retros are low hanging fruit (3) They put teams on the path to continuous improvement. Tim provides resources for facilitating retros.

featured in #202

How I Went From Dev To VP Of R&D In 25 Months

- Dan Lines tl;dr: Characteristics of an elite team and 7 "secrets" from building such a team, including (1) learning how to get developers to do what was right without formal authority (2) The smarter the person, the more “why” matters.

featured in #198