8 ms·

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a p

> Never start coding (making a solution) unless you fully understand the problem. While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. a) because when I break down a problem into its code-able component parts, I learn a lot about it b) because in the process of then actually implementing these parts I often discover edge cases or undefined cases (especially in naturally grown business-logic) c) because what the problem actually IS, is often not that clear at the start of the problem. Yes, in an ideal world, changing requirements would wait until the next version, however, sadly that's not what happens in the wild.

pan69 5y ago
I call this, Insight by Progress. I.e. the further you progress into a problem the more insight you gain. Personally I have never 100% solved a problem before writing any code. For me it really the other way around. By writing the code I better understand the problem. I guess what we're dealing with here is that different brains solve similar/same problems in different ways. I guess its also the reason that advice such as "Never start coding ... unless ..." doesn't work for everyone.
- usrbinbash 5y ago
  > I guess what we're dealing with here is that different brains solve similar/same problems in different ways. I think the main difference is between human brains and machines. Biological systems operate with a kind of "fuzzy logic" by default...glancing over edge cases, smoothen out discrepancies on the fly, filling in missing information with context knowledge or assumptions, etc. Being imprecise is not a problem, in fact being able to handle the imprecise, is what keeps living things going. When we describe a problem to a human like "take that crate and put it in the next room", we know that he will fill in the gaps (hopefully) like not assuming that the cleaning closet is the "room" we meant, even tho its right next to the starting room, and its technically a room. Describing this to a computer is different. Edge cases need to be considered. What if there is no crate? What if there are many, which one does he need to get? What does "in the room" mean? Does the orientation of the crate matter? What do I do when the room is full? "Next" on which side of the corridor? And so on, and so on. Only in having to describe a problem in an algorithmic way, can we fully appreciate all of its parts, and the information flowing through the process.
paskozdilar 5y ago
I agree. Coding a solution is my main approach to understanding a problem better. While it is possible to completely understand the problem before writing a solution, it takes much less time to just build a prototype, analyze it to see what mistakes you made, rinse and repeat. Note that the third principle of the "unix philosophy" is[0]: Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. [0] https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...
- koide 5y ago
  The key part here is that you shouldn't be afraid of throwing parts (or even throwing wholes) away. Many times we get too attached to solutions to the wrong problem because that's what we built. So in that sense we could rephrase the idea as do not commit to the code you write until you have a good understanding of the problem. Use it as a learning tool.
  - Sharlin 5y ago
    Yep. It’s fine to explore the problem space by coding. It’s not fine to think you already have the solution and end up coding yourself into a dead end. Ie. solving the wrong problem.
  - jimmygrapes 5y ago
    Yeah I believe this was identified as the main thing leading to the log4j debacle; they intentionally kept the offending code in there for backwards compatibility and edge cases, which really should have been thrown out a long time ago forcing users to accommodate the update or remain knowingly compromised.
    - paskozdilar 5y ago
      While what you say is true, the context is a little bit different. Java built its whole world on the premise that you write your code once, and you run it everywhere [forever]. Every single breaking change loses you a bit of customers - I suppose Java just cared more about keeping their customers, rather than keeping their customers safe.
Hendrikto 5y ago
If you read ahead two sentences: > You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. So the author seems to agree, somewhat contradicting his own point.
quickthrower2 5y ago
If like most of us you are working on legacy (as opposed to greenfield) then the existing code is a part of the problem space. Coding (and debugging) is a good way to understand that problem!
2OEH8eoCRo0 5y ago
This one is weird but I agree with the gist of it. You shouldn't be coding until you understand the problem and have a high level design planned out in one form or another.
is0tope 5y ago
Definitely agree. I think some people find it controversial these days with agile etc but i think making prototypes is a severely underrated skill and practice. Not all problems are obviously tractable from the outset by pure analysis. Sometimes you need to build something out of cardboard and rubber bands (figuratively) to see if it will work. Was a topic I wrote an essay about some time back (https://www.machow.ski/posts/galls-law-and-prototype-driven-development/ https://www.machow.ski/posts/galls-law-and-prototype-driven-...).
- renewedrebecca 5y ago
  The weird danger of making prototypes are managers who think having a prototype means you're almost done with the whole task. This is especially bad when the prototype works, but doesn't work well. They think you just need to polish things up a bit when really, you need to take what you've learned and build the real deliverable.
  - is0tope 5y ago
    Yes this is very true. There's a certain amount of managing upward, and expectation setting that is required. Unfortunately a common feature of many companies these days is non-technical management managing technical staff, and in such cases it's indeed a dangerous proposition. Another example perhaps as to how the software engineering field still has significant maturing to do vs. e.g. mechanical engineering.
blenderdt 5y ago
This is why a good IDE is so important. Since I use Jetbrains products (Rider, PhpStorm) I don't worry about refactoring anymore. This results in a very agile way of working. I believe people underestimate the power of a good IDE.
- whynotminot 5y ago
  > I believe people underestimate the power of a good IDE. Definitely. And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. Which, sure, vim is great! And you can get a lot of decent plugins that can make that workable. But gosh IDEs provide so much powerful functionality, why would you make your life harder on purpose by not using them. That attitude does seem to be fading though, in my more recent experience.
  - paskozdilar 5y ago
    > And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. I share the sentiment, but for completely other reasons. Human mind is very limited - it can only hold so much complexity at once before it starts making mistakes and oversights. IDE's raise that bar of tolerable complexity, making it easier for people to build enterprise-level Rube Goldberg's machines just to keep the software working. Using Vim (or any other non-IDE editor) forces me to keep the software simple, because otherwise I can't understand it. And in my experience, keeping software simple (long term) is much more important than keeping software working (short term). Of course, sometimes we have no choice but to meet the deadline. That's where all those bells and whistles really come in handy.
    - jcelerier 5y ago
      > Of course, sometimes we have no choice but to meet the deadline What do you mean, "sometimes"?
      - egypturnash 5y ago
henrik_w 5y ago
Completely agree! This is my number 1 point on my own "I've developed SW for decades, here's what I have learnt"-post: 1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution. I like this quote from John Gall: “A complex system that works is invariably found to have evolved from a simple system that worked.” From: https://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...
- _hcuq 5y ago
  Your principles are better than the OP’s.
- zelphirkalt 5y ago
  I would say, that it is not so easy to make this from-small-to-big approach work. It requires planning ahead on another layer. When you develop something small, which is supposed to grow later, you need to make sure to not bake in assumptions, which do not hold for later versions. You need to keep the primitives flexible. I see this as a basic skill, that we should aim to master at some point, even if we may never truly master this art. If we do not move carefully around assumptions, we will have to refactor things later, which means more work. Of course moving carefully can also consume time. At some point it may become a tradeoff.
derangedHorse 5y ago
I think that line may be more focused on eliminating any known ambiguities in the requirements rather than trying to determine any unknown ambiguities or tackling edge cases and bugs.
- dhimes 5y ago
  I agree.
timmg 5y ago
> While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. Me too. Sometimes when I don't feel like I really know how to solve a problem, I'll just write some really hacky code to try to get an answer. Just anything that moves the problem forward. Then once I understand what I want to do better, I either throw out that code and start clean. Or I just refactor the heck out of it until it is in a good state.
JKCalhoun 5y ago
Yeah, it could just be me, but I prefer to make two false starts, toss them, and then get it right on the third attempt rather than attempting to whiteboard the problem for two weeks. Not only is it more interesting to me to try three different ways to tackle a problem, but I have been burned when the two weeks of whiteboarding missed something and I'm back to having to iterate anyway. To be sure, I do a little whiteboarding, but generally it might be about 2 hours or so of sketching out ideas, major structures, code flow ideas. I generally was nodding along to most of the author's points though. I definitely have grown to divorce myself from my ego and always try to not only try to shine the spotlight on my younger coworkers (new engineers) but try to give them "ownership" of key pieces to allow them not only some sense of autonomy/ownership but a sense of pride as well. That does go slightly against some of the author's points about collaboratively working on a project. Engineers need a part of the code (let's say an image cache manager, as an example) that they can "own" though in order to grow. You don't want an engineer to always have "training wheels" on. (And frankly, I think this is one of the things I dislike about code reviews, I think it dis-incentivises autonomy.) The team though, let me be clear, is the most important part of any project, not the individual luminaries. The "team" though, to a degree, needs to have engineers who feel an ownership stake in pieces of the product. (FWIW, I have probably 35 years of programming experience, ha ha.)
- Palomides 5y ago
  I forget where I read this, but something like: first time to understand the problem second time to understand the solution third time to do it right
  - joseluis 5y ago
    it reminds me of some adage for surgeons in training: see one, botch one, nail one.
    - arethuza 5y ago
      I thought it was "See One, Do One, Train One"... which might actually be worse!
verinus 5y ago
me too... I usually so a vertical proof of concept where I tackle each step I understand in a unit-test. ofc it's no unit test- the test framework just serves as an quick entry point where I can test different approaches next to each other or different versions/variants of each approach. like a repl with the benefit of an easy view of my "history" with the ability to step back in time.
omginternets 5y ago
That's not coding the solution though, that's exploring the problem. Obviously it's helpful to formalize the problem! This is no different from manipulating mathematical equations on a piece of paper. =)
fizx 5y ago
This is pretty similar to the "pantsers vs plotters" debate in creative writing. Do you need an outline before writing a novel? How much of one?
- syngrog66 5y ago
  both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)
  - slothtrop 5y ago
    If one ever does forgo an outline (I'm not sure if this is ever done), you'd probably have to revise the entire thing a lot, such that you're imposing an outline anyway.
    - syngrog66 5y ago
      bingo. agreed. been bit by that a lot, esp when younger haha. my 1st book had no outline. my 2nd and 3rd books both have outlines. while still trying to keep the baby, minus the bathwater. I like the results, and the total sunk LOE much much better. related semi-tangent: with fiction I also adopted the rule to write the Ending first. because, for me at least, it then crystallizes what sorts of Middles and Beginnings might lead to it, and make the most sense or have the biggest emotional impact on the reader. which then practically paints out the character journeys for you, as the author. very helpful tactic
    - kayodelycaon 5y ago
      > If one ever does forgo an outline It's more common than you think.
  - kayodelycaon 5y ago
    > you also need a well-thought out outline for any larger work like a novel Hasn't been the case for me so far. Every story and essay I've written started with an idea. If there is an outline, it gets thrown away page 2 and never returns. On my second novel and this still hasn't changed. My writing is actually better this way because I start with characters and plot emerges as they deal with the forces around them. I never know how they will react until they do. I program the same way. Write a bit, revise, write a bit, revise. Drives some people nuts if they see the process, but the end result has been just as good or better than my coworkers throughout my career. (I'm a huge fan of tests. My revise step includes adding tests.)
seanmcdirmid 5y ago
I think this is common for many programmers. Programming isn't just a way to implement the solution to a problem, it is also a way to find solutions to problems (by working them out in code). Often times, programming can also help you figure out what the problem is. Programming isn't just about implementing things, it can also help with thinking.
bsedlm 5y ago
the 'beautiful' thing about this, is that it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards. In my experience they'd only relucantly agree if and only if it's "do this or die". Which then happens under time-pressure or under stress factors of other kinds. "if it already works, why fix it?" (because it's making developer's lives much more difficult than they could be? --"but how does this increase revenue?" --errhmm... because incresaingly difficult to maintain? but they don't care about this "that's your job")
- CRConrad 5y ago
  > it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards. > "if it already works, why fix it?" I suppose one attempt at a fix for this would be to make the user interface of your prototype the least prioritised part; maybe even go out of your way to make it ugly and clumsy, so the thing as a whole looks more like a prototype and less like a "solution".
munificent 5y ago
This idea is the source of Fred Brooks' observation: "Plan to throw one away. You will anyway." In order to implement a good solution you need to understand the problem well. Often, the only way to reach that level of understanding is by trying and failing to implement it. These days, with modern refactoring and incremental development, it's less throwing away a whole program and more gradually refactoring it until little of the first code remains but I think the observation still holds in many cases.
zarkov99 5y ago
I think this depends on the scale of the problem. For small, algorithmic, problems, the kind you would see in a coding interview I find it far more efficient to solve on paper, or on your head, before getting bogged down in code. The difficulty in these types of problems is not understanding the issue but coming up with a solution. For much larger problems, just getting you head around the problem is very challenging and you need some scaffolding, in the form of half-backed, but still precisely described solutions, simply to provide ballast to your thought process.
MrPatan 5y ago
Analysis through synthesis
polishdude20 5y ago
In a way, coding can be thought of as two distinct things. One: coding is a way to play around with ideas, equivalent to a back of the napkin calculation, a diagram in the sand or a pencil sketch of a part. We use code in this scenario more as a way to write down our thoughts and process. But rather than writing in just pure English and writing an essay or a set of Todos, we write more detailed "specs". "Do this three times or until this value is zero" is also written in code and perfectly understandable in code too. Two: code is used to run by a computer to produce an outcome. In this case, the back of the napkin sketch IS the part but more thought out. Society is so used to there being two material objects between the "plan" and the"final product" that we forget that code is different. With code, the plan and the final product are of the same form. Of the same physical space.
- marssaxman 5y ago
  The same distinction still holds in programming - it's just that the process of using the plan to generate the final product has been automated, by that handy class of tools we call "compilers".
jhgb 5y ago
>> Never start coding (making a solution) unless you fully understand the problem. > While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. I'd go as far as to say that programming is a good medium for expressing poorly understood and sloppily formulated ideas. Oh, wait, someone else already said that...

pan69 5y ago

I call this, Insight by Progress. I.e. the further you progress into a problem the more insight you gain. Personally I have never 100% solved a problem before writing any code. For me it really the other way around. By writing the code I better understand the problem. I guess what we're dealing with here is that different brains solve similar/same problems in different ways. I guess its also the reason that advice such as "Never start coding ... unless ..." doesn't work for everyone.

usrbinbash 5y ago
> I guess what we're dealing with here is that different brains solve similar/same problems in different ways. I think the main difference is between human brains and machines. Biological systems operate with a kind of "fuzzy logic" by default...glancing over edge cases, smoothen out discrepancies on the fly, filling in missing information with context knowledge or assumptions, etc. Being imprecise is not a problem, in fact being able to handle the imprecise, is what keeps living things going. When we describe a problem to a human like "take that crate and put it in the next room", we know that he will fill in the gaps (hopefully) like not assuming that the cleaning closet is the "room" we meant, even tho its right next to the starting room, and its technically a room. Describing this to a computer is different. Edge cases need to be considered. What if there is no crate? What if there are many, which one does he need to get? What does "in the room" mean? Does the orientation of the crate matter? What do I do when the room is full? "Next" on which side of the corridor? And so on, and so on. Only in having to describe a problem in an algorithmic way, can we fully appreciate all of its parts, and the information flowing through the process.

paskozdilar 5y ago

I agree. Coding a solution is my main approach to understanding a problem better. While it is possible to completely understand the problem before writing a solution, it takes much less time to just build a prototype, analyze it to see what mistakes you made, rinse and repeat. Note that the third principle of the "unix philosophy" is[0]: Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. [0] https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...

koide 5y ago
The key part here is that you shouldn't be afraid of throwing parts (or even throwing wholes) away. Many times we get too attached to solutions to the wrong problem because that's what we built. So in that sense we could rephrase the idea as do not commit to the code you write until you have a good understanding of the problem. Use it as a learning tool.
- Sharlin 5y ago
  Yep. It’s fine to explore the problem space by coding. It’s not fine to think you already have the solution and end up coding yourself into a dead end. Ie. solving the wrong problem.
- jimmygrapes 5y ago
  Yeah I believe this was identified as the main thing leading to the log4j debacle; they intentionally kept the offending code in there for backwards compatibility and edge cases, which really should have been thrown out a long time ago forcing users to accommodate the update or remain knowingly compromised.
  - paskozdilar 5y ago
    While what you say is true, the context is a little bit different. Java built its whole world on the premise that you write your code once, and you run it everywhere [forever]. Every single breaking change loses you a bit of customers - I suppose Java just cared more about keeping their customers, rather than keeping their customers safe.

Hendrikto 5y ago

If you read ahead two sentences: > You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end. So the author seems to agree, somewhat contradicting his own point.

quickthrower2 5y ago

If like most of us you are working on legacy (as opposed to greenfield) then the existing code is a part of the problem space. Coding (and debugging) is a good way to understand that problem!

2OEH8eoCRo0 5y ago

This one is weird but I agree with the gist of it. You shouldn't be coding until you understand the problem and have a high level design planned out in one form or another.

is0tope 5y ago

Definitely agree. I think some people find it controversial these days with agile etc but i think making prototypes is a severely underrated skill and practice. Not all problems are obviously tractable from the outset by pure analysis. Sometimes you need to build something out of cardboard and rubber bands (figuratively) to see if it will work. Was a topic I wrote an essay about some time back (https://www.machow.ski/posts/galls-law-and-prototype-driven-development/ https://www.machow.ski/posts/galls-law-and-prototype-driven-...).

renewedrebecca 5y ago
The weird danger of making prototypes are managers who think having a prototype means you're almost done with the whole task. This is especially bad when the prototype works, but doesn't work well. They think you just need to polish things up a bit when really, you need to take what you've learned and build the real deliverable.
- is0tope 5y ago
  Yes this is very true. There's a certain amount of managing upward, and expectation setting that is required. Unfortunately a common feature of many companies these days is non-technical management managing technical staff, and in such cases it's indeed a dangerous proposition. Another example perhaps as to how the software engineering field still has significant maturing to do vs. e.g. mechanical engineering.

blenderdt 5y ago

This is why a good IDE is so important. Since I use Jetbrains products (Rider, PhpStorm) I don't worry about refactoring anymore. This results in a very agile way of working. I believe people underestimate the power of a good IDE.

whynotminot 5y ago
> I believe people underestimate the power of a good IDE. Definitely. And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. Which, sure, vim is great! And you can get a lot of decent plugins that can make that workable. But gosh IDEs provide so much powerful functionality, why would you make your life harder on purpose by not using them. That attitude does seem to be fading though, in my more recent experience.
- paskozdilar 5y ago
  > And in some parts of the tech world, people actually deride the usage of an IDE! "If you're not using vim you're a newb," kinda deal. I share the sentiment, but for completely other reasons. Human mind is very limited - it can only hold so much complexity at once before it starts making mistakes and oversights. IDE's raise that bar of tolerable complexity, making it easier for people to build enterprise-level Rube Goldberg's machines just to keep the software working. Using Vim (or any other non-IDE editor) forces me to keep the software simple, because otherwise I can't understand it. And in my experience, keeping software simple (long term) is much more important than keeping software working (short term). Of course, sometimes we have no choice but to meet the deadline. That's where all those bells and whistles really come in handy.
  - jcelerier 5y ago
    > Of course, sometimes we have no choice but to meet the deadline What do you mean, "sometimes"?
    - egypturnash 5y ago

henrik_w 5y ago

Completely agree! This is my number 1 point on my own "I've developed SW for decades, here's what I have learnt"-post: 1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution. I like this quote from John Gall: “A complex system that works is invariably found to have evolved from a simple system that worked.” From: https://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ https://henrikwarne.com/2015/04/16/lessons-learned-in-softwa...

_hcuq 5y ago
Your principles are better than the OP’s.
zelphirkalt 5y ago
I would say, that it is not so easy to make this from-small-to-big approach work. It requires planning ahead on another layer. When you develop something small, which is supposed to grow later, you need to make sure to not bake in assumptions, which do not hold for later versions. You need to keep the primitives flexible. I see this as a basic skill, that we should aim to master at some point, even if we may never truly master this art. If we do not move carefully around assumptions, we will have to refactor things later, which means more work. Of course moving carefully can also consume time. At some point it may become a tradeoff.

derangedHorse 5y ago

I think that line may be more focused on eliminating any known ambiguities in the requirements rather than trying to determine any unknown ambiguities or tackling edge cases and bugs.

dhimes 5y ago
I agree.

timmg 5y ago

> While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. Me too. Sometimes when I don't feel like I really know how to solve a problem, I'll just write some really hacky code to try to get an answer. Just anything that moves the problem forward. Then once I understand what I want to do better, I either throw out that code and start clean. Or I just refactor the heck out of it until it is in a good state.

JKCalhoun 5y ago

Yeah, it could just be me, but I prefer to make two false starts, toss them, and then get it right on the third attempt rather than attempting to whiteboard the problem for two weeks. Not only is it more interesting to me to try three different ways to tackle a problem, but I have been burned when the two weeks of whiteboarding missed something and I'm back to having to iterate anyway. To be sure, I do a little whiteboarding, but generally it might be about 2 hours or so of sketching out ideas, major structures, code flow ideas. I generally was nodding along to most of the author's points though. I definitely have grown to divorce myself from my ego and always try to not only try to shine the spotlight on my younger coworkers (new engineers) but try to give them "ownership" of key pieces to allow them not only some sense of autonomy/ownership but a sense of pride as well. That does go slightly against some of the author's points about collaboratively working on a project. Engineers need a part of the code (let's say an image cache manager, as an example) that they can "own" though in order to grow. You don't want an engineer to always have "training wheels" on. (And frankly, I think this is one of the things I dislike about code reviews, I think it dis-incentivises autonomy.) The team though, let me be clear, is the most important part of any project, not the individual luminaries. The "team" though, to a degree, needs to have engineers who feel an ownership stake in pieces of the product. (FWIW, I have probably 35 years of programming experience, ha ha.)

Palomides 5y ago
I forget where I read this, but something like: first time to understand the problem second time to understand the solution third time to do it right
- joseluis 5y ago
  it reminds me of some adage for surgeons in training: see one, botch one, nail one.
  - arethuza 5y ago
    I thought it was "See One, Do One, Train One"... which might actually be worse!

verinus 5y ago

me too... I usually so a vertical proof of concept where I tackle each step I understand in a unit-test. ofc it's no unit test- the test framework just serves as an quick entry point where I can test different approaches next to each other or different versions/variants of each approach. like a repl with the benefit of an easy view of my "history" with the ability to step back in time.

omginternets 5y ago

That's not coding the solution though, that's exploring the problem. Obviously it's helpful to formalize the problem! This is no different from manipulating mathematical equations on a piece of paper. =)

fizx 5y ago

This is pretty similar to the "pantsers vs plotters" debate in creative writing. Do you need an outline before writing a novel? How much of one?

syngrog66 5y ago
both. you absolutely benefit from being free to improvise and follow the creative muse when pen on paper you also need a well-thought out outline for any larger work like a novel, or, it will be a disaster, or at least not be anywhere as good as it could have been credentials: creative writing for decades and experienced 1sthand tradeoffs of each. my verdict? seek the Hegelian dialectic. ;-)
- slothtrop 5y ago
  If one ever does forgo an outline (I'm not sure if this is ever done), you'd probably have to revise the entire thing a lot, such that you're imposing an outline anyway.
  - syngrog66 5y ago
    bingo. agreed. been bit by that a lot, esp when younger haha. my 1st book had no outline. my 2nd and 3rd books both have outlines. while still trying to keep the baby, minus the bathwater. I like the results, and the total sunk LOE much much better. related semi-tangent: with fiction I also adopted the rule to write the Ending first. because, for me at least, it then crystallizes what sorts of Middles and Beginnings might lead to it, and make the most sense or have the biggest emotional impact on the reader. which then practically paints out the character journeys for you, as the author. very helpful tactic
  - kayodelycaon 5y ago
    > If one ever does forgo an outline It's more common than you think.
- kayodelycaon 5y ago
  > you also need a well-thought out outline for any larger work like a novel Hasn't been the case for me so far. Every story and essay I've written started with an idea. If there is an outline, it gets thrown away page 2 and never returns. On my second novel and this still hasn't changed. My writing is actually better this way because I start with characters and plot emerges as they deal with the forces around them. I never know how they will react until they do. I program the same way. Write a bit, revise, write a bit, revise. Drives some people nuts if they see the process, but the end result has been just as good or better than my coworkers throughout my career. (I'm a huge fan of tests. My revise step includes adding tests.)

seanmcdirmid 5y ago

I think this is common for many programmers. Programming isn't just a way to implement the solution to a problem, it is also a way to find solutions to problems (by working them out in code). Often times, programming can also help you figure out what the problem is. Programming isn't just about implementing things, it can also help with thinking.

bsedlm 5y ago

the 'beautiful' thing about this, is that it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards. In my experience they'd only relucantly agree if and only if it's "do this or die". Which then happens under time-pressure or under stress factors of other kinds. "if it already works, why fix it?" (because it's making developer's lives much more difficult than they could be? --"but how does this increase revenue?" --errhmm... because incresaingly difficult to maintain? but they don't care about this "that's your job")

CRConrad 5y ago
> it's then impossible to convince product people and "stake holders" to authorize enough time and resources to improve the solution afterwards. > "if it already works, why fix it?" I suppose one attempt at a fix for this would be to make the user interface of your prototype the least prioritised part; maybe even go out of your way to make it ugly and clumsy, so the thing as a whole looks more like a prototype and less like a "solution".

munificent 5y ago

This idea is the source of Fred Brooks' observation: "Plan to throw one away. You will anyway." In order to implement a good solution you need to understand the problem well. Often, the only way to reach that level of understanding is by trying and failing to implement it. These days, with modern refactoring and incremental development, it's less throwing away a whole program and more gradually refactoring it until little of the first code remains but I think the observation still holds in many cases.

zarkov99 5y ago

I think this depends on the scale of the problem. For small, algorithmic, problems, the kind you would see in a coding interview I find it far more efficient to solve on paper, or on your head, before getting bogged down in code. The difficulty in these types of problems is not understanding the issue but coming up with a solution. For much larger problems, just getting you head around the problem is very challenging and you need some scaffolding, in the form of half-backed, but still precisely described solutions, simply to provide ballast to your thought process.

MrPatan 5y ago

Analysis through synthesis

polishdude20 5y ago

In a way, coding can be thought of as two distinct things. One: coding is a way to play around with ideas, equivalent to a back of the napkin calculation, a diagram in the sand or a pencil sketch of a part. We use code in this scenario more as a way to write down our thoughts and process. But rather than writing in just pure English and writing an essay or a set of Todos, we write more detailed "specs". "Do this three times or until this value is zero" is also written in code and perfectly understandable in code too. Two: code is used to run by a computer to produce an outcome. In this case, the back of the napkin sketch IS the part but more thought out. Society is so used to there being two material objects between the "plan" and the"final product" that we forget that code is different. With code, the plan and the final product are of the same form. Of the same physical space.

marssaxman 5y ago
The same distinction still holds in programming - it's just that the process of using the plan to generate the final product has been automated, by that handy class of tools we call "compilers".

jhgb 5y ago

>> Never start coding (making a solution) unless you fully understand the problem. > While I agree with this in general, I find that to reall fully understand a problem, I need to attempt to code, or at least formulate, a solution to it. I'd go as far as to say that programming is a good medium for expressing poorly understood and sloppily formulated ideas. Oh, wait, someone else already said that...