Reflections on One Year in as a Developer Advocate; Content

This month marks my one year anniversary with IBM which is also my first full year as a developer advocate. So I wanted to take a moment to reflect on lessons learned and share the wisdom gained from my first year as a developer advocate. This will be a three part series focusing on different aspects that come with being a developer advocate; content creation, travel, and being an advocate for developers.

I hope this series offers a glimpse of what it’s like to be a developer advocate; both the highs and lows, though word of caution this is my experience as a developer advocate so what I say shouldn’t be taken as a universal truth. Take as one opinionated view of being a developer advocate, but also be sure to take in other views as well.

Content by Developers for Developers

Content creation is easily where I have spent most of my time as a developer advocate. Content can come in many forms; blog articles, podcasts, presentations, workshops, proof of concepts/working examples, and so on. What content you will be creating will vary depending upon your own strengths and preferences, as well as the needs of your organization. No content is inherently better, though having a mix is good so as to  appeal to and support the needs of a larger audience.

Content creation can be an extremely time consuming and at times mentally taxing process. When your content has a technical aspect, there can be an extensive problem solving and investigative component as you actually build the technical resource. This part is probably not surprising to any developers, what is surprising is, is that the creative process, that is the actual creation of the content itself (i.e. the writing of an article, recording of a video, etc.) can be just as time consuming. At least for me I spend a large amount of time writing, re-writing, and editing my content to make sure it flows easily and is clear in its message.

Because content creation can be a time consuming process, finding ways to reuse content is key. A blog article can become a presentation, or vice versa, a demo can be expanded into a workshop. Taking existing content and transforming it in to different forms can not only save you a lot of time, but also make that content more accessible and usable to a larger audience. A presentation has an important human aspect that some find engaging, however not everyone can attend a presentation, so by taking your presentation and writing a blog article not only draws more value out of the work you already did, but also helps make your content make accessible to a wider audience.

Be sure to give yourself realistic timelines and/or set aside enough time for content creation. A big change that comes with being a developer advocate is the frequent hard deadlines. If you are producing content for an event; conference, meetup, client meeting, etc., your content has to be ready by the agreed upon time. There will inevitably be times where you will be frantically finishing a presentation moments before going on stage, but it is best to avoid this by making sure you are setting realistic deadlines before hand.

Tip of the Spear, Edge of the Knife

As a developer advocate, you will often be working with the cutting edge of technology. The content creation covered above, a large portion of it will be for your organization explaining to developers how to consume your organization’s services/products. This means a couple of things:

1. You will often be operating in an information vacuum, one you are working to fill! As you run into issues, you should reach out to members of your organization who work on the product you are writing about. This can not only help you in the problem solving process, but also be an opportunity for early feedback for the teams at your organization on how a product or service might be improved.
2. Because API and offerings are not yet in their final form, you might have to often go back and re-verify everything described in your content still works the same way. It has happened several times now where a step or process has changed between the time I wrote an article and the time it has been published. There is also the curation of released content. Organization will add new features, deprecate features, and change features to match the needs of their users, as your organization goes through this process, it is important for you to update content that you have created that might be affected.

Be Clear

I couldn’t agree more with Amara on this point, clear documentation is incredibly valuable. I cannot count the number of times I have read documentation where crucial steps were skipped or elements within a sample piece of code/configuration were glossed over. Being clear, complete, but also concise can really elevate your content.

The best advice I can give when you are creating content is to appreciate that your audience is not going to be nearly as familiar with the technology you are describing as you are (after all its the reason they are consuming your content!). As developers we often experience this with users interacting with our applications in ways we don’t predict. So in the same way when developing an application keeping in mind that many users will only rarely use your application is a beneficial trait for a developer, keeping a similar mindset when it comes to creating content is also beneficial for developer advocates.

Be Cautious of Overpromising

More than anything else, the biggest problem I have had in my transition to developer advocacy is over promising when it comes to content. While working as a staff software engineer deadlines were somewhat fungible. As a developer advocate hard deadlines are very common.

Dealing with hard deadlines of completing a presentation, workshop, or demo for a conference, user group, or client visit, can lead to a lot of stress, anxiety, and late nights. Sometimes this happens because a small task ends up being much larger than expected, as developers we have all ran into that seemingly innocent ticket consuming your entire week. Because of the frequency of hard deadlines, be mindful of not over-committing yourself. Burning yourself out with constant stress and late nights, or having a failed presentation because you weren’t able to complete it neither helps yourself nor your organization.

Helping Yourself as You Are Help Others

While much of this article to this point has been warning of the dangers and difficulties of creating content creation, it is also among the most rewarding aspects of being a developer advocate. Receiving a thank you from someone because they found your presentation, article, or code example helpful is incredibly rewarding. I also cannot count the number of times I have gone back to reference an article or proof-of-concept I created when working on something only tangentially related. For me at least, it reinforces that the content I am creating has value.

As a developer advocate I have also been forced into learning many more aspects of the software development pipeline. I have been a Java developer for over a decade, but until joining IBM, I only had a very vague understanding of the JVM. While I wouldn’t label myself a JVM expert, because I of my work with Eclipse OpenJ9, I have a much deeper understanding of JVMs, and how they operate. Another area as developer I often didn’t interact a lot with was operations and platform technologies. While it has at times been a frustrating experience in the past year learning about technologies like Docker, Kubernetes, these will be valuable skills going forward.

The learning process while at times difficult and stressful is also satisfying and incredibly rewarding. Because I am working with so many different technologies and practices I never feel like I am in a rut, which is a pleasant contrast from my experiences as a developer.

Conclusion

Content creation is a time consuming but rewarding process. As a developer advocate there is a good chance many of your highs and lows will come from content creation. The most important points to remember is set realistic estimates and avoid overpromising and you will hopefully avoid a good chunk of the stress and anxiety I have experienced in my first year as a developer advocate.