Blind Spots

By Max Woerner Chase

In this post:


Something I've been thinking about some is how I've been presenting refactoring and commentary on code on this blog. I feel like it's been too easy for me to get into a mode where I'm negative about other people's hard work that, to some extent or another, they did for themselves first.

I need to be more careful to present my opinions here as opinions, and make it clear that there's no objective thing here. (Also, by the standards I've alluded to in some of these posts, the very script I wrote to publish this blog is pretty heinous. It has avenues of improvement I can take it down, but until then, the uploader software I want and the uploader software I have seem pretty different to me.)

In the past, I've tried to be pretty extreme about metrics that seem sensible to me. One way to describe the way I tend to push coverage metrics on projects is "more 100% than 100%", from divide-and-cover. And I think taking the responsibility for covering a module's API surface, and putting it specifically on the tests explicitly associated with that module, I think that's a powerful tool. But it's time I admitted to myself that a tool's power is insufficient to justify its use. The only thing that justifies using a tool is having a problem that that tool can solve. Testing in general is a form of insurance, a way of constraining the changes that the code can undergo. I'm starting to think that testing is more valuable the more colloborative the development process is—noting well that development can be collaborative even if only one person is actually editing the code. Think of a test as a way of saying "It's important to me that this behavior holds. In fact, it's so important that I've instructed the computer to say so for me."

Reiterating on the aside about collaboration, I feel like when I release some software into the world, it should be ready for collaboration. I have not really lived up to this; aside from any issues of wounded pride I'm expressing here, projects like divide-and-cover should... have... tests... I went to all the trouble of composition and dependency injection and stuff, and then didn't write anything for them. Cleaning up divide-and-cover should be a project soon.

I guess the big takeaway is that I have some blind spots I should be working on. They seem like they don't make any sense; probably that's a part of why they're blind spots.