3 ms·

I agree that it is an important skill in engineering to recognize when the complexity got too high - At that point you need to take a step back (or several step

I agree that it is an important skill in engineering to recognize when the complexity got too high - At that point you need to take a step back (or several steps back) and find a different path to the solution - Sometimes that means throwing away large amounts of code. It's about acknowledging (and correcting) small mistakes to make sure that they don't pile up into a giant, disastrous one. Another thing I learned is that dumb, explicit code is highly desirable - It's better to have 10 dumb components to handle 10 different use cases than 1 clever component that can handle all 10 cases. I think the most important skill is being able to break down problems into their essential parts and then addressing each part individually but without losing track of the big picture.

mmcconnell1618 11y ago
I agree. I like to remember that I'm passing code into the future where I might not be working on it anymore. Clear, well named code helps the next developer far more than an obtuse algorithm that smashes all logic into a single line.
- JoeAltmaier 11y ago
  Almost always this is true. But mature code has been iterated over, and some critical places the code has been optimized out of clarity. Nothing helps then but a document - comments are just not enough to explain the crooked road that lead straight to that solution.
Gracana 11y ago
> Another thing I learned is that dumb, explicit code is highly desirable I knew for a long time that "dumb" code was easier to reason about, but it wasn't until I started looking at compiler output and profiling my code that I realized being "clever" in the source text really didn't matter. Now I'm quite happy to write code in the most straightforward fashion, rather than foolishly "compress" things. I imagine the same experience could be enlightening for a lot of newbie and intermediate programmers.
- TillE 11y ago
  There are definitely exceptions to this (generally correct) rule, in situations where performance does matter. RAM is still incredibly slow compared to the CPU caches, so painstaking cache-optimization can make a huge difference when that's the bottleneck. Of course, if you're just writing some I/O bound program anyway, it hardly matters.
davidjnelson 11y ago
Agreed. From my experience breaking things down into smaller pieces helps so much with initial development speed, future code change speed, and testability.

mmcconnell1618 11y ago

I agree. I like to remember that I'm passing code into the future where I might not be working on it anymore. Clear, well named code helps the next developer far more than an obtuse algorithm that smashes all logic into a single line.

JoeAltmaier 11y ago
Almost always this is true. But mature code has been iterated over, and some critical places the code has been optimized out of clarity. Nothing helps then but a document - comments are just not enough to explain the crooked road that lead straight to that solution.

Gracana 11y ago

> Another thing I learned is that dumb, explicit code is highly desirable I knew for a long time that "dumb" code was easier to reason about, but it wasn't until I started looking at compiler output and profiling my code that I realized being "clever" in the source text really didn't matter. Now I'm quite happy to write code in the most straightforward fashion, rather than foolishly "compress" things. I imagine the same experience could be enlightening for a lot of newbie and intermediate programmers.

TillE 11y ago
There are definitely exceptions to this (generally correct) rule, in situations where performance does matter. RAM is still incredibly slow compared to the CPU caches, so painstaking cache-optimization can make a huge difference when that's the bottleneck. Of course, if you're just writing some I/O bound program anyway, it hardly matters.

davidjnelson 11y ago

Agreed. From my experience breaking things down into smaller pieces helps so much with initial development speed, future code change speed, and testability.