Jim Coplien on how one of Dave Thomas' companies do software [2]:
"They build a prototype, then they throw it away. They learn from the prototype. Then they build the product, and throw it away. And then they build the deliverable; and ship release 1, release 2, and release 3--and throw it away. Every third release, they are throwing things away. Do you think they have any problems with technical debt?"
After he talked about throwing away code, he started hammering on the idea of understanding your domain. I don't think you can program without rich domain knowledge, if you are, then the software you write is very narrowly focused.
My idea of programming has shifted quite dramatically over the last couple months towards almost a hyperfocus on the domain, the data representation of that domain and the hierarchy of abstractions that we use to represent the ideas in the domain and the physicality in the data (and some extent the algorithms).
A computer program is a great way to let you know that you still have parts of the domain to understand.
We should be working in systems that are finely tuned TO the domain, so that we can play with concepts as easy as declaring self evident facts, so that we can constantly be throwing it away.
I experience this so often that I try to intentionally write software the first time with as little architecture as possible, so that there's less to strip out when the "correct" architecture becomes clear. Just leave everything as a big bag of functions and mostly-unstructured values passed on the stack, until it's working. Then figure out what abstractions might help make the code more expressive.
This approach has made my work much more relaxed and reduced stress a lot. The beauty of just first making it work somehow before going into design is that you can get rid of a good chunk of the unknown unknowns beforehand and you have a known working version you can always revert back to. It's less likely that you suddenly hit a brick wall when you think you are about to finish.
This is also my approach to organizing my room: first I put everything on the floor. Once I can see it all at once, I see out how things relate to one another.
I find it harder to see code all at once though (some IDEs have an "outline" of all variables and functions, but my current editor does not), and I wish there were more ergonomic ways to rearrange the order of things in code.
Funny enough, a big bag of functions and stack passed values is an accurate representation of assemble - how a computer might actually work. We often forget we're programming stack based machines
Generally agree, but I fall prey to the Second System Effect sometimes, tho. I rewrite my "organically grown into spaghetti code over some time" original program, aiming for a proper design, and end up with some overengineered mess that's hard to maintain and burns CPU and/or memory in layers of abstractions. The 3rd time then is the charm for me, more often than I'd like to admit - avoiding the pitfalls of original program and having learned the real requirements/needed features and details from it, and avoiding the overengineering of the 2nd attempt reminding me to KISS.
"Writing is nature's way of letting you know how sloppy your thinking is." [1] Dick Guindon
"To think, you have to write. If you're thinking without writing, chances are you're fooling yourself. You're only pretending to think." [1] Leslie Lamport
So much, this - I've occasionally gotten the opportunity to rewrite a piece of software and it is always a much better design the 2nd time.