3 ms·

I don't mean this as a response to you personally, but instead to everyone who works this way. We've been in this situation lots of times, where we'll write so

I don't mean this as a response to you personally, but instead to everyone who works this way. We've been in this situation lots of times, where we'll write some code, then finish the solution after a few days or a week, then look at it a month later and say "Wow, this is really not a good way of doing it," only to spend another few days or weeks rewriting it. The idea of spending 10 minutes drafting a solution, throwing it out, spending another 10 minutes on diagrams and guesses, throwing it out, typically gets met with "Just _code_ damnit," but, diagramming could compress months of rework into minutes.

laumars 10y ago
You're not wrong and my programming style is very much like that albeit I use the code itself to diagram as I find that's easier for my brain to parse than flow charts. But effectively it's the same process of "sketching a design and throwing it out" cycle that you described. I suspect quite a few developers who "just code damnit" follow this same process too. After all, it's not exactly hard to rewrite code and with tools like Git in place you can easily stash the different implementation methods so you're not having to lose any work during the cycles. Usually when bad code gets written by experienced developers it's not so much because of a lack of willingness to conceptualise the design but often just because either the deadline is sufficiently tight that you are forced into writing a "quick fix" rather than something robust. Or because the code base is already an mess (due to the evolution of the product and the aforementioned issue of quick fixes) which means the "ideal world" solution is a significantly larger undertaking than it should be and best not undertaken while you have deadlines depending on it. Or sometimes you see "bad" code simply because the aim of the project is a minimum viable product or proof of concept, thus it's more about proving the product works as a concept than the implementation of it. In that scenario it can make a lot of sense to throw quick code at a problem with the understanding that chunks of the application will be revisited when you start to scale the product.
psyc 10y ago
I do sketches both on paper, and in code. I write all my code in many, many drafts, so that by the time it ships each function has been rewritten. I'd guess about 5-10 times on average. Possibly contrary to intuition, I find this enables me to work much, much faster, and have far fewer defects than not doing it.

laumars 10y ago

You're not wrong and my programming style is very much like that albeit I use the code itself to diagram as I find that's easier for my brain to parse than flow charts. But effectively it's the same process of "sketching a design and throwing it out" cycle that you described. I suspect quite a few developers who "just code damnit" follow this same process too. After all, it's not exactly hard to rewrite code and with tools like Git in place you can easily stash the different implementation methods so you're not having to lose any work during the cycles. Usually when bad code gets written by experienced developers it's not so much because of a lack of willingness to conceptualise the design but often just because either the deadline is sufficiently tight that you are forced into writing a "quick fix" rather than something robust. Or because the code base is already an mess (due to the evolution of the product and the aforementioned issue of quick fixes) which means the "ideal world" solution is a significantly larger undertaking than it should be and best not undertaken while you have deadlines depending on it. Or sometimes you see "bad" code simply because the aim of the project is a minimum viable product or proof of concept, thus it's more about proving the product works as a concept than the implementation of it. In that scenario it can make a lot of sense to throw quick code at a problem with the understanding that chunks of the application will be revisited when you start to scale the product.

psyc 10y ago

I do sketches both on paper, and in code. I write all my code in many, many drafts, so that by the time it ships each function has been rewritten. I'd guess about 5-10 times on average. Possibly contrary to intuition, I find this enables me to work much, much faster, and have far fewer defects than not doing it.