At my first professional job, I’ll never forget walking through the warehouse after having seen our site’s Google Analytics numbers.
Suddenly it became tangible that many human life hours were being spent in a world I’d built.
When I came back to my desk and did the math, it came out to over 5 years of human consciousness inhabiting and discovering the site I’d built each and every day.
And this was only my first professional job!
As software developers, it’s so easy to forget the kind of impact we have on the world.
Humanity now spends so much time within the software worlds we build, that entire industries have begun inventing and sharing myths about how to best behave within them.
When should I post to social media? Where should I park my Uber to get the best riders? And how do I end up at the top search of results?
As much as we developers want to be building better, more humane software worlds, the outcomes of our efforts often seem beyond our control.
Bad organizational practices, technical debt, and a constantly shifting set of technical requirements all make the job of delivering quality software worlds difficult and less clear.
And given the scale of a software developer’s impact, there are clearly not nearly enough people dedicated to thinking about how developers can work more effectively, and where we, as an industry, are heading.
Humanity Increasingly Lives in Our Software
The experience of using software used to be actively hostile.
But over the past decade, the software industry has moved closer to thinking about the end user’s experience when using software as a key part of a software’s functionality.
In my role as a developer advocate, it’s my job to spend time thinking, talking, and asking about the implications of the software we’re collectively building, and how we can do it better.
In practice, that means I spend a portion of my time interviewing developers as they talk about the things they build, and the challenges and constraints they run into on the ground.
Consistently, the great developers and engineers I meet care.
No matter the problem space or industry they inhabit, they care about the product they’re building, and the end user’s experience.
By helping engineers extract the story of what they’ve accomplished, along with the challenges they’ve faced, I’m able to gain context for what matters in the process of building. And along the way, I get context about what we can build to make things better for them.
The Explosion of Developer Effectiveness and Developer Tools
Luckily for the developers who care, there is an entire industry working to make them more effective.
Better still, there is a sustainable set of incentives to grow the impact of developer tools:
By making your developer customers more effective, they in turn become more valuable in the marketplace, in turn making your product sticky enough they can’t work at the new, higher level without it.
And that focus on discovering how to make developers more effective, is the role of a developer advocate.
We work to make our developer’s experience better, more impactful, and to give them an edge on the rest of the people in their industry.
In turn, they give us a chance to continue proving we’ve earned their attention and trust.
Principles for Facilitating Engineering Excellence
But stepping into the role of being a public representative for a vendor means having to deal with a wide variety of strong personalities. Worse still, the range of technical detail you deal with on a daily basis can cross tens of subdomains. Being precise and empathetic and useful in a technical conversation can be challenging for even the most experienced developers.
Fortunately, there are a few tools which can help you navigate these worlds, the two most important being: Humility and Having Done your Homework.
As a group, engineers tend to respect people who try things first, admit they may be wrong, and ask questions after an initial effort. But beyond that, what are some principles for getting technical people to open up and share their stories?
Assume Excellence in Others
When I first moved to New York City from a small Florida town, I was blown away by the average competence level of a given person, at their job, regardless of what it was.
It seemed everyone had to be great at their job to make it in such a challenging, expensive environment. That pressure to work and excel meant everyone was holding themselves to a higher standard, and that they cared about the impact of the things they did. Being around so many great people made me want to raise my own professional standards for myself.
In the same way, I assume everyone I meet in the software engineering space is excellent and cares.
For each person, I assume they’re one of the top people at something in the world, and it’s my job to discover what that is in our conversation.
In assuming excellence, it helps to be genuinely curious, and to want to explore a problem space with them.
Seek to Understand their Problem Space
In any conversation, it helps to try to build a model of the other person’s world as you talk. What are the things that matter most to them, and what are their constraints?
On a surface level, all software development is the same. We all work with data structures and algorithms, legacy code and open source libraries. And yet, once we pass the surface level, we can have wildly different ideas about what the actual job of software development is.
Being curious about people and their world is how you discover these other ideas for the job.
It’s how you start to perceive meta patterns that are consistent across software sub-disciplines, and can be a great lever for judging new circumstances and technologies, or predicting interactions among people.
Is their role focused around risk minimization? (Security) Is it focused around growth at all costs? (VC funded startup) Growth with a specific cost constraint? (Sustainable growth company)
Does performance not matter at all, or is the primary business competitive edge? Discovering the contexts where things matter builds your engineering vocabulary, and helps relate stories across disciplines.
Respect their Time
If the pandemic has taught me anything, it is how valuable and limited our time is.
Being respectful of your audience’s time means having done preparation before you speak.
Amazon is famous for having executive meetings require a written document of six pages, and meetings begin with every person having to read it.
Being forced to write down your message for an audience means clarifying your thoughts, and also considering the other person’s time. In writing things down, clarify our ideas for the benefit of other people. We distill our time and thinking down into readily absorbable ideas for others.
Before you speak, consider the size and weight of your message. Is it interesting to your audience? Do they have the time for it? What is the main point, from which they can begin exploring on their own?
Discover the Details
As developers, we spend hours debugging, just to find out a file didn’t have the proper permissions, or that a REST endpoint expected a different date time format than what was in the documentation.
The details are our jobs, and the details are what can make us either productive, or lost in a sea of frustration and mounting deadlines.
Discover the details for your audience, and share them.
If you can, make sure they don’t have to have the same battles as you. Make the documentation better. Bring the feedback to the product team. Make the process better for the next person behind you.
Sustainable Advocacy
So given all of these lofty goals, how do you balance the personal ideals of improving software as a field, with the need to build internal, perceived corporate value?
The onset of the COVID-19 pandemic solidified what is, to me, a sustainable relationship for developer advocates.
Developer advocates exist to increase the effectiveness of our customers, partners, and their engineers.
Some days, this will take the form of building example applications, and discovering where friction exists in the product. Other days, it means highlighting the work of internal developers.
Advocates help everyone tell their story of how great engineering can be a lever for positive change in the world.
By attending one of our workshops, conferences, or talks, we hope you become more valuable to your employer, and in turn, more valuable to the market for developers.
This value delivered to you builds the perceived value of our brand, and increases the level of trust required for getting good, honest feedback from some of the best engineers in the world.
Advocating for a Product Internally
A significant portion of an advocate’s time is spent using the product, attempting to model the experience from both a beginner and experienced user’s perspective.
In using the product and building out example applications, advocates inevitably run into issues, sources of friction, and shortcomings of the product.
Part of the advocate’s job is reflecting on how and where to best raise these issues internally.
Depending on the level of established trust with the team responsible for the product, the approach to feedback might be as simple as reaching out to either an engineer or product manager. If there isn’t an established relationship, it can help to take a look at Github, and find the person contributing most often to the repository.
From there, research can begin by looking into the team’s road-map, OKRs, and then looking to see if the problem exists within the repo. All of this helps reduce the amount of context switching for the person we choose to engage with.
And again, when delivering feedback it’s helpful to remember the principles outlined above for facilitating engineering excellence. Before bringing feedback to the team, assume they’re competent, respect their time, and discover the details.
Choosing to Improve Developer Culture
A question we’ve all grappled with over the past year is, “What is my level of responsibility for the state of things?”
Much of our world, and especially our online worlds, can feel largely out of our control and disempowering. Given the state of software as a whole, and it’s importance, how much is required of us to make things better than we found it?
If you’re heads down with development, and don’t have time to share your story in building software, I encourage you to build some space for reflection on the metagame of what you’re doing.
There are so few people sharing their stories of building, and tradeoffs made openly, that any chance for reflection is a net positive for our collective body of work.
But, if the problem set of things I’ve discussed sounds interesting to you, and you’d like to spend your time actively working to make software culture better, I encourage you to seek out a role in developer advocacy.
My team is looking for people to move the industry forward across a wide variety of subdomains. If you care about the quality of software we’re collectively shipping, I encourage you to submit an application. If you’re hesitant, feel free to shoot me an email directly, or to reach out via Twitter.
Right now we need developer advocates with experience in things like CI/CD, security, distributed tracing, and a whole lot more. If you want to steer the conversation of where software is going, and how it’s getting better, I’d like to hear from you.
Thanks to @arapulido and @ajunaky for providing feedback on an earlier iteration of this post.
