Tag: opinion

Developer Relations isn't new, but it's also broad, ill-defined, and constantly evolving. It's difficult to keep your own skills up to date, never mind coping with a whole team full of people and constantly creeping industry scope. The required combination of specialist and generalist skills to be successful is any of the Developer Relations and allied roles is extensive, and it's easy to feel overwhelmed and end up coasting being just-good-enough at things but never feeling mastery.

As an individual contributor, manager and general DevRel presence over the years, I've developed some tactics both for myself and my team, and I'd like to share them in case they're useful to others. Also since I'm moving to a less DevRel role, writing this down while I can still think about it!

I work in Developer Relations, or "DevRel", and 2020 was a strange year with travel restrictions that meant that the entire industry did everything online, or digitally. I see this as a very positive progression of the way we work as DevRel professionals, and I understand that might be controversial, but I'd like to back up my position so hear me out (and then let me know what you think!).

I've been thinking lately about my own interactions online, especially around content. There are three main ways that I work with content: creating, curating and consuming. Each has their own place but I'll start by outlining each one.

Creating content is all about putting your own creations out for others to share. I've had this blog longer than I care to discuss and certainly since before microblogging was really a thing. It's much lower investment to throw out a quick tweet about something and in lots of cases it's a more appropriate medium

Examine the diff and comment on it, a line at a time

I've shipped a handful of greenfield APIs in recent months for different clients, and in each case I've been building the documentation before the API. I hadn't really recognised it as a pattern until someone else commented on it, but I do find this approach has worked well for my projects, so I thought I'd share my thoughts on this in a bit more detail.

Recently I was giving some advice (that I was asked for, which is novel) regarding one-to-one meetings between developers and either team leads or management can be structured. My thoughts really boiled down to some very short points (this is why sometimes, those meetings take 15 minutes and other times they take 3 times that for a monthly update!). In case they're useful to anyone else, here's my meeting outline:

• What's going well/what are you excited about?

• What's tedious/annoying or actually a problem?

• What could I be doing that I'm not?

It's Ada Lovelace day, a day when we celebrate women in technology. This year I'd like to mention a group of people who make the biggest difference in the tech life of any minority: the allies.

It's Ada Lovelace Day. If you don't know what that is, you can read more about it here: http://findingada.com/. Go ahead, I'll wait.

While being a woman in tech can be isolating, the women I meet along this journey make the experience what it is. I have fabulous male friends and mentors also, but today I'm focussing on the women around me. They are the modern-day equivalent of the cousins that you grow up with, share stories with, laugh and cry with. They have shared the personal and the professional, the joy and the fear. Today seems like a good time to call out some of the women that I'm so glad to have around me.

It's that time of year again, time for an "Ideas of March" post (you can read more about this initiative on Chris Shiflett's blog). Most years many bloggers pledge to write more often, start or restart their blogs, and generally embrace the idea that some thoughts are worth more than 140 characters. Chris himself wrote this year about the demise of google reader, and about blogging as a way of curating and retaining ownership of your ideas, which I thought was an excellent point to make.

One of the biggest dangers in this industry is getting left behind as the tools evolve very quickly. For me, working alone or as the most senior person on a project in most cases, this becomes doubly hard as there's nobody in my office to show me a new trick or share an idea that he or she learned in a previous job. So how do I deal with this?

I take "study days".

I get a lot of emails asking me to get involved with API projects, and that means I see a lot of both implemented and planned "RESTful" APIs. Now, I absolutely love REST and for a data-driven application, it would be my first choice. A service of some other description may work better for other scenarios or skill sets, and non-RESTful services can be very, very useful. If you tell me that your service is RESTful, then I expect it to be. If you're not sure, look out for these clues:

Becoming a master developer is like becoming a master craftsman; you just can't rush the process. You learn the basics, apply those skills, and over time master them and adapt them to be your own. As time goes on, you take on bigger and more complicated tasks, and apply appropriate skills to those, and so on. Our journey as developers is really much the same and yet sometimes I feel that we don't help those at the very start of the journey as much as we could.

I have an android smartphone, and I have *very* few paid for applications on it. Mostly I have document viewers, the wordpress app, mail/calendar/map from google, and so on - plus a couple of free games. In January I downloaded a new game and I've been playing it pretty regularly since*.