To what extent do you program by "sketching"?
In Hackers and Painters, Paul Graham talks about how he "sketches" as he programs:
For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
Do you do this too? To what extent?
LGC Decorators have finished little and enormous activities in Fulham region from painting the front way to the entire painter and decorator fulham structure rearrangement inside or remotely, likewise complete property repairs.
I always loved writing, and I always do it when I write. If I don't, the result is a total mess.
At the beginning, our knowledge is limited. We can't think about every little detail of our problem (which our software solve), so we need to sketch. If we don't, we will forget things, bring some misconception and create bugs.
By sketching, we defer the final decision. At the same time, we acquire knowledge about our problem. More we can defer the "final" solution, better it is, because it's easier to move code around and restructuring as much as we want.
I'm doing a lot of outlines as well, exactly like when I'm writing. I put the big ideas on the screen, then I move them around, without much implementation. Then I put more details, I see how it goes, and so on.
My mantra: take the decisions which will constrain your design as far in time as you can.
I always do architectural decisions and data model on paper 😁 this way I can have lots of oversight and flexibility — lately started using my iPad with Thoughts app (like a virtual canvas) and it’s even cooler because I can pan around and zoom in and out
This comment was deleted 5 years ago
Love the "solve the hard problem first" approach, but see it not as the opposite, but a complement to the "do the simplest thing that could actually work." The hard problem is your potential value proposition (solving it) and the simplest thing is an MVP that proves value before you refine it. After you build your MVP and reiterate to a strong foundational base of solving the hard problem you earn the right to, as you say, proceed to the fun stuff.
At least, that's my unique take after reflecting upon my past! 👍