Two years out of coding bootcamp and I had an incredible offer from one of the world’s most highly-regarded tech companies…and I declined it.

On paper, it was the dream job. Heck, it would have been the most “adult” job I’d ever had in my life so far. Stocks, bonuses, incredible benefits, prestige, and an incredible all-remote team.

It would absolutely sky-rocket my career. The name on my résumé would open doors, opportunities, and a path to further success. I would never have to worry about how to pay my bills again.

It took me six interviews and a take-home project to get this offer. So why did I decline it?

To turn down a role like this was no small decision, especially considering the financial implications. Personal anecdotes from others helped me to make my decision and I wanted to share my story and process, too.

How it all started

Who am I?

Hi, I’m Annie. I’m an Australian multi-disciplinary designer who graduated from a Canadian front-end development bootcamp in July 2019. I was also an English instructor in Japan, among a variety of other random jobs.

My first developer job out of bootcamp was at a small WordPress VIP agency, where I worked for a little over a year. I then moved to a B2B SaaS startup, Pastel, as their first hire in October 2020. (I’m currently the Front-end Engineering Lead here.) In July 2021, I got an offer from one of the world’s biggest and loved tech firms.

It’s been a wild journey.

That email

It’s May 2021. I’ve just received an email from the manager of a large tech company, asking if I was interested in a developer advocacy position on their growing team.

I instantly think they’ve made a mistake.

Clearly, they didn’t mean to email me. After the initial shock, I realise they’ve taken the time to fill out the form on my website. Slowly it dawned on me that yes, they did mean me.

At this point, I barely knew what developer advocacy was, but I was curious about it. They had found me through Twitter and the role sounded like it would involve a lot of the things I was already doing on the side. I mean, who wouldn’t want to get paid for the things they do in their free time, right?

However, I was really happy in my new job and was initially going to turn down the chance to interview. I shared the news with a good friend, an experienced senior engineer I trusted. Long story short, he yelled at me in all-caps and reminded me to, “Always be interviewing”.

And that’s how it started.

Deep-diving into Developer Advocacy

Over the next couple of months, I did my due diligence researching everything I could on developer advocacy/relations. I was keen to understand the role and what it would involve. I read many articles, including this very helpful Q&A with Angie Jones, a Senior Director of Developer Relations.

I was extremely fortunate to be able to reach out to current developer advocates through Twitter and my wider connections. I sought opinions from people with years of experience in the role. On calls and through messages, they shared growth ladders, salaries, experiences, expectations and the pros and cons of the position.

I scribbled notes on random pieces of paper and soaked it all in, trying to build an all-round picture of what my day to day might look like, both in the role itself and at the particular company in question.

The interview process

The first thing I did after talking to my friend was to schedule a casual call with the manager who had reached out. I got a good impression of what the team was trying to achieve and felt this was someone I could work well with.

I decided to proceed to the first formal step, which was speaking with the hiring manager. Here, I was given a high-level overview of the team and their current initiatives. It was a chance for me to ask more questions and get a feel for the people I’d be potentially working with. Afterwards, I had to sign an NDA before progressing any further, so I won’t be going into any detailed specifics.

The next stage was a take-home project. I was given two weeks to put together a presentation for the company’s Dev Rel team. I chose a couple of technologies and concepts, merged them together and added my own unique spin to teach and advocate for the platform.

I learned a lot for this presentation, as one of the platform’s technologies I chose was completely new to me. To understand it better, I had to deep dive into several other concepts. Not someone to do things in half measures, I poured hours into this outside my full-time job — researching, content creation and presentation practice — and it paid off.

The presentation itself went amazing and was well-received. Surprisingly, I felt confident and had a lot of fun with it! I don’t have much experience with public speaking, so this had been a concern of mine.

At this stage, I could choose to drop out of the rest of the interview process if I felt the role wouldn’t be a good fit. However, it was at this point where it hit me — I really could do this developer advocate thing!

I decided to go all-in, and my final four interviews were scheduled for the beginning of July.

The offer

It took just over two months from when the manager first reached out on May 11, 2021, to when I got the formal written offer on July 14th, 2021. Suddenly, the decision was brought into sharp focus, and I had two weeks to sign or decline.

How I made my decision

Trust that either choice is a win-win

It was quite stressful to be in a situation where the choice I made would have a huge impact on my life over the next few years. I lost sleep and my appetite was non-existent for a couple of weeks while I agonised over it.

However, at the end of the day, I realised there really wasn’t a bad choice. It all came down to which experiences I wanted to have.

When faced with tough choices, I always ask myself the question, “What would I regret less at the end of my life?” It might seem a bit extreme, but honestly, this question gives me big-picture clarity to decide what I want to do with the limited time I have on Earth. What meaningful experiences do I want to cultivate during this time?

If I chose to stay, I’d be able to dive deeper into software engineering, help grow and shape a small company, and learn about and get involved in business and product growth decisions.

For a while now, my professional goal has been to become exceptional at front-end development, while building knowledge in the back-end and dev ops to supplement this. I was very excited about Pastel’s company vision and direction, and I knew how I wanted to contribute to it.

In a startup, things move fast. With my CTO, we had long planned out my growth trajectory there — the kind of responsibilities I would have, the things I would do, and what that would look like.

If I chose to leave, I had the opportunity to be more visible in the community as someone from a non-traditional background, a person of colour and a woman. It would send a powerful message to others to know that this Big Tech company hires bootcamp grads and self-learners.

I would increase my breadth of skill as I learn about various tooling to share them with the wider community. Building my network and helping others get better at what they do would be part of my job. I would get better at presenting and be doing things similar to what I’d already been doing in my free time, but now with the support and formal backing of a large company behind me.

Know your values

Who do you want to be in a few years and what do you want to be doing? After the presentation, I knew I could do the developer advocacy role and do it well.

Years of design work, teaching/mentoring experience, and diverse overseas living would give me some particularly unique advantages here. Plus, as an extrovert, spending time with people is energizing for me and I love connecting with people and seeing them succeed.

Yet, when I thought deeply about my personal values, job stability, status, and a desire for prestige isn’t among them. These were some of the top benefits the new company offered. I crave novelty, I’m not risk-averse, and at heart, I’ve always been a creator. I want to build cool sh*t with cool people and have fun along the way.

In a startup — especially one pretty early on — the things you do from one year to the next change. There is novelty here. It’s easy to be swayed by big numbers but money itself has never been a singularly motivating factor for me throughout my life. I view it as a side effect of creating value.

That’s not to say I don’t negotiate salaries or seek to improve my financial situation — I just see it as one factor in a larger holistic list of considerations.

Coming back to my core values helped me make my decision.

Content creation and creative work aren’t new to me — I’ve had practice as a designer working on multiple projects. On the other hand, engineering is out of my comfort zone and doesn’t come naturally. In life, choosing the harder things are often the most rewarding for your growth.

I also figured the offer wasn’t enough to offset the loss of my engineering career capital. By switching into developer advocacy now, I would lose whatever momentum I was gaining by being in the trenches and repeatedly doing development work. At this stage, I wanted to focus on building depth of skill, as opposed to more breadth.

I also thought about impact and legacy. In a big company, you make a smaller impact on a greater number of people. In a small company, you make a greater impact on a smaller number of people. Neither one is better than the other — just different. The viable level of impact I’m able to have in a startup felt pretty meaningful to me.

For me, it ultimately came down to being a practitioner who occasionally teaches, versus a teacher who occasionally practices.

Side note: Shortly after I turned down the role, Kelly Vaughn tweeted this and it strongly resonated, making me feel like I’d made the right decision.

Don’t let social clout cloud your decision-making

Having an online audience brings opportunities, but there’s a cost to being in the public eye.

The developer advocate role is a fairly visible one, potentially requiring me to be more active on social media. I had not sought to “grow my Twitter following” when I first became more active on the platform and had concerns it might become difficult for me to untangle my sense of worth and value from the vanity metrics of social media.

Not only that, I’m aware of the distractive impact of social media on deep work — something I value in my quest to get good at my craft.

At one point, when I seriously thought I was going to take the role, I had already imagined what sharing the news on Twitter would be like. Someone I knew had started a job at the company around this time and their profile had absolutely blown up as a result.

More than anything, something that played in my mind over and over again was sharing proof that big tech companies do hire bootcamp graduates and self-learners like myself. It felt like such an incredibly powerful message to get out into the world. It could change someone’s life.

But at the end of the day, I had to do what felt right for me.

The grass isn’t always greener on the other side

In conversation with a senior developer who worked at another big tech company, I realised what I had was rare and valuable.

At our startup, we barely had any company politics. With a lean team of only five people, Pastel currently has a very flat company hierarchy.

In a bigger company, many are vying for the kind of responsibility I currently have and struggling to be noticed by higher-ups. In another company, big decisions are made, signed off and passed down to be executed.

Here, I’m an integral part of all roadmap plannings and product direction meetings. I have full freedom to handle and execute on the UI, UX, and improve accessibility on the app. My voice and opinions are trusted and valued.

Second, to find a mentor who’s deeply invested in your professional growth as an engineer, actively providing you with autonomy and responsibility, alongside a product you personally resonate with, isn’t something you find every day.

My CTO, as my professional mentor, has been coding since he was eight. He breezed through his computer science classes and turned down interviews with Google, Facebook, and others to work on his own thing.

True, in a few years, I could easily join another startup if I decided to move away from developer advocacy… but right now, I’m working on a product that lies at the intersection of design and development, much like my experiences as a designer/developer. Pastel speaks to me. It’s a product I can get behind and it personally solves a pain point I’ve experienced myself.

Do your homework

As mentioned earlier, while trying to make up my mind, I reached out and spoke to a lot of people. Being in the middle of this seemingly momentous career decision, I knew there would be blind spots and biases I wasn’t aware of. I wanted to make sure I had as much information as possible to make an informed decision that was right for me.

I spoke to numerous developer advocates to ask about their work and day-to-day. I spoke to people who worked at the company who made the offer. I spoke to people who had been in similar situations and asked how they came to their various decisions. I researched the new role heavily and, by the end, I knew a lot about a path that had not previously been on my radar.

A notable point came out from one particular conversation with a very senior engineer, who had been a developer advocate for a while. While in that role, he would give talks at conferences and there would be people doubting his experience because he didn’t have “engineer” in his current title.

To give context, he’s a white male who was fairly senior at that point. It gave me pause as to what people would think of me — female and without years of technical experience or a Computer Science degree.

Developer Advocacy is still a fairly new role in tech, and one of its hiccups is unfortunately people sometimes think advocates aren’t as technically able as full-time developers or engineers.

This is not correct. Those who do this work need to have technical ability, plus a range of other skillsets beyond that. Over time, I’m hopeful this mindset will gradually change.

Risk mitigation

As with everything in life, whether you do one thing or another, there’s some form of risk. These were factors I considered that reduced my risk of staying at a startup.

Counter Offer

Before you think crazy numbers, it must be stated that location plays a factor and I live in Canada, not America. There’s universal health care here and salaries are lower than the American numbers you often see flaunted all over the internet.

American tech companies have location-based salaries. To be transparent, while my offer was six figures in Canadian dollars, when converted to American, it would be five. Such is life.

If I was only making ~$55k CAD a year (the median salary of graduates from my bootcamp), leaving would have been a no-brainer. As it was, Pastel made a compelling counter-offer (which I negotiated) and this decreased the compensation gap between the two options. Hey, I’m all for building financial security in your life.

Many startups rely on investor funding without a market-proven product. Pastel is bootstrapped, runs on a subscription model, was profitable before I started, and is growing. This decreased the financial risk of the company going bankrupt and me losing my job.

Additionally, while my title is still that of a developer, I negotiated the ability to dedicate 30% of my time doing developer advocacy work, should I choose to. I felt this was an interesting and calculated way to dip my toes into this world, beyond my side projects.

Long Term Game

If this was a straight choice between doing engineering at Company A vs Company B, the decision might have been easier. However, this wasn’t a simple corporate vs startup decision. It was also a decision of the type of career path I wanted: Software Development vs Developer Advocacy.

You can absolutely build an incredible career through advocacy work. I know this through my research and those I see in the field.

But this is also true for Engineering. Given that, when I compared the two career paths, truthfully I felt more excited about building depth in development than I did about organising and giving talks on it.

In his book, “So Good They Can’t Ignore You: Why Skills Trump Passion in the Quest for Work You Love”, Cal Newport shared an interesting idea: Control is one of the most powerful traits you can acquire when creating work you love. In order to keep that, sometimes you might have to say no to a raise.

What is the end goal here? To find work you love? Or to get a company name on your résumé?

I also mentioned this briefly before, but it’s worth restating: Beyond engineering, I want to learn about building and managing a business. At a startup, I’m on the ground shaping company culture, advocating for better product decisions, and possibly doing future hiring. I have greater say on how the company can make an impact in the world.

The learnings I’m acquiring in this process are no small thing and are worth a lot to me. I’ll be able to take these skills, lessons, and knowledge into my next role.

Professional Network

It’s not a myth that people often get jobs through their network. Be it through a friend’s friend, a referral or something else, many a job has been secured via a connection. Had I felt less confident about this aspect of my life, the company name on my résumé would hold much greater sway over my decision.

As it is, over the past two years, I’ve slowly cultivated authentic industry connections I trust and value. Not for the purpose of getting work, but simply because I’m curious about who they are and the myriad of interesting things they’re doing in the world.

And yes, some of these good people work at FAANG and other big tech companies that shape much of our world.

When the time is right and if I’m no longer professionally challenged in my role, I’ll think about my next move. Who knows, maybe full developer advocacy will be on the books.

Listen to everyone’s advice… and ignore most of it

At the end of the day, your journey is your own. Oftentimes, you have a more nuanced picture of your particular situation than others.

Do your due diligence but follow your gut and decide how your life plays out. Your values, needs, and desires are different from others'. Own your journey, and don’t let others tell you what you should do.

About 90% of people I spoke to advised me to take the position— it wasn’t easy to go against the grain and do the opposite.

Yet, only you can decide who you want to be.

_Photo by [Unsplash](https://unsplash.com/@socialcut?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener">S O C I A L . C U T on <a href="https://unsplash.com/s/photos/inspirational-words?utm_source=unsplash&utm_medium=referral&utmcontent=creditCopyText" rel="noopener)

Final thoughts

Ultimately, this was an incredible opportunity. But it just wasn’t my opportunity. At least not right now. A no now doesn’t mean a no forever. Through this whole process of trying to figure out whether to stay or go, when I finally made my decision, it felt right for me. It was a very intentional decision.

I very clearly understood what I was giving up by declining the offer. In many ways, it gave me a stronger sense of purpose, confidence, and energy with the current path I’d chosen.

Do I feel sad about turning it down? Of course! It’s hard not to. The people I met throughout the process were all extremely kind and welcoming. I could imagine how much fun it would be to work with them. I’m grateful to have had this experience and the learnings I took away from it.

It’s not easy, but I’m excited about getting better at engineering. At Pastel, things are still tough right now, but the deep work I’d be doing over the next year or so to consolidate the skills I’m struggling with, are going to compound.

In a year or more, I’ll have greater breadth and depth of knowledge to build, grow and shape a company and product. This is incredibly energizing for me.

Watch this space.

I want to personally say the biggest thank you to everyone who was there throughout this journey with me. Thank you for your support, for taking the time to listen, weigh-in and consider options with me. I am beyond grateful you made time for me. You know who you are and I deeply appreciate you.

Between the three of them, the co-founders of Orbit have decades of experience in engineering and developer relations, building products at companies such as Accenture, Algolia, Apple and Keen.io. After launching Orbit, they spent the last year talking with people in the DevRel space about proving the value of DevRel.

January is a common time for executives to ask what kind of investments they should make in developer relations including what hires to make, and what the business case is.

After Orbit joined Heavybit last month, I sat down with Josh, Patrick, and Dustin to talk about their approach to DevRel, from partnerships and promotions to outsourcing and metrics.

Table of Contents

• What are the biggest missteps companies make when it comes to DevRel?
• What parts of DevRel should companies outsource?
• How do you leverage partnerships?
• How can DevRel partner with business development?
• How do you balance creation vs promotion?
• Who in DevRel would you like to call out?

Q: What are the biggest missteps companies make when it comes to DevRel?

One big mistake is trying to hire a developer advocate before the company has learned to do at least a little DevRel on their own. In the consulting world, companies would come to us and say "we’re ready to hire, we just need help writing a job description and sourcing candidates." At that point, sometimes these companies had not given a talk or created developer-facing content.

By contrast, at some companies, every engineer is doing some aspect of DevRel from the time the company starts, like giving talks and contributing to projects. If a company tries to hire a DevRel-specific role but doesn’t have experience in that area, it’s going to be difficult for them to be successful.

Companies and teams have to define their internal expectations for DevRel. It’s common to read a job description for DevRel that isn't focused -- it could span dozens of key activities! If a company has done DevRel themselves, they typically surface a more focused job description. For example, do they see this role on the road giving talks, or being an internal advocate? We want to help companies avoid writing job descriptions that are “be all the things.”

Q: What parts of DevRel should companies keep in-house, versus outsourcing?

It depends on which parts of the DevRel process you need help with.

On one hand, your DevRel person who has the touch points with the community -- that person should live and breathe inside your organization and embodies the organization's culture. If a company has contracted with an outside firm, you may not get the same experience talking to them, versus talking with employees embedded in the culture of the company.

If your advocate echoes your values, it leads to a better developer experience. That’s a risk when making a contract hire, especially on the community side. I’ve seen contractors do social media for a company’s developer community and it all goes wrong — it’s mind blowing why companies do this with little training and oversight.

However, if you’re working solely on content, tutorials, etc, that can be a great place for outside help, since there will be other people in the organization that are reviewing the content to make sure it falls in line with the company's positioning and values.

We consulted for the past year so we have some bias here, but using outside companies to generate strategic, third-party content can give you a lot of leverage. They can lean on your internal teams to amplify the content and bring the messages to market. We’ve done this a number of times with different companies -- it makes developer advocates inside the company feel like superheroes because they have a lot of great content that they can bring out and share with the community.

Q: How can we in developer relations leverage internal partnerships to increase our reach and effectiveness?

We think partnerships can be one of the most impactful parts of a successful DevRel strategy. A single advocate or DevRel team serves as a force multiplier across the entire company. The internal impacts of a team that’s working well are enormous when multiplied across the entire company.

We can give tons of examples, but to focus on a few: in marketing, DevRel can help keep the brand voice true to the developer personality. In return, marketing helps DevRel be more data driven, driving value in both directions.

In larger companies, there is an opportunity to bring the voice of the developer into internal conversations. You can imagine bringing stories from the field into the walls of the building and giving the company a few into how developers interact with your product.

Historically there has been somewhat of a mismatch between teams like sales and marketing and community teams like DevRel. Often this is based on a mismatch in funnels.

DevRel can evangelize alternate models of measuring impact of community instead of the standard model of pushing people into a funnel and measuring purchasing events. The Orbit model allows you to rewire the way companies think about community, not just a standard marketing funnel, but allowing you to create metrics around your community efforts.

We also see DevRel and Sales working well together — historically, this isn’t always the case! We've seen that they can be very collaborative and complementary when there is clear communication.

In large organizations it's rad to see individual developers participating in the community -- if a company's developers are contributing to your project, that’s a strong signal that the company may be interested in a commercial relationship.

From a sales perspective, you probably don't want an SDR emailing those developers, but the SDR would love to have feedback about that developer’s activity that they could reference when calling the developer’s manager. Of course, that requires data and tooling on the back-end to surface that information, and that’s something we see a lot of companies moving towards in 2020.

We actually wrote a whole series for Heavybit covering different tactics for internal collaboration.

Q: How about business development -- where are the opportunities for developer relations teams to partner there?

Agency partnerships come to mind pretty quickly. For companies with a developer-focused platform, part of the BizDev model is to partner with agencies who can build the platform into products for clients. Algolia had relationships with agencies implementing all the different ecommerce and CMS platforms.

Creating formal partnerships with these companies can be useful for BizDev but can also help your DevRel program by encouraging the agency developers to be involved in the technology ecosystem.

DevRel can also partner with complementary companies and projects. This can keep things fresh and make sure you’re not talking too much about yourself and your products -- you're bringing some fresh voices into the conversation.

Q: Where do you draw the line on creating new assets, such as content and talks, and promoting those assets? Should 100% of your DevRel budget go to creation, 100% to publicity, or somewhere in between?

Looking at DevRel as a whole, generally we think that more re-use would be smart. Writing a new presentation each time you give a talk is very expensive in terms of effort and mental energy.

Many developer advocates are hesitant to re-use material, but they shouldn’t be -- there are millions of developers out there who haven’t seen your presentation before. If stand-up comedians can re-use the same jokes for years, you shouldn’t have to worry about giving the same talk twice in the same city.

One trick I have: give talks to engineers inside the company, and then let the engineers give that talk elsewhere. Make your assets and presentations so that others can re-use the deck and script. That’s a nice way to get engagement in the DevRel effort from others in the organization — three months later, someone is speaking on stage, maybe for the first time.

Often there are engineers inside your company who want to get started getting talks, and as developer advocates who do this multiple times per week, we can facilitate these engineers and also cover more territory. (There are a lot of events I want to speak at, but I can’t be in two places at the same time.)

Q: Is there anybody out there in DevRel who is doing an amazing job, that you’d like to highlight?

• Doron Sherman, VP DevRel at Cloudinary has a great DevRel program
• Stefan Judis at Twilio for being data-driven, he’s got a great approach and dashboard for his content that is pretty impressive
• Tim Berglund and Ale Murray, Confluent team

Thanks to Josh Dzielak, Patrick Woods, and Dustin Larimer for chatting with me about their DevRel experience.

Next Steps:

• Follow Orbit on Twitter
• Check out (literally, you can check it out) the Orbit Model GitHub repo
• Catch up with Orbit's DevRel Blog.

IBM’s $34B acquisition of Red Hat closed last week, underscoring the huge and growing importance of hybrid cloud infrastructure. My colleague Marek Sadowski has become a subject matter expert in containers, Kubernetes and server-side Swift, although he started out as a full stack developer advocate, a robotics startup founder and an entrepreneur.

Marek has 20 years of enterprise consulting experience throughout the USA, Europe, Japan, Middle East and Africa, and he pioneered in research on VR goggles for the virtual reality system to control robots on Mars during his time at NASA. After founding a robotics startup, Marek came to work at IBM. I talked to him about his experience in DevOps advocacy.

Table of Contents

• How DevOps advocacy different from API/app advocacy?
• How do you focus on the DevRel community?
• What have you changed when moving to DevOps DevRel?
• How do you get developers to see Swift as server-side?
• How did you get into DevRel?

Q: One of your focus areas in DevRel is containers. How is advocating for a DevOps technology different than advocating for an API or application?

Good question. When working with containers, engineers think more in terms of the plumbing and ideas of DevOps and the ease of expanding your infrastructure footprint. In contrast, when you talk about APIs, you try to make application development the center of gravity for the discussion.

When discussing APIs with developers, you talk about how one could -- in a robust way -- consume the API. Let’s take the IBM Watson API as an example: our team will talk about how you can create and run SDKs for developers to consume APIs in their own language, for example, Swift (for mobile) or Java (for enterprise.) You’d look at the consumer of your API and discuss how you can produce the API, protect yourself and do the billing.

Getting back to containers: when discussing container technology, you speak more about plumbing of the cloud. How do you manage containers? Expand them? Manage their workloads? Deliver and test new versions?

It quickly becomes apparent that these are two separate concepts. Containerization deals with how your backend is working and proper maintenance of your application, which attracts people from a DevOps background. When you talk about APIs, that’s a completely different story. Your thought paradigm changes to the point of view of the consumer: How does the consumer find the API? How can developers consume the API?

I speak at conferences on both subjects areas. I’ve found that people who develop applications are more interested in the look and feel and developer experience of the application, whereas with containers it’s more about backend, load balancing, and seeing issues from a system administrator’s perspective.

Q: Many people are familiar with DevRel with a focus on software engineers, but DevOps is a different community entirely. How do you focus on that community?

There is a division — everybody is interested in new things like Kubernetes and Docker, but not too many will want to perfect their skills to the point that it’s their daily job. So many developers want to know how to spin up a container and a service inside the container, put it in their resume and be done with it. Developers may be interested because it’s fashionable or it’s a buzzword. However, you can find a lot of people who are running services in containers and have specific questions: sysadmins who want to monitor containers and assure security, load balancing, and other aspects of administration. It’s a completely different audience from developers who consume APIs and create a cool web application. They are two different communities, and you have to give each community different content.

For example, in a hackathon it’s very difficult to create large deployments in containers. It’s an optimization of development and operations more than application coding.

Q: How have you had to change your approach to DevRel when moving to DevOps advocacy?

Previously when I ran workshops focused on application developers, they’ll usually have a few goals: understand our API, consume data from API endpoints and create a simple “Hello World” types of applications. Developers in these workshops will ask questions about high-level ways of architecting applications, e.g. with Watson, in mobile applications or web applications, or a chain of processes.

On the contrary, when I speak about DevOps and containers, developers in the audience want to spin up the services, see how they scale up and scale down, investigate how the services behaving when something is failing and how to ameliorate security issues. It’s a completely different approach. They are not interested in building something new, they want to perfect their approach to deployment.

An analogy I can give to people new to this field: it’s like inviting a painter and a plumber to a party. They both do similar things, yet the painter wants to make a painting that you can hang on the wall, and the plumber will rarely speak about the type of piping he’s using inside your walls. Both are doing something in your house, but the painter is thinking about the people they will attract and the paint (our APIs) to ensure a pleasant viewing experience, while the plumber just wants to get the job done and never touch it again. The plumbers want to make changes as rarely as possible and focus on stability, the painter wants to create more new paintings. They have different approaches based on their different goals.

Q: You also give talks on Swift, specifically on the server side. Most people know Swift from the iOS development side, but why is it useful on the server? How do you get developers to think of it as a server language?

Server-side Swift is a relatively new development. I compare the current state of server-side Swift to where Java was twenty-four years ago. In 1996 I started writing a server-side application using Java -- it was a novel concept at that time! The same thing is happening now with Swift, as developers are moving the Swift language to the server. There are a lot of reasons why; one of the simplest is that you write in the same language on the server as you do for your mobile app, and in that way you can use the same data constructs, thought processes and personnel resources on both systems. You don’t need different systems or frameworks to talk to the database or the cloud.

Every mobile app nowadays asks you to connect to the internet for AI, messaging and social media. Even simple games allow you to exchange information or have a conversation with people all over the world. If your app and back-end are written in one language like Swift, it makes these data exchanges simple and transparent.

Some people are saying Swift is a fashionable language to learn. Since you have the option to write apps in Java or JavaScript, you can also write them in Swift. Swift has now been open-sourced by Apple, similar to the way Sun opened up Java. You can now write applications in the cloud or on any platform. For example, OpenWhisk allows you to write event-based Swift functions in the cloud without any DevOps code.

With Swift, developers are attracted to the beauty of the language and the ability to write one language from mobile to cloud to make your application better and easier to maintain. You can enjoy writing in your language of choice and expand the capabilities of the environment you love. If you are an iOS developer, maybe you can become a full-stack developer, and developers love the story that they can become something more and participate in the full stack development process.

Q: How did you get into developer relations?

I had just come to the United States from Poland as the founder of a startup, and the purpose of the move was to expand my company. They say that 99% of startups don’t succeed right away, and founders often need to bootstrap while in an existing job. I was told that working in the cloud is the key factor in a lot of industries, but I had little exposure to those technologies. On the other hand, I had built up skills talking to investors, and as an entrepreneur, I was able to understand what was important to startups. I also had a robust background in Java development and different IT technologies — I had a career as an architect supporting banks and other enterprises EMEA as a Java professional, demonstrating systems to customers.

There was an opening for a mobile-first developer advocate, and despite having no mobile or cloud experience, I convinced the interviewer that I was the perfect candidate due to my ease of speaking with developers and presenting technical subjects in an accessible manner. I enjoy explaining complex topics in a simple way through demos and example projects.

My hiring manager asked me to build a small mobile app as an employment test, which connected to IBM Cloud to exchange information between the user and a backend. I enjoyed the task and found I was good at it! After two years, I migrated to more cloud technologies and more and more IBM APIs. Eventually I started to find interest in Kubernetes and containers, and I realized containers are a field with amazing growth potential.

I must say, the thing that attracted me the most to DevRel was the opportunity to learn and convey new technologies to developers out there, and use my talent for explaining complex things in a straightforward manner.

Next Steps:

• Follow Marek on Twitter
• See Marek speak at an upcoming IBM Developer SF Meetup

I started my career as a software developer. However, since the summer of 2017, I have been a developer advocate.

In this story, I want to tell you how I moved to this position, why I chose this path, and what I do to improve in this field.

How I became a developer advocate

Have you ever felt that doing the job you used to enjoy doesn’t make you feel satisfied any more? I bet many of you have. They say that for a software developer it’s okay to change jobs every 2 - 3 years.

I had been working at JetBrains as a YouTrack (browser-based bug tracker) software developer for 4 to 5 years when I realized that I wasn’t happy at work. I was tired of programming, though I thought before that it was what I wanted to do for a living.

Fortunately, I understood that my problem was just a lack of satisfaction. I didn’t feel satisfied or that I was entirely using my potential when doing numerous tasks and fixing endless bugs day after day. I didn’t see my impact on the team’s results.

At that point, I started switching to other activities, related to YouTrack. I helped to write docs and to process feedback. We decided to organize a public webinar devoted to the updated YouTrack workflow API. I took a very active part in it and even started a small community in Slack while preparing examples.

Believe me, I felt happy and content those days and was way more productive than a couple of months before. So I’m very grateful to my manager, who allowed me to quit product development and to continue these community-related activities.

Why I am a developer advocate

It took me some time to find a proper job title. The range of my activities was wide and fell into different “usual” jobs:

• Helping our customers to make the most of our product by answering their questions - support engineer, I guess;

• Helping other JetBrains teams to use YouTrack - internal support engineer or something like that;

• Updating documentation - technical writer;

• Writing blog posts about using YouTrack workflow API - technical writer again;

• Managing the product community - community manager, probably.

I don’t remember how I found this “developer advocate” job title, but I liked it immediately, though the term is still a little bit unclear today. One may think that developer advocates do the same as technical evangelists but without religious associations. For me, these two jobs are different.

Technical evangelists work on turning everyone to their belief in the product; in other words, they engage new users in the product.

Developer advocates work with those who are already involved with the product. They help external developers use the programmable abilities of the product and advocate their needs before the team.

I’m not good at convincing people. However, I’m good at helping them.

What helps me be a better developer advocate

Over the last 1.5 years, I formulated the list of essential developer advocate skills. If you already are a developer advocate or are thinking about becoming one, you need to have them.

Knowledge of applications APIs

You can’t do without them, as they’re your bread and butter. You need to know how to use them for sure.

Even though most people outside your team are capable of reading the documentation, what you need is the following:

• Know how to solve particular problems with these APIs;

• Understand the API limits;

• Be aware of tricky parts within these APIs and how to deal with them.

What I do:

• Use those APIs myself: I have written tons of YouTrack workflows, a couple of dashboard widgets and several scripts, using the REST API.

• Help our users to solve their API-related issues in support.

Programming

As you are a developer advocate, you need to speak one language with developers. Or, as it is in my case, many languages. Java, Kotlin, JavaScript, PHP, Ruby, Python, C# - these are some of the languages our customers use to access the YouTrack REST API.

What I do:

• Regularly implement YouTrack extensions.

• Try out various languages and frameworks in pet projects.

• Recently I committed to the “100 Days of Code” challenge, which motivates me to program a little bit every day.

Writing

I consider writing blog posts and tutorials to be the most reliable and convenient way to help the community. Some may prefer video content.

However, making good videos requires a lot of time and effort, plus it is very costly to update them as soon as your software interface changes.

Written content is faster to create and cheaper to maintain, meaning that you provide more information in a given amount of time.

What I do:

• Have a blog (the one you are reading now). Apart from being the right place for practicing writing skills, it also helps me to build a personal brand.

• Write at least one sentence every day. It may sound too little, but most of the times I write much more, and the first sentence every day is just a catalyst.

• Use Grammarly to improve the quality of my English texts.

Public speaking

This subject is something I do not have much to say about at the moment. Developer advocates often participate in conferences and other events, and public speaking skills are essential for them.

As for me, right now I have a 6-month-old baby, work part-time from home and won’t be able to attend any events for another half a year at the very least. As soon as I start making talks, I will write another story about it.

In conclusion, I believe that three components make great developer advocates:

• Brain - to be able to help use their software in the most unexpected, ways;

• Heart - to take customer issues as their own; and

• Courage - to advocate their needs before the team.

If you have them, then I wish you a great walk on your yellow brick road to developer advocacy!