44 posts tagged with "tutorial"

Your best SRE quit last quarter. She didn't say "burnout" in the exit interview, but her last three months included 14 after-hours pages, 2 weekend incidents, and a 3am call on her birthday. A 2021 Catchpoint / DevOps Institute survey of 500+ on-call engineers found 67% reported burnout symptoms tied directly to paging load. Google's SRE book sets an internal ceiling of 2 incidents per on-call shift before a rotation is declared unhealthy — most teams we measure blow past that in week one.

On-call is fixable. It's a scheduling and sociotechnical problem, not a personality flaw in the people who can't hack it. Here's a 9-rule playbook that keeps your SLA intact and keeps your best engineers on the team past their second rotation.

The average post-mortem takes 4 hours to write and generates zero action items the team actually completes within 30 days. We looked at 120 post-mortem documents from three of our on-prem customers before rebuilding this template. 83% of action items were still "open" six months later. That's not an incident review — that's a document graveyard.

A post-mortem is worth writing only if it changes something. Everything else is CYA.

A mid-size team I advised last year had a standing rule: every ticket above 3 story points needed a design doc. Eight engineers, roughly four docs per week, each doc eating a half-day to write and another half-day in review cycles. That's 32 engineering hours per week — four full working days a week, spent on documents that most people scanned once and never reopened. The CTO thought they were a high-discipline shop. The data said they were documentation-heavy and velocity-poor.

The opposite extreme is worse. A 2019 report from Stack Overflow's Developer Survey listed "poor documentation of internal systems" as the #2 productivity blocker after technical debt itself. Skipping design docs entirely means every sixth-month refactor is an archaeology dig.

This is the framework I use to decide which changes deserve a doc, which deserve a 3-sentence RFC comment, and which deserve nothing at all.

The average engineering retro runs 60 minutes, produces five sticky notes, and ships zero action items into the next sprint. The Scrum Alliance's 2023 practitioner survey put "retros feel performative" as the #1 complaint from senior engineers. That's not a meeting problem. It's a measurement problem. Teams debate feelings because nobody pulled the data before the call.

This article gives you a 30-minute retrospective that opens with numbers, ends with named owners, and works on any team between 5 and 25 engineers.

Right now, your team has pull requests stuck in review. Probably three or more. One's been sitting for five days. A 2018 study from Google's engineering productivity group (Sadowski et al., Modern Code Review: A Case Study at Google) found that the median review at Google completes in less than 4 hours. In most teams we see, that number is 4 days — a 24× gap explained almost entirely by process, not talent.

This is a checklist of 11 rules that cut review time in half without reducing quality. Each is backed by external research, refined against real engineering-team data, and structured into three phases: author discipline, reviewer discipline, team discipline.

Most DORA adoption efforts fail not because of tooling or data — but because they become 6-month projects that die in committee. The Accelerate research (Forsgren, Humble, Kim, 2018) showed that organizations with visible delivery metrics improve faster. The key word is visible: a dashboard nobody looks at is worse than no dashboard, because it creates the illusion of measurement. Here's a day-by-day plan to go from zero to live DORA dashboards in two weeks — fast enough that the momentum doesn't dissipate.

Setting up a Git integration shouldn't take a sprint. With GitLab and PanDev Metrics, it takes about 15 minutes — then every commit, merge request, and pipeline event flows into your engineering dashboard automatically.

This guide covers both GitLab SaaS (gitlab.com) and self-managed instances. No plugins, no complex OAuth flows — just webhooks and a personal access token.

Managing personal access tokens and manual webhooks for every repo gets old fast. PanDev Metrics integrates with GitHub through a dedicated GitHub App — no tokens to rotate, fine-grained permissions out of the box, and automatic webhook management.

This guide walks you through installing the app, granting permissions, and verifying that commit and pull request data flows into your dashboards.

Your Jira board says a task took 3 days. But how much of that was actual coding? How much was waiting for review? How much was context switching between other tickets?

PanDev Metrics bridges Jira's task management with real developer activity data — commits, IDE time, code reviews — so you see the full picture. Not just "in progress" and "done," but what happened in between. The integration uses Jira's REST API and OAuth 2.0 for secure, read-only access to your project data.

Every team lead asks the same question: how much real effort does each task actually take? ClickUp tracks work organization; PanDev Metrics tracks engineering activity. Together, they close the gap between "assigned" and "done."

This guide walks you through connecting ClickUp to PanDev via the ClickUp API, syncing tasks and time entries, and using the combined data to make better planning decisions.