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.
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
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:
- 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
From JetBrains point of view, if you’re out at conferences giving popular talks, that makes
the company look good.
- 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.
- 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.)
- Webinars. I’m not a fan of giving webinars, it’s like doing a conference presentation, only
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…?”)
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
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
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:
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.
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.
Theoretically I also answer questions via
Twitter/StackOverflow/other social media about
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.
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
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
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
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
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
- 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
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
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
- 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.
- 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
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.
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
- Have a technical blog
- Have a profile on StackOverflow which demonstrates the ability to provide valuable answers to
- 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)
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
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.
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
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
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.