As a Developer Evangelist at Stormpath, one of my jobs is to help increase developer adoption of our User Management API.
In this post, I’ll share my personal goals with you, what I’m doing to reach them, and what I’m learning (as a series!). If you’re interested in developer evangelism, the inner workings of a
start-up, growing your developer-centric business, or just excited to learn more about Stormpath, this series of post is for you.
My job, as a developer evangelist, is to make Stormpath popular. That’s it. The overarching goal is to make sure that programmers who need Stormpath are able to find it easily, use it, and love it!
As you can imagine, there are lots of ways to be a successful developer evangelist. There’s no magic bullet, or direct path to success — it’s all a guess!
My job currently entails helping developers integrate with Stormpath, and doing whatever I can to ensure developers are able to build cool stuff with Stormpath.
As part of that work, I help with library and framework integrations, build sample applications, attend conferences and events, talk with a lot of different programmers, and of course, blog.
NOTE: It is a dream job, in case you were wondering ^^
And, since my job puts me in contact with so many different people, I also share whatever feedback I get with our engineering team so we can continue iterating on Stormpath’s core product, and make a better service for developers.
To kickstart this series, I’d like to formally clarify what my personal goals are as a Developer Evangelist at Stormpath:
- To have fun.
- To help a lot of developers build projects.
- To make life as easy as possible for developers.
“Find a job you love and you’ll never work a day in your life” – Confucius
My first and foremost, my personal goal here at Stormpath is to have a lot of fun — among other things, this means I’m focusing on:
- Working on projects that I find personally interesting and exciting.
- Attending events where I know I can have a genuinely good time, meet cool people, and make a difference.
- Pushing myself to produce quality work (projects, docs, libraries, etc.) that benefit a lot of people and are personally gratifying.
My reasons aren’t entirely selfish — I know that if I’m loving what I’m doing, then I’ll do a great job — and I didn’t come here to be mediocre!
While it may sound idealistic, fun is my top priority >:)
My next priority is to be genuinely helpful to developers — and help them build cool stuff.
“Help people build stuff.”
Which makes a lot of sense to me. He went on to explain that if you’re able to help someone out (fix a bug in their project, help them accomplish something, help them get some code launched — whatever), you’ve done your job for the day.
I really like this idea.
So — I’m taking it to heart! Whenever I’m working on projects, or attending events, the main thing I’m thinking about is: “How can I help someone do something awesome today?”
If I can’t find a way to help someone build a project, or write some cool code — I’m failing at my task.
This is quickly becoming one of my favorite aspects of the job.
By building personal connections with lots of people, I hope that some of these people will eventually learn about (and potentially use) Stormpath.
It’s obviously not a form of “scalable marketing”, but it’s genuine, nice, and most importantly: fun!
Luckily for me, this is completely in line with how the rest of Stormpath team thinks, and the brand we’re trying to build.
This point is pretty important: I want to help make my fellow developers’ lives easier.
I plan to do this in several ways:
- Writing various open source libraries that abstract away the pain of building stuff (both related and unrelated to what Stormpath does).
- Improving the Stormpath client libraries, to make interacting with Stormpath as painless as possible.
- Writing incredibly great developer facing documentation, to make Stormpath not only simpler to understand, but more useful.
- Giving talks which clearly explain complicated topics in software development, and spread knowledge on how to solve particular problems in the best possible way.
These points are more or less self-explanatory. By abstracting away lots of the boring and tedious components of software development, I’m hoping to make some programmer enjoy their life just a little bit more than they already do.
I can’t tell you how many times I’ve been building a project, ended up Googling some problem, and found a really lovely open source library which not only solved the problem for me, but solved it well! It’s such a great feeling to offload responsibility and complexity to a third party, particularly when the problem being solved is something boring!
Nobody wants to write boilerplate code all day long!
I’m still new to the role and learning a ton from our team, other evangelists, and our customers. In my next post, I’ll cover some of the more important things I’ve learned in my first few months as a developer evangelist.