Developer Productivity: Google’s Human-Centered View

Alexander Polomodov discusses Google’s Developer Productivity for Humans series through his experience leading engineering teams. The central question is whether engineers can achieve useful outcomes more easily. Task counts, code volume, and editor time cannot answer that alone. Finding a library may save a week of development while reducing recorded activity. Start with the goal and the decision that evidence could change, then choose the metric.

The conversation follows everyday goals: understanding unfamiliar code, waiting for builds, and joining a team. Logs show actions, surveys capture experience, and interviews help explain discrepancies. These observations need to be combined. An embedded AI chat, for example, increases editor time because engineers now read documentation there; switching between applications decreases. Builds need predictability as well as speed. Onboarding should account for independence and mentoring effort, beyond the first production change.

Another theme is the cost of local acceleration. A platform team can release libraries quickly while consumers spend increasing effort integrating updates. Quality needs to be examined across process, code, system, and product. Architecture matters through its contribution to product development and reliability. Reusing a solution can also be creative work, even when promotion incentives favor building something new. Include everyone involved, especially those who use the output.

The AI discussion examines four tensions: author time saved versus review effort, quick results versus accumulated debt, easy prototypes versus difficult production work, and generated code versus lost understanding. Automation also changes the task mix: eliminating simple operations can increase the average duration of remaining work. The episode ends with a month-long experiment: choose one painful goal, establish a baseline, try a bounded change, and discuss the outcome with the team. Define signs of benefit and harm beforehand, and be willing to stop an intervention that does not help.