Developer Experience DX

What is Developer Experience (DX) for Platform Engineers?

Developer Experience (DX) is how easy, fast, and reliable it is for engineers to build, ship, and operate software on your platform. For Platform Engineers, great DX means fewer support tickets, consistent standards, safer deployments, and happier teams. You create golden paths, tools, and guardrails so product teams can focus on features instead of plumbing.

What you will learn

• Design golden paths: opinionated defaults that speed up delivery while preserving autonomy.
• Build scaffolding and templates that encode best practices from day one.
• Create CLIs and internal portals that turn complex tasks into simple commands.
• Enable self-serve provisioning for services, infra, and secrets with safe guardrails.
• Standardize observability (logs, metrics, traces) across services.
• Optimize local dev and inner-loop speed to reduce wait times.
• Support teams through docs, onboarding, and enablement programs.

Who this is for

• Platform Engineers building internal platforms or paved roads.
• Backend Engineers influencing tooling and standards.
• Tech Leads responsible for delivery speed and quality.

Prerequisites

• Comfort with Git, CI/CD concepts, and container basics.
• Basic understanding of cloud/IaC (e.g., Terraform) and service operations.
• Familiarity with observability fundamentals (logs, metrics, traces).

Learning path (practical roadmap)

1. Capture the golden path
   • Interview 2–3 teams; list their top friction points.
   • Define the ideal service lifecycle: create → code → test → deploy → observe → iterate.
   • Document one-page standards: language, build, test, release, runtime, observability.
   Mini task

   Write a one-page golden path for a standard microservice, including the expected repo structure and CI stages.

2. Build service scaffolding
   • Create a template repo with boilerplate app, Dockerfile, CI pipeline, and observability setup.
   • Add input prompts (name, owner, runtime) and generate repo from template.
   Mini task

   Create a template that builds, tests, and publishes a container, then deploys to a staging namespace.

3. Ship a developer CLI or portal workflow
   • Add commands: new service, run local, test, deploy, open logs.
   • Make commands idempotent and chatty (clear output, helpful errors).
   Mini task

   Implement a dx new-service command that scaffolds a repo and opens a pull request.

4. Enable self-serve provisioning
   • Use GitOps-style PRs to request infra (databases, topics, buckets) via approved modules.
   • Add policy guardrails and reviewers for safety.
   Mini task

   Define a Terraform module that provisions a staging database with naming conventions and tags.

5. Standardize observability
   • Embed OpenTelemetry config, log format, health endpoints, and dashboards into templates.
   • Provide a one-click or one-command setup for alerts.
6. Improve local dev and inner loop
   • Support hot reload, fast unit tests, and minimal mocks.
   • Provide a docker-compose or dev container with consistent tooling.
7. Documentation and enablement
   • Create concise starter guides, checklists, and troubleshooting pages.
   • Run office hours and track common issues to refine the platform.

Worked examples

service-template/
  src/
    app.py
  tests/
    test_health.py
  Dockerfile
  .pipeline/ci.yml
  o11y/otel-config.yaml
  README.md

# .pipeline/ci.yml
stages:
  - test
  - build
  - publish
  - deploy

variables:
  IMAGE: registry.example.com/${CI_PROJECT_NAME}:${CI_COMMIT_SHA}

jobs:
  test:
    script:
      - make test
  build:
    script:
      - docker build -t ${IMAGE} .
  publish:
    script:
      - docker push ${IMAGE}
  deploy:
    script:
      - ./scripts/deploy.sh --image ${IMAGE} --env staging

# bin/dx
set -euo pipefail

usage() {
  echo "dx <command>"
  echo "  new-service NAME  - scaffold from template"
  echo "  run               - start local stack"
  echo "  logs              - tail service logs"
}

case "${1:-}" in
  new-service)
    NAME=${2:?"Provide service name"}
    echo "Scaffolding $NAME..."
    cp -r service-template "$NAME"
    git init "$NAME" && echo "Done. Push and open a PR to create repo."
    ;;
  run)
    docker compose up --build
    ;;
  logs)
    docker compose logs -f app
    ;;
  *) usage ;;
esac

# requests/dbs/team-catalog-staging.yaml
resource: postgres_db
name: team_catalog
env: staging
owner: team-catalog
size: small

# modules/postgres_db/main.tf
variable "name" {}
variable "env" {}
variable "owner" {}
variable "size" { default = "small" }

# Naming convention: {env}-{name}
# Tags include owner for cost visibility

# o11y/otel-config.yaml
exporters:
  otlp:
    endpoint: http://otel-collector:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      exporters: [otlp]

# src/app.py
from flask import Flask
import logging

app = Flask(__name__)
logging.basicConfig(format='%(asctime)s %(levelname)s %(message)s')

@app.route('/health')
def health():
    return {"status": "ok"}, 200

# docker-compose.yml
version: '3.8'
services:
  app:
    build: .
    command: make dev
    ports: ["8080:8080"]
    env_file: .env.local
    volumes:
      - ./:/workspace
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: local
      POSTGRES_DB: app
    ports: ["5432:5432"]

Drills and exercises

• [ ] Create a template that runs tests, builds an image, and deploys to staging.
• [ ] Add a dx new-service command that asks for service name and owner.
• [ ] Define a self-serve workflow that provisions a queue or topic safely.
• [ ] Implement standardized logging format and a health endpoint.
• [ ] Measure inner-loop time (edit → run tests) and reduce it by 30%.
• [ ] Write a one-page onboarding guide that a new hire can complete in 60 minutes.

Common mistakes and debugging tips

Mini project: the golden-path microservice

Goal: Deliver a one-command flow for creating and shipping a production-ready service.

• Template repo with app, tests, Dockerfile, CI, and o11y defaults.
• dx new-service scaffolds a repo and opens a PR.
• Self-serve PR creates a staging database for the service.
• Local dev uses docker-compose with hot reload.
• Dashboards and an alert rule are created automatically at first deploy.

Subskills

• Service Scaffolding And Templates — Standardize repo structure, CI, runtime, and o11y from the start.
• CLI Tools And Portals — Provide simple commands and workflows for common tasks.
• Documentation And Onboarding — Short, task-focused guides and checklists that unblock new hires fast.
• Self Serve Provisioning Workflows — PR-driven infra requests with policy guardrails.
• Standard Observability Integration — Logs, metrics, traces baked into templates.
• Local Dev Environments Basics — Dev containers or compose for consistent, fast local setup.
• Inner Loop Speed Improvements — Faster tests, hot reload, and caching to shorten feedback cycles.
• Support And Enablement — Office hours, chat support, and training that scales knowledge.

Practical projects

• Build a language-agnostic template that passes security, test, and license checks by default.
• Create a one-page runbook for incident handover embedded in the template README.
• Implement a "dry-run" mode in your CLI that shows planned actions without executing.
• Measure onboarding time for a new hire and reduce it by 50% with docs and automation.

Next steps

• Deepen reliability practices: rollout strategies, progressive delivery, and policy as code.
• Expand your CLI or portal with audit logs and usage telemetry (privacy-aware).
• Productize the platform: define SLAs, track satisfaction, and iterate based on feedback.