In my experience, some of the smartest, best guys at algorithms and puzzles make some of the worst coders. No one can understand their code, it's brittle and their work eventually gets replaced by code written by somehow with half their IQ but a decent sense of organization.
We are all mortals at the end of the day. You can choose to study algorithms or you can choose to study clean code. Few have the time to do both. I've noticed that it isn't just algorithms though. People that are really good at reasoning in code (maybe from studying algorithms so much) have a much higher tolerance to code complexity and produce much worse code as a result.
That said, I've worked with a few people who got both sides very well and they were a treasure to work with.
You don't have to "study" clean code. You just have to overcome the tendency to write code in an overly smartypants way. Coincidentally, in my experience, there seems to be a correlation between people who love to study algorithms and people who love doing this. :)
I can reduce that 20 line function into one line of maps / filters / reduces too, but I know I shouldn't if it's going to take 20 minutes for someone else (or me 6 months later) to get through it.
Basically, don't aim to reduce Kolmogorov complexity, aim to increase readability. These two aren't completely mutually exclusive anyway.
> You don't have to "study" clean code. You just have to overcome the tendency to write code in an overly smartypants way.
This is a great point. As an industry, we seem to be impressed by complex solutions (even if the complexity is unnecessary and the code unmaintainable). Writing clean, obvious code is often met with a "Duh, I see why it was written that way", but without understanding that it took a long time to get the complex solution down to that point.
I agree with the sentiment of your comment, and especially like your last two sentences. Maybe I'm just expanding on your last sentence.
I have to object to "20 line function into one line of maps / filters / reduces". I don't know what the 20-line function looks like, but I find use of classic higher order functions instead of loops makes code drastically quicker to read accurately.
As with human language, a larger vocabulary can be used in an "overly smartypants" way, but it can also be used to more quickly and robustly convey information between people (or to your future self).
Clean code is more than just not writing obtuse code. There is a lot of literature on the subject spanning advice about patterns and principles to cookbook recipes for problems and so forth. The challenging part with clean code is that most of it is fairly subjective. More of an art than a science. We know clean code when we see it, but we cannot always reproduce it ourselves.
If you haven't read the literature and do not practice with the different techniques, you are probably not writing clean code.
The absolute best people I know at "algorithms" are either CS theoreticians or straight-up mathematicians. They can program, perhaps even better than average coder, but they don't have quite the same whole-system view as a systems person or professional software engineer.
If you're solving problems that require algorithmic ingenuity, you absolutely want these people. And if you can pair them with a good engineer who can integrate their algorithm into a non-trivial system, that's when the magic happens.
It's true, if you're lucky enough to have someone who can write organized code that replaces the original clever junk. https://news.ycombinator.com/item?id=1221756 (ignore the top comment)
