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
The Top 7 Software Engineering Workflow Tips I Wish I Knew Earlier
- Jordan Cutler tl;dr: Jordan delves into the following areas: (1) Git & terminal workflow. (2) Coding, notably tracing code down or up a stack, navigating between locations & typing. (3) Saving what you learnt in accessible ways. (4) Offloading ideas and tasks immediately so you don’t carry them in your thoughts. (5) Communicating through visuals. (6) Using a password manager. (7) Window management.featured in #455
What Predicts Software Developers’ Productivity?
- Abi Noda tl;dr: Abi summarizes a study by Google researchers on the factors that correlate with software developers' productivity. The study found that "Job enthusiasm," "Peer support for new ideas," and "Useful feedback about job performance" were the most strongly correlated factors with self-rated productivity. The top 10 productivity factors were non-technical.featured in #451
The Ultimate Guide To Developer Counter-Productivity
- John Cutler tl;dr: John highlights 20+ specific areas where developers often lose productivity, including: (1) Reactive, unplanned work. (2) Context switching and startup costs. (3) Non-value-adding admin & compliance work. (5) Ineffective planning. (6) Dependency management overhead. (7) Ineffective meetings and communication. (8) Redundant manager briefing & orientation. (9) Consensus seeking and decision-making drag. (10) Ineffective collaboration arrangements. And more.featured in #448
Three Dimensions Of Developer Productivity
tl;dr: Abi offers a three-dimensional approach to understanding and measuring developer productivity. The dimensions are Velocity, Quality, and Satisfaction. The authors argue that "any picture of productivity would be incomplete if these dimensions are not considered." Velocity is the speed at which tasks are completed, but the authors caution that the type of task, its complexity, and routineness must be considered. Quality can be both internal (code quality) and external (end-user experience). Satisfaction encompasses feelings like happiness, autonomy, and flow, and it balances the other two dimensions e.g. "an increase in velocity may lead to reduced costs, but at the same time it can lead to increased stress for developers reducing satisfaction."featured in #445