[ This is a lightly edited internal post we’ve made public.]
Last week we had booths at DevConf Joburg, and DevConf Cape Town. They’re two ZA events run by the same crew with the same speakers, two days and 1400kms apart. The organisers set a bar in ZA for putting on polished and well-run events. Where the average event is in an old venue with limited food and chaotic organisation, DevConf is punctual, classy, and efficient.
Francois & Victor (Jhb), and Leighton & Daniel (Cpt) joined me in the two events, and we spent the time demo’ing Canary, and talking about Thinkst. We don’t expect to make sales from DevConf; the audience isn’t security, and they almost universally aren’t buyers. Any sales we get are bonuses. The reason we sponsor is not because we’re spendthrifts either. Through the year we get requests to sponsor events, podcasts, publications, software, education, meetups, do co-branding, write (or accept) guest blog posts, and more. We usually decline. For DevConf, our participation stands on two legs: supporting a developer community, and introducing (and maintaining) a public presence for future hiring. We do that mainly through 1-on-1 conversations with folks who walk up to the booth and, typically, start with “So, what does Thinkst Canary do?”.
One conversation I had in Cape Town stuck with me, and in this post I’ll reflect on it a little more. Late on Thursday afternoon, a gentleman came up to the booth with a friend. He introduced himself and (approximately) said, “Last year we chatted, and you spoke about Caring for the product. It was unexpected to hear, and I’ve been thinking about it since. I hadn’t heard about caring for the things I build. Can you tell me about how you care about the product?”. We then proceeded to have a solid chat about what it means for us in practise, and he went away happy, knowing more about our approach.1
I’m not writing here to be self-congratulatory about it,2 it strikes me there’s a deeper revelation lurking. The gentleman wasn’t a fresh graduate, he seemed to have some miles behind him. And he’s got this far in his career without hearing about deeply caring for the thing he builds. It’s not just him; I frequently hear similar sentiments when we interview folks.
What strikes me is how utterly fragile it is, to care about the thing we build. The standard incentives push towards getting junk out; whether it be investors demanding press releases with new features matching the latest hype cycle, or Support wanting to close tickets without digging into the customer’s real issue so as to reduce queue sizes, or logistics and back office folks skipping mails due to distraction, or developers mashing quick fixes over deeper problems knowing that “it’ll be someone else’s problem next time”. It’s so fragile, there are developers who can’t imagine caring about what they build, not because they don’t want to, but because they never encountered the idea. That’s deeply troubling.
Caring about software is like the (in)famous inverted pendulum. Imagine balancing a glass on a stick; you have to constantly keep moving to keep the glass balanced, because the system is inherently unstable and requires active feedback and input to keep the glass in the air. Maintaining care requires the same control loop: feedback on where we’re diverging from our ideal state, and counteracting the movement with action to push us back into the caring state. Tiny things perturb the system: individual people joining or leaving, people going on (or returning from) leave, rearranging reporting lines, software releases, supports tasks and tickets, large orders, small orders, customers in new geographic locations, and any number seemingly inconsequential actions.
Last week, we interviewed an experienced engineer with deep background in very technical work, and he never interacts with customers in his current role. Not “seldom”. Never. He has no direct feedback from them whether what he does solves their problems. He builds a feature according to a ticket, ships it, and doesn’t know whether anyone uses it. It’s hard to care about what you build in that instance (and it shows; when asked to articulate an example of building something delightful, he struggled.)
Our teams have done well in keeping the care evident in how we build, support, and maintain Canary. But that’s no guarantee about the next week, month, or year. So this is a reminder that caring about the thing we build isn’t the stable state, and that we have to constantly fight off the wolves of mediocrity, howling at the gate.
