Never stray from the way.

Developer Growth Report — 2026-04-21

Developer Growth Report

Period: April 15–21, 2026 Generated: 2026-04-21

Work Summary

This week split across three distinct areas. The largest chunk was engineering work: designing and beginning to implement Notification System V2 across the backend, building the ipd-notification-client shared library from scratch, and migrating several services. Alongside that ran a sustained investment in developer tooling — building two new Claude Code skills (what-i-have-done, collect_conversations.py), updating CLAUDE.md with a parallelism strategy, and investigating mprocs and GNU parallel for speeding up daily dev tasks. The third thread was technical communication: writing a blog post on Brook's Law ("Nine Mothers, One Baby") and building the what-i-have-done skill specifically to bridge the gap between engineering output and management understanding.

The pattern that stands out: you consistently invest time in meta-work — tooling, workflow, communication frameworks — not just feature delivery. This is a strong signal of engineering maturity. The gap this week is that several tools were researched and understood but not yet adopted in practice.

Improvement Areas

1. Parallelism: from theory to practice

Why it matters: You spent time this week understanding GNU parallel, mprocs, and the distinction between shell parallelism and subagent parallelism. You even codified the rule in your CLAUDE.md. But there is no evidence yet of mprocs being configured or used in any project, and no GNU parallel invocation in your workflow.

What I observed: You asked about mprocs for running pytest, ruff, django checks, and pylint in parallel, confirmed it was a good idea, confirmed the mprocs.yaml could be committed to the repo — then the conversation ended. The knowledge is there; the implementation is not.

Recommendation: Create mprocs.yaml in one service (start with analyses-service) with four processes: pytest, ruff check ., python manage.py check, python manage.py migrate --check. Run it once. This converts research into muscle memory.

Effort: 30 minutes to set up, one week to form the habit.

2. Technical writing: reducing iteration cycles

Why it matters: You are actively investing in writing — a blog post, a management report skill, architecture documents. But the hook section of "Nine Mothers, One Baby" required three rewrites in the same session. That is a signal that the drafting process lacks structure, not that the ideas are weak.

What I observed: Three consecutive messages: "could you help me rephrase it in something cleaner?" — same request, same section, same session. The ideas were sound; the structure to get from idea to prose was missing.

Recommendation: Before drafting any section, write one sentence answering: "What do I want the reader to feel or believe after reading this?" Then write to that. It eliminates the back-and-forth because the target is explicit.

Effort: No time investment — just a habit change at the start of each writing block.

3. Strategic positioning in the LLM era

Why it matters: You asked: "In 2026, what are the ways for a software engineer to stay relevant?" — then the conversation moved on. This is a question worth spending real time on, not leaving as a passing thought.

What I observed: The question was detailed and self-aware (mental models of large Django projects, feature implementation speed, PR reviews). You are already doing several of the right things: building meta-tooling, investing in domain knowledge (epidemiology surveillance systems), writing publicly, improving communication. But you haven't articulated a personal strategy — just instincts.

Recommendation: Write a one-page personal positioning document: what you are uniquely good at that an LLM cannot replicate (domain knowledge of epidemiological systems, multi-country context, Pasteur network relationships), and what skills you want to deepen over the next 12 months. Treat it like architecture documentation — a living doc, not a one-time exercise.

Effort: Two hours to write, revisited quarterly.

4. Skill and tool inventory

Why it matters: You now have a growing library of custom Claude Code skills, scripts, and conventions (smart-read, what-i-have-done, commit, collect_conversations.py, collect_git_activity.sh, CLAUDE.md rules). This is valuable infrastructure — but it is undocumented as a whole. You discovered this yourself when you asked "is there a way to list available skills, commands, hooks?"

What I observed: Skills are spread across ~/.claude/skills/, scripts in ~/.claude/scripts/, and conventions in CLAUDE.md. There is no single place to see what you have, what each thing does, and when to reach for it.

Recommendation: Add a ## My Tools section to your global CLAUDE.md — a one-line description per skill and script, updated when you add something new. This also helps when onboarding colleagues to your workflow.

Effort: 20 minutes now, 2 minutes per new tool going forward.

Strengths Observed

  • Architecture before code: Notification V2 went through multiple document revisions and a colleague review before a line of implementation was written. This prevents expensive rework and is a mark of engineering seniority.
  • Communication investment: Building tools to translate technical work for management (what-i-have-done) and writing publicly about engineering realities (Brook's Law post) shows awareness that output alone is not enough — visibility and communication are force multipliers.
  • Tooling ownership: You actively shape your own environment rather than accepting defaults. CLAUDE.md, custom skills, conversation scanners — this compounds over time.

Action Items

  1. Create mprocs.yaml in analyses-service with the four core Django dev checks — run it before end of this week.
  2. Before the next writing session (blog or architecture doc), write the one-sentence target first.
  3. Draft a one-page personal positioning document: domain strengths + 12-month skill priorities.

Learning Resources

Parallelism in practice

Staying relevant in the LLM era

Technical writing