Early in my career I tended to spend time refactoring code for readability. Often this was because I just wasn't good enough at reading code, and the code wasn't written well, so the refactoring was necessary just to figure out how things worked.
Then I got better at reading code, and I realized that all that refactoring work was time wasted. I needed to focus on solving real problems. Prioritize rigorously, as the article suggests. I started to get more things done.
Then I realized that some code lives a long time. And the confusing syntax/formatting/patterns that I learned to overlook nonetheless tripped up other programmers over and over again. (And sometimes me too.) And instead of decreasing over time, the confusing parts grew, because people tended to work on those parts and learn those patterns, because those were the parts that needed work, because they were confusing.
There's almost a natural law at work: Confusing code outgrows clean code.
The corollary of this law is that you can't have some confusing parts of the code, and even if most of it is clean, because over time it will become mostly confusing. You have to keep it all clean.
Now, late in my career, once again I do a lot of refactoring. (I'm more productive at it than before, because automated tools for grunt work like formatting either exist or I make them.) So now we all get more things done.
> The less code you need to solve your problem, the better.
Couldn't agree more. I always reject PRs with dead code in them. The author will argue that they added it for some future use case, but in my opinion it is never acceptable to have dead / unreachable code. It's confusing for future readers of your code and you can always add it later if your imaginary use case ever becomes real.
4 comments
[ 3.0 ms ] story [ 20.1 ms ] threadThen I got better at reading code, and I realized that all that refactoring work was time wasted. I needed to focus on solving real problems. Prioritize rigorously, as the article suggests. I started to get more things done.
Then I realized that some code lives a long time. And the confusing syntax/formatting/patterns that I learned to overlook nonetheless tripped up other programmers over and over again. (And sometimes me too.) And instead of decreasing over time, the confusing parts grew, because people tended to work on those parts and learn those patterns, because those were the parts that needed work, because they were confusing.
There's almost a natural law at work: Confusing code outgrows clean code.
The corollary of this law is that you can't have some confusing parts of the code, and even if most of it is clean, because over time it will become mostly confusing. You have to keep it all clean.
Now, late in my career, once again I do a lot of refactoring. (I'm more productive at it than before, because automated tools for grunt work like formatting either exist or I make them.) So now we all get more things done.
Couldn't agree more. I always reject PRs with dead code in them. The author will argue that they added it for some future use case, but in my opinion it is never acceptable to have dead / unreachable code. It's confusing for future readers of your code and you can always add it later if your imaginary use case ever becomes real.