January 29, 2020

While I have some ambivalent feelings about "awesome street band as a metaphor for crippling grief and depression", this video (featuring Richard Kind and the band What Cheer) is awesome and moving.

What Cheer? - starring Richard Kind from Five Eyed Films on Vimeo.

Code geek alert - and one I hope not too many future hiring interviewers see... Sometimes it feels like unit tests are like writing tests for individual Lego bricks.

95% of bugs I see that make it out of the developers play area are emergent - they arise from the interactions and poorly understood expectations between the bricks! But when you write a mock or a stub, all you are saying is "if the rest of the world matches my little toy fake-y model here I'm setting up with my mock... then my code is all good, baby."

Returning to the Lego metaphor, the scaffolding you use to hold up your Lego brick for inspection seems at least rickety as the damn brick... combine that with the unlikelihood of a coder hunting really hard for something they don't want to find (i.e. a bug in their own code and indication that they aren't so great...) - again, maybe a good coder codes so someone ELSE doesn't find a bug in their code. Which is good - but again, I feel like a telltale of a properly scoped unit isn't there isn't much in that should be subtly going wrong.

I know there's some side effects of testing that are positive, like breaking things up in small pieces, getting dependency injection going, whatever. But I feel like most of the benefits happen testing higher up, and I don't understand why so much of the coder world loves pouring over individual Lego bricks... are the people who love them that much smarter than me, more brain-washed, or just different, like how prescriptivists and descriptivists are different?

Sometimes they say unit tests help explain what the code does, but honestly, reading a test is usually harder to parse than the code itself - maybe there's some good example data that's a good crisp read, but compared to naming functions and parameters properly, and commenting where needed?

I feel like unit tests come from the same people who think a github site with a minimalist README.md is good enough to describe use of their framework...