4 ms·

This question is well discussed. A lot of the problems that exist in software, a lot of the problems that one encounters in writing... in building a system, in

This question is well discussed. A lot of the problems that exist in software, a lot of the problems that one encounters in writing... in building a system, in writing a program: those are problems that are caused by not thinking about what you are doing before starting to code. - Leslie Lamport An idiot with a plan can beat a genius without a plan. - Warren Buffett No battle was ever won according to plan, but no battle was ever won without one. - Dwight D. Eisenhower To think, you have to write. If you're thinking without writing, you only think you're thinking. - Leslie Lamport Anything you do is an iterative process. You start out by thinking about something, and then you start writing it, and in the course of writing it, you rewrite and you rewrite and you rewrite. - Leslie Lamport ... via https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup PS. Full disclosure: I spent today rewriting something I coded yesterday... but generated a lot of written pages before starting both days! (It's a nontrivial problem. I do planning on paper because it's faster.) Now it's mostly there and well documented.

_gabe_ 4y ago
So are artists all idiots? Storyboards usually don't start with a full script. They start with sketches. Architectural designs start with sketches. Mathematical theorems start with tinkering with equations and notes. Are these people all idiots? Different professions have different methods of "sketching" out ideas. Just because writing is the de facto method of sketching out an idea in the business world, doesn't mean it's the right fit for every profession ever. Most programmers I know feel like writing exploratory code is a form of sketching an idea. I have nothing against writing out your thought process, but it's not desirable or useful in every scenario for writing a program. I was working on some low level multiplayer code about 6 months ago. I spent around 2 and a half weeks researching other methods. Then I spent another week drawing out designs. I was paralyzed because I didn't know what I didn't know. I finally got around to writing the stupidest code, and in 3 days I had an MVP. Yes, this is anecdotal. But I've been paralyzed by design too many times in the past. I would much rather write a rough draft of my code that works, learn a bunch in the process. Then edit it and refine it. Why does writing English have to be the only way to explore a problem? Why is it so difficult to imagine that writing exploratory code is similar to writing a rough draft of a paper? Finally, do research papers get written before they go through the process? No. They do the research, they experiment, then they document the results. I guess these darn researchers are all idiots that didn't realize writing an essay will tell them way more about their research than actual experimentation.
- talideon 4y ago
  > So are artists all idiots? No, and GP didn't remotely imply anything like that. In fact, your examples are exactly backwards. Let's take the quote you're likely referring to. > An idiot with a plan can beat a genius without a plan. - Warren Buffett When an artist sketches, they're creating a rough specification for what they're ultimately going to do. That's the point of a sketch. It might not be _exactly_ what gets made in the end, but it should largely indicative of the end product. The sketch is your initial specification. Filling in details in the sketch is your MVP. The artwork is the finished product. People create sketches because they realise they're not geniuses who can just slap paint on a canvas an expect it to work. > Why does writing English have to be the only way to explore a problem? Why is it so difficult to imagine that writing exploratory code is similar to writing a rough draft of a paper? No, but only if _you_ are the only audience for it. If others, especially others outside of your team are the audience, then you need documentation. > But I've been paralyzed by design too many times in the past. I would much rather write a rough draft of my code that works, learn a bunch in the process. Then edit it and refine it. You should do both. Write some docs, hit a brick wall, write an MVP to test things out and clarify your thinking, then go back and update the docs with your findings. You know, _iterate_. The problem isn't documentation, but that you fell into the trap of Big Design Up-Front. > Finally, do research papers get written before they go through the process? No. They do the research, they experiment, then they document the results. I guess these darn researchers are all idiots that didn't realize writing an essay will tell them way more about their research than actual experimentation. Well, no, that's not how it happens. Researchers don't just write up everything at the end after they've done everything: they need to actually _plan_ the kinds of experiments they do, _plan_ their methodology, _document_ all that. Does this all end up in the paper at the end? No, but it does end up in their lab books, which they're required to keep. Material from those lab books ends up in and edited form of the final paper. The mistake you're falling into is that you're assuming that this means that _everything_ has to be defined up front. But nobody's actually saying that. Sure, you might have a situation like the one you mentioned previously where somebody will ask you what the minimal latency for X will be, and it's OK to say "I don't know, I'll need a spike to write some kind of MVP to discover that" in response. That doesn't mean that documenting your intents isn't a good thing.

_gabe_ 4y ago

So are artists all idiots? Storyboards usually don't start with a full script. They start with sketches. Architectural designs start with sketches. Mathematical theorems start with tinkering with equations and notes. Are these people all idiots? Different professions have different methods of "sketching" out ideas. Just because writing is the de facto method of sketching out an idea in the business world, doesn't mean it's the right fit for every profession ever. Most programmers I know feel like writing exploratory code is a form of sketching an idea. I have nothing against writing out your thought process, but it's not desirable or useful in every scenario for writing a program. I was working on some low level multiplayer code about 6 months ago. I spent around 2 and a half weeks researching other methods. Then I spent another week drawing out designs. I was paralyzed because I didn't know what I didn't know. I finally got around to writing the stupidest code, and in 3 days I had an MVP. Yes, this is anecdotal. But I've been paralyzed by design too many times in the past. I would much rather write a rough draft of my code that works, learn a bunch in the process. Then edit it and refine it. Why does writing English have to be the only way to explore a problem? Why is it so difficult to imagine that writing exploratory code is similar to writing a rough draft of a paper? Finally, do research papers get written before they go through the process? No. They do the research, they experiment, then they document the results. I guess these darn researchers are all idiots that didn't realize writing an essay will tell them way more about their research than actual experimentation.

talideon 4y ago
> So are artists all idiots? No, and GP didn't remotely imply anything like that. In fact, your examples are exactly backwards. Let's take the quote you're likely referring to. > An idiot with a plan can beat a genius without a plan. - Warren Buffett When an artist sketches, they're creating a rough specification for what they're ultimately going to do. That's the point of a sketch. It might not be _exactly_ what gets made in the end, but it should largely indicative of the end product. The sketch is your initial specification. Filling in details in the sketch is your MVP. The artwork is the finished product. People create sketches because they realise they're not geniuses who can just slap paint on a canvas an expect it to work. > Why does writing English have to be the only way to explore a problem? Why is it so difficult to imagine that writing exploratory code is similar to writing a rough draft of a paper? No, but only if _you_ are the only audience for it. If others, especially others outside of your team are the audience, then you need documentation. > But I've been paralyzed by design too many times in the past. I would much rather write a rough draft of my code that works, learn a bunch in the process. Then edit it and refine it. You should do both. Write some docs, hit a brick wall, write an MVP to test things out and clarify your thinking, then go back and update the docs with your findings. You know, _iterate_. The problem isn't documentation, but that you fell into the trap of Big Design Up-Front. > Finally, do research papers get written before they go through the process? No. They do the research, they experiment, then they document the results. I guess these darn researchers are all idiots that didn't realize writing an essay will tell them way more about their research than actual experimentation. Well, no, that's not how it happens. Researchers don't just write up everything at the end after they've done everything: they need to actually _plan_ the kinds of experiments they do, _plan_ their methodology, _document_ all that. Does this all end up in the paper at the end? No, but it does end up in their lab books, which they're required to keep. Material from those lab books ends up in and edited form of the final paper. The mistake you're falling into is that you're assuming that this means that _everything_ has to be defined up front. But nobody's actually saying that. Sure, you might have a situation like the one you mentioned previously where somebody will ask you what the minimal latency for X will be, and it's OK to say "I don't know, I'll need a spike to write some kind of MVP to discover that" in response. That doesn't mean that documenting your intents isn't a good thing.