Ep. #1, Introducing Steve and David

Steve Boak: I think for a long time developer experience design was synonymous with API design. Now we've entered a world where it means a lot more.

David Dollar: DX is part of your product. You have to think about pricing and value and all of these things before you open the gates completely. Having a good design aesthetic that's seen as a good thing in most developer circles now, as opposed to being like, maybe you don't know what you're talking about if you have a sense of style.

Steve: Product designers have used it as an excuse. We're making tools for developers, they want more tools available to them. So we're just gonna throw this stuff up on a screen and let them figure it out.

I think that's the wrong approach. Developers are users.

David: I'm a developer and just because I can write code doesn't mean I necessarily want to.

Steve: Hi, I'm Steve.

David: And I'm David, and you're listening to Don't Make Me Code. The bi-weekly series where we discuss developer experience and some of the unique challenges we face building developer-facing products.

Steve: Don't Make Me Code is brought to you by Heavybit, a nine-month program for developer-facing startups. For more information, visit heavybit.com.

David: If you're interested in being a guest on the show, or if you have a specific topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code. In this first episode, we talk about the origins of the term DX and the unique challenges we face as designers of developer-facing tools.

Introductions

Hi, I'm David Dollar. I'm CEO, co-founder of Convox, a Heavybit company. I've been working in developer experience for about, I guess, three, four years now. Founded the DX team at Heroku, worked on a whole bunch of open source tools, including Foreman, and now working on an open source platform as a service.

Steve: I'm Steve Boak, the co-founder and head of product at Opsee. We are a monitoring company and I've been working at several monitoring companies over the past six years, helping developers improve the experience of their products as well as find bugs in their code and improve the quality of their products.

And though I didn't hear the term DX for the first time until a few months ago, it's been a passion of mine for several years and it's nice to finally attach a name to it. And I'm excited about this first episode because we get to unpack the term a little bit and figure out what it means.

How DX Got Its Name at Heroku

I thought one of the most interesting parts of your background, David, was that you were part of this founding team at Heroku that sort of created DX. And I'm interested to hear more about that.

David: Yeah, so I guess this was maybe late 2012, early 2013, right as at Heroku we started to expand out of being just a Ruby host into being a host for really any language. That meant we also started to see more people. Our standard user before that had been sort of like an OS X user building Rails and there was sort of one happy path for that. As we expanded languages, we had Windows users and Linux users and sort of everybody coming together to try and build really anything, and that started to get out of hand really fast.

So really we formed the DX team, brought together basically the people that were in charge of the various languages at Heroku. Somebody in charge of the Ruby and somebody in charge of Python and Node, brought us all together into one team and really decided to try and make a consistent experience, sort of the Heroku way across all of these languages.

Steve: And was it called the developer experience team from the beginning?

David: It was, yeah. So I guess the first time I heard the term was from Adam Wiggins, who sort of came to me and said, like, hey, I think we should build this DX team, what do you think? And yeah, it sort of exactly described what it is we were trying to do, which was make this nice experience for people building things on Heroku.

Steve: And when was that? What year was that?

David: I think it was the end of 2012, but it's kinda fuzzy at this point. But yeah, it was a while ago.

Steve: And it does seem to continue to be an important thing for Heroku. I just, in researching the term a bit, saw that there's a Heroku.com/DX. I mean this is a big part of how they market themselves and clearly it's been important to Heroku for a long time.

Like I said, it's interesting to now talk about this with a name because a lot of us are doing this and have been doing it for a while, but giving it a name gives it so much more weight and it kind of marks how important it is for all of us.

What Makes Developer Experience Different

David: Yeah, I mean it's interesting, like, you think of DX, and what does that actually even mean? And there's a certain type of user that you're talking about now, right? When you're talking about designing an experience for this user that likes to kind of get under the hood and break things apart and do things their own way and sort of knows what's going on and maybe you could even consider a power user.

You want to make sure that they can sort of do whatever it is they're trying to do, but that the options aren't overwhelming and that it's not complete, utter chaos.

Steve: Yeah, and it's almost like this partnership that we as the makers of tools that developers then use to build tools for their customers, if they don't like the product that they're using, that may show in the product that they're ultimately trying to build. And so it's this partnership where we all try to write good code and create great products together.

And I think that's part of what makes this different from user experience design as a whole and why it's interesting as a topic all into itself.

David: Yeah, I definitely agree with that. Sort of the most rewarding thing about working, I guess, in developer experience that I found is when people do things that you never expected them to do.

You put all the pieces in place. You thought like, oh, maybe somebody will use these pieces to build X, and it turns out that somebody comes and builds something you never even thought of. And I think it's really rewarding to see that.

Steve: And it's interesting that I think a lot of product builders in general would probably share that sentiment in terms of the unexpected ways that people find to use their products and the hacks that they create. And I've heard even with consumer products, people being surprised by how the users are actually using the product in ways they never expected.

But with developers, that really is to another level because they may try to break your APIs. I mean they're much better at exploring the depths of your code and then creating tools that you never expected with it, which is both surprising and wonderful for us.

David: It's still largely about aesthetics, right? Like a good user experience, a good developer experience.

At the end of the day, is this thing easy to use? Is it pleasant to use? Am I able to figure out what's going on? Does it make me happy to use the thing at the end of the day?

So yeah, it takes a different set of things for when somebody's trying to come in and actually build something on top of your product.

Steve: Yeah, I remember in the early days of the Google Maps API, just how many experiments and apps were being written with that. I think partly because of how easy and accessible they made it for developers.

And I heard a talk from someone on that team talking about that the product that we all knew and loved then was not the first iteration of it and they actually had a much harder to use initial version. Do you know more about the history of that?

David: I don't really know.

Steve: Yeah, but that was one of my first exposures to using another company's API and it was a really rewarding experience. And they had all this boilerplate code that you could very easily lay down to plot pins on a map and see that.

And especially for me as a designer, it was so rewarding to get that gratifying output, the actual map on the screen with the pins that I had laid out.

And I think that is a really great way to measure how effective and how elegant your developer experience design is in how quickly a developer can make something themselves.

David: One of the barometers I use for the things that I'm building is you look for the blog posts people are writing around your tools, right? And are they writing the blog post of like, this thing was so insane I couldn't figure out how to use it? Like, here's my giant blog post teaching you actually how to use it because I had to figure all this out, or are they just sort of talking about how easy it made their lives and like, look at how awesome this is, you should try it too.

Choices, Defaults, and Sharp Tools

Steve: Yeah, and that makes me think of the JavaScript world today and just how many frameworks are being launched and the competing arguments for this or that. And in some ways, this has really gotten good for the development community as a whole because there are so many choices now and so many good frameworks to choose from.

Almost too many actually. And I think we're starting to see some of that in the JavaScript world, just competing ideas of how things should be done. And that almost raises a counterargument to the value of developer experience design, that when we open up too many possibilities and don't create a set of tools, I think you described it in your Heavybit talk as, I like to compose sharp tools.

David: So I mean it's sort of like the Unix philosophy, right? Like you want to make tiny tools that do one thing really well. You generally want to have some good examples or defaults like, all right, this is how to use these tools in combinations to make interesting things, but having those tools be sort of separate and composable is where you start to get really interesting things happening that you didn't expect.

Steve: Yeah, that each piece does its thing really well. But also that when combined they can form something greater and that the whole is greater than the sum of the parts.

David: Right. A good example of that, I mean it's not really developer experience, but like IFTTT. There's sort of like an infinite variation of all these little components that you can put together, but they also have some default pipelines that come out of the box. You say like, okay, I really just wanna make my email go to Google Drive or something. Just these nice defaults.

It's really important, I think, when you have all of these choices to really also have the guides through them.

Steve: Yeah. We use the Amazon APIs a lot now, and they're an ecosystem all into themselves. For every product that Amazon offers inside of AWS, there's a unique API, and many of those APIs seem to have differing views of the world and so in some sense they're prolific in the amount of tooling they create for developers and they clearly have won a huge share of the market with just how much they offer, but it still feels to me like they're a counterexample.

They seem to have APIs that a lot of us use, but not APIs and tools that a lot of developers enjoy using.

David: Even despite that, pretty much everybody is still using those things, right?

Steve: So I mean there's something to that. Facebook's API or Twitter's API, I can't speak to how good or bad those are, but man, a lot of people use them.

And there's something to that too, that the product as a whole has so much value and impact on the world that you are sort of forced into a place where you need to use it. And it doesn't absolve you from the responsibility to make your tools great for your developers and your partners in this, but it's sort of mind-blowing to see how much can be done when you are hitting on a big share of the market.

David: Yeah, the AWS API is another great example of that. There's so many options, so many ways to do things, it's great. You could really do anything, right? Like the sky is the limit.

But finding the happy path through it can oftentimes be, I mean it's just a lot of trial and error at the beginning and you end up just having to build up some expertise around that stuff and eventually you can, okay, now I understand how to design things using these tiny primitives. But yeah, there's not a really great, like, I just have some code and I want to put it on the internet.

Steve: Yeah, and part of Convox's business is really helping developers do this, right? That there are in fact so many possibilities to create an infrastructure in AWS that giving a little guidance is probably a good way of helping developers through that process.

David: Right. Yeah. It's basically just trying to create a happy path. We think there's a lot of choices that you don't necessarily have to make.

Steve: Yeah, we too at Opsee use AWS heavily. It's a monitoring product designed just for Amazon web hosting.

And when we were creating this product, we were assuming we would see a pretty high level of consistency in how our customers had configured their environments, but that was shot down almost immediately. There have been no two environments that are the same, and so now we're dealing with a wide variety of customer environments and it's an example of just how much people can do with these tools, but how differently they're choosing to do them.

Pricing on the Value to Developers

And that though does get to this other interesting question of how we measure the quality of a developer experience and how we know that we're doing well. And we talked already a bit about time to value and how quickly developers can make tools with our products. But then I think it's also interesting to talk about how that becomes part of how we price these tools.

Like we try to look at how much development time we can save our customers and then try to price the product based on that. Do you try to do something similar?

David: Yeah, so that's actually, we're trying to think about this as a pure developer tool. So rather than, a lot of people try and charge for resources, things like that, we're doing more of like charging per developer that's using the thing. So yeah, actually creating value for developers, I think, is sort of the core of what we're trying to do. So we're approaching it from that angle.

Steve: Yeah, and monitoring being a little bit different, we're mostly trying to measure how much code our developers don't have to write when they're using this tool and what they would have to do in a competing world.

But I think the one thing that all Heavybit companies, certainly, and all developer tools companies share is that at its core, we're trying to measure our value that way.

How much code can we save developers from writing? And how much time can we save them?

And that feels in many ways different from normal user experience design and consumer user experience design, that we have to look at the value that we're creating for our users in order to assess our own value.

Stripe and the Case for Good Design

So as designers of developer experience products, I think it's interesting to talk about the inspirations and the other companies that are doing this well. The first time I had ever really thought about developer experience as something to be measured was looking at Stripe and how you said earlier how blog posts and recognition within the community can mean a lot.

And I remember hearing lots of developers talk about the quality of Stripe's documentation to the point that it became synonymous with a great developer product. Like, do you have Stripe-level docs? And so they were always a barometer for, are we doing well and who do we measure ourselves against?

And I feel like they've done a great job not just in creating great documentation and great APIs, but in great products. I mean, even their web design. I mean, they've taken all aspects of their design to a level that I think was not common in our world when they were doing it.

David: Definitely, I mean, we use Stripe, but I just remember that when I was first clicking through their web admin console, I was just like, wow, this is really nice. Like you just have that thought to yourself while you're using it. So it's very pleasant to use.

Steve: And I don't know, in the early days of Heroku, I don't know if you saw much of this, but certainly five, six years ago if we designed a UI that was polished and really nice looking, there was almost a bit of hesitation among our developer customers that we didn't have the street cred, like, no, you can't be real because no one in our world would do this, would make a product like that.

And I think that's changed a lot over the last few years, but we were almost fighting this uphill battle to try to create an elegant and beautiful user experience because people didn't expect that.

David: And I certainly think that sentiment has changed though. I mean I think having a good sort of design aesthetic in a sense of that is actually seen as a good thing in most developer circles now, as opposed to being like maybe you don't know what you're talking about if you have a sense of style or something.

It seems to be important. Yeah, people really look for it when they're looking for tools or products. And it's also something that we tend to see celebrated now, I think.

Tools That Spawn Ecosystems

Steve: Yeah, it's also interesting that when a developer tool is successful, you start to see lots of other tools build on its ecosystem. AWS is an obvious example of that. I think Twilio is another one that I think probably because of how great their experience was, you saw this proliferation of VoIP apps come out after that and customer service was improved and lots of other tools could now benefit from this and improve their products because of what Twilio had done for them.

And I don't know if you have some other examples of tools like that that had sort of launched or spawned the whole ecosystem.

David: Yeah, I mean it's sort of like, it was totally a great example of this. This is sort of like, you hear the term software is eating the world, sort of this is what it looks like, right? It's like somebody builds something really great and easy to use and that makes it so other people can differentiate even more on top of that without having to repeat all of that other stuff.

As soon as Twilio started to come out, you saw all kinds of crazy things with like, my phone would call me and tell me what the weather is or something like that.

Steve: Yeah, and even Facebook and Twitter as these powerful social media products, they have developer tools that they've made available. And we have of course seen this huge proliferation of tools trying to benefit from the social network.

Twitter makes a really interesting topic of conversation there because they in their early days had a very open API and a lot of tools got built on top of that. A lot of competing third-party apps.

And I don't know if it was because Twitter felt that they were competing with those apps for usage or that they felt that they needed to control the user experience because they were a growing company that I think still struggles with their identity. But then they have this transition where they kind of cut the developer community off and I think they still haven't recovered from the bad blood that they created as a result of that.

David: Yeah, Twitter was interesting because they basically had an API very early on when really the only thing they had of value in the entire thing was sort of the information and networks on the thing, right? So you make an API straight to that stuff, and now if you're assuming that at some point you're gonna figure out how to build value on top of that stuff, now you've also enabled everybody else to beat you to the punch, right?

So I think it's important. I mean you have to think about DX is part of your product and you have to think about pricing and value and sort of all of these things before you just open the gates completely. Twitter, it's probably ads, right? They want to control the experience so they can put feature content and ads in the right place. And if you can't build that thing on top without completely cutting off your API, it's tough.

Steve: Yeah, and that's an interesting one too, that as the makers of tools that the developers will use, we have to know how we're opening those doors, that we ourselves need to be a healthy company in order to support the developer community that builds tools on top of us.

And so if we're not careful and we, I don't want to say expose too much, but if we don't think about what our core business is and make sure that that's understood, then we do create a potentially dangerous situation where we're competing with our own developers. That is worrisome.

David: Yeah, I mean so you see that really with any platform too. You especially see that with AWS. It's like how much stuff gets built on top of AWS that then the next year AWS decides to climb the stack a little bit and now they're competing with their own developers. So it goes both ways for sure.

Steve: Yeah, we've seen Amazon launch tools that compete with other products inside their ecosystem. Even, I think it's Keen. Like Amazon just launched something that seemed like a competitor to Keen and then Amazon is huge at this point and they giveth, they taketh away, that they've created an ecosystem and empowered developers to build great tools on top, but then they've also allowed for the possibility that they can just come and compete with them and put them out of the ecosystem entirely and shut them down.

And there seems to be a sort of unwritten code of ethics that to play nice in the technology community you're maybe supposed to acquire companies like that or partner with them. But it feels like there are some companies in this world that have gotten a pretty solid reputation for playing nice in the ecosystem and partnering with companies that are developing great tools on top and others that have developed the opposite reputation, that they're hostile and they take from their developers.

David: This has sort of been an issue for a long time, right? Like even if you're building an application on Windows in 1999, there's a chance that Microsoft is gonna decide that your application is something that should just be built into the operating system. And no, there's not much room for you. I mean, we all build on top of other things and it's just sort of something we have to take into account.

And it's something that developers or products should go into with both eyes open. What is their reputation of this company? Is it likely that they're just gonna like come and do the same thing I'm doing?

Steve: Yeah, our companies both live in a world where we could be shut down by Amazon at any point if they wanted to, and so we're at risk as makers of companies of being shut down. I think there was this set of companies using Twitter's Firehose API. They wanted access to all of the data for analytics, for whatever their reasons were, and they got shut down and all those companies kind of went out of business because they no longer had access to the data that they were expecting.

And that's another consideration I think that we as makers of DevTools have to consider, is like, what are we putting out there that we might not be able to take back or that we're gonna suffer a lot if we do try to take back.

David: Yeah, I mean there's the risk with very nearly anything. I mean, look at some of the music companies that had their access to licenses just shut off. It's basically the same thing.

The Scope of DX Design

Steve: So we talked a little bit earlier about the scope of DX design. I don't know if we might be able to unpack that a bit more.

I think when it started, it was basically the design of APIs, that for a long time I think developer experience design was synonymous with API design. Now I think we've entered a world where it means a lot more. That the design of your APIs, the design of your documentation, those are all important considerations, but every aspect of your product is looked at now.

We're expected to design elegant user experiences everywhere, just as any other consumer product would be. What do you think about the scope of that definition?

David: I think it's definitely increased for sure. I mean it's not an afterthought anymore, I guess, is the easiest way to think about that. It's not like, oh I built this product and I'm just gonna come slap an API on it from the side now.

I think you really have to take that into account from the beginning. And really think about like, what are the actual primitives or pieces of my application and what can I expose to other people to customize without giving away all of the value, and thinking about all of that from the beginning, I think, is really important.

Steve: Yeah, and tools like Stripe have really set the bar that you're now expected to consider everything from the beginning and that you just can't focus on a great API. You have to have the entire package.

And as makers of products, in some sense, we do have to think about it as regular user experience design. We're creating an elegant experience for our users. But I also worry that that can be a bit of a red herring.

I've seen a lot of dev tools that continue to be very information dense and very powerful, but difficult to use. And then I think to some degree, product designers have used it as an excuse.

We're making tools for developers. These are power users. They want more functionality, they want more tools available to them. So we're just gonna throw this stuff up on a screen and let them figure it out.

We see a lot of this in the monitoring world, these dashboard products that are heavy, they have no comparable mobile experience. It's just something you kind of have to throw up on a big screen and configure.

I think that's the wrong approach, that developers are users, and we should have a similar focus on creating a minimal and elegant experience in all parts of our product that we would for any other user.

David: I definitely agree. I think it's really important, even when you're designing tools for developers, to make sure that step one isn't write this giant pile of code and completely understand my entire system before you can even get started.

There's definitely a path into that where maybe you can click on a couple of things and set up some default configurations and play with it a little bit and then start to customize from there. If your product is only an API and no tools around that, if you're not sort of the first and best consumer of your own API on behalf of people, I think it's a quagmire. Nobody wants to just get dropped into that world and have to figure out the entire thing.

Steve: Yeah, and the proliferation of mobile devices in particular has, I think, forced a lot of us to rethink how the experiences that we're creating can be made simpler. And we're certainly trying to do this with monitoring. We're trying to develop in part an experience that is rich and powerful on mobile devices, which is not something we've seen a lot of in the monitoring world.

And that poses different challenges. We have to make compromises. We can't throw up the kinds of rich detailed graphs that people have come to expect in this world. And so we have to think about, what can we take away? What can we refine to make this possible on mobile at all?

David: Yeah, I think it's important, like, so I'm a developer. I come to some of these tools and just because I can write code doesn't mean I necessarily want to. And yeah, if you're talking about monitoring tools, the less work you make me do to get this thing integrated up front, the better.

And maybe down the road I'm gonna want to do something a little more intense or advanced, and maybe I'll start customizing at that point. But yeah, I think it's really important to just not make me dive right into the craziness right up front.

Onboarding and Time to Value

Steve: And that too, one consideration of a great developer experience being onboarding and time to value. Not just how quickly you can help the developer create their first project with your tool, but how easy you make it for them to integrate your tools into their environment, and this really all starts to blend together, that the first time a developer uses your product, you of course want them to create something very quickly with it, because that's how they're gonna feel empowered.

But then your documentation also has to be really good because they're gonna have questions and they need to follow up on them and get answers. And in many ways, I think that it makes our jobs harder. There's a lot to consider because you have a very limited amount of time to capture the attention of your user.

And they're gonna have lots of questions that a normal consumer product user might not. And so our responsibility is pretty big there.

David: Yeah, definitely. And yeah, the onboarding thing is key. I mean just constantly going over your onboarding is really important.

It's so hard to remove all of your own knowledge about the thing, so every time you come to it, there's terminology you may have invented or just sort of how the thing works, like you already know, and it's hard to shed that knowledge and think about it through the eyes of somebody that's coming to this thing for the first time, but it's so important to do. The first five minutes that somebody has with your product are gonna, I mean first impressions matter so much.

Steve: Yeah, there were a couple of interesting things you touched on there, that I think any product really has a responsibility to test what they're doing with their users. And for us, onboarding was a big one for that. We had both invented new terminology and assumed that people would know things that they didn't actually know.

And so being able to guide people and again, I think it comes back to this question of the assumption that some of us make as builders of developer tools, we assume that we're dealing with really intelligent power users and that lets us get lazy sometimes. And we got lazy at a few points.

We assumed people would understand things in our world that they didn't, and we had some invented terminology for things that people just called us out on and said, I don't know what this means. Tell me. And yeah, there are no excuses.

We can't take liberties and just assume our customers are smarter. Well, maybe they are smarter, but we still owe it to them to explain ourselves and to make the experience as elegant as we can.

David: We've all been on the other side of that, right? Just kind of see yourself, it's very frustrating when you're like, I actually have no idea what you're talking about and how to use this thing. So yeah, it's definitely something to be really thoughtful of.

Measuring Developer Experience

Steve: In terms of how we measure the developer experience and the ways that we know we're succeeding, one is definitely time to value and how quickly a developer can create something with the tools that we make available to them. I think another way that we measure that is in terms of the code developers don't have to write.

Somebody needs to be able to look and think about what they would have to do as an alternative and realize that using your tool means writing less code.

David: Yeah, I think I would add to that maybe just the quality of the automation around your tools as well. So you're building these pieces and you want them to be used to build whatever it is that you're trying to do. But there's certainly a lot of choices that you can make people not have to make.

Maybe they are choices and maybe they're available at some point in the future if you need them, but it's really important to not make me think too much about installing this stuff from the beginning. I think the how do we measure and who's doing it well are kind of open-ended, right? There's a lot of subjectiveness there. That would be something interesting to talk to other people about, I think.

Steve: Yeah, this has been a great start to the conversation. I think trying to unpack the term and discuss why it exists at all has been a great start.

And yeah, as you said, it's totally subjective. Who is doing developer experience well? Who can we learn from? And that's a big part of what I think this podcast is here for.

Who else can we talk to that's gonna have opinions that are different from ours about this? And who can we learn from? There are so many companies just within Heavybit trying to do this and I think there's a lot that we can learn by talking to more of them.

David: I definitely agree with that.

Steve: We're just getting started talking about developer experience design and this has been a great first episode and you can reach out to us anytime over email or on Twitter. My Twitter handle is @sboak.

David: And I'm @ddollar.

Steve: That's about all we have time for today. If you're interested in being a guest on the show, or if you have a DX topic you'd like us to dive into, you can reach us at dmmc at heavybit.com or on Twitter at Don't Make Me Code.

David: To learn more about Heavybit, visit heavybit.com. And while you're there, check out the library. It's packed with amazing talks from founders of developer tools companies and other industry leaders.