/Process

Some Principles Of Human-Centered Computing

- John Allspaw tl;dr: (1) The Aretha Franklin Principle: Emphasizes valuing both humans and machines in a system, aiming for synergy rather than competition. (2) The Sacagawea Principle: Stresses the importance of computational tools supporting active information management and decision-making processes. (3) The Lewis and Clark Principle: Highlights the need to present guidance to users in a way that aligns with their goals and facilitates comprehension of key decisions.

featured in #552

Using Your Own Product Is A Superpower

- Ian Vanagas tl;dr: “Everyone at PostHog “dogfoods” our product, including non-product teams like marketing and sales. This helps ship faster, intercept problems, stay motivated, deeply understand our product and develop empathy. But none of this happens by accident. It requires a strong, intentional culture of feedback, transparency, and simple, repeatable processes. This is how we do it.”

featured in #547

Unlocking CI/CD Efficiency

- Sean Chapman tl;dr: Understanding the impact of each of your deployments is crucial, especially as they become increasingly frequent. Chances are, your team is either aiming to increase shipping velocity or has already started deploying “continuously”. And while CD comes with a host of well-established benefits, it also introduces a heightened risk of introducing new errors and issues. Today, Raygun takes a look at the state of continuous deployment according to survey data, so you can see how you stack up compared to other teams. 

featured in #544

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