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.
> 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.
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.
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.
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.
Agreed. From my experience breaking things down into smaller pieces helps so much with initial development speed, future code change speed, and testability.
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.