/Process

How We Decide What To Build

- Ian Vanagas tl;dr: “There is a point in your product journey where what to build next goes from obvious to unclear. The options seem endless and choosing correctly can be the difference between a thriving product and a failing one.” Ian discusses how to navigate this. 

featured in #506

Developing Rapidly With Generative AI

- Shannon Phu tl;dr: From the engineering team at Discord: “We break down the process of building with LLMs into a few stages. Starting with product ideation and defining requirements, we first need to figure out what we’re building and how it can benefit users. Next, we develop a prototype of our idea, learn from small-scale experiments, and repeat that process until our feature is in a good state. Finally, we fully launch and deploy our product at scale. In this post, we will dive deeper into each stage of this process.”

featured in #505

Headline Driven Development

- Slava Akhmechet tl;dr: Process involves: (1) Decomposing the project into a stream of headlines. (2) Picking an aggressive ship date for the first headline and working hard to meet it. (3) Having everyone focus only on one headline at a time - the upcoming one. (4) Ignoring everything else that doesn't help ship the current headline. (5) Once a headline ships, switching to the next one and repeating. This process works well as for three reasons - headlines is how humans process change, prioritization is easy and setting deadlines is effective. 

featured in #504

Bottleneck #06: Onboarding

- Tim Cochran Premanand Chandrasekaran tl;dr: Signs that your company is bottlenecked by an ineffective onboarding process, and best practice solutions: (1) New people cannot access tools and systems. (2) New developers cannot make a production deployment. (3) Newcomers feel orphaned. (4) Too much focus on individual work. (5) Not enough openness to change. (6) Seemingly simple things take too long. (7) Fast turnover. (8) Documentation can't answer questions from new hires. 

featured in #483

The Scary Thing About Automating Deploys

- Sean McIlroy tl;dr: Sean delves into the complexities and strategies of automating deployments at scale, focusing on how Slack transitioned from manual oversight to using their automated tool for deployment processes in a high-change environment. “When people talk about continuous deployment, they’re often thinking about deploying to systems as soon as changes are ready. They talk about microservices and 2-pizza teams (~8 people). But what does continuous deployment mean when you’re looking at 150 changes on a normal day? That’s a lot of pizzas…" 

featured in #482

Sensenmann: Code Deletion At Scale

- Phil Norman tl;dr: “What if we could clean up dead code automatically? That was exactly what people started thinking several years ago, during the Zürich Engineering Productivity team's annual hackathon. The Sensenmann project, named after the German word for the embodiment of Death, has been highly successful. It submits over 1000 deletion changelists per week, and has so far deleted nearly 5% of all C++ at Google. Its goal is simple (at least, in principle): automatically identify dead code, and send code review requests to delete it.” Phil discusses its logic. 

featured in #482

Canon TDD

- Kent Beck tl;dr: Test-driven development (TDD) is a programming method where new features are added without disrupting existing functions. It ensures new and old features work correctly, readies the system for future updates, and builds programmer confidence. The flow is as follows: (1) Write a list of the test scenarios you want to cover. (2) Turn exactly one item on the list into an actual, concrete, runnable test. (3) Change the code to make the test (& all previous tests) pass (adding items to the list as you discover them). (4) Optionally refactor to improve the implementation design. (5) Until the list is empty, go back to #2.

featured in #473

Performance & Compensation (For Eng Execs)

- Will Larson tl;dr: Will discusses: (1) The conflicting goals between those designing, operating, and participating in performance and compensation processes. (2) How to run performance processes, including calibrations, and their challenges. (3) How to participate in a compensation process effectively. (4) How often you should run performance and compensation cycles. (5) Why your goal should be an effective process rather than a perfect one.

featured in #446

Why Fast?

- Matt Rickard tl;dr: “Why do ambitious things sometimes come together so fast?” Matt argues the following: (1) Right time, right place: “Sometimes, groundwork from many disparate threads comes together, making the previously impossible possible.“ (2) A sense of urgency is one of the best motivators. (3) Constraints foster creativity. (4) Fast favors prototypes. A focusing mechanism for pruning unnecessary details.

featured in #446

Push And Pull

- Kellan Elliot-McCrea tl;dr: Kellan discusses a model for understanding engineering processes that focuses on two elements: "Push" and "Pull." "Push" refers to the rules, templates, and expectations set by a team for a process. "Pull" is the inherent value or need that the process fulfills, making it worthwhile and valuable for team members to engage in it. The author notes that many processes fail due to a lack of "Pull," as seen in the example of weekly status updates that fade out because "It didn’t feel like anyone was reading it."

featured in #445