6 Lessons from 6 Professional DevRels

My main takeaways.

For the past two years, I’ve been teaching myself to program and pushing full-stack Web3 builds onto my GitHub. I even built some blockchain data indexing projects with Rust and Substreams powered Subgraphs.

Programming is always a pleasure,

but the real reason I began programming in Web3 was to build a hard skill that would pair with my philosophy degree.

I love philosophy, but being a philosopher as a career is a bit much for me.

But now that I have hard skills and a background in technical writing in
philosophy, I am ready to move to the next step. This step is a career that blends philosophy’s subjective nature with code’s objective nature.

Something like… Developer Relations!

I applied for this free exclusive course that, to my surprise, featured guest speakers who were people I had been watching for a long time on YouTube.

In this article, I’m honored to share the main things I’ve learned from each speaker in each class.

Lesson 1: Getting Situated (30–60–90 Plan)

When hired, you’ll want a plan for attacking your task of
being a DevRel. The best thing to do in the first 30 days is to study the company you work for.

What is the culture, how does the product work, and who uses it?

What kinds of people are shareholders, is the documentation up to date, and what is the voice and tone of marketing?

Studying these will help you fit in and align with the company’s mission.

From the 30-day mark to the 60-day mark, you’re done treading the shallows and ready to dive deep.

Go through your company’s and competitor’s code examples. Which is better? Shouldn’t be your competitors after you’re done with changing a few things.

For 90 days and out, you are situated. You know your team, the culture, the
documentation, the product, and everything that goes into representing a company.

Lesson 2: Bootstrapping DevRel? Sounds like a trip

Bootstrapping sounds super exciting. Imagine getting hired by a company that has no DevRels.

This means you get to do everything and set the standard for the future. Steph Orpilla gave a fantastic presentation about how she bootstrapped DevRel at Nillion.

She talked about the importance of not putting the wagon before the horse.

This expression symbolizes that nice things should not be prioritized above the required things. In DevRel terms, it means you must put on your developer hat and write documentation, code examples, and open communication channels with users.

Nothing matters if these bases aren’t covered.

Lesson 3: Why Developers Hate Docs

My main takeaway from Patrick Collin’s presentation is an article he wrote: “Why developers don’t like docs”.

I understood from the read that documentation doesn’t inspire people to do anything cool.

It makes me want to leave my computer and do something else.

Documentation should be something people refer to in the event they need something specific. It should NOT be the sole source of information about the technology.

I’ve worked with very niche tools like this, and it sucks.

Not the tools, just the developer experience.

So what should you do if people hate docs? Give them an alternative… a challenge! A guide that forces them to think and explore what your company has to offer.

A good challenge should drive their curiosity and let them uncover features, all while being guided through a project.

Imagine if video games, instead of having a tutorial section at the start of the game, had an instruction booklet for what buttons to press.

Yeah, hopefully, that stays in our imagination.

Lesson 4: Give People Money

Now, I’m super biased about this lesson. However, the strongest thing that kept me learning and building in Web3 was a stream of ETH from the BuildGuild founded by Austin Griffith, who was also the speaker for this lesson.

I knew that if I could program well enough to make contributions to Scaffold-ETH, I had my foot in the door as a certified Web3 engineer. After a year, I was part of the BuildGuild, making contributions, prototyping dApps, and improving the developer experience.

I asked Austin during the lesson how he got Scaffold-ETH (check it out if you don’t know about it, I’ll shill it till I die) to reach so many people.

He said, “Give people money”. If people build with your technology in good faith and are rewarded with money, many people will be building with your technology.

It’s actually within the BuildGuild that I discovered my passion for developer relations.

Lesson 5: Bridge Builder

I was traveling and unable to attend this class by Nader Dabit, but I read a blog post related to this class.

In the blog was an old poem I memorized in college: Bridge Builder. Of course, as a college student who was here to party, this poem was corny, long, and annoying. But now that I don’t have to memorize it,

I can fully appreciate the poem’s pacing, rhyming, and message.

Bridge Builder is about an old man who crosses a big chasm with little effort. The chasm never bothered him because he was experienced. He begins to build a bridge across the chasm, and a young man approaches and asks him why he’s wasting what little time he has left on this earth building where he’ll never walk again. The old man explains that this chasm was easy to cross for him but not for fair-haired youths. So he’s building a bridge for them.

Beautifully put, elegant, and wholesome, Bridge Builder is about getting people to where you’re at with less pain.

Lesson 6: Treating your Docs as your Product

The final lesson I learned was from Michiel Mulders.

Your docs are also your product because they are an extension of your product.

With docs (including tutorials, examples, and how-to guides), your product is more useful than what people can figure out what to do with it. At that point, people will choose another product they can use more easily and efficiently.

Wrapping up

DevRel Uni has been a great experience, and I’m honored to have been part of it. I learned a lot, gained clarity on where I want to take my career, and I’m ready to start taking action.

So far, I’m helping make documentation for Edge and Node, Streamingfast, and Scaffold-ETH.

I worked closely with a friend to make a substreams powered subgraph challenge, and I’m testing and adding features to a collaborative project between Edge and Node and Scaffold-ETH. Thanks for reading!