Ramiro Berrelleza - Redefining the developer experience

In today's episode, we'll be talking about redefining the developer experience, and we'll be covering both culture and technology with a particular focus, obviously, on the impact of new and emerging AI tools. As well as concluding with a few case studies of Okteto's clients that Ramiro will share with us.

So, Ramiro, welcome to the show. Thank you for being here with us today. It's great having you. Do you want to add anything before we begin?

Ramiro Berrelleza: Hi Tim, how are you? Nice being on your podcast. Thank you for having me. No, I think you covered it super well. Excited to dive deep into these topics.

Tim Butara: Yep, same here. I think it's a topic that will resonate both with the more technical and more, more kind of technology oriented listeners, as well as with strictly business listeners, because obviously software development and web development is something that has become more and more important as kind of advanced digital experiences become the norm, rather than just something that's kind of desirable.

And yeah, I'm also excited to get into everything with you today, Ramiro. So my first question that I kind of started answering already, I guess, is why is there such a strong need to revisit or redefine the developer experience, not just focus on it?

Ramiro Berrelleza: I think you covered a lot of it, but I want to extend on that because it's been very interesting to see how over the past, I would say, 20, 15 years, year after year, we're seeing this acceleration of software becoming more and more important for businesses, not only, you know, internally to help us operate businesses, but also as one of the major differentiating factors for companies nowadays, you see banks, healthcare, large enterprises investing a lot on like software driven experiences, you know, starting from websites, apps, systems for their suppliers.

So as software becomes more important, I think all these decision makers are realizing that we have to be good at this. We have to be good at software to be able to, you know, beat everybody else. And I think that is pushing this need for like, hey, okay, how do we get better at it? You know, I started with the transformation, moving to the cloud, streamlining operations, automating as much as possible.

And once production was kind of like a more of an understood situation, by no means solved, but at least understood. What I've seen is that now companies are looking at the next step, which is, hey, developers, what can we do to make them more effective? In the past, it was, hey, developer, here's a laptop, you know, like a super expensive Mac, super powerful, and then you figure it out from there.

But, you know, as organizations mature, we've learned that that's not enough, that setting up, you know, common practices, that setting up standards, making processes more reputable, giving developers the space to make decisions, but also kind of like give them some of them pre-made so they don't have to like, choose every single thing by themselves.

I think all that is driving this motion of dev experience. And for me, it's been exciting because it's different. It means that finally, you know, like companies have realized that, hey, we need to like give developers good tools to do their job, which... It's really happening for every other discipline. It just, it was missing for developers.

Tim Butara: And it's also not just companies, but a lot of new like developer frameworks, especially like front end UI frameworks, are kind of using this improved developer experience as their unique selling proposition, almost in a way. I'm thinking here about, you know, frameworks like Vue for the front end or like in the web development sphere, Laravel, which basically is based on PHP.

But, you know, people that dislike PHP love Laravel and it kind of starts, they start to rethink their whole approach to PHP and it's just a lot of this DX focused innovation all across the board, basically.

Ramiro Berrelleza: Yeah, it's amazing. It's something that, you know, I've been on this industry for, for a while now. And, you know, in the old days it was still kind of like almost to a certain degree, a point of pride that, hey, you know, like, you have to learn these things and they're hard on purpose because they're not meant for everybody. It was almost like a secret code, but I'm very excited to see this change in all fronts, like, and you're right, more and more products and frameworks and tools now start with the dev experience as a core principle.

For me, Docker was a huge kind of like proponent of this. I remember when I started using Docker, it was like, wow, the first time I felt like, oh, this is a tool for like kind of DevOps, Dev, they were kind of on the border, but it was really clear, hey, this is really cool. They really thought about how to make it easy, how to make it obvious, how to lower the bar and how to make me more effective. And it's really cool to see more and more tools to the point that I believe that now, like anybody building developer tools, if they don't think about developer experience, they're not going to be successful; we can't go back to like a super hard, like tools to use. I think nowadays that's something you have to think of first. And then build your own products on top of this experience that you want to provide.

Tim Butara: And we'll talk a little bit more about tools in just a little bit, but first I want to take a step back and just maybe adopt more the business perspective and talk a little bit about the main challenges today that businesses face in building strong development teams in the current economic and business climate.

Ramiro Berrelleza: Yeah, that's a topic that you can imagine as a CEO of a company that builds tools for, you know, developer experience automation and productivity. That is a topic that we talk a lot, with decision makers, internally. It's challenging. I mean, it's always been challenging to build good dev teams because it's, you know, it's a challenging job, you know, we do things that are complex.

But in terms of kind of like where we've been discussing one of the biggest challenges that I've seen kind of happen today is trying to figure out how can I make my developers effective, how can I help them achieve high velocity, but at the same time, you know, give them the freedom to build and create, but also as a business, how do I make sure that they stay within, you know, what the business needs.

For example, you know, one of the times I've seen in the past is when you have multiple developer teams, and then every team is trying to solve the same problems in isolation. How do we approach the production? How do we get data from a database to the next database? How do we design APIs? What I've seen lately is like this, this whole emergence of what now is called platform engineering, which is helping kind of like canalize these efforts so that you have one team who's focused on kind of solving these common problems. And then that way, the rest of the teams are free to focus on the problems that are unique to their team.

For me, that's a challenge because when done well, you can see teams really gain speed by not having to carry, you know, all these decisions with themselves. They're kind of operating from a common set of standards, sandboxes, governance, all those things. But if it's not done well, it's a balance, like if it's not done well, you can see teams that are slowed down by this common things that don't quite work for them.

And that's when you see teams kind of having to circumvent the rules to invent their own thing to kind of hack around the process. And that's very challenging because there's no recipe for this. And, you know, every team, every organization needs to find their, that good medium point where you give them enough, you give everybody enough tools, you take enough decisions out of their plate for them to be effective, but without being too heavy handed.

It's a challenge, but it's something that, you know, the industry is right now discussing a lot, which is exciting because it's like definitely something that everybody, you know, wants to go faster, everybody wants to ship value as quickly as possible. So we're all aligned on that goal. How we get there, that's when it gets more challenging, and it's interesting. And that's where tools, frameworks, practices are emerging to help us manage all of these things.

Tim Butara: Well, and one of the most important set of tools that are emerging that we really need to talk about in this context is obviously the emergence of new AI tools, specifically generative AI tools, stuff like that.

And these are already making a huge splash in the world of software development. So, let's talk a little bit about this. So how are all these newly emerging AI tools impacting the job of developers and the future of developer experience? So obviously we're talking here about stuff like Chat-GPT and GitHub's Copilot. I think there was a study by McKinsey done recently that also broke down a lot of really interesting insights related to this. So let's talk a little bit about this.

Ramiro Berrelleza: Yeah, that study by McKinsey was super interesting. When I read it the other day, it really kind of like caused a splash. And there's been like a lot of conversations about that. I think it goes very aligned with what we're saying before, around today, a lot of what AI does is around taking things outside of the, of the developer's purview stuff that they don't have to worry about, right?

And for me, one of the biggest benefits of things like Copilot when I've used it is, hey, I'm now not spending time writing all this very repetitive code, all this scaffolding, you know, you can operate at a higher level of explaining, hey, I want you to do this, I want you to give me a piece of code that does X, Y, Z. To me, that's very powerful because in the past, you know, you have to, like, sit and think, and then you're writing the code, and, you know, you're doing more things, and you have to write the code, you have to think about it, you have to think about the solution.

Now with these tools, and what we're seeing today, I believe, is kind of just the beginning of a massive shift. I think we're going to start seeing all these tools where more and more of these non differentiations are taken care of by AI, like writing code to go retrieve things from a database. That's not what makes your business great.

So if we can automate that, then you can move faster. It happened to me the other day that I was writing this code to kind of like go over our data warehouse and extract some data. And it was a mix of Python code and SQL queries. And I figured, okay, let's just, you know, open Copilot. It was Chat-GPT, actually. Open Chat-GPT. Say, hey, Chat-GPT, I'm trying to do this, x, y, z. This is the scenario. Kind of send some prompts. And then when I got back, it was like this very refined queries. And some code examples, which it wasn't exactly what I needed, but it got me 85% there.

So instead of having to start from zero and think and try to figure out how do I do all these queries, try to remember the syntax for some of the things I was trying to do, I started at 85, which means that now I can go a lot farther with the same of the resources than what I could do before. And for me, that is the beauty of AI. I think to answer your other question the impact on DevX is going to happen when we no longer see AI. I think that's something that, you know, kind of like the thought sphere aren't talking about this, is how today it's very visible, it's hot, it's new. We see kind of like everybody talking about AI.

For me, the interesting shift for the experience is when you don't realize when you use it. It's there. It's a tool. You don't have to opt in all these special AI model. No, you're writing code and you're going to get suggestions, you're going to see a bug, and you're going to get like a... right there, you're going to be able to like get a prompt and kind of figure out where the bug is and solve it.

I think there's a lot of like very interesting possibilities there. And I believe they're already aligned just the same as the DevX movement around reducing developers' toil, reducing cognitive load, making it easier for developers to focus on solving the problems that are unique to their business and not solving over and over again this kind of common set of problems, like how do I query for this data? Or how do I, you know, write a REST API on Python? Those things are done. We don't have to spend so much time on them while we could be spending time on, you know, pushing whatever the frontier of tech is for your industry. That's what I would like to spend my time. And that's what AI I believe it's going to enable us to do.

Tim Butara: The example that you gave of how you are using it reflects almost exactly a conversation that I had with one of our developers who said that the main benefit that he sees from his own use of generative AI while coding is that it's much easier to achieve and to enter this flow state because you don't have to lose time and energy. And, you know, the biggest chunk of energy that you would otherwise be able to give into like, like innovating and ideating, you would, you would then need to invest like, I don't know, 50 or 60 percent of it into just getting started. Just, you know, starting at 85%, as you said before, is then something completely different. And it just allows you to just instantly enter this state of, you know, of dedicated, committed work and ideation.

Ramiro Berrelleza: Yeah, staying in that flow is, it's a good way of putting it because that's what everybody, every tool that I use, every platform, you know, all the tools I use them for that, like the longer I stay in flow or any developer or anybody who's creating something new, the more productive you become and I think it's a nice tie up to the other question around productivity and yeah, it's all about this, like everything that - whether it comes from the developer, from the team, from leadership, anything you can do to kind of like remove the friction to let developers stay in flow the longest possible helps a lot in creating this kind of high performing engineering organizations.

Tim Butara: So maybe one thing that we could also talk a little bit about here is how too many meetings can negatively impact the developer experience and I'm guessing if, you know, flow state is so important for developers, then redefining the developer experience would also necessitate a revisit of how we approach meetings and how, you know, developers are involved in meetings and how, you know, what the real ROI and the really important thing here is, is it that somebody attends all meetings or is it that their flow state isn't interrupted? So what are your thoughts here?

Ramiro Berrelleza: Yeah, that's one of the never-ending debates in software. And others, there's this essay by Paul Graham, one of the founders of YC, talks about the maker's schedule versus the manager's schedule, and touched on this as a full essay on why developers should be, how you should build things and experience that developers spend a lot of time in the flow.

And he talks about it because, you know, it just takes a long time to get there. And if you're interrupted because you have to go to a meeting, or take... and it's interesting because it's always a challenge because meetings, you know, they have a place in business. You know, you need that touch point to make sure that, hey, are we all working on the same things? Are we synchronized on this situation?

It's a challenge that we have at our company where we're always trying to balance the interruptions versus the needs of communication versus the, you know, the needs of the business. You know, you're working on something, but suddenly there's an incident and somebody needs to take care of it. Like, why is the service no longer responding? Or there's like a high priority bug. So it's a challenge. That's something that I do believe that giving developers kind of just make sure they have this blocks of uninterrupted work is very important.

I think that's becoming even more challenging now with companies going remote because of, you know, things like Slack, Discord, they make it harder to kind of get that, but it is very important. It is very important from the company building dev experience to have clear, hey, these are the meetings I want you to attend. I'm a big fan of async communication. Like, they put things in writing, I use Loom a lot to communicate things through video, and then just kind of like share the links.

It's tough, but I do believe that moving to an async model of communication, which is what open source has been using for a long time, it's a good step towards building a dev experience where developers can have this larger blocks of time uninterrupted. It's something that every manager, myself included, struggles with because you have this need for information, but as we all build this new way of work, I'm again, same with AI, very optimistic thatas we build these new ways of work, we will make this more effective as async communication, the need for meetings starts to get lower and lower, which, you know, some meetings are not that useful, others are fantastic.

So knowing which ones to optimize helps. But we'll get there, but it's definitely something that what I, what I tell the team and what I tell everybody is one thing that's very important is for developers to manage their time as well. And if you need to shut down Slack, do it. If you need anything to kind of get into the flow, as long as it's done with proper communication. I believe it's a great step towards, you know, building this dev experience that has this flow and less interruptions.

Tim Butara: Yeah, I think some awesome points, especially here at the end about, like, knowing how to balance, knowing which types of meeting to optimize, being able to kind of discern which types of meetings are actually valuable and actually demand everybody attend them and which meetings could have just been, so to speak, emails, or like notes in a Google Doc or something.

And another thing that I wanted to ask you about are ephemeral development environments. So what are ephemeral development environments and how do dev teams need to adapt if they want to fully leverage them?

Ramiro Berrelleza: Yeah, ephemeral environments, you know, it's a topic, it's a passion of mine. My company does that and it's something that I've been working on for a very long time. And it kind of comes from the same need of flow. To kind of give you some context, the idea of ephemeral environments came from, you know, we all have done this, right? We're like, as a developer... and you said something about this earlier, right? You're spending a lot of time just getting ready to work.

In the specific case of ephemeral environments, we're trying to attack, like, all the time that developers are spending trying to set up all the info they need to work - databases, microservices, code; we'll call this Developer Experience Automation as everything the developer needs to kind of get ready to work.

Everywhere I've worked at before, anything from like, big tech to small startups has had this problem where like, it's a lot of work. You have to set this up. You have to figure it out. When somebody new joins your team, somebody has spent days explaining them, well, you use this VM or you run these containers, and then you go to this service and you get these credentials.

So the idea with ephemeral environments is: what if we, the same way we automated production, what if we were to automate all of this developer experience? Create a YAML where you define what this experience looks like, which services you need, which accounts, where you want to get data from, and then give you a single command, kind of like, to just spin that up for you.

That way you don't have to think about it, you don't have to wait for it, it's just there. And it's quite ephemeral because the idea was... Rather than having, you know, this handcrafted environment on your laptop, spin this environment up, work on it, and when you're done, whether it's for the day, for the feature, or whatever, destroy it, and then you just launch another one.

And for me, it's aligned with everything else we've said today, which is developer experience is all about getting you to the flow. And you don't get to the flow by, you know, trying to figure out which version of POS Orders I'm supposed to run, or, hey, I have node 16, but I need node 18. How do I install it?

The flow is by saying, hey, I want to work on this really cool API I'm designing. And you want everything else taken care of for you. And that is a principle of ephemeral environments. It's very exciting to me. It's something I've always wanted to work on. I've built different integrations of this in the past using other technologies, but not, you know, this new world where you have AI, you have serverless, Kubernetes, infra is now like so easy to spin up and it's really exciting to see a lot of what I was imagining over the years just happened and really it's all about making developers more effective in our case by having them not to worry about like this setup and, and just say, start it, build features and then ship them as fast as possible.

Tim Butara: Can you maybe share an example or two of how specifically you've helped your clients optimize their DX through your tool?

Ramiro Berrelleza: Yeah, no, of course, I think of a kind of like a good example. So one of our customers, LaunchDarkly, is a famous... the leader of like feature flags. It's a SaaS product that's broadly used across the world. And one of the challenges they have, or they had, is that in order for a developer, you know, when they joined their company, in order for a developer to work, they have to run this very heavy Docker compose file. And it was like, it was just like a lot of, we all can empathize with this, a lot of services, databases, different data stores, all that stuff.

And one of the concerns was that, hey, I want to make sure that when somebody joins, you know, they're like basically for startup, they're growing a lot. They were like, hey, when I want a developer to join my company, I want them to be able to, you know, like ship the first week. I don't want to have to wait a month for them to ship something because they're waiting for things to be ready. I want them to feel confident and ship fast. And as they were looking for solutions, they came to ours and then we talked with them and then we partnered with them and, you know, that's now what they do, is they have, you know, our product Okteto configured to use with their own stuff.

Which means that now anybody at the company can log in, click one button, and they have a full environment with like their entire product running, all their dependencies, data, services, other accounts, so that they can then focus on building the next big feature and then push, you know, that first week, which for them was very important because for them, going back to the topic of effectiveness, having a developer shift to production fast was a key metric of how efficient and how good the organization is.

And that's something we've seen across the board, like super interesting that we have customers in many different verticals, enterprises, hybrid startups, SaaS, small businesses, a bit of everything, right? And they have developers everywhere, even like government entities, and all of them constantly say how, hey, by not having to worry about this, by putting this out of my head, I gain time, I feel more confident.

Because now I have this environment I can use where I can run my tests faster, where I can like validate that things work end to end, it's all fully automated. So I know it's going to look just like production and that way they feel more confident, that way they can innovate faster. And, you know, as we've been saying, they can ship code faster and ship value faster for their own customers.

Tim Butara: I picture it almost as a kind of Swiss army knife, but for developer experience.

Ramiro Berrelleza: It is, it is. Once, once you see this, and I, when I got a chance to see how our customers fully implement our solution, it is really cool what you see, like, yeah, that idea of like one click, everything is there. And then the other thing we do is because everything is running on the cloud, not on your laptop, your laptop is no longer like, you know, running out of CPU, running out of memory, your battery lasts longer.

You don't have to wait for like, you know, I'll tap and then you have to wait because it's lag and VSCode and your debugger are fighting for resources. As you move more and more things to the cloud as you automate more of this, it's less and less things to carry on your laptop and on your head, which to me is the idea of like the cognitive load that developers have to carry or deal with when they're developing. Anything we can do to reduce that makes them substantially more happier and, you know, more performant.

Tim Butara: But wait, so you're saying that this also means that they're no longer able to have the excuse of it works on my machine?

Ramiro Berrelleza: That is my end goal with this. It's removing that from our lexicon. Not because it's an excuse, but because honestly... For me, I don't know, maybe for everybody else, but for me, my career, it's always been a source of frustration because it's like, it works on my machine. Why is it not working in production? And you know, production is always this black box. You have no idea what's going on there. There's no other thing like it. So then you end up having to engage in this super frustrating cycles of like, okay, it's broken in production. Let me add some logs, do it again. Let me add some more logs, do it again. And then sometimes it works and you have no idea why it works now. And you know, no one likes to ship buggy code.

Developers suffer a lot by shipping buggy code. Companies suffer a lot. There's all this research on how much time... one of our customers actually did some analysis and they discovered that for them, every production issue added something like five days of unplanned work. Because, you know, you have to like undo it, iterate, test it again, do it again, plus all the work you postpone.

So if we can get rid of that, like that's my dream, right? It's like get rid of the works in my machine. Make sure your environment and production are as close as it's feasible to reduce this. And to me, that's one of the big bets of ephemeral environments, is by giving you something that's very close to production, you're going to have less of these issues.

So you're going to have less cognitive load because you're no longer having to provision all this by hand, but also you're going to have less bugs because when you're writing your code. It looks more like the real thing. And then the jump from like Dev environment to production, eventually we're going to get it to like be zero, but right now it's a small jump, but it's a smaller than before.

And I believe that's already giving, I mean, I've seen it with our customers, it's already giving them a lot of like benefits. And, you know, it's funny how just the trust, like when you're a developer and you're like feeling empowered and you don't have to feel like, oh, well this break it or not, just that kind of developing a lot of trust makes you go way faster.

Tim Butara: Well, Ramiro, thanks so much for the great conversation, the great insights. Just before we wrap it up, if listeners would like to learn more about you or connect with you or learn more about Okteto, where would you point them to?

Ramiro Berrelleza: Yeah, I mean, if any of this resonates with you, if you want to talk about developer experience, about your challenges, if you want to get a sense of what we're doing, please reach out to [email protected]. That's podcast at O K T E T O dot com. You know, happy to talk. I love talking dev experience all day. I love learning how other teams, individuals are facing these challenges. So please, please reach out. And also I'm fairly active on Twitter. If you search for my name on Twitter or X now, I guess it will pop up. That's also a good place for us to connect and talk more about, you know, all these challenges in our industry and how, what can we all do to make, you know, all of us faster with less friction. And, you know, happier, happier developers are effective developers.

Tim Butara: Awesome. Perfect note to finish on, Ramiro. And thanks again. It was great having you with us today.

Ramiro Berrelleza: Thank you very much, Tim. Enjoyed the conversation.

Tim Butara: And well, to our listeners, that's all for this episode. Have a great day, everyone, and stay safe.

Outro:
Thanks for tuning in. If you'd like to check out our other episodes, you can find all of them at agiledrop.com/podcast, as well as on all the most popular podcasting platforms. Make sure to subscribe so you don't miss any new episodes. And don't forget to share the podcast with your friends and colleagues.