I caught a cold last weekend, immediately after having done something to my shoulder that aggravated my rotator cuff. I started the year off very strong, maintaining a great fitness program for the first few weeks, only to get sidelined at the end of January. Bummer.

Mostly, I'm just bummed that I'm not surfing today, but I'm still sniffling. Last time I went surfing with a cold it turned into many weeks of bronchitis. Best to stay out of the water until the lungs are 100% healthy.

I encountered a "hot" take on LinkedIn that I'm not going to link to here. The author was arguing that "code reuse" isn't a best practice. It was the same old argument: if you DRY something up, but it turns out you've combined two concepts that actually change independently, it's very hard to undo.

That's all true, but that doesn't mean code reuse is bad. Aggressively refactoring code before you can be sufficiently confident that the things you're combining are conceptually the same is risky. I particularly like Dan Abramov's talk from Deconstruct 2019.

While it's wise to be cautious when refactoring functionality into shared abstractions, it's also wise to create those shared abstractions once you're sufficiently confident that you've identified code that is going to vary collectively.

By creating the shared abstraction, you ensure that future changes to that code are shared everywhere it is used. The whole point of DRY is to avoid situations where a change is applied somewhere in a codebase, but a necessary change that goes along with it somewhere else is missed.

We have to understand the tradeoff. It is riskier to aggressively extract abstractions when we're not confident in them because disentangling them later will be hard. It is still risky to have multiple duplicated pieces of code in your codebase that need to change together, though definitely less risky.

This is why I'm completely fine when someone adds a comment to a project like this:

# If you make any changes the next line, you need to make a
# corresponding update to $SOME_OTHER_FILE.

Duplication is encouraged when you're not sure what abstraction you need. Duplication is encouraged when you're not sure what you're looking at is duplication. (Code being visually/structurally similar doesn't mean that it's conceptually the same idea or will change together.) Duplication is acceptable when it would be overly complex to avoid.

Duplication is a code smell, though. Less code is better, so if we're confident in an abstraction and its ability to adapt as our code changes, we should be using that abstraction.

It's absurd to suggest that code reuse isn't a best practice, but it's also not the goal. Less code or more reused code isn't an end unto itself, just a handy lens with which to evaluate possible approaches.

My "to listen" pile is big, but I've been ripping through the backlog over the past couple of weeks. The tail end is mostly comprised of albums that were reviewed well enough to make it into the pile, but not well enough that other things didn't beat them to my ears the week they came out.

Enter Cabal's Everything Rots. Front to back, this is disc packs a plethora of talented vocalists into the band's filthy blackened deathcore sound. Cabal's songwriting is on point too, elevating the album above the average deathcore template without losing the violence and menace associated with the genre.

CABALEverything Rots