If one can get their mind around it overnight then it's likely not in the class of hard problems the author is addressing.
You’d be surprised how experience can shorten the planning time.
Also, I’m not quite “neurotypical,” and avoid writing things down. I tend to keep my strategic model in my head. I’m constantly wargaming my strategy. You might be surprised at the scope of the project I’m doing right now. I’ve been working on it for around two years, and we’re getting within sight of the finish line. About the only time I write stuff down, is when I want to pass it by other team members.
I’ve also learned that, sometimes, there’s no substitute for writing some code, stepping through it, and seeing how that jives with your strategy.
To do things my way, you have to be willing to toss out a lot of code; sometimes, weeks’ worth of code.
What happens to the project if you get hit by a bus?
It’s over (but maybe not -see below).
Sucks, but that’s life.
This is a nonprofit, and they can’t afford to hire a large team of programmers. Heck, they can’t even afford me. I work for free.
The code, itself, is documented almost beyond belief. The only place I’ve ever seen documentation that even comes close to what I do, is in exposed Apple and Adobe code (where I got a lot of my inspiration). Don’t believe me? Look for yourself. My GH ID is the same as my HN ID[0]. All my code is like that. Look at any one of my projects. They are all heavily documented, and loaded with meaningful, relevant tests[1].
I’m a big believer in what I call “forensic design”[2], as well as really heavy-duty documentation[3].
So that means that, if there’s a developer with skill like mine, they’ll be able to take over the project in a relatively straightforward manner, but less-skilled people will probably be fairly stymied. They are likely to complain about my code, and rewrite from scratch, with typical modern crap code (and with typical modern crap results).
I’m not gonna do a crappy job, and make dross, just so some inexperienced jargonauts can mess up the project in the future. If that means it dies with me, then so be it. I’ve gone way beyond the pale, in delivering a project that can be maintained. If the people I deliver it to, mess it up by cheaping out on the hired help; that’s on them. They are the ones harnessing a racehorse to a plow.
I have a fair bit of prior art. I’ve written software architecture that has lasted decades, and has been taken over (and is still very much in use), by teams of skilled engineers. I don’t know if it’s still in use, as it’s been five years since I left my last company, but, at the time that I left, if you got their DSLR SDK, it had a C code API in it that I wrote in 1995.
[0] https://github.com/ChrisMarshallNY
[1] https://littlegreenviper.com/miscellany/testing-harness-vs-u...
[2] https://littlegreenviper.com/miscellany/forensic-design-docu...
[3] https://littlegreenviper.com/miscellany/leaving-a-legacy/
If you wasted weeks coding the wrong thing then you didn't solve it overnight. Making mistakes is a part of the process, you have to count that time as well.
That was what the OP said.
For me "typing code" is part of the thought process. These days, with GUI IDEs, and symbolic debuggers, there's almost no excuse to "measure twice; cut once," like we did in the "big iron" days.
I was trained as an artist, and the process of sketching is a lot like the way I work in architecting my code.
Also, I wouldn't call it "wasted" code. What was it that Edison is reputed to have said about 10,000 failed experiments?
"I now know 10,000 things that don't work."
I actually enjoy coding. I also really like my code to be clean, efficient, and useful. If code that I write is not all of these, I don't want it in my work.
I saw a chap that had a .sig that said something like:
"I hate code, and want as little of it as possible in my programs."
Few things make me feel as good as ripping out large swaths of code. It's like lancing a boil.
With coding, you are confined to formal syntax and semantics, but if the code (even partially) works, you can be more confident in your design.
With paper, you can plan as high-level as you want, with the danger of being too highlevel and overlooking things.
I cut my teeth, in the days when we were supposed to design the entire program; from start to finish, on a pad of paper, hand it to a data entry clerk, who would then create a deck of cards, based on the work.
It would then be scheduled for an expensive slice of time, and, if it screwed up, you got spanked.
It sucked. It really sucked.
Full disclosure: by the time I entered the field, punchcards had been replaced by VT-100 terminals and line printers, but the process was still the same, minus the data entry clerk.
These days, it's totally freewheeling. I try stuff out, screw up, kick myself, then try again.
I write about how I do stuff, here: https://littlegreenviper.com/miscellany/thats-not-what-ships...