“Clean code” isn't actually clean

Attended a couple of clean code trainings, always wrote the shittiest code for a week or two afterwards. ¯\_(ツ)_/¯

So no data, no examples, no anything. Full of such wisdom as "Testing isn't as important as it might seem but it's still important"

The only thing actually articulated was "you don't need 100% test coverage", which is not contrary to existing practice (afaik). I'm not sure the singular point nested in platitudes can be useful to me.

Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia%3AChesterton%27s_fen...

A lot of software engineering practices lean towards tribal wisdom instead of being evidence-based.

The only resource I know of that provides citations to studies is Code Complete by McConnell. But having data is no guarantee of correctness. Bossavit debunks some SWE common sense in "The leprechauns of software engineering", including the cone of uncertainty which is referenced by McConnell.

I'm also planning on reading SW engineering best practices by Capers Jones, which is likewise based on data, not anecdotes.

On my side projects at home, I can't even remember the last time I had to slow down or got stuck on maintenance/integration type stuff (as opposed to new functionality or algorithms, which don't rely on existing code). And I have a couple of fairly big ones, it's not all "Todo list" stuff.

It's happened constantly at work though, throughout multiple jobs. Sometimes I've been so stuck I've got basically nothing done for days or weeks at a time. Sometimes that happens a few times in a row and I feel like I'm an inch away from being fired for incompetence. This even happens on relatively small projects. It's not confined to big 10 year old monstrosities.

The sad thing is, I work for startups, which should be all about lean, clean code and making big changes rapidly to respond to business needs.

I think a lot of it comes down to how hard it is to work on other's code. I don't think any of the conventional wisdom is a solution to this problem either. I haven't noticed any discernable difference between projects with big fuck off linters, or 50 page style guides. It's not a mish mash of semi-colons that's causing trouble (although consistency is nice).

"Dirty code" is really the crux of the problem. But like the author of this article, I don't always agree with what the conventional wisdom says about writing clean code.

To me, the most important part of keeping your code clean is always having the minimal solution to the problem. Your code shouldn't do one thing extra it doesn't need to. Half of this is YAGNI, half of it is being a good enough developer to come up with simple solutions that aren't too fancy.

On that note, don't get too fancy, and don't take DRY too seriously. Whatever complicated mess of higher order functions you're writing probably isn't going to phase other experienced devs in a vacuum, but combined with all the other icky parts of the code base and it might just be the straw that breaks the camel's back. If you need to write twice as many lines to make it more grokable, that's fine.

Speaking of YAGNI, people should be applying it somewhat to dependencies as well as functionality. It's just far too easy for a simple React project to blow out in complexity because of an over-reliance on other's code. Sometimes it's easier to build something out of code than NPM Lego.