it was meant to say: "gong".
Also good.
It's called "Spec-Driven Development"
I didn't knew the name for it. Thank you. I'm pretty sure a prof at U told us a long time ago, but many years later I "reinvented it by myself", back when I was programming 8bit µCs in Assembler. If Assembler teaches you one thing, it's to document your code in a way you can understand what the code does, how, and why.
First write pure text, what you're going to do, and how, for the whole program. Today I place it into an own file, 'cause two or three pages of prose in the header is no fun to have in the code file. I have at least two vim sessions open at the same time: code and the according docu.
Also write down some ideas you have how to code something (mostly the core), if you already have such. Having a certain idea how to do a certain job is tempting to start directly on writing code. Not good. Because all the "rest around" is still not even sketched yet. Write it down, so you don't have the pressure to forget it.
Then there is two jobs to be done parallel: split the job into smaller parts, as prose text, which you only need to fill later with code. Those will become the in code comments. And write the code, while you correct/adapt the text/docu to it. Often enough I realize I need to reconsider the one thing or the other cannot be done as I thought in the first place. (In some of my sources actually textplaces can be found like "I have the feeling this can be done more elegant, but at this moment I cannot think of anything better.")
At the end, both jobs are done: working code, and a good documentation already done. No need to do the docu while new jobs already attracting, and having no interest anymore doing this dull, boring task, postponing it, finding arguments to shut up those who say documenation is needed...instead of doing it.
It sounds like twice the work, but it's not, since both needs to be done anyway. Plus you not only approach the code from two sides: code, and thinking about it in prose, which makes you reconsider more what you're doing, which IMO delivers not only better code, but brings you quicker to the target, since it also lightens debugging a lot.
Plus you have less pressure, because you don't need to think always of several parts in the code at the same time, fearing to forget something. The text is your notes: Having a sudden idea for another part of the code: Write it down now. Do it later.
Plus you come easy into work: Instead of staring at a blank screen for quite a while, thinking of code snippets in your head, you can directly start writing, which transforms into code almost automatically; and it's easier to delete some lines of prose BS written, than to realize you coded BS, and then bicker with yourself, how to remodel, to safe all the work, while you already know deep inside, this BS needs to be rewritten all over completely new again aynway.
