Clean code is not a goal

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:

/me nods in approval

Goodbye, Clean Code →

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

Harry Roberts: Refactoring CSS Without Losing Your Mind

Working with CSS is tricky enough as it is; working with legacy CSS can be nightmarish. In this talk, we’ll look at how we decide what to refactor and when; how we can refactor code whilst still shipping features; how to avoid regressions when adding new CSS; how

Extract Till You Drop

Under the pressure of deadlines and endless change requests, under the weight of years of legacy, code becomes unmaintainable. With the right tools, techniques, and mindset, any codebase can be brought under test, and be refactored towards a better architecture. Let’s skip the theory and dive straight into the spaghetti code. In a live coding session, I will demonstrate how you can start refactoring your way out of a mess today.