> Most programming should be done long before a single line of code is written
I would say “most engineering should be done before a single line of production code is written”.
Formalizing a “draft process” is something I’m really trying to sell to my team. We work in an old codebase - like, it’s now older than most of the new hires. Needless to say, there’s a whole world of complexity in just navigating the system. My take: don’t try to predict when the production code will be done, focus on the next draft, and iterate until we can define and measure what the right impact will be.
The problem is that there’s a ton of neanderthal software engineering management thinking that we’re just ticket machines. They think the process is “senior make ticket, anyone implement ticket, unga bunga”. What usually happens here is that we write a bunch of crappy code learning the system, then we’re supposed to just throw that in a PR. Then management is like “it’s done, right” and now there’s a ton of implicit pressure to ship crap. And the technical debt grows.
I haven’t quite codified a draft process, but I think it’s kind of in line with what Chris here is talking about: you shouldn’t worry about starting with writing production code until you’re very confident you know exactly what to do.
Ah well, it’s a fun list of opinions to read. Chris’ WIP book is an interesting read as well