If you have a short attention span and want to know why I switched from a developer relations role into software engineering, the very short answer is: imposter syndrome.
If I still have your attention in a world of constant distractions, I’ll give you all the details. It’s been nearly 3 years since I moved into a software engineering role, so I’ve got some good perspective on what’s involved and how it compares to developer relations (DevRel). This post assumes you know a bit about each of these roles.
What motivated me to move into engineering?
Most of my career decisions thus far have been motivated by a desire to fill knowledge gaps, keep learning, and do something that scares me by getting a little out of my depth. This career move was no different. I spent most of my 8+ years in a developer relations role on the same team, but over this time I shifted the area I was focusing on every time I started to feel too comfortable, or if I felt I had started to plateau in learning new things. When I first joined Cloud developer relations I worked on machine learning APIs. These were APIs for images and text that would give you details about what was in an image or the category or sentiment for some text (side note: it’s wild to look at how far the technology has come since then!). I was new to machine learning at the time and these were a great way for me to get introduced to the field. However, by using these APIs I wasn’t interacting directly with any machine learning models. That was the main benefit they provided to the user, but personally I wanted to learn more about the underlying technology.
To get a little uncomfortable, I asked to switch my focus to a product that enabled building your own machine learning models. At first, I had little to no confidence in myself and wondered why I should be trusted to teach others something I barely knew myself. But after some time getting to know the technology and asking a lot of questions to product and engineering teams, I started to get the hang of it. Slowly I built confidence while still remembering what it felt like to be totally new to a topic, which I think is part of the reason I was successful in this role. The angle I always took when developing code samples, talks, or blog posts was to put myself in the position of someone just getting started and explain concepts from that perspective.
Whenever I felt I’d maxed out what I could learn about a particular product, I’d start over with another. I repeated this process a few times throughout my years in DevRel. But my whole time in this role there was always a little nagging voice that said, “you’ve never been a software engineer, how can you really be any good at this?”. This persistent lack of confidence was definitely annoying (maybe you’re even sick of reading about it), but it wasn’t all bad. It’s what continued to push me to keep challenging myself.
Many folks in the developer relations role have previously been software engineers, though it’s definitely not required. After all, I made it to Staff Developer Relations Engineer without having been a software engineer. I even think not having a software engineering background was an asset to me in DevRel. But somewhere along the line I started to feel like an anomaly and I wondered, could I do it? Part of this doubt stemmed from having my technical skills questioned every now and then. This mostly happened at in-person events, which led me to believe that maybe it was a gender issue. Sometimes after I presented a demo someone would come up and ask “did you write the code for that?” Yes but why did it matter? Or there was the occasional “it’s so cool to see a woman do a technical presentation.” What about simply, your presentation was great. Or if I was staffing a booth at a conference someone would look right at me asking “Is there someone who can answer my question about X technology?” It’s me, hi. When things like this happened I’d brush them off in the moment as no big deal, but over time they got to me and I started to wonder if there was truth to them.
In the end I decided the only way to get rid of these doubts was to prove to myself I could do it. Was that a good enough reason to switch roles? I’m not sure, but it was my reason. I also thought it would be cool to tell people I met I was a software engineer. Barely anyone outside of the tech world has heard of DevRel, but most people know what an engineer is. Slightly petty? Perhaps.
My engineering rotation
Determined to prove to myself I could write code, I finagled a six month software engineering rotation on a different team. This seemed like a pretty risk-free way to try out the role. If I hated it or was terrible at it I could go right back to my previous team and pretend this never happened.
Before I started the rotation, I was debating joining a completely different product team for a change of pace. In the end I decided to stay in Cloud AI, which turned out to be a great decision. I don’t like changing too many things at once, and because I was already familiar with the product it made my onboarding experience much smoother.
I dove into the rotation wide-eyed, surprised at how different the work was from my previous role. I did write a lot of code in DevRel, but it was usually for demos or samples which rarely required writing tests or thinking about backwards or forwards compatibility. When an idea formed in my head for a demo, I’d start writing code immediately without thinking about design. And while I did collect feedback and improve a demo over time, the feedback would typically be about the demo itself and not on the underlying code.
The engineering role was totally different. If I was in charge of building a feature, there was quite a bit of work to do before I even started writing code. I’d propose a design with multiple options, get feedback from teammates, update the design, and finally begin development. Being an impatient person, at first this process was at odds with how I liked to work. I preferred starting immediately and then updating my plan as I ran into issues. In the long run though, thinking about design first led to a smoother development process.
Then there were the tests. Oh, the tests! Testing code was mostly new to me. If you’re reading this horrified, wondering how I’d gotten along barely having written tests until this point, remember I was new to this role (we all were at some point). A demo is usually short-lived, and so the idea of writing tests for demo code is typically silly and not the best use of time, since a demo is often built on a tight timeline. This is all to say, spending time fully testing a new feature I was working on or even a bug fix was a little overwhelming to me. As a result, for my first few months in this role I was terrible at estimating how long it would take me to complete something. As someone who usually liked to underpromise and overdeliver this was tough and also embarrassing.
Over time, my estimates started to improve and so did my confidence. Whenever doubt crept in, I reminded myself of my track record of eventually figuring things out. At the beginning of the rotation this career transition felt like the toughest one yet, but as I found my stride I started to really enjoy the role. As I approached the end of the six months, I had a few projects still underway and started to really feel like I was getting the hang of the work. That’s what led me to do a role transfer and stay on this team full time.
Which role do I prefer?
Annoyingly I’m going to have to say it depends. I don’t think one role is better than the other - they both have pros and cons depending on your skillset, the phase of life you’re in, and what you enjoy working on.
One thing I really like about engineering is that most of the time I’m working on a clearly defined task. That definitely doesn’t mean the path to completing it is obvious, but when I start work each day I know exactly what I’ll be working on. DevRel is much more open-ended; there are many ways to have impact and be successful in the role and often it’s up to you how you’ll do that. At times I love that self-directed way of working too, but at the time I was ready for a break from it.
The flip side to being in a very well-defined, well-understood role is the way your work is perceived by others outside your team. As an engineer, I’m assigned a project, finish it, and then move onto the next one. Everyone in the company knows what the software engineering role involves, and when you finish something you are assigned there isn’t much fanfare about it. DevRel is understood in small circles, but many people aren’t familiar with it even if they have worked in tech for a while, maybe because it’s specific to developer-facing products. The upside of this is many things that are part of your job description are perceived by other teams as an extra bonus. “You wrote a blog post about our product? Amazing!! You built a demo to show off our product to customers? Wow! You are truly the best!” As a millennial who likes to be told I’m doing a good job, I will be the first to admit I liked this and got used to it. Because of this, for my first few months in the engineering role I kept wondering “Am I doing this right?”
One skill that’s essential to both DevRel and engineering (and probably every job) is communication. There’s a perception that engineers spend their days staring at their computer screen without any human interaction. This is far from the truth. You need to be able to present design proposals, convince others that a certain approach is best, walk through how your code works, and provide feedback to teammates when reviewing code. Perhaps most importantly, you need to document how your product works even if it’s only used within the company. Code on its own is ok, but it’s nothing if no one else knows how to use it easily.
DevRel is typically an external-facing role, so the communication skills required are more obvious - giving talks, writing blog posts and tutorials, building demos, making videos, etc. What people may not see is the internal advocacy that I believe is essential in DevRel. This involves sharing the feedback you’ve heard from external users with product and engineering teams, and presenting this feedback in a way that’s actionable. This is all to say, I enjoy the communication aspect of both roles. On the engineering side, sometimes I do have to withhold the urge to spend my time building a demo of some feature I’ve just built. I suppose after nearly a decade in DevRel I’m hardwired to do this.
Do I want to be an engineer forever? I have no idea. I’m really happy with my decision to try an engineering role. I love getting to solve puzzles every day, and you can’t beat those aha moments after spending hours investigating an obscure bug. Sometimes I do miss the creativity and writing parts of DevRel (maybe that’s why I’m restarting my blog). I’m grateful for the opportunity to switch roles, and spending time in engineering has given me a more well-rounded understanding of how organizations run. I’m confident my DevRel experience has made me a better engineer.