My interview process with IBM, from start to finish, lasted three months. I initially interviewed for an engineering position on the Swift team at IBM, and I would have focused on Kitura. At first, the team said they were unable to find room for me, and to call back in 1 - 6 months.
After three more weeks, I got a call asking if I would be interested in joining the Strongloop team advocating for Loopback, which is a Node.js server-generation framework, but as an evangelist for Swift developers. I mean…sure? I hesitated before ultimately taking the role, and for two reasons.
- I’d played with Node, but not to the point that I was about to talk to developers about how awesome it was as though I’d been using it forever.
- What even is a Developer Evangelist?
I ultimately have to thank Sumitha Nathan for believing in me strongly enough to bring me across the Atlantic ocean to do this job. I got a crash course in what it meant to be in Developer Relations within my first two weeks at IBM. I started flying everywhere and felt like I was seemingly doing everything.
I gave talks. I ran labs. I filmed videos. I made demo apps. Where do you draw the line when it comes to being asked to do all of those things? Furthermore, when do you get time to “work on something real”? Working on “something real” has proved to be an important question, and I felt myself chasing that high of working on a “real project” more times than I’d like to admit.
Eventually, I shifted away from specifically Node.js advocacy to focus on working with clients, and I’m supremely grateful to Kelley Hilborn. However, I still managed to maintain a close relationship with the Kitura team. Regardless of the future of that team, I’m proud of what they brought me in to help with, and I’m forever grateful for the opportunity to help them succeed in their mission.
Further, I got to live the tenets of the developer relations field as much as anyone in our industry. However, I’ve decided to make a change recently, and I’m switching into a role where I’ll be responsible for leading a team of developers working on a product again. I’m excited to make that announcement, but that’s not the main reason why I’m writing this. When I first started, Ray Camden gave me the best advice I’d ever receive as a Developer Advocate:
“When you learn something, share it big and share it small.”
Joe Sepi gave me the idea of sharing what I’ve learned going into this field, spending three and a half years in it, and going back to a pure engineering role. I hope this is interesting and insightful to those of you reading this, whether you’re interested in pursuing a career in DevRel, or you want to know some of the fun things we get to deal with regularly.
If you want to see where I’m going, scroll down :) Otherwise, here’s a list of 10 tips and tricks that (in my own humble opinion) helped me experience some success during my time in DevRel with IBM, and could help you out too!
1. Focus on Projects and Examples, not Tweets
Delete the Twitter app from your phone! Please do it now. Once you accept that Twitter is a forum and not a means for instant gratification, you’ll feel way more comfortable logging on. Twitter is a fantastic way to share what you’re working on and to get nearly real-time feedback on whatever it is you share there.
If we’re talking SEO, the tweets that “perform better” are the tweets that link out to your open-source project. Another example could be a video you’re recording that demonstrates a new feature of the product you advocate for, or even a blog post detailing, perhaps, some tips and tricks about your career.
2. Pick an Airline, And A Hotel Chain
You’re going to be on an airplane a lot. You’re going to have to adjust to being in a hotel a lot. I’m a creature of habit, and while this isn’t the ideal role for adopting a routine lifestyle, little things here and there can make things like being on the other side of the world feel a little more familiar.
You’ll inevitably come to a crossroads where you choose a one-stop flight with your airline over a nonstop flight with another airline. It might seem easy at the time to go with the nonstop on another airline, but there are obvious benefits in racking up the miles. My honeymoon later this year is also a free first-class round trip on Delta Airlines, and a pretty-much free hotel suite courtesy of Hilton. I assure you that the flight time was worth it.
3. Get To Know The Developers On The Project You Care Most About
If you’re chasing the high of working on a “real project,” then you should sit and spend time with the developers that are doing so. In my case, the Kitura team were always hoping to find someone to be able to show others how their software works, and what real-life use cases it could fill.
Ian Partridge and Chris Bailey are talented enough to provide this material on their own. I was eager and delighted to advocate for them as developers of the project to legitimize the work they were doing with both the community and clients alike as well as explain their intentions. IBM always intends to make software that works for the enterprise, but that doesn’t mean Kitura wasn’t useful on a smaller scale. I loved getting to provide a platform for what they intended for the stack, and I hope it was helpful to them.
4. Get To Know The Developers That Use Projects That Compete With Your Favorite Project
In DevRel, you need to be able to be an advocate within your company on behalf of the developers using your product to give your company insight. You might want to tell the product team how users are responding to your software, explain what features they want but are lacking, and, most importantly, why users are choosing other products over yours.
I was fortunate to meet Tanner Nelson at Swift Cloud Workshop 4, and while I wish I had spent more time with him, I feel like spending the time I did get with him helped me understand what was going into Vapor. Ultimately, Ian, Chris, And Tanner all directly contributed to the Swift Server Working Group and helped form the mission of that ecosystem way deeper than I ever could. Still, I can tell you that spending time with Vapor developers helped me understand why they chose to use it, and this was important for the Kitura team to know while it was in active development.
5. Buy A Standing Desk
Unless your company exclusively pays for business class on flights everywhere, you’re going to be sitting down a lot. You’ll be sitting at your conference booth. You’ll be sitting at your desk, giving hands-on labs. You’ll be sitting waiting for flights to take off, land, or stop bumping. Get a standing desk that lets you keep your back in alignment and preserve your posture. Even if you don’t use it that much, having the freedom to do so does wonder for your sense of belonging, so that you can feel the power of choice.
6. Invest In Your Personal Health
Being able to travel as much as I did help me get over some of my fears about eating by trying new foods everywhere I went. The unfortunate byproduct of this is that you try a lot of new foods, and they aren’t always healthy. Waking up in a new hotel room in a new city, potentially in a new country, can feel exhausting. Working up the motivation to find time to get into the gym, go for a run, or even just a walk, can be equally exhausting.
I’ve found that forcing myself to build a habit takes 21 days - this is not new - but it yields the feeling of “I have to go break a sweat for my day to feel normal.” That feeling is irreplaceable, and it yields dividends as you work through your day and your workload, wherever you happen to be.
7. Start A Meetup Or Be A Regular At One
When I moved to Austin, there were a couple of meetups in the area, but none close to what I wanted to do. When I was in New York City in January of 2017, I was lucky enough to get invited to go to the Artsy Happy Hour, then to the Swift Peer Lab the next morning in their offices. The peer lab, run by Ash Furrow and Orta Therox, was great, fun, and low key. I wanted to bring something similar to the table.
I saw that Ash had started a website for installing similar peer labs in other cities. I started Weird Swift ATX as a result, and we’ve been running strong for more than three years now, every single Thursday from 6-10 pm. Thanks to IBM for picking up the tab every week! The meetup helped create a community of like-minded developers in my home city that I could lean on to help me solve problems, and for me to be able to help others as well. I also made some pretty great friends as a result.
8. Make A Wiki For Your Future Teammates
I have a decent memory, but everyone has a limit. I also know that a particular weakness of mine at my job at IDscan before IBM was my inability to reliably document things I was working on. I can safely say that I improved upon this weakness during my time at IBM, and I feel comfortable that anyone joining my old team in the future will know where to look when they have questions like:
- Where do I go to file expenses?
- How do I choose a hotel?
- What are the proper guidelines for posting about open source projects online?
There really is no such thing as a stupid question, and your company inevitably has the means to provide you a way to answer all of them pre-emptively. We were fortunate enough to have Github enterprise at IBM (because of course, we did), but other companies have Confluence, open-source Github wikis, or anything else. Being able to provide answers to these questions not only helps future coworkers of yours, but it also helps clear up the confusion that you may already have about certain procedures on your team, so this is incredibly worth it!
9. Try Side Projects That Scare You
I remember the first time I tried deploying a Kitura container onto a Kubernetes cluster. I called Jason Kennedy into the office with me and I very politely demanded that he just sit next to me as I stumble my way through the process. I wish I had been live-streaming the whole ordeal, as I probably looked like a psychopath clutching to my desk as I entered CLI commands. Even though I’ve run countless labs with clients now helping them do the same thing, I wish people could have seen the abject fear on my face as I went through it for the first time, just to help them understand that the fear of trying something new is genuine, and it’s nice to have a friend.
With that said, I often recall what my CEO, Ginny Rometty, relayed in an introduction video when I joined IBM:
“Growth and comfort are rarely in the same sentence…”
As a Developer Advocate, you will find yourself in a position speaking to someone who is interested in using what you advocate for, but unsure where to get started. Going through this initial fear yourself will better prepare you for that specific situation, and being able to relate to developers in that vein will speak wonders for your reputation in the community.
10. Accept That Projects Both Change And Disappear
Companies contribute to open source software because they want to see how much mileage developers get out of it - not because of some altruistic fantasy of making the world a better place or preparing the world for natural disasters or something. When you accept this cold, hard fact, it makes the tough pills that will inevitably appear on your desk a little easier to swallow.
Thank you to everyone in my career at IBM who helped me grow, and to those that supported me on my many missions! On February 18th, I’ll begin the next chapter of my journey as the iOS Technical Director for Charles Schwab in Austin, TX! Entering the world of iOS is an exciting mission to be on, and I’m eager to dive back into a space that is near and dear to my heart. I am excited to share more as I go, but thank you for reading this far, and I hope this information was helpful to you!