Developer Growth Report — 2026-06-08

Developer Growth Report

Period: 2026-06-01 to 2026-06-08 Generated: 2026-06-08

Work Summary

This week touched nine separate projects across backend microservices (Django/Python), an Angular frontend, documentation pipelines (Quarto/Pandoc), and infrastructure tooling (Kubernetes, Docker, shell scripting). The dominant technical focus was on the backend microservice platform: implementing soft-delete, a coordinated security hardening sprint across six services, and investigating export/filter inconsistencies in the analyses service.

A notable meta-theme ran alongside the feature work: you spent time explicitly improving your development tooling and constraints — refining CLAUDE.md, fixing the test-stub skill, and wiring up the plan-track system. This is a healthy signal. You are aware of the gaps in your workflow and investing in closing them, rather than just shipping features.

The breadth of the week is worth naming: backend, frontend, DevOps, documentation, and tooling all in seven days. That breadth is a genuine strength and also a source of the context-loss patterns discussed below.

Improvement Areas

1. The TDD red phase — from formality to genuine design signal

Why it matters: A test that fails only because of assert False, "implement me" teaches you nothing about your design. The value of TDD is in writing a test that describes the interface you wish existed and watching it fail for the right reason — the implementation doesn't exist yet. Skipping this produces tests that pass once you fill in the placeholder, without ever having validated that the test actually catches regressions.

What I observed: You spent a significant portion of June 6th refining TDD enforcement in CLAUDE.md and fixing the test-stub skill. You caught that assert False placeholders produce trivially-satisfied red steps ("the red step is satisfied — tests will always fail because of the placeholder, not because the logic is wrong"). You also asked about using pytest --collect-only to verify test existence before writing — and then correctly abandoned that as too complex. This shows sharp intuition about the problem but the fix is still being searched for.

Recommendation: For the next feature you implement — pick one model method or manager method — write the test before any implementation file is touched, run pytest -k test_name to confirm it fails with AttributeError or ImportError (not AssertionError from a placeholder), then implement. Do this three times deliberately and the habit wires in.

Effort: One intentional practice session per day for one week. No reading required — this is a muscle, not knowledge.

2. Django domain layer — confident migrations and manager design

Why it matters: Uncertainty at the ORM and migration layer slows down every feature. When you have to ask "what will happen to existing rows?", or iterate on a field name three times (is_active → is_deleted → is_active again), you are paying a cognitive tax on every domain change. Closing this gap makes refactoring faster and migrations less scary.

What I observed: During the soft-delete implementation, you asked "when applying the migration we just created about is_active, what will happen to the existing rows? Do we need an explicit migration to add True to all the existing rows?" — a valid question but one that a confident Django user resolves by reading the migration file directly. Separately, you noticed a difference between migrations for two services (one had AddField only, the other had AddField + AlterModelManager) and needed confirmation that the SQL was identical — this is a good instinct to verify, but the underlying mental model of what Django migrations track (schema vs. Python-layer manager registration) was not yet solid.

Recommendation: Read the Django docs section on custom managers and querysets back-to-back with the HackerNews thread linked below on building higher-level query APIs. Then open any migration file in your codebase, read it line by line, and explain to yourself what each operation does at the SQL level. Do this for three migrations of different shapes.

Effort: Two focused reading sessions (90 minutes total).

3. Security built into the workflow, not discovered after the fact

Why it matters: Every security finding discovered after a feature ships is a finding that lived in production for some time. The JWT log-scrubbing fix this week was correct and well-executed — but it was triggered by "could you help me make my Django project more secure?" after the feature was already running. A security checklist applied at PR time would have caught this before the first commit.

What I observed: The security sprint on June 2nd started with an explicit reactive prompt: "could you help me make my Django project even more secure and tell/show me how to detect if there are some cyberattacks possible on them?" The django-security-hunter scan (linked below, April 2026) is exactly the kind of tool that can be wired into a pre-commit or CI step to catch these passively. The OpenAPI/Swagger exposure behind DEBUG was similarly a finding, not a design decision made upfront.

Recommendation: Add one step to your PR checklist (or CLAUDE.md): before merging a new endpoint or model field, ask "does this touch auth, tokens, secrets, or logging?" If yes, run django-security-hunter before the PR is reviewed. This converts security from a sprint into a gate.

Effort: 30 minutes to wire up django-security-hunter in one project as a proof of concept.

4. Release pipeline codification — from scripting to a defined process

Why it matters: You asked on June 3rd: "what is the most cleanest, stable, robust approach to do a release?" — and the SQL migration script you started with that day was described as written "à la va vite" (hastily). These two signals together mean the path from develop to production is not yet documented, automated, or reliably repeatable. Every release carries unquantified risk.

What I observed: You have multiple environments (develop → recette → release → production), database migrations sometimes done via manage.py migrate and sometimes via raw SQL scripts, and environment variable setup that currently requires manual Kubernetes configmap edits (which you also built a script for this week). The individual tools exist; the pipeline connecting them does not.

Recommendation: Write a single RELEASE.md at the repo root of your most-deployed service describing the current manual steps in order. Do not automate yet — just document what actually happens. The act of writing it will reveal the gaps, the ordering assumptions, and the steps that are error-prone. Then automate the one step you do most often.

Effort: 2-hour documentation session; automation of one step is a separate sprint.

5. Cross-session project memory — structured tracking to avoid context loss

Why it matters: When you have to ask "do you remember this bash script?", or say "I completely forgot what we were doing" about an in-progress project (dorkat), you are paying a re-orientation tax at the start of every session. For a developer working across 9 projects simultaneously, this compounds quickly.

What I observed: On June 7th you asked me to help locate a Kubernetes script from a previous conversation. On June 6th you opened the dorkat project and said "I completely forgot" what was in progress, needing to read PLAN files to reconstruct context. Both cases were resolved successfully — but only because the artefacts existed (the script, the PLAN files). The pattern suggests the PLAN.md system you set up is working but not yet consistently used across all projects.

Recommendation: At the close of each session (not just at the start), write one sentence to the PLAN.md or TODO.txt of the project you were in: "Stopped here: [what you were doing] — next step is [X]." Two minutes at session end saves fifteen minutes at the next session start. The dorkat experience is the proof.

Effort: A two-minute habit at each session close. The tooling (PLAN.md) already exists.

Strengths Observed

• Breadth without shallow execution: Across nine projects in seven days, every deliverable was tested, committed properly, and reasoned through carefully. You do not ship half-measures.
• Design intuition on domain modeling: When colleagues suggested is_deleted, you pushed back on the right grounds ("one day None, another day a date, another day None again — not consistent enough") and defended the correct field semantics.
• Meta-investment in tooling: Spending time fixing the test-stub skill, refining CLAUDE.md, and adding the plan-track system shows awareness that developer workflows compound. Engineers who ignore this debt become slower over time; you are going the other way.

Action Items

1. Write one test using a real assertion (no placeholder) before touching an implementation file — do it for the next function you add anywhere. Confirm red with pytest -k.
2. Add django-security-hunter to one project's pre-commit or CI pipeline this week.
3. Write RELEASE.md for the analyses-service: document the current manual release steps in order, no automation yet.
4. At the end of today's last coding session: write one sentence to the relevant PLAN.md — "Stopped here: X, next step is Y."

Learning Resources

Django ORM and domain layer

• Building a higher-level query API: the right way to use Django's ORM — Classic HN thread on PassThroughManager and composable querysets; directly relevant to the domain-logic-in-views problem you identified.
• Taming the beast that is the Django ORM – An introduction — More recent (2024) overview with emphasis on query optimisation patterns; good mental model for manager vs. queryset design.
• Django: One ORM to rule all databases — HN discussion on ORM trade-offs; useful for understanding when to reach for raw SQL in migrations.

TDD — the red phase

• Red/Green TDD — Recent HN thread (2026) directly on the red/green cycle and what makes a red phase meaningful.
• Ask HN: Seriously, how do you TDD? — Practitioner answers on what TDD actually looks like in production codebases; useful for calibrating expectations.
• Test Driven Development for your LLMs? Yes please — Relevant for your Claude-assisted workflow specifically.

Security built into workflow

• Show HN: Django-security-hunter – Django security scanner CLI — April 2026; the exact tool to wire into pre-commit for the JWT/SECRET_KEY class of issues.
• Authentication with Django and Single Page Apps — HN discussion on JWT vs. session auth in Django; useful context for the log-scrubbing decisions you made.

Release pipeline design

• The CD Pipeline Manifesto — Principled approach to continuous delivery; good framing for the develop → recette → production flow.
• Ask HN: How do you do CI/CD in 2025? — Practitioner answers from Oct 2025; useful for understanding what mature teams actually do vs. what the docs say.
• Managing Databases in a CI/CD pipeline is frankly difficult — Directly addresses the "sometimes manage.py migrate, sometimes raw SQL" problem you have.

Cross-session context and habits

• Habits of great software engineers — HN discussion with practitioner habits; the session-close note-writing habit is discussed in several comments.
• Good Software Development Habits — Nov 2024 thread with concrete micro-habits; short read, high signal density.

Report covers engineering work sessions from 2026-06-01 to 2026-06-08. Generated 2026-06-08.