Comment by aenis
19 days ago
I'd add:
Religiously, routinely refactor. After almost every feature I do a feature level code analysis and refactoring, and every few features - codebase wide code analysis and refactoring.
I am quite happy with the resulting code - much less shameful than most things I've created in 40 years of being passionate about coding.
This. Historically there's been a lot of resistance to the idea of refactoring or refining features. The classic "It works, just ship it" mentality that leaves mountains of tech debt in its wake.
And there _was_ a good reason to resist refactoring. It takes time and effort! After "finishing" something, the timeline, the mental and physical energy, the institutional support, is all dried up. Just ship it and move on.
But LLMs change the equation. There's no reason to leave sloppy sub-optimal code around. If you see something, say something. Wholesale refactoring your PR is likely faster than running your test suite. Literally no excuses for bad code anymore.
You'd think it didn't need to be said but, given we have a tool to make coding vastly more efficient, some people use that tool to improve quality rather than just pump out more quantity.
We are becoming spec writers, wearing the PM/lead hats.
1) Do a gap and needs assessment. 2) Build business requirements. 3) Define scope of work to advance fulfillment. 4) Create functional and non-functional specs. 5) Divide-conquer-refine loop.
This is the main thing I have learned too. I've been building an internal tool for myself to annotate lines in each commit diff as good (green) / needs refactor (yellow) / needs rewrite (red) and it has helped me keep track of this kind of tech debt. Basically does what you could do with "TODO refactor" comments all over, but is more comprehensive and doesn't litter your source code. Plan to open source it once I've dog-fooded it a little more