No offense to the author (I don't really disagree with anything he's written) but the stuff he's talking about isn't the hard part about keeping code clean.
The thing that I find hard about keeping code clean is:
- time pressure: someone wants something now and you feel the pressure and you need to make quick changes
- failed attempts at abstractions: people try to rewrite/refactor something in order to make it more reusable, they get halfway there, something else takes priority, and you're left with a mess
- unclear/changing requirements: you're kinda tweaking and feeling your way along and by the time it's doing what it should do, it's a bit messy, but time pressure means you're not going to go back to it
- god awful things done in the name of testability: people not really knowing how to write great tests leaking the guts of the implementation all over
- quick hacks to fix nasty bugs: root causes never fixed, band-aids and duct tape all over
- performance over readability: sometimes something needs to be fast and that doesn't necessary mean that someone jumping into the codebase is going to be able to grok it right away
- did I mention time constraints? Given infinite time, most of us will produce a reasonably readable function
It’s the classic toy example vs actual real world problem.
But there are people who struggle with the toy problems. I recently saw some code from McKinsey data scientists who apparently don’t care about any of the basics. There’s no indentation and variables are c1 to c6 style.
Sure, they bill by the hour so they shouldn’t waste time but it doesn’t take more time to do better than that. They have no excuse for shoddy code other than not caring or knowing about the basics.
The thing that I find hard about keeping code clean is:
- time pressure: someone wants something now and you feel the pressure and you need to make quick changes
- failed attempts at abstractions: people try to rewrite/refactor something in order to make it more reusable, they get halfway there, something else takes priority, and you're left with a mess
- unclear/changing requirements: you're kinda tweaking and feeling your way along and by the time it's doing what it should do, it's a bit messy, but time pressure means you're not going to go back to it
- god awful things done in the name of testability: people not really knowing how to write great tests leaking the guts of the implementation all over
- quick hacks to fix nasty bugs: root causes never fixed, band-aids and duct tape all over
- performance over readability: sometimes something needs to be fast and that doesn't necessary mean that someone jumping into the codebase is going to be able to grok it right away
- did I mention time constraints? Given infinite time, most of us will produce a reasonably readable function