Developer Experience Engineering

Developer experience (DevEx) is the sum of all interactions an engineer has with their tools, processes, and platform. Poor DevEx — slow builds, complex deployments, undocumented services — drains productivity and morale. Platform engineering exists to improve DevEx: providing golden paths, self-service tools, and clear documentation.

---

Developer Experience Dimensions

SPACE Framework (from Microsoft Research):

Satisfaction:
  "How happy are developers with their tools and processes?"
  Measure: Developer survey (quarterly)
  Target: >80% satisfaction score

Performance:
  "How well does the system perform?"
  Measure: Build time, deploy time, test time
  Target: Build < 5min, deploy < 15min

Activity:
  "How much work is being done?"
  Measure: PRs merged, deployments per day, commits
  Caution: Activity ≠ productivity (don't game metrics)

Communication & Collaboration:
  "How well do teams communicate?"
  Measure: PR review time, cross-team dependencies
  Target: Review within 4 hours

Efficiency & Flow:
  "How often are developers in flow state?"
  Measure: Context switches per day, unplanned work %
  Target: < 3 context switches/day, < 20% unplanned work

---

Golden Path

A golden path is the blessed, supported way to do something.
It's opinionated, documented, and maintained by the platform team.

Example: "I want to create a new microservice"

Golden path:
  1. Run: platform create-service --name=my-service --template=rest-api
  2. Auto-generated:
     ├── Dockerfile (optimized, security-scanned)
     ├── CI/CD pipeline (.github/workflows)
     ├── Terraform module (networking, IAM)
     ├── Monitoring dashboards (Grafana)
     ├── Alert rules (PagerDuty)
     ├── README.md (with runbook links)
     └── Tests (unit, integration, contract)
  3. First deployment: Push to main → auto-deploys to staging
  4. Production: Merge to production branch → canary deploy

Without golden path:
  1. Copy another service (which one? it's complicated)
  2. Modify Dockerfile (hope you get the base image right)
  3. Write CI/CD from scratch (3 days of YAML debugging)
  4. Request infrastructure (ticket, wait 2 weeks)
  5. Set up monitoring (forget alerting, find out from users)
  6. First deployment: "It works on my machine 🤷"
  
Golden path: 30 minutes to first deployment
Without: 2-3 weeks to first deployment

---

Developer Portal

# Backstage service catalog entry
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payment-service
  description: "Handles payment processing via Stripe"
  annotations:
    github.com/project-slug: "myorg/payment-service"
    pagerduty.com/service-id: "P1234567"
    grafana/dashboard-selector: "service=payment"
spec:
  type: service
  lifecycle: production
  owner: payments-team
  system: checkout
  providesApis:
    - payment-api
  consumesApis:
    - stripe-api
    - user-api
  dependsOn:
    - resource:payments-db
    - resource:redis-cache

# What developers get:
# - Service catalog (who owns what)
# - API documentation (auto-generated)
# - Dependency graph (visual)
# - Runbooks (linked from PagerDuty)
# - Dashboards (linked from Grafana)
# - One-click dev environment

---

Anti-Patterns

Anti-Pattern	Consequence	Fix
”Just read the wiki”	Wiki is outdated, wrong, incomplete	Golden paths with working templates
Infrastructure via ticket	2-week wait for a namespace	Self-service with guardrails
No service catalog	”Who owns this service?” (nobody knows)	Backstage or equivalent developer portal
Measure lines of code	Gaming metrics, no real signal	SPACE framework (multi-dimensional)
Build platform without users	Platform nobody uses	Talk to developers, solve their actual pain

Developer experience is an investment with compound returns. Every hour saved from a golden path is multiplied by every engineer who uses it, every time they create a new service.