Zeno Rocha explores the emerging trend of developer-first products, noting the increased influence of developers in tech adoption within companies. Zeno traced the evolution of tools through 4 distinct generations created for developers, starting with early offerings like Splunk and JetBrains, evolving to API-centric tools like Auth0 and Firebase, and culminating in current tools like Gatsby and Netlify that emphasize immediate production integration.
The rest of the talk answers the question 'How to create developer happiness?'
The answer comes in the form of 5 categories:
- Cognitive Overload
- The Little Things
- Buyer vs User Dilemma
- Treat Docs as Code
- Developer Obsessed
Emphasizing the importance of developer happiness, Zeno discussed the detrimental effects of overwhelming choices, drawing from Hick's Law, which states that decision time increases with the number of alternatives. Zeno stressed how attention to detail in developer tools enhances user experience, noting how this care reflects technical competence and excellence.
The talk highlighted the contrast between buyer and user experiences, pointing out the pitfalls of focusing solely on either. Zeno introduced the static usability effect, suggesting tools with visually appealing designs are often perceived as more user-friendly.
Drawing parallels with Maslow's hierarchy of needs, Zeno proposed a similar hierarchy for developers interacting with technology products, emphasizing that tools should not just be functional but also delight users. The presentation ended with a call for continuous improvement and innovation in the tech and programming space.
Share this talk with your friends
Transcript
So, today we're going to talk about the next generation of developer-first products.
If you're a developer and you love building things for other developers, this talk is for you. But why building something that is developer-first? I feel like there's a fundamental shift in terms of the role of developers in companies.
In the past, it used to be the case where developers could only influence the purchase decision of a certain thing, but not authorize. And that was their role. But that's no longer the case. Now we can come in, swipe our credit cards, and start using products much faster than before.
Before your manager, the CTO, someone would have to come in and say, hey, I've been looking into this tech, and then they would talk to procurement, they would go through that process, and then now you have to use this technology. It was much more of a top-down type of approach.
Whereas today, you're at your house, wearing your pajamas, and then on a Saturday morning, you look at something on Twitter, and then you're like, oh, let me check this out. You sign up, you go through the docs, and then if you like it, then Monday morning you
come to your team and say, hey, check what I built over the weekend, and then you start adopting internally. So there's a shift. There's a tremendous difference in terms of how developers can make decisions, and that's good news for folks who are building products for developers.
And I feel like there's a difference in terms of what is expected today in terms of a developer tool. The bar is so much higher. I tried to break it down, the different generations of developer tools.
And this first generation came about between the year 2000 and 2009. During this generation, everything was pretty costly. Those tools were nice to have, but the beauty of those is that they enabled collaboration, which is something we didn't have before.
So things like GitHub, Twilio, Splunk, and JetBrains, Heroku, that was amazing, but those were still toys early on, and then they started to become something that you would use at your companies. Then the second generation come in between the year 2010 and 2013, and this generation
was much more about being cost-efficient. They were API-driven, and now they became mission-critical. Now like if those APIs were down, oh man, we got a problem.
And those are things like Auth0, and Firebase, and Segment, and Plaid, and so many others. Those tools, they start to become crucial. And the third generation, from 2014 to 2017, now this generation was about just plugging
in the first day that you interact with that API, you can already push that to production. And that was very easy to integrate. So things like Gatsby, and Retool, Vercel popped up with so many new products, and Netify.
There was a new hope, a new generation of developers coming in, as long as a new generation of tools. And today, it's a completely different scenario. Now it's a lot about getting started quickly.
And people throw this term a lot, like being API-first, as if this is the case. I very much disagree with that. I feel like we're living in a SDK-first world, which is very unique. The things you expect from a dev tool is so much different than before.
And all of these tools, they're obsessed with developer happiness. When you look at Clerk, and Liveblocks, and Superbase, and Raycast, and WorkOS, and Resend, those companies are really focusing on making a product that people not only use and it's
useful, but it's a product that people love, that they are obsessed with, that they cannot stop but talk about it. But how do you even go about creating developer happiness? What's the formula of that? I put together five different things that I believe are really important to make that happen.
And the first one is about the cognitive overload that we have to go through as we're evaluating different dev tools. This is me in 2015, I guess, when I moved to the US. And this was my first car. And I was so happy when I bought that with my wife.
And we were celebrating. And then we started driving the car. And then the first thing, we stopped to grab a bite. And I look at these signs, and I was like, what's happening? Can I even park here or not? I have no idea. I still got confused. I'm not going to lie.
I did the math. I moved to SF last year. And I already paid $1,200 in fines, which is something I'm not proud of. I don't know if I'm the problem or the city. I don't know. But anyways, there's a lot happening.
And that's where Hick's Law comes from. They state that the time that it takes to make a decision increases with the number and complexity of choices. And we all experience that ourselves, right?
When you see so many different options, it makes it so much harder to react, to make a decision. That's where analysis paralysis comes into play. When you go to Azure, for example, and you start looking at the different products, I want to build a web app. OK, good luck.
There's so many options. There's so many things you can do with it. And I get it. It's a different problem to solve. But the more options you have, the harder it is for you to get started. In contrast, you look at something like Heroku.
They have all these buttons, like 7,000 of those. But when you go and you look at it, there's more information. You see the number of forks and stars. You click one button, and now there you go. Now you can deploy a ghost instance in the cloud.
All you have to do is choose the app name, the region, and you're good to go. So there's something really beautiful about eliminating the number of options, or at least surfacing more information so you can make a more informed decision.
So definitely keep that in mind as you're thinking about building your own dev tools. The other thing is about focusing on the details, focusing on the things that people don't really pay attention. I'm sure many of you are familiar with the term broken windows.
This is a concept that the former mayor of New York City came up. And what he said back then is that, obviously, murder and graffiti are two vastly different crimes, right? We all agree with that. But they're part of the same continuum.
And a climate that tolerates one is more likely to tolerate the other. This is so important. And I feel like each one of us in this room, we can relate to a time where you saw some code, maybe you pushed that code that you're not that proud, but you had to do that because
of all the other things that were happening in that environment. And the more you do that, the more technical debt you incur. And that's the broken window theory. Visible signs of crime and civil disorder create more of that.
Same way with code, right? The more corners that we cut in our code base, the more likely we'll be to cut even more corners. So when you go to a website like Sentry, amazing website, I absolutely love their brand.
And as with any website, they have a cookie banner. And it just works. You go, you accept the cookie or not, and that's it, right? There are no broken windows at all here. But maybe there's something better that you could do. So if you go to the JetBrains website, they have this little terminal.
And as a developer, I'm like, oh, this is so cool. This is so refreshing. It's not like this super annoying banner. So I can go as a terminal, and then I can just agree or disagree. That's the kind of thing that now I'm going to talk to my friends about it.
Or when you go to the Mona Lisa website, which is a monospace font, you can test that font with these different themes that you have. And that's amazing, because they know that as a developer, you're going to use that font in your code editor.
And you know that the best theme is Dracula. So then you just go choose Dracula, and then you can see that font in action. So that's beautiful. When you go to Plaid, and you click Run on this code snippet, they break down the payload, the response object.
And they start talking about, hey, this is what this object is for, this other one, and this other one. This is a really nice way to go about educating folks on your API. For us at Resend, when we built our first website, and we put this crazy Rubik's Cube
on the landing page, people would ask us, why are you even doing that? This is like an email service. Why are you? There's absolutely no reason. But I really believe that communicates much more than, hey, we're building something new. It communicates that we care about the details.
We care about technical excellence. And I could write a whole paragraph or a whole manifesto about why I care about those things, or I can demonstrate that in the most important part of my website. So that's how I think about the details.
There's another part on the website when you go, and then you scroll, and there's this Integrate This Morning section. This is what shows up if you're looking at the website during the morning. But if you go during the afternoon, it changes. If you go during the night, it also changes.
And if you go Friday after 5 p.m., it also changes. And it's not only about changing the colors or the messaging. There's another detail, if you pay attention here. The light, when it's the morning, goes one way. Afternoon, another direction.
During the night, another direction. This is the type of thing that probably no one will notice. But the people who do, they will think about it and be like, wow, these guys, they went the extra mile. In our dashboard, we have these links, these icons in the sidebar. They're so silly.
Like, it didn't take us that much time to add it on the website. And people absolutely love it because, again, it communicates something deeper, communicates that we care. I feel like that's what's needed to build a DevTools in 2024.
If you're building something new, you want to create that idea of always surprising users with little details and little initiatives. If you keep doing that, if you go to a website, and the website is good, and then you go to
the docs, it's easy to read, and then you test the getting started code, and it works, and the first API call works, amazing. That's what I'm going to bring to my team Monday morning. And that's a product that I'm going to love, I'm going to praise. And ultimately, I'm going to talk to others about it.
And the opposite is also true. I go to a new DevTools, and then I go through the website, and it's so hard to understand. But then I give a second chance. Let me look at the docs, and it's so confusing. I can't get started quickly. There's a typo.
I try to download a GitHub code repo, and then when I try to run it, it doesn't work. I would just create a sense of distrust, or I'm just going to leave that service, or the worst thing that can happen to a brand, which is indifference.
I'll just not care about that thing, and then I'll just go about my day, and I'll continue doing what I want, and I'll just forget about what I just did. So that's really important, caring about the details. And if you do that consistently, that's going to pay off. It's definitely not something easy to do.
It's extremely hard to do. There's also this dilemma of who are you pleasing when you're building DevTools? Are you pleasing the buyer or the user? I had to go to the dentist recently, and as a buyer, that seemed like a great idea.
I need to take care of my mouth, and yeah, that's what I'm going to do. As a user, I absolutely hate every second in that chair. That's what typically is the case, right? The thing that the buyer loves is completely different than what the user sees.
It's completely different. It's a completely different experience. And you've got to tailor whatever you're building to that. I love this story about LA.
They spent like $1.3 billion on new iPads, only to realize later that 1 out of 245 classrooms were using those iPads.
That's what happens when a buyer makes a decision that didn't include the user. And the other way around could also happen. If only the user goes and makes a decision, then there's a lot of things that could affect the buyer. This is not the current Prisma website.
It's an older one. But I remember feeling so good as a user there. There's an npm install command. I could try in five minutes. There was a code right in front of my face in the first, like, above the phone screen,
and I could see a taste of this tool right away. When I go to HashiCorp, on the other hand, I could read a customer story, I could request a demo, I could contact sales. Those are the things that I definitely don't want to do. As a user, I don't want to talk to sales.
I don't want to get in a call. I just want to try. Let me try the product. And if I like it, then we can continue the discussion. So this is working very well for HashiCorp. Don't get me wrong. They are doing fine, but they're tailing to the buyer.
That's the case with sales-led products like Atlassian and Jira. Jira now is almost this thing where people love hating on, and they're just not happy as users. In contracts, you have things like Notion and Linear that people absolutely love because
those products are tailored to the user. And that's the dilemma because one approach is not necessarily better than the other. I'm sure the Atlassian founders are not complaining. They make a lot of money with their products. So it's just about what do you want to do yourself?
What do you believe? What do you care the most? And then go through that and be respectful about the decisions that you're making, being consistent about those two. The other part is about docs.
I don't know how you think about docs, but for me, I feel like docs should be treated as code. We do all these things with code, right? We lent our code. We have unit tests. We have CI, CD pipelines that are super sophisticated.
We have roadmaps to improve the product. And we have technical depth that we are always fixing. So why don't we lent our docs? Why don't we have unit tests for our docs as well? Why not have CI, CD for our docs?
Why are we not having roadmaps on how we can improve our documentation? There's so many cool tools out there, like all sorts of linting packages that you can,
Instead of having mixed double quotes or single quotes, please just lint your code examples. That's a small thing you can do. Another one is that you can include a package in your CI, CD to check for typos, to check
for inconsistencies in your writing. As a non-English, native English speaker, this is gold for me. This is gold for my team, which is international. So that type of thing is really important. What about links?
Is there something more annoying than going to a docs and then you click a link and you go to a 404 page? I absolutely hate those moments. And you can check those things on the CI. Go through every single link, make sure it returns 200. And if it does, you're good to go.
If not, you can block the CI and fail the pipeline. So documentation is not auxiliary to the product. That's how most people think, oh, it's the thing you do after you build a product. No, documentation is the product.
If you're building developer tools, that's going to be the mindset that you need to have. On Resend, one cool thing that we do that I really like, we have this API button in every single page. And you can see how you can interact with that entity with code right away.
And you have snippets for all the different languages that you might want to use. Now the last thing is about being developer obsessed. And there are so many ways that you can go about building something, right? You can build something that works, or you can build something that delights people.
I love the story of Jiro. I don't know if you ever watched this documentary called Jiro Dreams of Sushi. And this is about a guy that is, you know, he has a Michelin three-star restaurant. And he started working from the age of seven.
And he's still a sushi master after all these years. And I separated like a clip from that documentary where he talks about how he approaches his craft.
♪♪♪♪♪♪♪♪♪
♪♪♪♪♪♪♪♪♪ What's truly amazing about this is the fact that this guy who's been doing his work for more than
80 years, he still feels like there's more. There's more that he could improve. There are a lot of things that he can do better. And if we're building developer tools, that's the mindset that we need. I used to have a mindset of, you know, oh, if I just move super fast and build this thing,
everybody's going to love it. And, oh, this is awesome. But this is an infinite game. It takes a lot of time, a lot of energy, and things keep moving. Right. And you can go and design a product that works right. And there are many examples of that, like Braintree. You go to the Braintree
website if we need to interact with a payment API. And it just works. It's good enough. It's there. Or you can do a design that inspires. You go to Stripe, and you're blown away by the quality. You immediately know that there's something deeper here, something that is tailored to you,
and something that communicates that extra layer of quality. You can have a changelog that works, like this changelog page from Algolia, where you have everything that you need, the date, what changed, and that's it. That's all
you need for a changelog. That works. Or you can have a changelog that inspires. You go to Raycast, and that's beautiful. You can see that this is a team that cares. You know, I can see what changed. I can see the breakdown between new things, improvements, and fixes. And there's care.
You can do recruiting that works, too. You can go to PayPal and find a job, like any other job board that you know, where you go to the role, and then you apply. You have this huge form, and that's it. Or you can go to Plaid and have a recruiting experience that inspires you. You can apply
by API call. How awesome is that? You know, like you go, you fill out your info, and you're good. So there's this concept of a static usability effect, where users will perceive a statically
pleasing design as design that's more usable. And that's for all the other layers of a product, right? When you see something that looks good, and there's attention to detail, you might think that, wow, if they went this extra mile to build this super cool front end, imagine what they did on
the back end. And there's this Maslow hierarchy of needs, right? This is a common human concept where you have the physiological needs, like food, water, and sleep. Safety needs, like housing and
financial needs. Belonging, a sense of community, like we have right now. Steam, respect from others, and then peace, knowledge, innovation. It's hard to innovate when you don't have water or
food or sleep, right? There are different levels that you need to go through. The same is for developer experience. You first need the functionality and the basics of that functionality. You need to expose that API with JSON and not XML, you know, crazy things like that. It needs to be
reliable, because if it's not up, then it's all for nothing. If the latency is super high, it could be perceived as not working. How about the usability? How are the docs, the SDKs, the demos,
the changelog? Then, can I build an extra layer on top of that API? Can I have a GraphQL layer? Can I have an OpenAPI spec? And then it can be more creative. If you go to recent.com slash secret, and I just realized maybe I shouldn't say that, because that was a secret and now this is being
recorded, but if you go to that endpoint, you can get a hoodie. And it's just the kind of thing that no one knows until now, but you can be more creative once you have those other layers. And if you ever settle, you're doing it wrong. I feel like that's the beauty of tech,
that's the beauty of programming, and that's the beauty of being a maker. So, thank you so much. Thank you.
