Being a Developer Advocate at JetBrains

Mandatory initial exclamation about how little I have blogged here lately. Over a year without updates, oh dear! But a) I have been blogging quite a lot for the IntelliJ IDEA and Upsource blogs, and b) I had another baby, which kept me quite busy.

So on that topic (more or less) I get a lot of questions about my job: what’s involved in the job, what’s it like working for JetBrains, what does a Developer Advocate do, what’s it like working remotely etc etc. Given I also rather generously1 recently offered to answer people’s questions about my job, I thought the most scalable way was to write-once-read-many, i.e. write it in a single blog post for everyone to read.

This is a Very Long Post. It’s also a bit of a brain dump and is not well organised, sorry. I take comfort in the fact that if you don’t care about the role you won’t read it, and if you do care you’re probably interested in all this.

Getting Started

One of the most common questions I get is “How does one become a Developer Advocate?”. I’ve already written about My Path to Evangelism, which covers how I got into this job. My route is not the only route, but at the bottom of that post there are some things you can do to a) see if you like doing this kind of thing b) improve your skills in this area and c) get the experience and visibility you need to make it easier for someone to hire you to do this professionally.

What do I do?

I’m a Developer Advocate for JetBrains. Developer Advocates/Evangelists come in various different shapes and sizes depending upon the individual and the organisation. At JetBrains advocates do advocacy first and foremost (see the next section which explains a bit about what I mean). For me, this means I:

  1. Physically go to conferences and give presentations. I prefer live coding demos, because I think a) it makes me look clever and b) it showcases the tools nicely. This is not a requirement of the role, it’s something I personally chose because I thought it was good for my personal “brand” (this is linked a bit to the fact that I’m a female developer, more on that later). Hadi’s talks are more varied than mine, he has plenty that aren’t specifically code-related.
    From JetBrains point of view, if you’re out at conferences giving popular talks, that makes the company look good.

  2. While I am physically in a country/city I may also seek out user groups and customers to go and see. This is not a requirement of the job, but it’s something I want to do more of and get better at. It’s very effective and fairly limited extra overhead to also give the same talk you’re giving at some conference to the local user group and some customers.

  3. Customer meetings. When I originally took this role, I thought I’d be doing a bit of consulting as part of the job, e.g. going to a customer and trouble-shooting their TeamCity installation or running tailored training courses on IntelliJ IDEA. I’ve been here three years and I haven’t done that. I have, however, done pre-sales trips to demo a particular product (usually Upsource and answer questions about it: what does it do, how does it scale, where will it fit into this company’s process, etc. I’ve only physically had to travel for these a couple of times, usually a company is more than happy to have me present this via a private webinar. These webinars can sometimes be to a huge number of developers (hundreds), more usually to 10-20 techies, occasionally just to one or two people. Whether it’s a webinar or a physical meeting, I always, always have backup to help me with things I don’t know. I’m a technical advocate, I understand how to use the tool really well. I don’t necessarily know everything on the roadmap (that’s usually the PMM), nor do I know all the technical limitations (a lead techy will know this). It scares me a bit going into these meetings knowing that I don’t know everything, but sometimes I have someone with me (either physically at the meeting or online with me during the webinar) and I always have someone available via Slack to answer any questions I don’t know the answer to. I don’t believe my credibility has suffered when I’ve said “I don’t know the answer to that, let me quickly find out”, especially when there’s almost always a fast response. If there’s no adequate response there and then, I make a note of the question and promise to get back to them. I usually end the meeting by repeating the next steps and listing the information I believe I have to find out for them, and always follow up with an email. If the answers were quick to find, all the answers will be in the follow up email. If the answers are still pending, I will tell them that in the quick response and get back to them later with the answers (e.g. I don’t leave them hanging with no response, it looks bad.)

  4. Webinars. I’m not a fan of giving webinars, it’s like doing a conference presentation, only with waaaaay more real-time viewers and almost zero real-time feedback. It’s like talking into the void. Some people like giving webinars precisely because they CAN’T see the audience. I used to hate them because the lack of feedback is very unnerving, but with practice (like anything) I’ve become more comfortable with them. I probably give maybe 3 public webinars a year (like my upcoming webinar on Java 10, and maybe 6 or so private ones a year. These numbers may be totally incorrect, but that’s what it feels like. The public webinars are frequently one of my conference talks just presented online, the private ones are less formal/practiced and may be something like a short-ish live demo (10-20 mins) followed by questions and further customer-driven demos (i.e. “can you show me how you…?")

  5. Screencasts. I hadn’t done any screencasts before I came to JetBrains and they’re a totally different skillset. Not only do you have to learn how to use a brand new tool (I use Camtasia) that requires a set of skills you probably don’t have already (i.e. video editing), but putting together a 5 minute video of features is a VERY different thing to taking 40-60 minutes exploring a concept in real-time with an audience. You have to work out up-front what it is you’re trying to demo, figure out a sensible real-world use case for it, and then record the video and narration that effectively shows this to users. I record those two things separately and edit them together, others like to record the whole lot together. Because this area in particular is one where probably most of the team was new to the skills needed, we’ve shared our knowledge a few times here to try and improve ourselves and to try to get some consistency in approach. I quite like doing screencasts because they’re a good way to poke at particular features in a tool, and I like finding the use case that makes the feature make sense. But they can be quite a lot of work. A screencast like my VCS features in IntelliJ IDEA 2018.1 can take less than a day to put together (most of which is editing), because this is an area of the tool I know well, and I have a lot of example projects that showcase different use cases of Git workflows. A screencast on Spring features is more likely to take 2 or more days, most of which is locating the right sort of code example that shows the features. It’s an area of the tool I haven’t used much in a real development environment, a framework I’m familiar with but again don’t use much, and also a framework that moves very rapidly, so I spend a lot of time getting up to speed on the new parts of the framework and finding examples. Screencasts generally fall into two categories.

  6. Blogging. I love writing. It’s what got me into this. It’s why this blog post is SO much longer than it really ought to be. I probably average 1-2 blog posts a month. Probably not that much actually, it depends a lot on my travel and other workloads. For JetBrains I blog about:

  1. Twitter. I have access to Tweet on intellijidea and upsource_jb. I’m not the only one behind those handles though. I post links to the videos, blog posts and other content I produce, and I also create content for the Twitter Tips for both of those products. I use Camtasia to record short videos and convert them to GIFs. The most painful part of this process is thinking of something interesting to Tweet about.
  2. I also Tweet from my own personal account. As I have gained more followers I have been more and more careful/restrained about what I Tweet from there. I recently realised these days I retweet a lot and occasionally tweet things I think are interesting to developers. I spend less and less time ranting on there or making personal observations, although I would quite like to bring back a more personal element to my Tweets.
  3. Theoretically I also answer questions via Twitter/StackOverflow/other social media about our tools. I don’t get around to doing this very often, I should work it into my schedule/routine, but sometimes I find it takes a disproportionally long time to replicate a problem and work out a fix, by which time someone else has already answered or the original user has worked it out. If someone addresses me directly I always try to respond, even if it’s just to ask someone to file a ticket in YouTrack.
  4. Admin. I actually have to do quite a lot of mundane admin stuff. Part of it might be because of my particular perfectionism, part of it might be because my situation really does require it. For example, I have to book my own travel for a lot of the conferences, usually this means flights and accommodation. I tried a travel agent for this, but I found a lot of the complications were not around the actual booking process, but coordinating with everyone (my family included) which times/days work best, am I bringing the family, am I going to do customer visits, which customers might want to see me, when works for them etc. Also since I’m travelling from Seville, we do have an airport but I’m very limited for flight choices, which always bites me even though it’s five years since I was spoiled by living in London.

How are the advocates organised at JetBrains?

When I was at MongoDB, the Advocates were engineers who spent most of their time working on language drivers for the database and some of their time blogging and speaking at conferences. At JetBrains, the Advocate position is a full time job doing the advocacy stuff. We don’t report to engineering, we don’t report to marketing, our Boss Person reports directly to the CEO.

The advocates all belong to the same team, but each advocate has their own product(s) and specialties. In terms of co-ordinating what we’re actually going to work on, we talk to the PMMs (Product Marketing Managers) for our product and they’ll let us know what they need from us. Each PMM and each product is different, so they have different interests/focuses/plans. With IntelliJ IDEA I spend quite a lot of time working with the PMM on each of the 3 releases a year, and most of the rest of the content is driven by me: it’s either connected to something else I’m working on (like one of my conference talks) or a Java release or something. Working in this way is quite familiar if you’ve been a consultant: in this model, the PMM is basically my customer and not my manager.

Physically, our team is almost entirely remote. The JetBrains development teams are based in Munich and St Petersburg, and there’s an office in Prague, so those of us on a European timezone have an easier time of it. Our American team members tend to be dragged out of bed earlier than they would probably like in order to dial in to meetings.

Do I still code?

Yes and no. I don’t write enterprise code any more, and I don’t write code that goes into the IntelliJ IDEA codebase. I do, however, spend a good chunk of the year creating projects that demonstrate particular things, and live-coding within these projects. I also occasionally still contribute to Morphia, although mostly I use that as an example code base to demo various things

  • I love the Morphia code because it’s real lived-in code that is very similar to the sort of code that real developers will be working with, it’s not just a nice clean toy project that bears zero resemblance to real life.

On a weekly basis I don’t spend a lot of time coding, but every now and then I will devote a day or two (or sometimes a week or two) to playing with something to scratch that itch. This is often used in blog posts or demos but sometimes it’s enough just to learn something new.

Other members of my team spend more time coding, either on open source projects, on bots for Slack, on creating tutorial code, on plugins for IntelliJ platform IDEs, etc. I probably code less than any of the others and I would like to change that this year.

What did I need to learn on the job?

I had been doing advocacy before I got to JetBrains, but there were still plenty of things I needed to learn or level-up when I got here:

  • Screencasts: I had zero experience here, and I struggled to begin with. But then the whole team had a number of discussions about how we did them. At first I was scared to talk about didn’t know or what I was struggling with, but I found that when I opened up (both on Slack and during one of our annual actual-face-to-face get togethers) about my pain points, I found a) lots of the others struggle too and b) some people had answers that worked for me. Also c) turned out I knew things other people didn’t know, and that gave me a big confidence boost. A lot of this is now documented on Confluence, so new people won’t have to struggle as much
  • Webinars: I’d done two at MongoDB and I really didn’t like them. For the first year at JetBrains I still didn’t really like them, but we gather feedback from attendees and on the whole people liked my webinars, and those that didn’t usually gave constructive feedback, so I gained confidence and I think I’ve improved in this area too. Also, it became clear I absolutely had to pay a lot more for my home internet connection, since the major complaint was always that my sound would frequently cut out or get out of sync. Now I have faster internet and it’s made my (work) life all round much better.
  • Self management: I’ve worked a lot at “proper” enterprises, where there’s a clear chain of command. I’ve also worked for consultancies, where customers have clear expectations of you. I’ve worked at startups, at one of which my manager liked to micromanage everyone, down to the lines of code they wrote. JetBrains is not like any of those. It is genuinely a flat organisation (as I mentioned above, there’s very little management between me and the head boss person), and people are given the freedom to work on what they want to, more or less however they want to, you’re trusted to get on with your job. This can be quite a change if you’re used to formal management. It’s both a good thing and a challenge if you’re remote - there’s no central person to contact regarding… pretty much anything, which can be strange, but on the plus side you get to locate and talk to lots of individuals about what they work on and what they care about.

How much travel is involved?

Over the last 5 years of doing advocacy I have been to quite a lot of conferences. Every year I say I’ll do less, and every year I end up doing much more than I expected. Last year I “only” did 7 events, and I was unable fly/on maternity leave for nearly 3 months. That’s slightly more than the one-every-other-month I wanted to do, but quite a bit less than previous years. This year I’m currently signed up for only two conferences, I expect that to at least double by the end of the year.

Not everyone travels as much as me though, Hadi and I probably travel more than any of the others. Advocacy doesn’t have to be spending your whole life racking up air miles, and at JetBrains how much travel you do is entirely up to you. I choose which conferences to submit to, I choose which ones to go to when I’ve been invited. I can ask for guidance on which ones may be valuable to JetBrains, but ultimately the decision to travel is mine (now all the conference organisers who I’ve said “no” to probably feel aggrieved I didn’t want to go to theirs - I’m so sorry, but I won’t spend my whole life on a plane. Or, more likely, sat in the lounge in Madrid/Barcelona/London/Amsterdam/Paris waiting for a connecting flight).

I expect our technical writers won’t have to travel at all, except perhaps occasionally to the office to connect with people.

What’s it like working remotely?

I’ll be honest, it doesn’t suit everyone. And there’s a skill to it too. I tend to like to work 10ish-6ish because if I don’t work normal office hours I’m worried I won’t be doing enough. I also track how much time I spend on things, mostly to see where all my time is spent on those weeks where I feel like I haven’t done anything.

JetBrains uses Slack a lot, so us remote people do have a direct line to what’s going on, even into the teams that are all sat together in an office. The Developer Advocates have our own Slack channel, of course, and that tends to be full of “witty banter” / water cooler conversation. It’s also the first place I go to ask questions about anything, and I’m no longer scared of looking stupid if I ask a “dumb” question.

I’ve worked remotely in the past, it’s better here than other places because JetBrains understands there are remote workers and that we have rights and needs. It’s also good for me because I’m in Europe, so although I’m physically separate at least I don’t have the timezone problem.

Working remotely is great for flexibility, of course. And although I do try to work 10-6ish, in my office upstairs where the children can’t get to me, I am around if one of them needs me immediately. I also don’t have a commute, so my hours are a lot shorter than if I worked (for example) in London. I don’t believe I could have gone back to work after just 4 months of maternity leave if I had to work in an office - I’m still breastfeeding and this would have been impossible if I didn’t work from home.

Of course this has its pros and cons, working at home also comes with distractions (although it’s nice to be able to get the laundry done throughout the week rather than have to do it all at the weekend). Pros: a good excuse for a nice computer and exactly the desk / chair / office setup you want; close to the family and much more available than in an office. Cons: can be quite isolated, can be easily distracted, can be quite noisy (currently both the 5-month-old and the two-year-old are crying: is OK to be writing a blog now, would be a terrible time to record a screencast).

Remote working is a big topic of its own. If you’ve done it before, you know the deal. And JetBrains is better than most places because they recognise us as real workers. But also probably because the whole team is remote, so it’s not just one or two people cut off.

We’re in the process of working on an employee handbook which will help us remote people a lot too, there’s a lot of knowledge stored in people’s brains that isn’t documented anywhere.

What is the team like?

There are a dozen or so advocates on the team, all with different technology backgrounds and covering different tools. Hadi and Svetlana cover Kotlin, which also tends to overlap with IntelliJ IDEA. I do IntelliJ IDEA (I guess I’m the main IDEA advocate, I do all the release material etc) and I’m the only one who really does Upsource, and have so far been nearly 100% Java-the-language. Anton does TeamCity and because he’s Java & Kotlin there’s some overlap there with IntelliJ IDEA. Other team members cover C++, Python, Go, .NET, Web technologies (this last is an area we’re looking for specific expertise) and related tools (Resharper, Rider, GoLand, CLion, PyCharm, WebStorm) and I have probably forgotten a load of them too. I see us as individuals doing a similar job but with surprisingly little overlap. This is one reason being remote actually works for us, we don’t need to co-ordinate much. But we are trying to get better at reusing stuff between tools, and/or taking other people’s ideas and content and reworking it for our communities (for example, I stole a load of Paul’s PyCharm tip tweets and did them for IntelliJ IDEA).

The average age of the team is somewhere up in the late thirties. I myself am just about to cross into the 40s - eeeek! We’re all experienced developers with an interest in our technologies and communities. We’re laid back and passionate, which sounds like a weird combination but works well for us. There’s no such thing as a stupid question in our team, and even though we don’t work super closely on everything, we all support each other and do our best to make the team happy and productive. We definitely have room for improvement for working together (Gary and I had fun recording our series of Git videos but we haven’t managed to do anything similar since) but it’s not because we don’t want to work together.

What are the good parts?

  • Being remote
  • Managing myself
  • Picking my own code projects
  • Learning new technologies and tools
  • Flexibility
  • Travel
  • My office
  • Where I live
  • The coffee

What are the bad parts?

  • Being remote
  • Managing myself
  • Not having enough time to code
  • Learning new technologies and tools
  • Travel

Yep. The plus sides are also the downsides. I probably don’t have to explain why, but if anyone is interested in the specifics drop a note in the comments below.

What are we looking for in a developer advocate / technical writer?

This was all sparked by our need to hire a couple of people, and wanting to be really transparent about what the role was like, ideally to attract people who might not have considered this role for themselves.

JetBrains is currently hiring a bunch of people, but the two roles that sparked this whole conversation are a Web Technologies Developer Advocate and an Engineering Technical Writer. I’m not the one making the hiring decisions, and on top of that there’s no real hard and fast rules about what makes a good hire into these roles, but I think these things are interesting to us:

  1. Ideally you will have at least 10 years of experience as a developer. You don’t need to have been an architect/tech lead or other “senior” role, but you do need to have a very good understanding of what it’s like to be a developer, what the pain points are for people in this role, how developers use technology and how they learn it. In our writing / presentations / screencasts we try to present information in a way that makes developers awesome at their jobs (see Kathy Sierra’s Badass: Making Users Awesome), which means our content is usually pretty technical and targeted at developers. Having a good chunk of experience as a developer in the real working world makes this substantially easier.
  2. You use our tools. Yes, it’s possible for anyone to learn on the job. As developers this is pretty much all we do. But it’s going to be much easier for you to talk about how our tools make developer’s lives easier / improve people’s productivity if you’ve actually used the tools in real life, have really felt their benefits, and have a good enough understanding of how to use them to look like a power user (at least in the context you’ll be showing them). You don’t have to have used all of our tools all of the time, but to be a developer advocate of a particular IDE, you really should have used that IDE to code in the day job and have used it as more than just a text editor2.
  3. Ideally you’ll have some public profile that demonstrates you are not only interested in some technology community (ideally the one we’re hiring for, e.g. web technologies) but are active in that community. We’re not looking for Rock Star Ninja Fully-Established Famous Developers. But this role is very much about being visible to developers, so it would be nice to see that you are capable of interacting with other techies in a community. What do I mean by this? I mean you don’t have to have tens of thousands of followers on Twitter and thousands of points on StackOverflow and have been speaking at conferences for years and be the leader of a user group and have an established blog and have written a book. What we would like to see though is maybe one (or more) of the following (there may be other types of public (or public-ish) activity which is just as good. The key point is that you are involved in your community in some way3):
  • Have presented at a conference or user group
  • Active involvement in User Group(s) - e.g. organiser, regular presenter, active on mailing list etc
  • Have a technical blog
  • Have a profile on StackOverflow which demonstrates the ability to provide valuable answers to questions
  • Have a GitHub (or similar) profile which showcases involvement in open source code and/or has demo projects / code that other developers have found useful.
  • Have a Twitter profile that shows an interest in relevant technologies, and that you post content that’s valuable to other developers (e.g. re-tweeting/linking to interesting content)
  1. Related to point three, you have to be able to demonstrate truly excellent communication skills. I have been involved in hiring developers at all sorts of organisations, and communication skills is always seen as an important part of the role. But for a role like this, the job is almost entirely about communicating to people: to developers / architects / even management about why and how to use our tools, and between you and the product marketing managers for the tool you’re the advocate for (more on that above). Add to that the fact that we are largely remote, it’s that much more difficult both to express what we mean to our colleagues and to get a feel for what our colleagues are trying to tell us. You need to be able to communicate potentially very technical ideas to other techies, you may need to be able to understand process and talk about how a tool fits into a process (or what process works for a tool set), you need to be able to work out with potentially multiple stakeholders what your priorities are and talk honestly to set expectations.
  2. Ability to be self-managed. We’re experienced people who are grown up enough to make our own decisions. We manage our own priorities, with input from stakeholders. We can ping the Boss Person to ask for help, opinions, input, and he’s always, always there to help unblock us, give us advice, point us to the right place/person. He will NOT be going through our backlog and prioritising work for us, setting deadlines, or demanding anything from us. Our job is to keep users, customers, and the product owners happy, and we’re trusted to get on with that with the full support of the team and leadership.

Call to women.

Right, so, I didn’t really want to do this because I hate trying to suggest that different genders have different needs by singling out a particular gender. I also have found that my advice “for women” works really well for almost everyone anyway.

But I do very specifically want to talk to you if you are a woman developer (or other minority, but I can only speak from my experience of being a woman) and are even vaguely interested in developer advocacy as a career.

  • If you think you maybe could do this, but you’re not ready yet, you probably are ready. For every time you’ve thought you couldn’t present at a conference, think of those talks you’ve seen where you’ve though “I could do that. I could do better than that”. You don’t have to be perfect straight away and you don’t have to be better than everyone immediately. You simply have to be good enough.
  • You already have the skills you need for managing the social media side of this job. I had an excellent question last week on Twitter about how I handle the fact that my Twitter feed is effectively a public representation of JetBrains as a company. And I realised I don’t freak out about this - partly because JetBrains is really cool about “the voice” of the company and is happy to have us just being ourselves, but mostly because as a woman, particularly a woman developer, I am already super-conscious of what I post, how I word things, how I appear on social media. Doing this as a job required almost zero adjustment for me.
  • My experience in the Java/JVM community has shown me being a woman is a massive advantage for things like getting in to speak at conferences. I’ve been on the programme committee for a couple of conferences, and I’ve seen the CFPs generally dominated by submissions from men. We’ve actively looked for those from women and generally said “yes” to them unless there was a compelling reason not to. You will often get emails from conference organisers saying “I’d really love for you to submit to this conference because we don’t have enough women speakers”, and while that particular approach makes me roll my eyes (what, you don’t care about the content, you just care about having a woman’s face somewhere on your website?) it is something you can use to your advantage. And to be fair, they wouldn’t invite you if you were crap.
  • If you’re worried about being taken seriously as a developer when you’re a woman, I can tell you from my own personal experience that being semi-famous in this space has reduced the number of “are you a real developer?” questions at conferences and events to zero. If you’ve got “speaker” on your lanyard, if you’ve just given a live demo showing you can code, you no longer have to prove yourself to anyone, it’s out there for everyone to see.
  • I don’t want to draw attention to this side of things because I don’t want you to worry about it if you hadn’t already thought about it, but it’s something that I was scared of right at the beginning: I was worried I might get shit over Twitter or on the blog for being a woman. So far (fingers crossed) I haven’t had the sort of thing I was afraid of. I do get mansplained at sometimes, and I do have to respond to idiots on Twitter. But a) I see my (white, male) colleagues suffering the same thing all the time and b) my team, JetBrains and even my Twitter followers etc have my back. I have a support network. The fear is still real though.
  • If there are more of us doing this job, there will be fewer people looking at the single woman developer thinking she represents all women developers. If half a dozen women’s voices are out there, it becomes clearer we don’t all want the same things or work the same way, And That’s OK.

If you are a woman developer and are considering applying for this role, I urge you to please apply. And if you have any questions, queries, doubts etc, please do contact me directly.

I’d really love to see more applications from women developers. That’s not to say we discourage or dislike applications from men or that we’ll reject you if you’re not female, but if you are a woman developer and are even marginally interested in this role, please, please go for it!

1 It's not generous at all, it's totally self-serving for JetBrains since we're trying to hire developer advocates and technical writers
2 I was a power user of IntelliJ IDEA, and I had done live coding demos with it in the past when I joined, and that was probably a large part of why I was hired. However, I hadn't used Upsource or TeamCity before I came to JetBrains and I have done advocacy for both tools, so you don't need to be an expert in all JB tools. But the fact that I had used other code review tools before and felt a LOT of pain while using them made Upsource a joy to advocate, since it fixes so many of the pain points I've felt with other tools. And the fact that I've worked in Continuous Delivery environments, and had experience with Jenkins, also made it easier for me to see where TeamCity fits, what it does well, why you might use it.
3 Now I have children I seriously appreciate that physically getting out to user group events or conferences is very challenging for developers who are parents. That's why this list also includes things which are a little easier to do on what can laughably be called the "spare time" when the children aren't demanding 100% of your attention, e.g. blogs/Twitter/StackOverflow/mailing lists.
comments powered by Disqus