💻 Closing the Developer Experience Gap

Hello. Hi, Steven. It's great to have you here with us. Yeah, it's a real pleasure. So I'm Rita.

I'm a product manager here at Cloudflare, working primarily on developer experience-related things for workers.

So it's great to have a real expert on developer experience here with us.

Would you like to introduce yourself briefly as well?

Sure. I'm Steven O' Grady. I'm the co-founder of RedMonk. RedMonk, if you haven't heard of us, is an industry analyst firm that focuses on the developer or practitioners, sort of depending on the category.

So that's me. Cool. Well, I have a list of questions here from the AMA, so I'm excited to go through them with you.

I guess to start us off, Steve, you hear from developers a lot.

What are common pain points that you hear regularly with respect to, especially front-end experience from your customers, since we had the Pages announcement recently, especially?

So we hear a lot of things about developer experience. Probably the number one is just there are just too many pieces, right?

There's too many different things I have to work through, too many things I have to connect, too many things I have to integrate, too many things I have to operate and sort of maintain over time, right?

That's probably number one. Number two, I mentioned operation. What we hear from folks all the time is, I just don't want to run this.

I have better things to do than try to make this work and be responsible for not just standing something up, but making sure it runs over a period of time, protecting its security and all that, right?

And I think lastly, I guess one of the things that we hear, particularly on the front end, is just the sort of quality of experience, right?

Meaning everything that goes into it, like the aesthetics.

I wrote a piece about this a while ago and sort of referred to the elegance of solutions because a lot of them are, let's just say, not elegant.

So I think those are a couple of things, at least when we have these conversations, those are things that come up frequently.

I'll put it that way.

That makes sense. We've definitely heard a lot of very similar feedback as well.

I'm interested in your thoughts on around the first point of too many pieces to integrate.

I think one thing from the product side that we're always towing the spectrum of is how much configurability do you give a user, right?

Because on one hand, developers especially can be very demanding in terms of having as much granularity as possible on things.

And I think a lot of developer experience is actually kind of in the other direction of having an opinion, which means maybe you get fewer lovers or you have to integrate fewer things yourself.

So do you think developers will take no as an answer to, you know, sorry, you can't do that, but that's the trade-off of the reason that you like this experience, for example, right?

I think, yeah, I think the short answer is yes, in some cases, right? Because, you know, look, there are always things that you can't do, right?

There's always things that, I mean, like anybody who, anybody who's ever compiled code and been told, no, you can't do this, right?

Yeah, is familiar with that concept, which is, you know, hey, I would really like to do this.

And you're told, nah, in fact, you can't actually do that.

So, you know, like, I think that there is absolutely an element, you know, where you're willing to make some sacrifices.

The question is where that is, right?

And a lot of it, you know, will depend on, all right, what do I get out of this, right?

What's the return? And, you know, I think a lot of it will just come down to, you know, sort of a cost benefit, if you will, right?

Which is, okay, I can't do this one thing or the couple of things that I want to do, but I don't have to do these other 10 or 20 things, right?

And, you know, that is, you know, I mean, I can tell you when, you know, when Red Rock got started, you know, the website was, it has been WordPress forever.

And we used to manage that because, you know, we wanted to do a couple things here and there with plugins and blah, blah, blah.

It was just, it was not worth it, right? And we eventually transitioned over to, okay, let's find somebody to manage this for us.

And man, you know, just not having to sort of, you know, manage the day to day operations is huge, right?

And can I see a sort of world in which we go to, you know, something static down the line?

For sure, right? Because, you know, then, okay, maybe we lose some bells and whistles in that process, but it gets faster, it gets easier to maintain over time.

So anyway, yeah, I think the short answer for developers is that, yes, they will accept no in certain cases.

You just have to make a compelling case as to why they, you know, why they should.

That makes absolute sense and has been my experience as well.

And actually, I think your last point around explaining why it doesn't has, you know, obviously you can't explain everything to everyone.

And there's kind of the old mantra of, if you're explaining, you're losing.

But I do think that being as open as possible with developers about this is why we need these choices or these trade-offs is very helpful in getting across the line.

Like, okay, now I understand why the answer is no and I'm more willing to accept it.

Yeah, I think that's exactly right. Like one of the things we tell people all the time is be up front about what you don't do, right?

Because the developer is going to find that, you know, one way or another.

And either you can save them the time of discovering that on their own, in which case they're probably going to be ticked off of you.

Or, you know, you can say, hey, look, you know, if you want to do X, you know, this isn't for you.

And, you know, to your point, not just, you know, hey, this isn't for you, but here's why, right?

You know, here's the reasons behind this decision. And, you know, like I said, you know, there will be cases where, you know, that, you know, just won't work, you know, for a developer, they, you know, they really need to do whatever it is that you don't do.

But you'd always rather have a relationship with the developer, which is honest and transparent.

Because like I said, then they're more likely to come back to you in future.

You know, if you try to lull them in with like, no, you can do whatever you want, it's going to be fine.

And then they, you know, hit that later.

Let's just say that tends to knock over terribly well, long term.

Right. There's no worse feeling than having spent a few hours going down a rabbit hole and finding out that something is not possible.

That is the opposite of a good developer experience.

Exactly right. The third point, actually, that you mentioned, I thought was really interesting around kind of delight and aesthetic.

And, you know, the standard today being kind of what we're used to with what I interpret to be very loaded dashboards, and people leaning towards and things that feel more pleasant to use.

Do you think? Yeah, what do you make of that?

Does it feel I don't think that it's a bad thing that we've gotten, so to say, spoiled in that way.

But it's something that we're definitely noticing as well.

And for us, having even a feel that's very accessible is something that's been very core to Cloudflare from the very beginning.

But I'm interested to see kind of how that plays out in customer conversations, because we've actually heard the opposite as well, which is like, is this enterprising enough?

Yeah, you know, I think, honestly, you know, a lot of it comes down to, you know, I don't know if it comes across in the in the camera, but, you know, I've got a little gray and a little white in my beard.

So I've been around long enough to remember when, you know, the enterprise, you know, basically enterprise software, you know, sort of across the board looked terrible, like just awful, and offered a terrible experience.

And, you know, I, you know, I remember being asked this sort of years ago, like, why is that?

Like, why would that be? The answer is really simple, right?

It was designed for the, you know, folks at the top of an organization for whom usability wasn't an issue, right?

Because in many cases, they weren't going to be the ones using it.

So they were concerned with saying, you know, if I'm a CIO, my concern was, how does this scale?

Has it fit in with, you know, the rest of my infrastructure?

Is it secure? Is it this that the other thing, you know, the usability and the aesthetics of the software was literally last on the list.

And, you know, it was reflected in a whole generation of products that, like I said, just looked awful.

And, you know, that has certainly pivoted, you know, in the last, you know, sort of five or 10 years.

And it's pivoted, at least in part, because, you know, when you are making products, they're going to be selected, you know, at least or at least heavily influenced by developers.

Well, developers do care about the aesthetics, they do care about the usability, they do care about sort of the experience that you're offering.

And, you know, consequently, you know, people sort of making products, you know, for developers, or conversely, you know, in the enterprise, you know, for regular users, you know, they were influenced sort of on their end by things like, okay, how's it look on an iPhone, right?

So anyway, you know, the industry sort of as overall, you know, has undergone this sort of transformation, which is, no, actually, you know what, you know, what this looks like, and how people use it, and how the interface with the day to day is important, right, and something to be valued.

And that, to me, is a very welcome development.

You know, like I said, as somebody who spent far too much of my time, you know, just dealing with software that just, I mean, it was, it was really, I can't even, you know, I wish I had some, some sort of ready examples for you that I could, you know, sort of pull up, but I mean, it was just awful, right?

And we don't live in that world anymore.

And I'm glad. And yeah, so, you know, for, you know, folks designing, you know, are competing in these markets, you have to care.

And that's a good thing. Yeah, I think you touched on a really interesting point there, too, which is how software was acquired, and thus who it was sold to, in the way in which it was expected to be sold, right?

Like, I think the software that you're talking about, it was expected that with it came a pretty expensive package of, and someone from our company will come or consultant will come and train your entire team on how to use it.

So maybe to an extent, it's even a feature that it's complicated and convoluted, because we get hours of, you know, professional services out of it.

And I think a really interesting shift has been that now the decision makers are much more the developers, which is where, you know, if you have a good experience building something for, for even your blog, or something like that.

Now, those same people are joining a company and becoming engineering managers and choosing to adopt those same technologies for, for their companies.

Is that something that you're, you've seen much of or starting to see more of?

Oh, for sure, for sure. So many of the technologies, you know, it's funny, we kind of joke at RedMonk that the thing that makes us sort of sit up and take notice of a technology is when somebody calls it a toy, right?

You know, because you can go back and sort of look at, you know, I don't know, you know, maybe one of the classic examples was, you know, virtualization started to come out and people are like, Oh, it's just a toy.

You're like, Oh, okay, I'm gonna pay attention now because these toys have a way of growing up and becoming important.

And, you know, that's what we've seen, you know, certainly in the cloud world.

Right. And I can remember when the first instances started to roll out, people were like, Yeah, this is fine.

It's just this toy thing for people sort of, you know, developers sort of running their blogs.

And, you know, you fast forward, that's, you know, pick a pick a number, but it's a large number, you know, in terms of the percentage of the industry that is that is eaten.

So, yeah, I think all these all these sort of individual, you know, tools and, and assets, they have a way of becoming important.

Because if you if you put tools in the hands of developers, you know, they will familiarize themselves with them and then find new ways to build on top of them.

Right. And that's what you want. So yeah, for for sure. Like I said, you know, the first thing whenever an enterprise like a traditional company, you know, looks at something new and says, you know, we don't have to pay attention to that, because that's just this, you know, toy thing that people are building with.

You know, that's a at least as far as we're concerned, that's a good sign.

And we that's what we start paying attention for sure.

Yeah, I remember. Very similar. Honestly, I feel like we've gone through that transition with Cloudflare Workers where four years ago, it was just a little UI with a widget, where you wrote a little code and you deployed it.

And yeah, that was very much the criticism. And yeah, slowly, you, you kind of mature and grow out of that into a massive developer ecosystem.

So yeah, very similarly, when we hear people criticize other tools as being toys, definitely a sign to start paying attention.

That's right. All right. So one of the other questions in here is, why is developer experience such an issue in 2021?

Shouldn't we have figured this out by now? Well, you know, you'd think so.

But honestly, I think the way that we refer to it is, is that developers at this point have like a Scrooge McDuck embarrassment of riches, right?

In terms of they just have so many tools and so many assets at their disposal.

You know, whether that's cloud services, you know, things like workers, or, you know, whether it's the, you know, sea of open source libraries, frameworks, packages, sort of, you name it, right.

And, you know, what ends up happening from a developer standpoint is, is that they have, you know, sort of all these individual services, right?

You know, I might use this for code scanning, I might use this for, you know, my deployment target, I might use this for builds, you know, test and sort of on and on and on.

And, you know, the end result is a really highly performant tool chain, right?

You know, one that has, you know, sort of these, these huge, you know, sort of impressive capabilities, particularly, you know, given what was available, you know, relative to what was available five or 10 years ago.

But you've also assumed this huge burden of, you know, keeping this, and sort of patchwork quilt of different tools and services together, right?

So, and I think, honestly, the story in 2021 is, you know, we have this huge array of impressive capabilities, but a pretty limited ability to, you know, go to a, you know, an individual developer and say, hey, here's a good experience, right?

Largely, we're putting that on them, you know, to build and deliver, which is, which is too bad.

Is the solution here, kind of more purpose built tools, or, like, how do you help developers navigate the vast array of choices?

You know, I think there's, there will be two approaches that I think are taken longer term, right?

You know, one is, you know, you'll have a, an approach that basically says, okay, you know, we're going to deliver, you know, a single provider is going to deliver, say, 80% of what you need, right?

You know, which is, okay, you know, from, you know, the very first lines of code that are being written, you know, capture, inversion, control, all the way out to production.

You know, you'll have a sort of native path, you know, to go from, you know, all the way through, right?

And it won't be the most performant, it won't, it won't have all, you know, sort of the, the capabilities of a best of breed approach.

But its advantage will be, you know, you don't have to context switch, you don't have to leave a single environment, right?

So that'll be one approach. And the other will be, okay, you know, that approach is going to be limiting, you know, sort of in many respects, because it won't have, you know, sort of X, Y, or Z capabilities, in which case, how do we take the existing sea of different applications and provide a, you know, essentially a path, an integrated path, right?

So, you know, at Netflix, for example, they talk about like paved roads, right, which is, okay, we're gonna have a paved road that you can follow, if you want to go do something else, you can, but you're on your own.

And I think we'll just see more of these paved roads created, right, from different services that say, okay, look, we're not just thinking about, you know, compute or build or whatever, you know, our little sort of corner of the world, we're going to think about the whole experience, and think about, okay, who are the other partners, and who are the other services and projects that we need to work with, right, and we need integrate with to deliver this sort of seamless experience.

So I think those will be the two paths, I think that you'll see, you know, from an industry standpoint.

I think that makes a lot of sense. And that's exactly what we've done with Cloudflare pages, where all the components for you to build it yourself have always been there.

But what we saw was front end developers doing the same thing over and over.

So we're like, okay, here's a well paved path for the front end development experience.

And taking you having to worry about configuring any of it away from you.

I feel like in the front end development space, at least, there are a few solutions that do this today, right?

It feels like we're starting to converge on what the developer experience for front end especially is, what do you think are areas of software where developer experience is much less explored, or there aren't as well paved paths, where you do kind of have to, you know, trod your own?

Yeah. You know, honestly, the one that we hear sort of most is, you know, sort of in the the sort of pre deployment phases, right, in terms of things like build tests, you know, CICD, and so on, you know, because obviously, there's hooks, and, you know, some, some folks have this working pretty well.

But, you know, there's just, there's a lot of moving pieces, as we talked about.

And some of those moving pieces are just not connected as well as they need to be.

You know, so that's one, you know, one that, you know, honestly, gets less attention from the developer side.

But I think it's sort of no less important here is on the database, right?

You know, because you have a, you know, on the application development side of the house, the way that we've, you know, done things for it over the last 5, 10, 20 years has changed night and day, right?

The way you develop software today looks nothing like it did five years ago, 10 years ago, 20 years ago, on the database side, that's not really true, you know, a lot of the sort of old processes sort of remain.

And a lot of that is because the linkages between sort of different steps are just aren't there, right?

Or, you know, hey, this is how we did things 10 years ago.

So I think you'll see it there as well. But honestly, you know, if you pick a, if you pick any aspect of what developers are dealing with today, there's some fundamental part of it that's broken, right?

Because, you know, as I said, you know, companies have just been doing what they can to build out capabilities as quickly as they can, because that's what developers want and need.

And that's gotten us to a point where, like I said, we have this huge array of really impressive tools and services and so on.

But we're getting to the point where, you know, we kind of collectively as an industry need to take a step back and think not just about, okay, these tools in and of themselves, but how they all work together.

And I think that's what will, you know, that's, you know, to be honest, that's what we're already seeing.

We're seeing people, you know, pay more and more attention to this.

That makes sense. So to jump to another question.

So at some point in the future, we believe that a startup worth a billion dollars will only have one developer on staff focused on developing their application.

So that means that in reality, they won't have to spend as much time on things like backend management and scaling.

As an industry, kind of going back to your point, where do you think we are in being able to make that a reality or effectively serve that developer?

I'd say we're pretty close, honestly, surprisingly, you know, because I'm trying to remember off the top of my head what the numbers were.

But, you know, WhatsApp, you know, what was it? It was like, I can't remember how big it was under 20 people, I believe.

And, you know, the scale that they were delivering was just obscene, right?

I mean, it was just this sort of incredible success story, you know, with a very small number of developers.

So we're clearly not there, right? I mean, it was more than one, you know, more than one person for sure.

But I think, you know, as I said, I think we're in a place where a single developer by leveraging services, you know, of companies that have learned and sort of learned how to deliver at scale can do incredible things.

I think the issue for, at least for me, is that we're still asking that developer to do too much, right, in terms of piecing it all together.

So, you know, if you are an exceptional developer, you can do exceptional things.

I think we, you know, are headed towards a world where, you know, even, you know, non-exceptional developers will be able to do exceptional things because, you know, the tools are not only present, but they're made accessible and useful in ways that, you know, maybe they just aren't today.

Yeah, I think, I guess, do you think, on one hand, I feel like it's so much easier to be a developer now.

On the other hand, there are a lot more tools and services and it can be pretty overwhelming to get started.

So, yeah, do you think developers getting started today on, you know, harebrained idea that could become the next billion dollar business, or it sounds like you think they're overall still way better off?

I think they're better off, you know, for sure, you know, in the sense that there are just so many things you just don't have to worry about now.

You know, like I said.

What are some of those things? Well, I mean, I can remember, you know, sort of examples, you know, this is going back, you know, forever, but I remember the first time that I saw Rails, right?

And I was like, oh my God, like, I don't have to build all the scaffolding?

This is fantastic. Like, why did I waste all of my time building this over and over and over in different places, right?

Somebody's just gone off, you know, gone off and sort of built this for me.

And, you know, I mean, Rails is, God, how old now?

I don't even remember, you know, 15, 16, you know, whatever it is, right?

It's been around forever. And we've had, you know, well over a decade, you know, we've had basically two decades of, you know, continual advancements like that, right?

Which are developers saying, hey, all right, here's this thing used to be really hard to do, and you don't have to worry about that now, right?

Just sort of take that off your plate. You know, because, you know, even things like, oh, I don't know, you know, sort of on the database front, you know, you see this all the time, you know, companies have to roll their own, you know, sort of in-memory stores, you know, sort of caches and so on.

And it's like, nope, you got really good stuff to use off the shelf, you know, for all of that, right?

So yeah, we're in a much better place than we used to be as far as the tooling.

But, you know, I think it is, it's interesting, like I said, you know, we have this sort of embarrassment of riches, and that could be off-putting, right?

In the sense that, you know, we, you know, there was a quote from Marco Armat, who, you know, was about an employee, eight or 10 or something at Tumblr, and was going on to do, you know, some other, you know, impressive things in the podcasting space.

And, you know, he said this, I don't know, a number of years ago, you know, basically, like I've lost almost all interest in being a web developer.

And it was because, you know, frameworks were arriving so continually, there's so much to take in, that the job of a developer was counterintuitively harder, because of all these tools, right?

You'd think, oh, no, I have this wealth of tools.

But then you'd have to sort of wade through this wealth of tools to figure out, all right, which one do I want?

And what are the trade offs? And, you know, I might make this call, this might be the best technical product now, project now, but it's not the one that wins long term.

So, you know, there are definitely costs, you know, for, you know, for all of this sort of, you know, for these riches, right?

You know, it's not a unmitigated good, you know, so to speak. Yeah, analysis paralysis is definitely a very real problem in that realm.

But then to the last nugget of what you said around, is the something that I choose early on going to be the right choice in the future?

Our goal with workers, at least, is very much to make it easy in the beginning, and the right bet in the long term, in that the whole purpose is that it scales so seamlessly that you don't have to, I think one of the challenges that people did have with Heroku is like, it was a great bet for getting started.

And then later down the road, I was like, Oh, my God, I don't know how to scale this or like, people are hitting performance problems.

And I love Heroku, I was a big fan from the very beginning. So definitely not a knock on them or anything.

No, for sure. Okay, last question. I'm interested in what role do you think local development plays in the developer experience?

That's something that we certainly get a lot of questions about and talk about a lot internally.

And yeah, one ongoing debate that we've been having is how local does local have to be right.

So for example, our Wrangler dev tool actually connects to our edge, but the intent is to give you the immediate feedback, which is kind of the goal of local development.

But on the flip side, we've also seen that feedback kind of given to the industry as a whole, especially in terms of like serverless and cloud.

Why do you think everyone that's something that everyone's struggling with so much?

And yeah, what role do you think it plays?

Yeah, it's a good question. I think, you know, the short version is that, you know, I think developers are just, there is something about opening your machine, writing some lines of code and, you know, being able to do something just on your machine without having to worry about networks, without having to worry about sort of pushing things in different places.

You know, even in situations where it's straightforward, right?

I mean, obviously there's so many services now where it's like, okay, you know, I'll do a push to GitHub, you know, something will pick it up and, you know, do a build.

And I can see that, but there is latency, right?

There's latency in terms of, okay, you know, that has to get pushed, something else has to sort of, you know, listen for that and so on, you know, versus like, okay, you know, I have a preview pane up and I'm watching this thing live locally.

Now, a lot of services, you know, right, have been trying to get developers to do that online, right?

In sort of, you know, basically, okay, you know, you have essentially the equivalent of a text editor, you know, up in the cloud somewhere.

And oh, by the way, because it's in the cloud, we can do some really impressive things.

And I think, you know, I think that'll be sort of an increasing part of development over the longer term.

But, you know, like I said, there is just something magical about that, you know, hey, I'm just sort of writing some quick lines here, and this is where I want to start.

And, you know, I've seen companies for years try to, you know, basically get developers to deprecate that and sort of drop that approach.

And, you know, like I said, while I see cloud, you know, playing in a more and more important role, you know, moving forward, I think it'll be a long, long time, you know, before local development goes away.

I suppose to play devil's advocate a little bit, and go back to the, you know, developers somewhere, maybe in Eastern Europe, maybe in Asia, maybe in Oceania, right, working on maybe in India, working on the next billion dollar application.

I think one of the really powerful things about technology today is that things like even GitHub code spaces, right, you could write a whole application on an iPad, you don't need a fancy computer anymore, in order to give you that capability.

So, yeah, I think if we're able to, and that's kind of the thing with technology, right, is like how do you overcome the uncanny valley of it's not running on my machine, and it's making me feel weird?

Right, right. Yeah, I mean, that's the question, right?

All right. Well, thank you so much for joining us today, Stephen.

Not at all, my pleasure, Rita.