We require you to submit markdown plan before working on a feature, which must have full context, scope, implementation details. Also verification tests mardown file of happy path and critical failure modes that would affect customer, and how tests were performed. Must be checked in with the commit. More complex, large features require UML diagrams of architecture, sequences, etc. to be checked in too.
If your plan or verification docs have wrong context, missing obvious implementation flaws, bad coupling, architecture, interfaces, boundary conditions, missing test cases, etc then PR rejected.
Every developer’s performance is judged as a systems engineer. Thoughtless features without systems docs and continued lack of improvement in your systems thinking gets you PIPed.
That’s a good point. We’ve been using the UML diagrams as a tool to catch behavioral red flags, but the reuse and implementation details of that are left undefined.
Maybe the answer lies in also explicitly spending a few passes focusing on code health, explainability, maintainability (while keeping brain on). This is something I go through at end and then retry verification tests, but not something we explicitly require in our process at the moment.
But in the end you have to know what good looks like and be able to call bullshit. Hmm I guess strong first principles are still the foundation of being good at something, no matter how the tools change. And practice, feedback, and constraint exposure are what turn that into actual effectiveness.