A Day in the Life of a Staff Developer Evangelist

Curious about what a Staff Developer Evangelist does and how they help other developers to be successful? Dive into a conversation with Mark Sohm, our Staff Developer Evangelist, to uncover all the details.

How would you best describe your role? 

The main goal of my role is to educate developers outside of Mappedin on how to use our software development kits (SDKs) and application programming interfaces (APIs)  and help them overcome technical hurdles. I get to be a jack of all trades, writing guides, blogs, and sample code in many different programming languages. 

What does your typical workday look like?

For me, day-to-day activities vary a lot from one day to the next, which is one of the things I like best about my role.

Morning:

The morning routine typically begins with checking and responding to emails received from customers in different time zones overnight, ensuring prompt communication and support. This is followed by a team standup call, where members gather to discuss project updates, goals for the day, and any potential challenges or roadblocks, fostering alignment and collaboration within the team for the day ahead.

Afternoon:

Throughout the day, the main tasks involve providing support to developers via email or calls, elucidating the functionalities of the SDKs, instructing developers on effectively utilizing the SDKs and APIs to fulfill their objectives, aiding in bug resolution, crafting developer guides or blog posts, generating sample code, engaging in collaboration with internal teams regarding bug reports and feature enhancements, and conducting coding tasks related to the improvement of the SDKs.

What is your go-to lunch? 

More often than not it’s leftovers. I like to eat a variety of different foods so it varies from week to week.

What do you enjoy the most about working at Mappedin? 

The people. It’s a friendly group who are always available to help one another out. It’s a “rising tide floats all boats” mentality. Teams also welcome others to jump in and lend their expertise to build and enhance a project. I also enjoy the technological growth within Mappedin and am excited about its future. 

What tools or platforms do you use and advocate for?

I use quite a lot of tools and platforms, this is where the “jack of all trades developer” comes in. Mappedin has REST APIs and SDKs for TypeScript/JavaScript, React-Native, Android, and iOS. So that means I’m regularly switching between coding languages, which can be tough with some languages having similar structures. Sometimes my brain wants Swift but my fingers type in Kotlin.

As for tools, I regularly use Visual Studio Code, Android Studio, XCode, and Slack for internal communication. I’m also a fan of Github Desktop, it helps keep me on the correct git path.

What are some of the best ways to build a developer community? 

The first part is to have a compelling product that developers want to use. Any time you can make use of public standards instead of making something proprietary makes it easier for developers to onboard. 

As we look to expand our participation in developer forums, initially Mappedin may need to respond to most questions. But as a community matures, it’s best to wait a day or so to allow other community members to reply to one another. This fosters participation and helps to grow community leaders who become experts in helping others. The more people you have that can step in to answer questions the better!

How do you stay up-to-date with the latest trends and advancements in software engineering, and how does that influence your evangelist work?

While I am here to teach our customers, I also learn a lot from them as well. Through their questions, I learn about trends and new technologies that developers are making use of. When a customer has a question about integrating with a technology that’s new to me, I need to take the time to learn about it. 

Our daily team standup is also a good source of information as I get to hear about unique and interesting things other team members are working on.

How do you balance your advocacy responsibilities with other tasks or commitments you may have?

Simply put, time and money. My measurement of time is "how many people are waiting for me to finish X?" If there is a problem holding up a team of a dozen people, that will take priority over something like writing some sample code to show off something cool that no one’s asked for. Both are useful, but one is blocking people and the other isn’t.

When I say money, I try to think how big of an impact a task will have on the success of Mappedin. For example, I may have ideas for two blog posts, one that showcases a new feature that many customers have been asking for and another that explains an older existing feature. I’ll choose to write about the new feature because it will be more valuable to our customers and in turn, may result in more sales for Mappedin.

What advice would you give to someone aspiring to become a Developer Evangelist or pursuing a similar role in the tech industry?

At its core, the Developer Evangelist role is about helping other developers be successful. You need to be a good developer, problem solver, writer, and communicator. 

You can practice and work on all four by supporting your favorite technology or open-source project. Write some sample code and discuss it in a blog article. Find the place where developers are asking questions about it and help them out. Doing this will give you a taste of the role to see if you like it, as well as content for your resume.

You’ve participated in many hackathons in your career, how should students prioritize their time and resources when hacking together a solution?

It’s important to break your project into small steps that can be worked on individually. This is very important if you are working with a team, but is still essential if you are working on something yourself.

By building something incrementally making sure each part is working ensures that you’ll have something to demo when the hackathon ends. If you do the opposite and build as one big monolithic project, you may not finish it in time and may end with many incomplete components or worse yet, a project that doesn’t work at all.

If you're interested in joining our team, check out our careers page for current opportunities.