Sad Code: A Folk Pathology

Image: Kotivalo

You and me: We’re in Developer Relations. We love to help get people started building cool things on our platforms. But it doesn’t always work out. A lot of the time, we can get people started…but it’s maybe not so easy to help get them across the line. The result: Discarded projects.

The world is littered with discarded projects. Call them “Sad Code”.

I get the notion of Sad Code from a delightful and inspirational book of photographs of chairs discarded in St Louis alleys, cleverly entitled Sad Chairs. These chairs were perhaps once useful pieces of furniture, now tossed out into the public thoroughfare in the vain hope that someone will find them useful.

Of course, no one ever does.

So it is with Sad Code.

Insofar as we, as DevRel types, are charged with shepherding the success of our developers, Sad Code is our own failure.

😭

So, here’s what I’m driving at: Each instance of Sad Code is a lost opportunity to engage with our platforms. If we measure DevRel success, in part, in terms of the number of successful projects in the wild built on our platform, projects actually being used (call it…Happy Code), then we have an obligation to take an active part in helping our customers see their projects through, to help them avoid those paths that lead to abandoning their efforts.

Sad Code is not just our enemy — it is our own doing, because Sad Code is often abandoned side projects, experiments with our platform. And so we have some control over it. And we can control it if we understand its root causes. In the next few paragraphs, I want to develop a folk pathology of Sad Code — a first pass at understanding these root causes, with an eye to understanding what we can do to turn Sad Code into Happy Code.

We made this mess, we can get out of it!

When I say “folk pathology”, I mean simply an intuitive guess at the root causes. I don’t present these as canonical—indeed I would like to gather your feedback on the factors you have seen in your work.

From my own experience, I see among the most obvious factors: lack of time, lack of energy, lack of external validation, and lack of a compelling use case. We’ve all seen these — and experienced them.

Time

When we invite developers to try building something on our platform — perhaps at a Hackathon, or as a side project or a 20% project — we are asking them to give us a chunk of their time. Of course, I don’t need to repeat that time is a finite resource. Often the developers whose time we most cherish have the least to offer.

Energy

This is perhaps the other really obvious point of failure. Any project requires energy to complete it, and the more complex and interesting a project, the more energy it takes.

Even the most compelling project with plenty of free time is a tax on personal resources if the author is stuck with a full day’s work. How many times have you come home, totally beat, and ready for little more than a bit of TV or light reading or a game? We should be cognizant of the fact that in asking developers to try out our platform, we are asking them to potentially sacrifice some of their well being for our own benefit.

External Validation

External validation comes, to my eye, in two forms: The first is the ego-stroking kind, where others look at your work and say “nice job!”. The second is the satisfaction of a job well done—that in the kinds of cases we’re talking about, usually stems from observing others using what you’ve built and finding it useful. The two often come hand-in-hand, but not always, so it’s worth considering each individually.

Imagine putting something out there in the hopes that others will find it cool or clever, and finding instead crickets chirping. That’s heartbreaking for sure, to build something you think is interesting only to be told — explicitly or implicitly — that it is not. And who knows whether it actually was interesting, the result is the same: A chilling effect that discourages you from trying again.

Now, imagine putting something out there because you found it useful for yourself, in the hopes that others will find it useful too, and finding instead…crickets chirping. That’s also heartbreaking, but in a different way. To see how, imagine that maybe others found your work cool and interesting, but then no-one bothers actually using it. The project feels like a failure because it hasn’t fulfilled its telos, is reason for being. And again, we find a chilling effect.

Compelling Use Cases

The final factor that I can see (although you no doubt can see more!) is the distinct lack of motivation that comes from not really knowing what to build. “Hello world” style programs are great for teaching the basics, but don’t provide a framework for thinking about how to expand the ecosystem by building something compelling. Ideas are hard, especially if your first motivation was tinkering around with a cool new technology with the thought that the inspiration would come later. Now it is later, and where is the inspiration? This kind of Sad Code is the Saddest of All, because it never even had a chance to be in the world in the first place.

Well, geez, that was…sad

Yeah, it was. And I imagine you have your own stories about Sad Code, and I’d like to collect them as part of this folk pathology. I invite you to share your stories of projects abandoned in the comments below, or on Twitter with #sadcode.

Next time — no, we’re not done here yet — I start rambling about what we DevRels can do to combat Sad Code. You can guess what the title will be.

😆