Measuring Engineering Velocity On A Software Team
- Zach Zaro tl;dr: Zach Zaro, CEO and cofounder of Coherence, reviews the history and state of the art of velocity. Measuring engineering velocity is a valuable exercise for software teams aiming to improve their processes and deliver value consistently. By understanding its nuances and potential pitfalls, teams can use velocity as a tool for growth and continuous improvement rather than a blunt instrument of judgment.featured in #479
8 Tips To Manage Your Time Better To Achieve Your Goals In 2024
- Peter Yang tl;dr: (1) Focus on one big thing: Your one big thing is usually important but not urgent. You should do your one big thing as early as possible every day. (2) Manage your energy: Before noon, I do tasks that require critical thinking like writing and making important decisions at work. In the afternoon, I do tasks that require less mental energy like sharing product updates or consuming content. (3) Ask to discuss async. Peter's favorite response when someone asks to meet is: "can we discuss async first?" And more.featured in #477
Practical Magic: Improving Productivity and Happiness for Software Development Teams
- Max Kanat-Alexander Grant Jenks tl;dr: "Today we are open-sourcing the LinkedIn Developer Productivity & Happiness Framework (DPH Framework) - a collection of documents that describe the systems, processes, metrics, and feedback systems we use to understand our developers and their needs internally at LinkedIn."featured in #476
A Simple Programming Productivity Trick: Leave Work Unfinished To Reach Flow
- Leonardo Creed tl;dr: “Stop right before a “sticking point.” A sticking point is a task that’s part of a project where I know the steps to do to complete it, but I don’t know if there are hidden costs. For example, if my sticking point is deploying my ML model and HTTP server to a dev instance and verifying that it processes requests properly, then the hidden costs are deployment errors, authentication errors, resource constraints, etc... Write down the next steps extremely clearly. Writing down steps makes regaining context and the state of mind from the day before easier. Make them actionable and unambiguous.” Leonardo also shares 3 other productivity tips.featured in #475
Biggest Productivity Killers In The Engineering Industry
- Gregor Ojstersek tl;dr: Perfectionism: (1) Progress is much more important than perfection, waiting for perfect moments causes more issues than actually doing it when it’s not. 95% is often good enough for the majority of cases. (2) Procrastination: focus on finishing the hardest task first thing in the morning. Other tasks become much easier to finish. (3) Context-switching: Timeboxing of tasks, sticking to one task until you finish it. Dividing time into meeting and maker time.featured in #474
featured in #474
How Much Do Companies Invest in Developer Productivity Teams?
- Abi Noda tl;dr: What percentage of headcount should be allocated toward centralized productivity teams? Abi found that companies under 1,000 engineers allocate 18.9% of their headcount toward centralized productivity teams, with a range of 8%-37%. The average allocation decreased to 17.8% when including companies with more than 1,000 engineers. Abi breaks this down further by company size and categories of productivity teams.featured in #473
The Surprising Connection Between After-Hours Work And Decreased Productivity
tl;dr: Key learnings from Slack’s Workforce Index: (1) Employees who log off at the end of the workday register 20% higher productivity scores than those who feel obligated to work after hours. (2) Making time for breaks during the workday improves employee productivity and well-being, and yet half of all desk workers say they rarely or never take breaks. (3) On average, desk workers say that the ideal amount of focus time is around four hours a day, and more than two hours a day in meetings is the tipping point at which a majority of workers feel overburdened by meetings. (4) Three out of every four desk workers report working in the 3 to 6pm timeframe, but of those, only one in four consider these hours highly productive.featured in #473
Practical Ways To Increase Product Velocity
tl;dr: "This post contains my go-to steps for debugging slow product velocity, particularly in SaaS. While I believe that these tactics are generally applicable, they’re heavily informed by my personal background. I have an engineering background and a reasonable sense for when I’m getting bullshitted about how hard something is. I also have a degree of control over both what teams work on and how they work – without that, some techniques may not apply. So while your mileage may vary, I hope that it’s helpful to lay these tactics out in one place."featured in #472
Summarizing Post Incident Reviews With GPT-4
- Wuji Zhu tl;dr: "We start by fetching the report from Confluence and parsing the HTML to extract the content of the PIR as raw text. We then remove sensitive data, including links, emails, and Slack channel names, to avoid exposing internal information to public models and ensure blameless summaries. We then send the text version of the report to GPT-4 chat completion to generate a summary." This is then archived with additional metadata and summarized onto the Jira ticket. Wuji provides an overview of how this is operationalized.featured in #468