November 22, 2021

Principles of Software Evangelism

My job these days is researching exotic software technologies and selling them to companies, which means I'm a software evangelist. And because I literally cannot turn my brain off ever, I started thinking about what "evangelism" actually means.

Evangelism is an "embarrassing job": SE culture looks down on evangelism, considering it untrustworthy. I'm not doubting the valid reasons. I'm lamenting that there's no community to discuss the techniques of evangelism, because the internet would gleefully tear it to shreds.¹

(I mean, beyond the usual clickfarm junk which I have notorious opinions about)

So there's nothing to learn from, and most of my principles here are coming entirely from my own experiences. My context is that I'm trying to convince people to adopt fringe, high-risk high-reward technologies, particularly formal methods. I'm not backed by a company, but I have individual reputation— people sometimes read stuff they'd otherwise ignore just because my name is attached to it. My audience is developers, not CTOs, project managers, etc. All of this affects what I think matters about evangelism, and people in different contexts might think very differently.

I haven't systematized any of this so you just get a random collection of thoughts.

Goal of Evangelism

To change the community's opinions on something: a product, a process, a language, anything. You can evangelize Agile, testing, Clojure, MongoDB, functional programming, emotional well-being, the use of dev/urandom, anything. I'm going to call the object of evangelism the Topic.

Efforts fall very roughly into two categories: networking and output. Networking is building relations with groups and individuals output is the material you produce to change the culture. Output includes things like talks, essays, projects, demos, particularly viral tweets, etc. I'm going to ignore networking because convincing you that evangelism is meaningful is hard enough, I don't need to add another dirty word on top of that. So let's pretend evangelism is just output for now.

Ensembles

Think of every developer as having an "activation energy" to be convinced. The activation energy depends on a ton of different factors: problem domain, workplace, personality, background knowledge, prior experience, personal relationships... While some factors have predictable influences, on the whole activation energy is wildly variable. One person might be enthusiastic about the topic while another on the same team, doing the same work, can be completely uninterested.

This makes evangelizing to individuals inefficient. Instead, it's better to evangelize to the ensemble, the population of developers as a whole. Make it so that people with low activation energy have an easy time finding your output, while people with high AE don't think you're a creep. You don't know who specifically will listen to you, but you know some people will, and that means you're successful.

Over time, you'll get better at evangelizing to the ensemble. First, you'll start to see patterns of who in the ensemble listens. Is it mostly juniors, enterprise C# developers, academics, cannibals? The patterns help guide your efforts. Second, you'll see more of the influences on activation energy. AE isn't a single number, it's a plethora of different factors, some you may be able to directly influence. If people are resistant because they think the Topic is too theoretical, produce practical examples and case studies. If it's because the infrastructure is terrible, aim to improve it. If it doesn't apply to their context, find ways of making the Topic more useful...

...or say "yeah you're right, it won't help you" and talk about something else. Preach to the ensemble.²

Trust

The core of evangelism is about managing trust. In order to convince people, they need to trust you. The best way to be trusted is to be deserving of trust. There's (at least) two kinds of trust here:³

1. Your expertise is trustworthy: your judgement about the best approach is correct.
2. Your opinions is trustworthy: you aren't deceiving people about your judgement.

(Having trustworthy opinions does not mean you don't have ulterior motives. I like making money and I like having lots of readers. But it means your ulterior motives aren't deceptive. Your opinion isn't materially changed because of your motives.)

So being a good evangelist means demonstrating expertise and honesty. The latter leads to one of the most important principles of evangelism:

Objectivity

The evangelist should strive to be as objective as possible.

This is both absolutely essential to evangelism and seemingly impossible. Your goal is to shill a product, how can you possibly be objective about it?

We square the circle in the most direct way possible. We don't make ourselves objective about the things we advocate, we advocate what's objectively good. Our judgment should determine what we shill, not the other way around.

I teach TLA+ and Alloy because I earnestly think they can revolutionize our industry. If I ever stop believing that, I will stop teaching them.

Being objective does limit the Topics you can evangelize. It also limits the contexts you can work in. Being objective means being willing to say "this is the wrong tool for the job, you do not need this, you do not want this." Or "this normally would help you, but property XYZ about your context severely limits its effectiveness", or even "this alternate approach that I absolutely despise is better for you."

Being objective is worth it, though. First of all, you're always in sync with your principles. Lot harder to advocate when you feel like you're dying inside.⁴ Secondarily, this makes you much more deserving of trust. If you're okay saying "this is the wrong tool", then people know you're not lying when you say "this is the right tool".

A special case of this is hate your tools. You should understand not just the benefits of the Topic, but also its drawbacks. Nothing in this world is a free ride, and if you can't present the issues with your Topic then you're not being objective.

Quality

There's always a tradeoff in output between quality and quantity. Should you prefer to make better output or more output? Obviously "both" is preferable, but we have finite time.

Common advice to early stage bloggers is to publish often. It's too easy for beginners to fall into a perfectionism trap where they revise again and again without actually putting anything out. But there's a floor to quality. But I see the other extreme, too, where people think all that matters is quantity. As an evangelist, you are representing the Topic: the quality of your output doesn't only affect how people see you, it affects how people see the Topic.

The simplest, most essential, and most agonizing way to improve quality is editing. Even one round of editing, done the next day, will meaningfully improve a piece of output. Better: get feedback on the draft and use it to guide your editing. Most of my blog posts are edited 4-5 times before they go online. If your output is talks or videos, that many rounds may be unaffordable.

When editing, don't be afraid to cut. It's okay to drop an entire section for brevity. It's okay to take three paragraphs you like and delete everything else. It's okay to abandon the piece entirely and come back to it a year later. Or never. This is a process of purification. Even if the new draft doesn't contain a single sentence, a single word of the old draft, it still sublimated from the old draft's ashes.

Variety

This is more a specific technique than a principle, and I don't know how universal it is, but I think it's interesting enough to talk about.

Every few years there's a bit of trouble between the Haskell and Clojure communities. In 2018 it was instigated by Rich Hickey's Maybe Not talk, where he dunked on the value of option types, which made a lot of Haskellers go "wtf". Lots of flamewars on Twitter, bad blood, etc.

Ever since then, I've had this fantasy of Hickey going to the Haskell Symposium or LambdaJam or whatever and giving a talk on Template Haskell without mentioning Clojure once. I would love to see the fallout from that.

The more your life bends around a single topic, the more out-of-touch you become with the rest of software. This makes you less trustworthy, because you don't have the knowledge base to be objective. You're still earnest about your opinions, but you're also signalling a lack of expertise.

The simplest counter to this is variety: have output besides the Topic. This shows you're interested in and studying a broader swathe of software than your Topic. It also helps you reach a wider part of the ensemble: people otherwise out of your sphere find you through the variety. I know a decent chunk of my audience first found me through my writing on software history and only later heard about formal methods.

Finally, variety makes you more trustworthy. There's a difference between having expertise and people believing you have expertise. People aren't great at evaluating expertise in a novel domain, such as your Topic, and they know this. How How can they tell you're an actual expert and not just some schlub talking out of their butt?

Well, it helps if you can point to output they do understand and can appraise. They can tell you put the work into mastering topic X, they'll give you the benefit of the doubt on topic Y. It's not a perfect signal, but it's better than nothing.

(A corollary to this is that you can't "phone in" variety. Low quality variety reflects poorly on your Topic output. Remember, evangelism is about being worth people's trust.)

Oh yeah, one more benefit of variety is that it feels good. Presumably you're doing evangelism because you enjoy sharing your passions, and it feels good to turn your skills to things besides the Topic. You get to write about stuff you like! People will read it!

General Thoughts

In writing all this, I'm noticing a lot of the principles are means of self-acceptance. To be a good evangelist, you have to be okay with being an evangelist. If you're not okay with the work then it doesn't matter how good you are, you shouldn't be doing this. So you need to evangelize in a way that meshes with your identity and morals. In my case, it means being honest, objective, and intentional. I imagine someone who valued different things would come up with different principles, to make evangelism acceptable to themselves.

Also, a lot on signalling mechanisms. One thing I left out is cultural signalling, showing you understand a community well enough to get its memes, injokes, etc. But there's also signalling via objectivity, variety, and quality. How, once you've become deserving of trust, you actually get other people to trust you.

---

Article in Increment: Planning with Flare

The new and final issue of Increment magazine is out, and I'm in it! Planning with Flare, about using formal methods to plan projects, and the time it found a fundamental contradiction in our core requirements. Give it a read!

No Newsletter Next 2 Weeks

Workshop stuff. I'll send an announcement when the new Alloy 6 post is out but won't be including a newsletter essay on top of that.

If you're reading this on the web, you can subscribe here. Updates are once a week. My main website is here.

My new book, Logic for Programmers, is now in early access! Get it here.