Right at Home in My New Role

(Get it? Because I’m working from home...)

Hi, I’m Shelby 👋 I’m a new Developer Advocate at Honeycomb.

The New Normal

What a strange time to be changing jobs.

I’m thrilled about my new role, my new team, having my dog Nova as a co-working buddy.

But it’s bittersweet. Things are pretty terrible right now.

I have it easier than most people, with relatively good health, a job I can work remotely, and no kids who are suddenly in need of homeschooling. But I feel for everyone out there who’s struggling, overworked, spread thin, or suddenly without income.

I want to help. My fellow Developer Advocate, Liz Fong-Jones, has already shared an offer to help through Honeycomb, specifically for teams “maintaining critical infrastructure to help people stay the fuck home.”

Liz is holding private office hours, you can schedule a meeting via Calendly.

While I’m still getting my bearings in this new role, I’m making a similar offer. Allow me to be your observability study buddy. Let’s pair on instrumenting your systems.

If you’re ready to start a Honeycomb trial but life is too hectic for you to even think, please reach out via email or Twitter. I will make time for you.

But Why?

A major theme in my career has been helping other people do their work better. I learned to channel my annoying know-it-all tendencies from childhood into an aptitude for explaining things (to people who’ve asked).

After working for years as a tutor and a brief stint as an English teacher, I went back to school to study computer science. Indeed, every one of my software roles has involved a significant amount of teaching and mentoring work. A few years after starting full-time software engineering work, I was introduced to the field of developer relations. It sounded perfect for me.

So now I’ve started this new role. I hadn’t even been seriously looking, but when I saw Emily Nakashima's tweet about Honeycomb hiring a new Developer Advocate, I pounced on the opportunity.

A User Story

On Christmas Eve 2018, a mentor recommended I follow Charity Majors on Twitter. That’s how I first learned about Honeycomb.

Charity authored countless threads on observability and system resilience, and I soaked them up. I was familiar with Google’s Site Reliability Engineering book, but (by my understanding) their practices couldn’t be applied whole-cloth to my small team. It couldn't hurt to hear insights from a variety of sources.

I was also intrigued about Honeycomb and wanted to try out the tool. Still, I found myself intimidated in the beginning. I felt like I didn’t know how to distinguish between Honeycomb and the monitoring tools my team was already using. This was less than a year into my first DevOps role, so I was just gaining a grasp on the core technology we maintained internally. Third party services were a whole new can of worms.

On top of that, the concept of observability felt like too big of a paradigm shift for me. It took me months of Twitter threads and numerous visits to Honeycomb’s website before I felt confident in my ability to explain it. Still, Charity’s advice and enthusiasm kept me hooked, and when Liz Fong-Jones joined Honeycomb as the first Developer Advocate, I started following her too. I wanted to grow up to be like these accomplished leaders and technologists.

Getting Started

Last summer I started printing out various Honeycomb white papers, including Liz and Charity’s collaborative effort developing an Observability Maturity Model. Having worked on numerous projects that I felt lacked operational maturity and engineering discipline, their advice struck a chord with me. I wanted to level up my own team.

I tried out Honeycomb’s Play demo and shared it with some of my colleagues. One platform engineer was especially thrilled: Honeycomb offered exactly the features he’d been dreaming of. We scraped together some mental bandwidth and I pulled the trigger on a trial.

As we started integrating with Honeycomb, I witnessed a transformation in my teammate. He’d been struggling with burnout for months, but adding Honeycomb instrumentation and interacting with real data was making him excited about his work again. No longer were we poking at a black box, making guesses about system behavior. The answers were right there.

The Socio-technical

Part of why I wanted to study computer science is because software is interwoven in every part of our lives.

I’m grateful for Charity’s recent blog post on socio-technical systems. The concept of a “socio-technical system” has been echoing around my head since I first learned heard about it from Amy Tobey:

that's why I'm in love with the term "socio-technical system"

— @renice@hachyderm.io (@MissAmyTobey) September 16, 2019

It struck a chord.

For years I’ve felt that tools and technology won’t solve the mushy people problems that are hurting my team and the organizations around me. Things like misaligned values, poor communication, or lack of psychological safety can’t be fixed with an app. I was disappointed by the tech industry’s narrow-minded focus on technical solutions that were inadequate for solving complex organizational and societal issues.

Put more simply: I don’t believe tech will solve all our people problems. Rather, people are solving our people problems. People like you are also solving our tech problems, and y’all will continue to do so.

Since I started programming I’ve argued that we should let computers do what computers are good at. That way, we could enable people to do what people are good at. Rather than hiding away the mushy people problems, effective tooling can facilitate human solutions.

I also believe that most people want to do good work. Burnout comes more from powerlessness than from long hours. Whether a person works at a large company, a small startup, a non-profit, or themself, work is a lot more enjoyable when it’s connected to an impact.

So What?

Your tooling matters because software correctness and system efficacy matter, for your developers, your customers, your end users. Better tooling improves engineer productivity, according to the 2019 Accelerate State of DevOps Report. Martin Fowler has argued that high quality software is cheaper to produce. We’ve learned in recent years that engineer productivity creates value that benefits the rest of your organization (link to PDF).

The point of a paradigm shift like observability isn’t just about making engineers happy, although I certainly care about that. It’s about the ripple effects.

Let’s never forget that software is written by people and for people. Software is a tool, a means to an end. That’s why Honeycomb can help. I’ve personally witnessed what a difference observability makes for developers, reducing feelings of burnout and helping them experience joy in their work. As engineers, owning our code in production is a feedback loop we crave. It allows us to map effort to impact.

Observability is a paradigm on which we can build a safe, healthy, sustainable future for the tech industry. A better tech industry is better for supporting this complex, interdependent society we live in.

Reach Out

I don’t think I’m going to save the world in a few Zoom calls with users. But I can use the resources at my disposal to make a difference in someone’s day, and that’s improvement in the right direction.

So let me be your advocate. Like I said before, I’m here to help. Send me an email, or reach out on Twitter.