A year in reflection
Journeying from developer to DevRel
A year ago I was working on an Android app for a grocery store. Now I am part of the Android Developer Relations team focusing on Android TV.
I have a lot to learn about Developer Relations (DevRel) but these are the highlights of my journey from my first year of adventure.
After a year at Google, I learned a lot about the industry, the world, and developers. I used to be a developer working on some project for some company trying to figure out how to manipulate a library or technology to solve our needs. Upon joining Google my role reversed. In this new role I need to understand other developer’s needs and make sure the technology solves them easily.
Difference between software engineering and DevRel
A software engineer writes code to solve problems from the company for their product. The main objective is to make the business happy and make the bottom line increase while keeping the users of their product happy. Often developers never meet the users of the system but feel a sense of pride and connection with the programs built.
In DevRel, there is no business handing us tasks. Our goal is to stay in touch with our users and work directly with them. Our users are software engineers just like us. The main difference is that other software engineers are working on real world problems and we try to make technology the least of their worries by providing samples, codelabs, documentation, etc.
What do I do in DevRel?
I started at Google as a Developer Programs Engineer (DPE). My main responsibility was to create and publish samples as new features and APIs were being released. For example, I wrote a code lab about Android TV’s new home screen for Google I/O last year.
In addition, DPEs need to scalably be involved in the community. This means contributing to social media or answering questions on forums such as StackOverflow. By seeing what questions developers have about Android, we can either update https://developer.android.com, build a new support library, or discuss with the engineers of the framework how to make the public API better for developers. The more connected we are with the outside world, the more we can champion for developers internally at Google.
My first project was to build a sample, and I was excited at the possibilities. Being at a tech company and there are no restrictions, right? It was easy to create a running app thanks to the tools of the community, such as Butterknife. I was ready for my first of many code reviews and had no idea what to expect. The app’s first review did not pay attention to the code but instead questioned the use of the third party libraries to demonstrate a first party API.
A sample should highlight an API and not confuse the reader with extra complexity and implicit knowledge of third party libraries. When introducing extra complexity, it becomes harder to understand exactly how to use an API and see the big picture usage of the API. There is an art to being able to build a functioning sample that demonstrates the capabilities of an API while not cluttering the sample with boilerplate code.
The app went through another revision where the libraries were removed. It seemed counterintuitive to remove the EventBus library and build that complexity manually into the app. However, the sample abstracted the boilerplate of an event bus in order to highlight the intended API.
Our job is to make Google’s products better and become adopted. If the community created a widely used library, then the community is free to let it mature.
Switching from developer, I struggled not being able to use third party libraries.
Learning Android TV
I have developed many Android applications before but never for Android TV. It was always a product or an example of an innovative way to use Android. I had to become an expert on Android TV and be a leader in the community.
This was a great opportunity to understand the “getting started” story with Android TV and identify any gaps and improve them. I found out that my personal “getting started” experience did not matter. I built small precise samples, not real world apps, thus my experience might not have represented what others experience. The experiences of real-world developers drive impact, and I was no longer one of them.
Without an app to build or problem to solve, it can be difficult to learn a technology thoroughly. Fortunately, I was able to learn from fellow developers. Whenever someone asked a question in the community, I spent a few hours trying to recreate their issue and find a solution. The engineers on the Android TV team helped me with a lot of the questions. Along the way, I gained more knowledge, but just as Albert Einstein once proclaimed,
“The more I learn, the more I realize how much I do not know.”
Albert Einstein omitted that it is okay to not know everything.
Rewards of the job
One of the greatest feelings I receive from DevRel is being able to help developers and be the bridge between them and engineers.
For example, a developer filed an issue in the leanback sample. They took the time to look at the source code and discover a possible solution. The issue was with the leanback library and not with the sample. The developer filed a bug to track the issue properly. I updated the bug with steps to reproduce removing a lot of back-and-forth that can happen. Then I worked directly with the engineer to diagnose and found a solution. It was a very rewarding experience helping the developer.
Developers see blog posts, samples, YouTube clips, etc, that come from DevRel but there is a lot more involved to make sure that those are the most impactful for developers. Sometimes we accidently overlook a few details and do not realize until it is too late. However, we have the ability to quickly figure out the details and elaborate more.
For example, I learned about an API, how to use it, drafted an article and had it reviewed, and I had many conversations about the API to understand it. I understood the API pretty well, but it was not until a developer asked an insightful question that a pain point become evident in the API. I researched the framework and several first party apps to better understand the issue and how Google apps work around it. Understanding the underpinnings of the framework helped avoid the issue. I published a follow-up article explaining my findings and reached out to the developer. Once he understood why there was an issue in the framework, he was able to correct it in his app.
For DevRel to be most effective, if developers see something, they need to say something so we can work together to make the developer experience better.
Looking forward to the future
It has been a bumpy ride switching from engineering for the business to engineering for engineers. Sometimes I miss working on a production app, but then I reflect on the opportunities and excitement that comes with DevRel and I know this is the right position for me.
Before, I would build a feature that would affect a few hundred people, but I never used the product which made it hard to personally connect and feel like I was making an impact. Now I positively affect a framework / library, enabling millions of developers to build innovative products. This is a lot more gratifying for me.
I am looking forward to working with more developers, hearing what they have to say and making their lives better. I feel successful now that I turn feedback from five to ten apps into making the next fifty apps better.