Technology Evangelist

Developer evangelism is one of those professions that defies easy explanation. It’s sort of marketing, but it’s not quite that. It’s developer relations, but not exclusively that. It’s selling, but with an app on GitHub. At this point, the lines between the above have become so blurred that even those practicing it don’t always agree on what they do. Consider: There are folks at Microsoft or Google (other vendors are available) who are contributing code samples and repositories to open source one day and presenting to developers about that company’s cloud platform or API the next. (Spoiler: It probably isn’t actually the future but they’re gonna convince you it is.) The point is, if it’s any consolation, there is no one-size-fits-all description for the practice of tech evangelism these days. You have the corporate evangelists, those big-name tech company reps who flit from conference stage to conference stage proselytizing to developers on how to adopt a specific technology or product. Then you have the scrappy indie evangelists who can’t be bothered to even call themselves that, but are instead the solo rep for an otherwise unknown startup peddling a…well, let’s be honest here, evangelism is the only thing giving most of these startups that little extra cache, and without evangelism, what they have to say usually doesn’t matter much in the grand scheme of tech. They are at every tech meetup doing demos on their laptop, which is always stickered to within an inch of its life.

I won’t beat around the bush on this one, it takes a particular kind of person to excel at this. Developer evangelism is objectively a ridiculous job in terms of skillset requirements. Coding-wise, you’ve got to be good enough that developers are not immediately dismissive when you share code with them, but not so good that you end up in engineering and never speak to another human. (I like to think I’m good at both though, what can I say? Dual threat.) Speaking is an obvious prerequisite. Presenting, after all, is a key part of the job. Workshops, podcasts, tweets half the time, when a JavaScript framework you use every day drops a breaking release at 2am. Writing, too, is key, because much of evangelism is written, in blog posts, documentation, GitHub READMEs that are…readable? Wow that’s rare when I think about it. Oh, and you better have the gift of the gab on top of all of that, or your community just won’t vibe with you. It’s a difficult thing to explain. Some days when I see the line-up for the next tech conference, I just shake my head at what people have to put up with to be great at this job.

The downside is… the code produced can be meh? Like it works but isn’t good. It’ll do what you asked but often with missing edge cases or will produce something correct but an older dev will cry during code review (I myself have committed at least one of these heinous things that’s technically correct but no one should write). I’ve seen AI functions with massive responsibilities or doing too many things all in one go, or writing a correct answer but in an unnecessarily slow manner. It’s using pattern-matching to generate answers but it does not actually understand performance so it can do really stupid things. So of course you need to review everything super duper carefully (learned that the hard way after shipping a bug that was literally right there in the suggested code by AI)

Debugging is pretty interesting tbh. You paste your error message and some context and get some suggestions and occasionally it’s impressively accurate! Obviously not every time but frequently enough where I have folded it into my regular process now. So instead of immediately searching or checking docs I ask the AI. Worst case it’s giving me the wrong answer and I go research anyway, best case it points me directly to what I need to fix and I save like 15 minutes of Googling. I think on average it probably saves 20-30% of debugging time which really adds up over a week.

Security is also… yeah we gotta talk about the security landmines. AI models will write perfectly working code with hardcoded passwords or SQL injection flaws if you’re not super careful. They don’t “natively” have a sense of security best practices, they just pattern-match them from what’s in their training data. And a lot of that training data is random GitHub repos with shitty insecure code, so it’ll be what it is. You HAVE to be diligent about reviewing everything with a security mindset, AI will not do that on its own.

You also have to have a social media presence because let’s face it, that’s the age we live in. For an evangelist, that also becomes a kind of performance. Be the funny one. Be the deep-technical-one. Be the controversial hot-take machine. It doesn’t matter what you pick, you are on stage all the time. Streaming code on Twitch, making TikTok videos about debugging (yes this is real), arguing with randoms on Twitter about whether this new JavaScript framework really does solve a problem that developers have or whether it’s entirely arbitrary. It’s exhausting to watch for those of us that do not enjoy being micro-celebrities in tiny little circles of the tech community. And I don’t mean to say there are those of us in the mix and then you. There are so many of us doing this, watching each other to see who steps over the line or, worse, does not. Some of you relish this. You are made for it! You breathe the stuff. You have built brands from it. Good for you. But you can see the others with your eyes closed, forced to be “on” all the time, slowly dying inside. You can see it with your eyes closed.

Code reviews and team dynamics are also changing in some very subtle but real ways as well and I don’t think this has really been talked about enough. For one, code reviews are now ALSO checking what a human accepted from an AI, which means you’re not just reviewing your teammates code but the AI’s as well? The bar feels different? You start to get this “oh the AI also suggested it” fallacy creep in as well. Onboarding people is weird now because you have to teach them not just development but how to properly use these AI tools, which is kind of… a skillset in its own right?

There’s the open source side of things, because much of the best evangelism often happens in those communities where developers contribute because it’s their passion project and they aren’t expecting a return on investment the next quarter. Answering questions on Stack Overflow at midnight? It’s not because your quarterly targets demand it, but because that’s how you build trust and rapport. Fixing bugs in another project’s docs? Not for that quarter’s numbers, but for the overall ecosystem’s good. Developer evangelism can’t shake that friction between community cultivation and that drive for short-term company gains. Every company does it a little differently and the companies that do this well handle it differently as well, obviously. Some that just…

Man, I don’t even know what to say about the future of this work, other than I think AI is going to upend the whole thing. If a developer needs sample code, it’s now a five-second Google search or chat with ChatGPT. “I’m having this error” doesn’t need to mean “please join our Discord server.” So does this make evangelism less relevant, or more? Does the human connection mean more because the bread and butter tasks have been automated? Likely a little of both. The work is morphing and evolving already, whatever happens with tech. Five years ago, developer livestreams were not a thing. Ten years ago, Twitter was not the primary form of communication between dev and evangelist. No one knows what the hell’s next.