I draw the same way. My sketches are tons and tons of lines in the wrong places that somehow end up looking right, because the majority of the lines are near to or in the right places.
Though this only works for the implementation side of things in my experience; you still need a good mental model of roughly what you’re aiming for architecturally, I think.
The job has only started when it is working. That doesn't mean you're done! :)
Also, the domain is so large in programming, it is impossible for me to contextualize the entire set of edge cases. From remembering what exceptions to handle to library interactions, types, etc.. returned from various methods, it is just not really possible to think about even a small system this way (as in a system with 4-5 methods that perform real logic beyond "format this"
But, yeah - definitely large picture before I start to code. "Huh, yeah that calls that... ok.." but once I need to solve a problem "oh, this queue needs to be maintained this way... I need to compare these values against these values, oh, I need a second queue... I need to take this lock... oh this returns this type, which needs to be serialized so I need to figure that out..." - all of that stuff needs to be hashed out in a combination of paper & code. No way I can hold that in my head.
And as another plus, that makes my code very readable for others. I leave the comments in.
If it's a problem that I have to address right now, it's more like prototyping the first idea that comes to mind and then debugging and refining and being more critical.
Reminds me of Rich Hickey’s Hammock Driven Development https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
Must have been less than 150 lines of C, but it was written in one go, compiled without warnings, and ran as expected.
Not even a forgotten comma, or an off-by-one.
I just sat there for five minutes enjoying the feeling of raw rarity.
