44 posts tagged with "tutorial"

Google's engineering culture has a ritual: before a line of code ships for anything non-trivial, there's a design doc. Not a 40-page monument — usually 5 to 12 pages, reviewed by two peers, commented in the margins. Researchers at Google's Engineering Practices team have publicly described this as one of the cheapest quality levers the company uses.

Most teams outside Google skip this step or bolt a Confluence template onto an existing process and watch it atrophy. The template below is what actually survives contact with a distracted reviewer at 4:45 PM on a Thursday — the moment most specs live or die.

A 40-person engineering team shipped the same architectural decision twice in eight months — once in June, once in February, reverted both times. The second revert triggered the RFC process. What they discovered reviewing the commit history: the original context had been captured in a Slack thread that auto-archived after 90 days, and the engineer who owned the decision had left. An RFC document would have cost 4 hours to write and saved roughly 3 engineer-weeks of rework.

RFC (Request for Comments) processes exist because technical decisions outlive the people who made them. Stripe, Cloudflare, Oxide Computer, and the Rust project all publish their RFC formats — and the common structure is narrower than most teams assume. This article is the template they converge on, plus a review cadence that works for 10-80 person teams, plus honest numbers on when RFCs waste time.

A fintech team in Warsaw trimmed their average workday by 45 minutes and shipped more features. A 40-person SaaS in Singapore banned morning meetings before 11am and watched their median PR lead time drop 22%. Neither team invented anything new — they adopted protected deep-work blocks. UC Irvine's Gloria Mark has published for almost two decades (The Cost of Interrupted Work: More Speed and Stress, 2008, and follow-ups) that a single interruption costs ~23 minutes of refocus time. Cal Newport's Deep Work (2016) popularized the term for engineering leaders. The data is settled; the implementation is where teams diverge.

This piece walks through five real team schedules. The rituals that worked, the rituals that broke, and what we saw in the IDE telemetry once the pattern stabilized.

Sprint 47, 8-person team. The standard retro narrative would be: "Velocity dropped 20%, lots of bug fires, we'll prioritize better next sprint." Same vibe as Sprint 46. Same vibe as Sprint 45. Now add one number to the same retro: total sprint cost was $32,800, of which $11,600 (35%) went to bug-fix tickets versus $14,200 (43%) to features. The team's rolling-average bug share is 18%. That single line, "we doubled our usual bug spend this sprint," moved the team from "we'll do better" to "Sprint 48's first three days are bug-prevention only, full stop."

This article shows how to wire one financial number into a 30-minute retro so it produces decisions, not vibes.

A 6-person engineering team running a 15-minute daily standup costs you 7.5 person-hours a week in scheduled time alone. Add context switching cost — UC Irvine's Gloria Mark measured ~23 minutes to refocus after an interruption — and the real cost is closer to 15 hours a week. For a team running 10 weeks on one feature, that's 150 engineering-hours. That's not a meeting. That's a part-time engineer you hired and immediately deployed to talking.

Standups aren't inherently bad. They solve a real problem: surfacing blockers before they rot. The question is whether the daily synchronous format is the only way — or even the best way — to solve it. The State of Agile 2024 report shows 32% of teams actively experimenting with async-first alternatives, and the cleanest data we have from IDE telemetry suggests these alternatives recover 1-2 hours of focus time per developer per week without harming delivery.

This is a comparison of 5 standup alternatives, when each fits, and how to decide which one your team needs.

Most "remote rituals" are synchronous meetings wearing a remote costume. A daily standup at 9 AM UTC that five engineers across four timezones reluctantly attend isn't a ritual. It's office cosplay. GitLab's 2024 Remote Work Report found 71% of remote engineers cite "too many synchronous meetings" as the single biggest productivity drain of distributed work. The problem isn't remote; the problem is importing colocated rituals whole.

This is the list of 7 rituals that actually survive on remote engineering teams we've measured: teams where the telemetry shows they're not just happier but also shipping faster.

A sprint-planning meeting scheduled "at 10am so everyone can attend" is the fastest way to lose engineering time in a distributed org. The math is simple: with engineers in Americas, EMEA, and APAC, there is no "everyone can attend" slot — at least one timezone loses 3+ hours to meeting at the wrong end of their day. Microsoft's 2022 Work Trend Index, based on 61,000 employees, found meetings scheduled outside local 9am-5pm windows reduce participant engagement by 52% and increase follow-up misunderstandings by 2.4×.

This is a checklist — not a philosophical discussion — for how to run sprint planning for a team spread across more than two timezones. It's built from the patterns we see in our IDE heartbeat dataset, specifically the 62 teams in our data that work with ≥ 3 timezone sprint planning.

The average engineering manager spends 4 hours per week shuffling Jira tickets. Not planning, not 1:1s — triaging, reminding, closing stale, and chasing down fields people forgot to fill. We surveyed 31 EMs across our B2B customers; 27 of them named Jira as their single biggest time sink after meetings.

Atlassian ships a reasonably capable automation engine in every Jira plan (yes, even Standard). Teams ignore it. Or worse, they use it for one rule — auto-close on "Done" — and miss the 11 that matter. What follows is a set of 12 rules that, together, cut the EM's Jira admin load from 4h/week to around 40 minutes. We've used variants of these at PanDev Metrics in our own engineering org and across three on-prem customer deployments.

A 14-minute CI pipeline isn't just 14 minutes of waiting. GitHub Octoverse 2024 reported that the median enterprise repository now runs a pull request through CI 4.2 times before merge: retries, pushes after review, fixing flaky tests. That's nearly an hour of compute per PR. On a team shipping 200 PRs a week, the CI bill buys you nothing and the context-switch tax costs you a senior developer's Thursday.

This is a how-to. Six steps that consistently cut GitHub Actions CI time by 50%+ on real repos we've helped optimize. No theory; each step has a patch you can adapt.

A 40-engineer fintech I spoke to last month was paying $960/month for GitHub Copilot Business across their team, but their legal department had just blocked it after a compliance review flagged code-completion telemetry flowing through Microsoft's cloud. Their CTO asked me a deceptively simple question: "Can we self-host something equivalent?"

The answer is "yes, but only if you pass three filters." Stack Overflow's 2024 Developer Survey found 76% of developers use or plan to use AI tools, but adoption in regulated industries lags by 20-30 points. The gap isn't skepticism — it's infrastructure. Most engineering teams want private inference but underestimate what "self-hosted" actually costs in GPU capex, SRE time, and model-quality compromise.

This is the decision framework we hand teams considering the switch: when self-hosted LLMs beat the cloud, when they don't, and the three breakpoints that tip the math.