The Lead Doesn't Write Code

Two executors on the main line, one on fixes, and a lead who only cuts, hands over and accepts. The moment the lead starts writing code, the facts stop being prepared - and the next batch of tasks costs more than the hour that got saved. 👋 I'm Anton - a software engineer working mostly in PHP/Symfony and Go, currently carving a live PHP monolith into Go services. The earlier parts of this series were about what a task must contain and how small it has to be cut. This one is about who does what once the cutting is a habit: the split of roles, and why the number of live executors is capped. Notes: github.com/brilliant-almazov . Maybe you run this better, maybe you'd draw the line somewhere else. Either way it's one arrangement on one codebase, not advice for yours. The thesis The lead doesn't write code. Not "shouldn't, mostly". Doesn't. The moment the lead starts writing code, the facts stop being prepared - and the next batch of tasks goes out with holes in it. That costs more than the hour of typing that got saved. The chain Five steps, and the lead owns all five: Prepare the facts. Exact paths, full type signatures, values, the acceptance command. This is the only place in the whole process where reading the code is allowed. Hand over. The executor gets the task whole, in one message. Accept the iteration - by its own package, one command, nothing else. Accept the stage - the full pass, exactly once, at the end. Close the executors. One that has finished is closed straight away. Then, once the set is closed, one more thing that isn't part of the loop: the audit of the set . It comes after step five, not instead of it. 1 2 3 4 5 ┌──────────┐ ┌────────┐ ┌────────────┐ ┌────────────┐ ┌──────────┐ │ prepare │─▶│ hand │─▶│ accept the │─▶│ accept the │─▶│ close │ │ the facts│ │ over │ │ iteration │ │ stage │ │ executors│ └──────────┘ └────────┘ └────────────┘ └────────────┘ └──────────┘ the only its own one full pass place reading package, at the end, the code is one co