Introducing Developer Experience at Depot

Hello, world!

That is, hello to the world of lightning-fast builds! Believe me when I say that I’m sincerely stoked to be here, both at Depot as Head of Developer Experience, and in this particular cranny of the software development space.

The team and I thought it might be worthwhile to introduce myself to the Depot community, including just how I got here, why I'm passionate about Developer Experience, and what you can expect from the Developer Experience team at Depot.

So without further ado...

How Did I End Up Here?

Like many in the software world, my path to tech was rather circuitous. I spent the first part of my career teaching English as a Second and Foreign Language, first in South Korea to adorable elementary-age children, and later at Colorado State University. I love linguistics, I love teaching, and I love reading and conducting research, and thus, through my first couple years teaching at CSU, I thought I'd found a professional home as a university intructor.

Well, it turns out that university adjunct instructors don’t get paid a living wage, or benefit from any level of job security, or have much opportunity for professional growth. Probably, I should have figured these things out before I went down that career path, but hey: We follow our passions, right?

Heartbreaking as it was, I didn’t see a path to financial security staying in academia, and so I started to think about finding something more viable. Luckily for me, at that moment in time, the software industry was hungry for talent and willing to mentor entry-level programmers. Coding bootcamps had cropped up everywhere to meet this demand, and so in 2016, I spent six grueling months in a full-stack software development bootcamp learning how to code. By some miracle (okay...with a lot of dedication and hard work), I got spit out of there with enough skill to land a role as a junior developer. Over the subsequent six years, I went from writing code across the stack as an individual contributor, to managing an engineering team, to planning and facilitating technical upskilling initiatives for other software developers.

Then, in 2022, I met Dr. Cat Hicks and Dr. Carol Lee, two scientists doing human-centered research in the software engineering space. Dr. Hicks founded the Developer Success Lab at Pluralsight, and as I began informally collaborating with her and Dr. Lee to investigate the human aspects of software work, I learned that there was a place for empirical research outside of academia. This introduction to the empirical world of software engineering rekindled my passion for scholarly research, a passion that I’d thought I had to leave behind when I left academia.

In early 2024, Dr. Hicks brought me on to formally collaborate with the Developer Success Lab as a Principal Developer Experience Engineer. In this role, I worked closely with the lab’s research scientists as a software expert coauthor, collaborating from beginning-to-end on research projects. I also led the lab’s public-facing educational wing, creating educational and practical materials to accompany the lab’s original research launches.

I loved this work, as it reflected my deeply-held belief that most of what we do as software practitioners can (and even should) be informed by scientific inquiry. For various reasons, I made the hard decision to leave that role, but my passion for the Developer Experience space was very much ignited through my collaborations with the lab.

And so, you can imagine my excitement when Depot co-founders Kyle Galbraith and Jacob Gillespie reached out to discuss launching a Developer Experience function at Depot...

Okay, but hold up: What even is Developer Experience?

Developer Experience - DevEx for short - is a concept that was introduced by scientists Fabian Fagerholm and Jürgen Münch in 2012 with their article “Developer experience: Concept and definition.” There, they describe DevEx as reflecting “how developers think and feel about their activities within their working environments.” Since then, the concept has taken the industry by storm, and these days, we see both academic research and industry products (e.g., DX, Jellyfish, Flow) lending credence to the importance of paying attention to and investing in improvements in DevEx.

Why Do I Care About DevEx?

I’ve always been innately interested in how people think and feel about things. I've also typically approached life and work with a mind toward experimentation and incremental improvement. And I think that this is what DevEx is all about: Examining what software practitioners are thinking and feeling about their ability to deliver working software, and then using those insights to incremementally remove friction from their development environment.

You can likely think of a handful of factors that regularly affect your own DevEx. Maybe it's an incomplete test suite, or an overly-manual release process. Maybe it's a lack of autonomy, or unreasonable deadlines. If you're here, reading this, it might be build processes that take forever. The factors that can affect our DevEx are many, and when too many of them are bad, it’s like death by a thousand papercuts. The frictions and frustrations can pile up quickly and compound each other. Poor DevEx can cause folks to quit teams. Hell, really bad DevEx can cause folks to drop out of the profession entirely.

I don’t want people to drop out of this profession. Being a software developer has changed my life for the better in so many ways, and I want others to experience these same benefits. But the reality is that there’s a lot about the experience of developing software that is absolutely maddening. However, I deeply believe that people have the potential to improve a lot of them, including the experience of developing with particular tools and technologies.

Why Does Depot Care about DevEx?

In other words, what the heck am I doing here?

Well, personally I don't think we can argue against the fact that Depot is a DevEx tool. Or rather, a suite of DevEx tools. A burgeoning body of research points to sources of friction and frustration in the software development process as major obstacles to good DevEx, which does not surprise me one bit because I’m telling you: Few things have caused me more frustration than sitting around waiting for slow builds to finish. Especially when those builds fail halfway through, and I have to kick them off again and again during the troubleshooting process. This kind of friction increases cognitive load, decreases flow state, encourages context-switching, et cetera, et cetera. Fundamentally, it impedes my progress toward delivering value to stakeholders. To getting my shit done.

And so, that’s why I’m here. To help with the (great) work the team has already started in making sure this suite of tools improves the experience of developing software, and to help ensure your voices continue to get heard as we continue to develop these tools for you. Kyle, Jacob, and the rest of the team are 100% committed to building the product that you want, one that contributes to a great Developer Experience for you, and that commitment is one of the reasons I joined this company.

With that, please feel free to open a conversation with me around the experience of developing with Depot. I'll be in the Depot Community Discord channel if you want to reach out directly there. Or, you can reach out to me on LinkedIn. I'm excited to learn how you’re thinking about DevEx in general, as well as the experience of developing with Depot’s products!

I look forward to hearing from you!