/Management

The Worst Programmer I Know

- Daniel Terhorst-North tl;dr: Dan introduces us to Tim Mackinnon, a programmer whose productivity score was consistently zero because he never signed up for any stories in the team's project management system. "Tim wasn’t delivering software; Tim was delivering a team that was delivering software." Mackinnon spent his time pairing with teammates, guiding less experienced developers, and co-creating solutions with seniors. His presence made the entire team "more effective, more productive, more aligned, more idiomatic, more fun." Dan argues against individual performance metrics, stating that they are flawed measures in a "complex adaptive system" like software development. Productivity should be measured in terms of tangible business impact, such as dollars saved, generated, or protected. 

featured in #445

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

When, Why, And How GitHub And GitLab Use Feature Flags

- Ian Vanagas tl;dr: Ian discusses several benefits, such as reduced stress on developers, fewer failed deployments, and a higher rate of shipping features. GitLab calculated that fixing an issue without flags is as time-consuming as "developing a whole new feature." The article explores the advantages of feature flags over long-living feature branches for collaboration. Feature flags keep code changes small, make reviews easier, and limit merge conflicts. Both GitHub and GitLab use feature flags not just based on users but also on "actors" like organizations, teams, and repositories to create consistent experiences.

featured in #445

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

Measuring Developer Productivity? A Response To McKinsey

- Kent Beck Gergely Orosz tl;dr: “We wrote this article for software developers and engineering leaders, and anybody who cares about nurturing high-performing software development teams. By “high performing” we mean teams where developers satisfy their customers, feel good about coming to work, and don’t feel like they’re constantly measured on senseless metrics which work against building software that solves customers’ problems. Our goal is to help hands-on leaders to make suggestions for measuring without causing harm, and to help software developers become more productive.”

featured in #444

The Engineering Executive’s Role In Hiring

- Will Larson tl;dr: Will discusses your role as an executive in your organization’s hiring, the components you need to build for an effective hiring process and provides concrete recommendations for navigating the many challenges that you’re likely to run into while operating the hiring process. He gives you enough to get started, build a system that supports your goals, and start evolving it into something exceptionally useful.”

featured in #444

Why Top Engineering Teams Are Using Multi For Collaboration

- Alexander Embiricos tl;dr: With teams being more distributed than ever before, Multi is bringing the joy of building together back by making your apps and operating system multiplayer. With Multi, multiple people can share screen at the same time, cursor sharing and drawing is effortless, and automatic deep links make sharing context one click away.

featured in #444

An Effective Team Communicates Much Like Optimized Code: With Clarity, Modularity, And A Focus On Simplicity.

- Addy Osmani tl;dr: “Just as we strive for optimized, clean code, our teams should aim for clear, modular, and simple communication.” Addy shares tips from his time at Google: (1) Optimize communication for the target audience. (2) Speak clearly and slowly. (3) Opt for concise messages rather than apologizing for long ones. (4) Use simple and common words. Remove unnecessary and unrelated words. (5) Avoid English idioms and slang phrases if working with a global team. (6) Use inclusive language that considers all educational backgrounds.

featured in #443

8 Reasons Why WhatsApp Was Able To Support 50 Billion Messages A Day With Only 32 Engineers

tl;dr: (1) Single responsibility principle. (2) Tech stack. Erlang provides scale with a tiny footprint. (3) Leveraged robust open source and third party libraries. (4) A huge emphasis was given to cross-cutting concerns to improve quality. (5) Diagonal scaling to keep the costs and operational complexity low. (6) Critical aspects were measured so bottlenecks were identified and eliminated quickly. (7) Load testing was performed to identify single points of failure. (8) Communication paths between engineers were kept short.

featured in #443

Hire For Floors, Not Ceilings

- Jacob Kaplan-Moss tl;dr: Jacob uses the sports performance analogy of "floors" and "ceilings" to discuss hiring practices. In sports, an athlete's "ceiling" denotes their peak potential, while their "floor" represents their worst performance. Jacob identifies four performance archetypes, from consistently excellent athletes to those who are unpredictably variable. Drawing parallels to hiring, Jacob argue that employers often mistakenly prioritize a candidate's potential (ceiling) over their consistency (floor). He emphasizes that a consistently average performer is often more valuable than an unpredictable one, stating, consistency and reliability should be prioritized over sporadic potential.

featured in #443