Over the years, I’ve built up a repository of resources that have shaped my thinking about software engineering, open source, work, life, and so much more. Every so often, I reference them in conversation and am asked for links, other recommendations, and thoughts or commentary about them. This year, I’ll be posting two or three every month, both as a way to revisit them as well as share a few thoughts about how they have changed how I journey throughout this (sometimes confusing) world.
Here are the first two. Enjoy!
Contempt Culture, by Aurynn Shaw
Without a doubt, the article I have quoted, referenced, linked, lauded the most is Contempt Culture (archive) by Aurynn Shaw. When she first published this, I was working as a developer advocate, working with developer communities. I was immersed in developer culture; the great “emacs versus vi” debate was still raging (and is to this day, though it’s more tongue-in-cheek now), we used emotionally charged language when stating preferences about technologies, and finding community often meant uniting with others who had the same antipathies as you did.
Contempt Culture prompted me to step back and think about how my behavior was affecting my interactions with the developers I was serving and how it was affecting my own internal narrative. How I was internalizing and recycling toxicity, and how completely unnecessary that was.
“I bought my sense of belonging, with contempt, and paid for it with contempt and exclusionary behaviour.”
This hit me like a tonne of bricks. I too was using contempt as currency. I too was perpetuating environments that not only excluded others, but also actively made them feel badly in order to build myself up.
Aurynn concluded her article with this challenge:
“leave things better than when you started”
That one phrase has been my guiding principle ever since.
Machine Learning: The High Interest Credit Card of Technical Debt, by Sculley et al.
Going in a completely different direction, we have Machine Machine Learning: The High Interest Credit Card of Technical Debt (archive of pdf) by Sculley et al. This paper was presented at a NeurIPS (née NIPS) 2014 Workshop, when machine learning was really starting to be commercialized, owing in large part to the increase in available training data and low-cost computing resources. While an excellent exploration of the complexity that machine learning introduces into any system on top of standard technical complexity, I found that most of the observations still held true if one substituted “open source” for “machine learning”.
In section 2.3, Undeclared Consumers:
The expense of undeclared consumers is drawn from the sudden tight coupling of model A to other parts of the stack. Changes to A will very likely impact these other parts, sometimes in ways that are unintended, poorly understood, or detrimental. In practice, this has the effect of making it difficult and expensive to make any changes to A at all.
Those who work in or with open source encounter this frequently. This is one of the reasons that many consumers of open source packages will refrain from updating to the latest version. Unless the consumer has rigorous integration tests in place, ingesting upstream changes to a package poses a risk to the stability or functionality of the wider system.
Technical debt is by no means a new concept, but typically we talk about it within the context of a closed system. An open source project. An application. A product. The machine learning and open source ecosystems are not confined to one system, closed or open, known or unknown. It ramps up the complexity of creation and consumption dramatically.
Another thing that machine learning and open source have in common? People like to pretend that using them is far simpler and expedient than it actually is.