Never stray from the way.

Developer Growth Report — 2026-06-22

Developer Growth Report

Period: 2026-06-15 to 2026-06-22 Generated: 2026-06-22

Work Summary

This week spanned 7 projects and 131 recorded messages — a dense, multi-domain sprint. The dominant thread was the WALIP health surveillance platform: auditing 6 Django microservices (consultation, analyses, patient, notifications, organizations, bio_bank), reasoning about cross-service data ownership, hardening Kafka consumers, securing Swagger endpoints, and exploring deployment infrastructure for multi-country rollouts. A second thread was content creation — a comprehensive article on the Senegalese road code (code-de-la-route-sn.md) requiring research, source verification, interactive mind maps, and structured HTML tables across 10+ sections.

DevOps thinking ran deep this week: the deployment repository (automatisation-deploiement-4s-sn-et-pays) triggered a full infrastructure analysis — mixed k8s/Docker Compose strategies per country, database migration approaches (Django ORM vs. raw SQL), and an exploration of OCI-artifact-based Compose includes and git submodules. There was also a brief but intentional foray into Zig, signaling a curiosity about systems-level programming beyond the Python/Django comfort zone.

The most significant event was personal: the user explicitly acknowledged having over-delegated code writing to AI over many months, and consciously chose to write code themselves — asking Claude to verify rather than generate.

Improvement Areas

1. Reclaiming Active Coding Ownership

Why it matters: Fluency degrades without exercise. The muscle memory for writing, debugging, and reading code is separate from the ability to instruct an AI. If the AI is always the one holding the keyboard, the engineer's own speed and confidence shrink over time.

What I observed: Direct self-report: "i spent so many months/weeks asking you to write code for me that i lost the habit :) i think i'm good now" (consultation-microservice session, June 17). Later in the same session, the user wrote the migration themselves and asked for verification — a concrete behavioral shift. This is significant and worth reinforcing deliberately.

Recommendation: Introduce a personal rule — for any task estimated under 30 minutes, write the code first, then ask for review. Use Claude for verification and feedback, not generation. Treat this like a gym habit: schedule 3 "solo coding sessions" per week where Claude is read-only.

Effort: Ongoing habit — zero extra time, just a change in mode.

2. Stop Bypassing Pre-commit Hooks

Why it matters: --no-verify is a deferred bug. Every bypass accumulates technical debt in the form of code that skipped the agreed-upon safety net. Worse, it normalizes the bypass as a workaround rather than signaling that the hook itself needs fixing.

What I observed: --no-verify was used across at least 4 separate commits in 3 different microservices this week (notifications, consultation, patient). In one session, the user explicitly said: "please just do a commit and use the --no-verify flag, we'll deal with pre-commit in a later time". The "later time" rarely comes.

Recommendation: Dedicate one focused session to auditing what pre-commit checks are failing and why. Fix the root causes (likely import sorting, type stubs, or missing test coverage). Add a note to your team's CONTRIBUTING.md that --no-verify requires a paired follow-up ticket. CI/CD should run the same checks — so bypassing locally only shifts the pain downstream.

Effort: 2–4 hours to audit and fix pre-commit configuration across the monorepo.

3. Formalizing Microservice Data Ownership Decisions

Why it matters: The WALIP platform has 6 services with fuzzy boundaries. This week saw multiple conversations about where models should live (Project model: analyses-service vs consultation-service?), what crosses via Kafka vs REST, and how to represent cross-service references (FK vs. string code vs. ArrayField). Without a shared decision framework, each engineer makes these calls differently.

What I observed: Three separate sessions involved the same class of question — "where should this model live?" and "should I store the ID or the code?". The reasoning was good each time, but there was no reference document to anchor decisions. The ArrayField approach for projects was implemented across Prescription, TDR, SymptomType, Vaccines, ChronicDisease — which is a significant cross-cutting decision that deserves explicit documentation.

Recommendation: Write a one-page Architecture Decision Record (ADR) for the WALIP platform covering: (1) which service owns which entities, (2) how cross-service references are represented (string codes vs. IDs), (3) when to use Kafka vs. REST. This document prevents the same reasoning from being re-derived in every session.

Effort: 3–4 hours to draft, review with team.

4. Deep Dive into Kafka Consumer Guarantees

Why it matters: The consumer porting work this week was done correctly, but the understanding of why each pattern matters — at-least-once delivery, auto-commit vs. manual commit, idempotency — was built incrementally through conversation rather than from a solid mental model. Gaps here surface as subtle bugs that don't crash but produce broken behavior (as the user found: 2 logic bugs missed in first review).

What I observed: After porting the improved consumer from analyses-service to notifications-microservice, the user asked: "before doing the commit, teach me about the algorithm, the principles that has been followed to write this consumer module". This is exactly the right instinct. The content was saved to a text file for future reference — but it hasn't been transformed into a working mental model yet.

Recommendation: Turn that saved text file (kafka_consumer.txt) into a blog article (you already write those). The act of explaining it for a reader cements understanding better than passive reading. Complement with a deliberate experiment: write a consumer that deliberately fails mid-batch and verify your error handling behaves correctly.

Effort: 4–6 hours (article draft + hands-on experiment).

5. Closing the DevOps Knowledge Gap Systematically

Why it matters: The deployment repository revealed several patterns the user encountered for the first time this week: OCI-artifact-based Docker Compose includes, mixed k8s/Compose per-country strategies, git submodules for deployment config sharing. Each was explored reactively — prompted by a problem, not proactively understood.

What I observed: Multiple "is this normal? is this something serious companies do?" questions around k8s vs Compose mixed deployments (June 18). The user was skeptical — correctly — about using k8s CronJobs for countries whose main stack runs on Compose. The analysis was sound, but the knowledge was assembled from scratch in session rather than drawn from existing mental models.

Recommendation: Pick one authoritative resource on production deployment patterns (Kelsey Hightower's Kubernetes the Hard Way, or the Docker Compose production guide) and work through it deliberately — not as a project, but as 30-minute reading blocks between coding sessions. Build the vocabulary so future deployment conversations start from a shared baseline.

Effort: 1–2 hours/week over 4 weeks.

Strengths Observed

  • Strong analogical thinking: Proactively sought aviation safety principles (CRM, checklists, dead-man's switch) to apply to Django API development — a rare and valuable habit. Keep doing this cross-domain synthesis.
  • Documentation discipline: Consistently saved key conversations to text files for future reference (aviation principles, infrastructure analysis, Kafka consumer patterns). This is how organizational knowledge gets built.
  • Knowing when to push back: In the WALIP metrics session, the user challenged WHO/CDC conventions rather than accepting them blindly — "is there really anything that I can do as a software engineer?" — and extracted actionable engineering implications. That intellectual honesty is a strength.

Action Items

  1. This week: Write one piece of code solo (no generation, only verification). The patient-microservice migration you wrote yourself is the model — repeat it deliberately.
  2. This week: Run pre-commit run --all-files on one microservice, list the failures, fix them, and document why they were failing.
  3. Next 2 weeks: Draft the WALIP ADR for service data ownership. Start with the projects ArrayField decision — it's already been applied across 5 models.
  4. Next month: Convert kafka_consumer.txt into a publishable article on the blog.
  5. Ongoing: 30 min/week of structured DevOps reading — pick one resource and stick to it for a month.

Learning Resources

Code Ownership & AI Dependency

Pre-commit Hooks & Git Discipline

Microservices & Event-Driven Data Ownership

Kafka Consumer Reliability

DevOps: Kubernetes vs. Docker Compose