Clean code is not a goal

Written by / Original link on Jan. 12, 2020

Photo by Kevin Ku on Unsplash

Dan Abramov on how he once overnight refactored a piece of WET code written by a colleague, but then got called out for doing so:

My boss invited me for a one-on-one chat where they politely asked me to revert my change. I was aghast. The old code was a mess, and mine was clean!

I begrudginly complied, but it took me years to see they were right.

There’s a fine balance to be found between code that works for the team and code that is clever/abstract/clean. Sometimes it’s better to write cheap code, as that’s not only cheaper to read, but also cheaper to maintain, cheaper to throw away, etc. — Abstractions are good, up to a certain extent.

On Twitter, Dan also said this about // @TODO comments:

TODO doesn’t mean you actually intend to do something. It’s a marker for the next person that the logic was left unfinished and they shouldn’t be surprised by missing corner cases or strange code structure.

— Dan Abramov (@dan_abramov) January 11, 2020

/me nods in approval

Goodbye, Clean Code →

On a related note, be sure to also read Kent C. Dodds’ Avoid Hasty Abstractions

bram link calevans refactoring bram

« Cloud Run vs App Engine: What’s the difference? - The Basecamp Guide to Internal Communication »