6 ms·

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 s

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.

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.