I have spent the last 10+ years freelancing and contracting as a software developer. This January, that changed when I became a developer advocate at CodeSee.

I’m not gonna lie, it’s been an exhilarating opportunity to dip my toes into Developer Relations, or DevRel.

Next week being the end of my fourth month at CodeSee, and having listened to an incredible Twitter Spaces event where folks gave their experiences and insights into what DevRel is, I felt it was a good time to share my thoughts and experiences over the last months on this new journey. I wanted to expand on the how and why to get into DevRel by adding what it’s like a few months in.

Some context

CodeSee is working on a dev tool to help folks understand and collaborate on complex code bases. My job partly consists of thinking about the kinds of solutions I can offer fellow devs, such as the types of content related to understanding code, reading code, collaborating, mentoring, etc.!

Touching on the context of the story itself: CodeSee is currently in a closed Beta and up until a week ago was in stealth, meaning that instead of trying to have a broad outreach, we were going for a deliberate, 1:1 approach.

On jobsharing

My colleague and friend Jessica approached me toward the end of 2020 with the idea of doing a job share. In short, CodeSee hired the two of us to fulfil one full-time role, splitting the compensation. I won’t go into the details of how it works or why it’s beneficial, because she’s already done that in a fantastic way.

Doing this as a part time gig has given me the benefit of not having to immediately stop doing my freelancing, and instead just taken on smaller contracts or keep existing ones on the side. Having this flexibility has allowed me to continue exploring software development and at the same time be more selective of how I spend that time. It’s a process I’m working on to better improve my work-life balance.

A developer advocate… advocates for developers!

I found the following tweet from Nader Dabit really helpful:

In DevRel, if you can make developers both successful and happy then almost everything else will take care of itself.

The problem is that it takes a lot of consistent & sometimes thankless work over a long period of time to get there.

One of my favourite parts of being involved in tech communities after many years has been empowering people in their tech journeys. It’s brought me great amounts of joy to be able to do things like:

Funnily enough it wasn’t until the idea of working as a developer advocate was proposed to me that it clicked: this could be something I could be good at or at the very least already have been doing!

Nevertheless…

Hello impostor syndrome, my old friend

My relationship with impostor syndrome confuses me sometimes. It’s never really gone away in the 10+ years that I’ve been building software. One of the most important things that working as a freelancer has been seeing lots of different projects, codebases and the ways that different clients work and learning to get quite comfortable in my discomfort when confronted with an unfamiliar problem. I even gave a talk about this at JSUnconf 2018. It’s a topic I feel quite comfortable in. Again, that’s not to say that it’s completely gone, mind you, just manageable.

That is, until I started with this DevRel role. All of a sudden, the impostor syndrome washed over me, big time! Even though I’d been doing things in-and-out of being related to DevRel for many years this felt different.

One thing that’s helped me with this has been to just talk to fellow DevRel folks! Joe was kind enough on the week before my first day to sit down with me, hear me out, calm my nerves, and recommend some resources:

The shows of kindness from Jess, Joe, and so many others have meant the world to me. My intention is to pay it forward, so if you’re nervous about getting into DevRel, please feel free to reach out!

Turns out there are also loads of communities and events related to DevRel! I’ve been happily helping The DevRel Salon with note-taking, and also joined the DevRel Collective.

This is all made especially easier by the fact that my fellow teammates at CodeSee have been nothing but supportive, uplifting, and overall wonderful.

On demoing

One of my main tasks at CodeSee has been holding sessions with interested folks in trying out the product. As I said before, CodeSee was in stealth and in closed Beta, so we’ve been inviting folks to 1:1s with myself and/or Jess to show them the tools in action. This has been the first of a new set of skills I’ve been developing as a developer advocate, and it’s been fascinating.

The closest thing I’ve been able to compare this to has been giving talks at conferences or other events. I remember how easy it became after time to develop a routine in my head for giving a talk, trying, of course, to adapt these to the audience and context.

When it comes to giving demos of a devtool, however, there are some minor changes to keep in mind! Most significant is the scale and approach. Since demos tend to be 1:1, we can cater the demo experience to that one developer or team lead. One of my favourite pieces of advice was from Sareh who after a demo advised to open the demo with a question:

What do you hope to get out of this demo?

What are your pain points?

What this does for me is completely change the tone of the demo to be less one-sided from me talking to demo attendee (demoee?), but opens the discussion to go both ways and allows me to really, as the job role would imply, to advocate for the developer I’m showing the tool to! How our tool can make their job easier.

On following up

Our goal as a dev tool over the Beta is to get as much feedback as we can from users and see where things can be improved and how to go about this. This will involve a lot of following up with leads.

What I mean by following up in this case is, after showing someone CodeSee and giving them access to the Beta, to message them and see whether they’ve tried it, seeing if they’re stuck on the install portion, and whether we can pair with them with this.

A personal struggle of mine has been figuring out how to follow up without being (or feeling!) overly pushy. Honestly, it’s been the hardest part for me, since I never want to bother anyone.

I’ve been trying reframing this as an opportunity to empower instead of chasing a fellow developer and see how we can help them. We are by no means forced to enter a relationship where they use our tool unless they need it!

Lastly, it’s important to bear in mind that the worst thing that’ll happen is you’ll be turned down. And that’s ok! It’s not a “never”, it’s a “not now, maybe not me”. As much better put by Flaki:

I think to me the thing that best helped to frame this has been the understanding of ‘just because this person/team does not need what you can offer right now, by being helpful and giving them a great experience you already sown a seed and you never know when something comes out of that relationship.’

Producing content

When coming into the role, the value that CodeSee provides to developers comes to mind: being a continuous understanding tool, our aim is to help developers understand, document and collaborate on complex codebases.

Going off of this, the mind begins to wander, how can we as developer advocates communicate our value this way?

When it comes to blog posts, I can think of the value I’ve had in reading codebases over the years, and how developers can benefit from doing so. So I wrote the article, the first of hopefully many!

As time goes on, we plan to expand this into other media, such as talks, videos, and more.

Streaming

This last week, Jess and I held a soft launch of our streaming with CodeSee! We had a friendly chat as an introduction to open source.

It was also an opportunity to try out our tech stack. Since this was a soft launch, we did it with Zoom, streaming onto Twitch. We were adamant about having captioning on our stream, which Zoom supports as a paid feature!

We did a brief, last minute announcement to get some friends and loved ones in and had a great time!

Open Source

One task I’ve enjoyed greatly during my time at CodeSee is trying our tool on different open source projects. One advantage of doing this is trying the CodeSee tracker on multiple codebases and finding points of improvement.

On the other hand, I’ve been getting to see the value that we can bring open source maintainers by aiding in the onboarding process of their projects. Heck, by trying to install CodeSee onto a codebase, I’m getting partially onboarded onto these projects! Since this is something that matters a lot to what we’re trying to do at CodeSee, getting this experience first hand has been really valuable.

Moving forward

Well now that we’re out of stealth, we can start looking into other kinds of activities, such as collaborating with other folks, giving talks, appearing on podcasts, and more!

Conclusion

When talking to folks potentially interested in DevRel, I get the impression that the lucrative nature of the job can be intimidating or seem like an endgoal. My hope is that by sharing my experiences I can show that learning is definitely still involved and to invite you to give it a try!

Finding the points where I feel the most comfortable, such as empowering fellow devs, trying out sticky open source projects, writing blog posts, coming up with and giving conference talks, or dealing with my impostor syndrome has helped me really work hard on those specific points.

As I said at the start, working in DevRel has been an absolute joy for me. If you’ve recently started a DevRel position or are interested in doing so, please feel free to reach out!

Buy me a coffee