Developer Experience - Why is it So Important Really? Dan Leshem, Creator - Dark Mode, and Yshay Yaacobi, Livecycle

Episode Transcript תמליל הפרק

Hebrew, then English* בעברית ואז אנגלית:

(*Translated with Google Translate - so there may be some errors. Please also bear in mind that Hebrew is a gendered language and therefore anything that is noted in a specific gender is intended as neutral and not gender-specific.)

 (opening music)

Welcome to the second season of Dev Interrupted, the Hebrew version of Dev Interrupted, LinearB's podcast for engineering managers. Where we will host leaders in the industry and talk with them about everything that interests engineering managers, those who work with them and those who might want to manage an engineering organization some day. This season we will place a special emphasis on developer experience. I'm Yishai Beeri, CTO at LinearB, let’s get started.

(transitional music)

Yishai: In this episode I am happy to host Yshay Yaacobi, co-founder and CTO at Livecycle, Hi Yshay.

Yshay: Hey.

Yishai: And Dan Leshem, the Creator of Dark Mode and founder of FineDev, ahalan.

Dan: Hello Hello.

Yishai: How fun to have you here.

Dan: Great fun.

Yishai: So as usual I will start by asking everyone how you got to this point, come on Yeshi, tell me a little about your career and how you got to where you are today, CTO and founder and partner at Livecycle.

Yshay: Okay, I'd love to. So actually I always loved programming, it was something that really interested me even from a very young age, both when I was a child and later in high school I took another computer track, in the army I got to dabble a bit in programming, also in such a role of computing, and after I was released I actually started working in a company that was involved in building websites and also a little in the world of mobile and social, and in fact my really big connection to the profession was that I started at Soluto. I was there for 8.5 years, where I got to work in almost every role in terms of technical roles. As a developer, frontend, backend, DevOps, architecture, and so on I also really fell in love with this world of developer tools and everything related to the developer experience, and after being there for 8.5 years I decided to start a company. I did it with two partners who are good friends, one I met at Soluto, who worked with me, the other friend I met indirectly through Soluto because his wife worked there, and that's how the journey towards the Livecycle began, which we've now been in for about two years, and it's really a company. I'll talk about it in more detail later, that deals in this world of how to really improve the lives of development teams.

Yishai: So basically you were a developer in all kinds of positions in the technical worlds and then you jumped to starting a company, where we will build this, let's build something new.

Yshay: By and large, yes, entrepreneurship has always interested me in general, I've always loved creating, this thing of building things. Even when I worked at Soluto, it was always an area I was most interested in, like entrepreneurship and creating projects, but yes, the big jump was the moment I left Soluto to establish Livecycle.

Yishai: Well, then we'll hear more about Livecycle and go deeper, Dan, tell us about your career.

Dan: Well, I owe my tech career to Harry Potter, as a child I was a Harry Potter freak and I wanted to set up a website, so I read Harry Potter in the library and there were programming books next to Harry Potter, so I learned PHP that way and set up the Harry Potter website and I rolled from there. A year later I already started dabbling in website development and from there I've been doing it for 15 years, as a manager of development teams, I was at OrCam for a few years, I managed the mobile team there and that's it. I'm also an entrepreneur in my soul so I founded, after OrCam I founded my startup, we did some chatbots for customer support, we had a good run of two years and closed and that's it, today I do Dark Mode and other things.

Yishai: So come tell us a little about Dark Mode, what is Dark Mode for those who don't know?

Dan: Dark Mode is a network series about the developer experience, about the development experience and the engineering culture in companies here in the ecosystem, in Israel. Actually, a year ago me and some friends heard about developer experience, we heard about it a little from (engineering organizations like) Netflix and we heard from Spotify and we heard that there would be some hype around this thing and we wanted to double click on it, understand what is there, and we started importing this concept to Israel,. While we were researching - an idea came up to do a network series together with companies like Wix and AppsFlyer and Ziprecruiter and Taboola and some other big names here in the industry. That actually in this framework we came to them, to their offices, sat with all the developers for hours, I think we had almost 80 hours of content that we recorded with them and many more hours of investigation, and we wanted to understand, as it were, problems of programmers, as this world is so complex. What is developer experience really, what is there? So we heard from them and in the end we took all 60, 80 hours of this content and shortened it to 10 episodes, each episode 10 minutes. We had very, very difficult editing work, that's it, and each episode focuses on a different content world, at a different stage in the development process .

Yishai: And what kind of responses do you get to Dark Mode? Okay, there's a series, who's listening to it? What do you hear, what impact does it have on the world, on the industry here?

Dan: The truth is that the feedback I hear and such makes me say okay, there is a return for all the investment we put into this thing. The fact that ICs come to us and tell us listen, it changes the way we work in the company. It's as if you gave us ammunition that we can then send to our managers and raise awareness of the developer experience within the company. We are suddenly aware of these things that slow us down, that make us uncomfortable, all these things that are like some kind of gravel in the shoe.

Yishai: So in Dark Mode I will find an echo of what hurts me? Here, it also hurts others, here, we give it a name? Or will I also find solutions?

Dan: Both and, it's mostly, mostly you'll find an echo, and you'll get a little taste of how others solve this thing, what others face and what can be done. Mainly a basis for discussion, I would say, within the team.

Yishai: Ok, so ICs can bring it into the discussion and say I'm not making this up, it hurts others too, there is a name for this pain I feel. What is the next step? What’s after Dark Mode? Is there a series? Where do you take it next?

Dan: So maybe Dark Mode might have a second season, I don't know, it was really a very long project. I personally continue to work within this world, I am now working on a new venture, FineDev, we want to help developers make better architecture, together with AI.

Yishai: Ok, so is FineDev a product? Is it a community?

Dan: It's a product.

Yishai: Now that we know the name, give me the pitch in a few words,

Dan: We know the cost of bad design, right? We will probably also talk about it, also in the context of developer experience apropos. And, what we do, we actually connect to the existing codebase and through AI turn empower every programmer to become the architect in them and help make a more correct architecture, a better design for his code.

Yishai: I mean it connects to my codebase and understands the current architecture and from there recommends what to improve, what to change?

Dan: Yes.

Yishai: Walla. What areas of the code? My Terraform? Things like that or the actual applicative code?

Dan: Right now the actual applicative code, i.e. what you came up with in your repository, later we might also connect to the cloud. Yes, it's still preliminary, experimental, but we're excited for it.

Yishai: Excellent, so Yshay you mentioned, we talked about the fact that you are the founder of Livecycle, come tell us a little about what it is, what Livecycle is, what you do.

Yshay: So Livecycle is actually a SaaS product designed to allow development teams to work more efficiently, there are actually two components here, one component is the infrastructure component. Livecycle actually builds preview environments from a repository, where the goal is for every PR to have a live environment where you can experience what's happening in the product. In a visual product, this thing gives a lot of power to how you can do a review in a better way. Because many times let's say if I do a code review on something visual, I don't see it with my eyes. I don't see what the problem is, where are the bugs, I mainly see text files. And beyond that, in a visual product we want to maybe bring in the rest of the team, it could be product people, it could be designers, it could be QA for the review process at an earlier stage, long before staging. Basically this is how we can do that while the developers are working on the PR, they are already starting to receive the feedback as they would receive it from developers, and they don't have to wait for it to reach staging or use a feature flag, everything can happen much, much sooner. And the goal is to save a lot of ping pong in the end, developers know this, ping pong that happens a lot between development and design people, for the product. And the ambition is that as soon as -, actually to solve this problem there are two elements that we integrate into the product. One is how we make accessible what happens in the code, actually in these preview environments, and the second problem is how we create better communication. In order to provide better communication, actually in preview environments we actually implement tools that are embedded, such as in the overlay, that allow us to propose changes to copy, CSS changes, record images, draw, record videos, and basically create such a thread of communication that the whole team can communicate within it, which is also really synchronized with Pull Requests or Jira Tickets which is connected or to a LinearB Ticket or Slack or whatever, the tools that the organization uses.

Yishai: I understand, so you actually identified a pain in this area of engineering building something and then the design or the product basically tells us it's not what we wanted or it's not what we intended or it's not exactly like in Figma. And it happens at a relatively late stage of the development or we have already put it, deployed it to some kind of environment to show, because this deployment is sometimes expensive and the feedback comes late.

Yshay: True, and actually as a developer I receive a lot of context switches and the ambition is that I can receive the feedback at an earlier stage, in a more orderly manner, not even with many tools that sometimes it appears in my Slack, sometimes it appears in Notion or Jira or in any other form,

Yishai: So everything is focused on PR basically.

Yshay: Exactly, like we do with the code review, because let's say this process of the code review we feel it works very well––so if we make changes to the product that are more let's say visual, like it doesn't have to be but the case of a visual product, to see it with the eyes, it is very clear and very easy to explain to customers what they are getting in this situation.

Yishai: Yes, this is also one of the areas that gets the most late feedback. Because when you do the demo, then everyone has something to say and in many cases it's "excellent, but this button should be green". By the way, in many cases the feedback is about the product, not about the developer, but it always comes down to changing something. Now you have to write new code or change the code because basically we decided that the button should move or the text is wrong or

Dan: The truth is that it is interesting because one of the things we discovered in Dark Mode while we were doing this research - this issue of developer experience and somehow many of the problems in DX are actually communication problems between the product and the programmers. Like it's incorrect definitions of a product or this circle of the feedback loop, which goes to the product and QA and returns back to the developer, and all this in the end complicates the whole process even more.

(transitional music)

Yishai: So I want Dan to use, you mentioned this term DX, let's dive in a little bit, let's try to understand, what is DX in your eyes? What is developer experience?

Dan: When we started researching this story of DX what we saw, if you search now what is DX on Google or ChatGPT, you will get a response of,  it's like user experience, but for developers, developer experience. I think that this definition is a bit lacking, something whose name is not entirely clear to me, what does user experience mean for developers? The first question that is asked is why even talk about the experience of developers? We need to, we are a product company, we need to talk about the value we give to our customers, and that is what is important. And I think where things start to connect is that you realize when things start to move more slowly within your company, and the developers take time to do their task or are too busy with the infrastructure., and everything is a little slower or depends on many factors and other people, this is where this developer experience starts to break down. This is where in the end you see that it also affects the value you give to your customers. Because things start to move slower, things are more cumbersome, and in the end the one who gets hurt by this is your customers. There is, I don't know, maybe our listeners already know, but there is the famous McKinsey study that showed that companies whose programmers' productivity is higher, in the end show a higher profit line or 4 or 5 times more performance in revenue, so maybe I didn't answer your question what is developer experience, but we started talking a little about why developer experience.

Yishai: Okay, so you say how easy or difficult it is for developers to generate value on an ongoing basis, then you say at least in terms of velocity and productivity, if the experience is not good, the company will move slowly, a company that relies on development and technology will be harmed.

Dan: Yes.

Yishai: Yshay, how do you define developer experience?

Yshay: I also think that the concept itself is still not completely clear, as if we can talk about something that is closer to UX where we talk for example how a terminal or API should look or documentation, but I really connect more with the direction where we look at the pain that developers experience on a daily basis, and actually how do we turn it into something that is easier. Actually as a developer, and I think everyone who studied software at some point gets burned, experiences this thing that you learn how to program, you learn how to write an application, you learn how to write code, but a lot of the problems you're going to deal with in life are not related to that, they are actually related to things that may be related to delivery, or release, maybe even source control, working in a team, code reviews, bugs in setting up the environment, a tool that doesn't work. And in fact a lot of our day-to-day life is like surviving among a lot of tools and systems and navigating between them in such a way that we are still productive, that we wanted to do something and we managed to get there and not as if we ran into a lot of obstacles. And it could be anywhere, it could be say in production that it's hard for us to debug a problem or we can't monitor something, and it could be that our IDE doesn't work because of some extension or because of some plugin, actually our day to day as developers is such a minefield.

Yishai: I only have one line to fix, I know exactly what needs to be changed in the code, but to bring it to a state where it is really tested and works in a local environment and then I was able to deploy it in a staging or QA environment, is 100 times more work.

Yshay: Yes, and in my mind developer experience is a lot about how to navigate these things, how to reach a situation where the experience of the development team is very optimal to develop, to produce this value.

Yishai: So why now? Let's say we've been developing software for decades, probably 15-20 years already in cloud worlds, worlds we'll call a bit more modern, why now suddenly we're starting to hear about DX, why are we suddenly there, a name was created, it's interesting to do a network series about what it is, What changed?

Dan: I think everything has become more complicated. It’s complex. We, like when I started writing code 15 years ago, you'd write some HTML, open an FTP server, and that's it, you'd do delivery. And today there is only this CNCF poster of the tools, I think last time I checked it was 1,117 tools, it must have gone up another thousand or so since then. And it's like it's getting complicated to develop software, there's a lot of context that needs to be maintained, the systems have become more cumbersome, and finally you, what you said a moment ago, as a developer you just want to change a small line and you come to do it and you find out that you're wasting two weeks.

Yishai: You say it gets more complicated, what, it's microservices? Is that the big name in this complication? Because in the end we moved to the cloud, it should be easier, we moved to Source Control and Git compared to Subversion and CVS and all kinds of pre-historical tooling, it should be easier, simpler. Today, at the price of deploying and doing a reversion to it compared to 15 years ago, it's much simpler, much easier to protect yourself, on the other hand, you say it's much more complicated.

Dan: Yes, I think much more complicated maybe for several reasons, at least in my perception. The first thing is that you have crazy fragmentation of tools, like this DevOps that brought the tools revolution, it's probably worth it in the bottom line, I can't really say. But eventually you find yourself dealing with so many tools to do something and you want to F5, refresh the browser and see it happen. This process is as if fragmented in a very, very complex way, and I think it makes it difficult for everyone.

Yshay: Yes, I think it also stems from, firstly, the fact that developers today are much more owners of things that in the past they didn't bother with. I mean, today developers, certainly of a product, sometimes a developer can be fullstack, they also deal with frontend and let's say backend, DevOps, this is also something that developers today do touch. In the past, developers didn't necessarily touch production, as if it was something that was very empowering, but on the other hand, it suddenly becomes - as a programmer, I now have to take ownership of the quality of the product, of it working well in production, of monitoring it, of many things that used to be out of the scope of development - he was not the owner of it. Now it comes together with a field that is very developing and in fact also within a lot of different tools, but as if none of them have yet, as if it has not reached a state of maybe stability that will become like a standard. Even let's say on the back end we see it all the time that now basically the whole stack is actually being built again around containers and Kubernetes, you can say that this also happened in the frontend around the frontend frameworks that are constantly changing and I think there is an evolution here that is now very good, it is very interesting, it allows more, because the demand is also what software can do and where it enters and we will be more everywhere, developers enter in every corner, from the front end to the back end and dev-ops, and this system is very moving and while we are moving there is a lot of mess, things break, things may move.

Yishai: So the developers got a lot more power, but that power complicates their lives and now a DX challenge is created. So what, developer experience solutions take a step back and say I'll make it simpler for you, I'll take some of the power or some of the responsibility away from you, so that it flows easily for you? You are no longer responsible for Terraform, for infrastructure, for deploying, make a change in the code and you already have a system that works? That's the spirit?

Dan: I think that when we come to do good DX, we need a moment to think about what we are trying to achieve, maybe we can really try to define a moment together what good DX is. In my view, a good DX is something that allows me to do my task, and give value to my clients without having to worry too much about infrastructure or dependencies among other things. I want to set up my task, set up the product and get in and get it done as quickly as possible. I think that everything that takes me on this path as quickly as possible, without me now having to dive in and understand what Kubernetes is or without me having to even choose Serverless or not Serverless, like anything that will help me give the value faster to my client, I think that takes me one step forward on the way to better DX.

"In my view, a good DX is something that allows me to do my task, and give value to my clients without having to worry too much about infrastructure or dependencies among other things." - Dan Leshem

Yshay: Yes, I completely agree, I think in the end, when I look at DX it's more things that help control this complexity so that it doesn't bother me, or things that eliminate this complexity. That is, we found another way that is simpler and now this flow is easier and simpler and I don't get the penalty of tools that are very complicated because in the end the more powerful and more enabling the tools are, many times they come with another penalty of complexity.

"In the end the more powerful and more enabling the tools are, many times they come with another penalty of complexity."  - Yshay Yaacobi

Yishai: And does that mean there is another team? Is there someone else responsible for this complexity for me? The DevOps team or Platform Engineering?

Yshay: Platform, yes.

Yishai: They actually build cookie cutters there and make sure that I can only make the change in the code and everything else flows?

Yshay: So this is a question, in my mind it depends on, one of the things that seem to allow teams to move quickly is that they have, let's say, a very high autonomy. Now the platform team can help them but if it suddenly becomes a bottleneck, if they can't do things themselves and get there faster, then suddenly you've created a new problem. As if in general I was, I am of the attitude that I would try as much as possible to cut off a team's dependence on an external team, but this comes together with the fact that how will this team get, for example, the knowledge or certain tools, many times it can also be tools that are open source, not necessarily tools within the organization, so that he doesn't have to deal with these things all the time.

Yishai: Say Dan, what did you see working on Dark Mode and actually encountered or talked to a lot of developers about these pains, can you highlight what are the points that came up the most? That rose most strongly? That different companies repeatedly encounter the same problem? Where are the big pains of the DX?

Dan: So really after we finished the project ofDark Mode, we transcribed all our conversations with developers,

Yishai: Did you do a word cloud on this thing?

Dan: Yes, we did a kind of word cloud and mapped 81, we call it DX killers or DX blockers, 81 things that everyone complained about. Stuff repeated more than 3 times in our conversations with developers, and there was really everything from everything, we were very, very broad. It wasn't just in the infrastructure, and I think I can reduce this thing to 5 things, into 5 general categories. The first thing is probably everything related to infrastructure, I don't want to mess with logs, I don't want to mess with connecting to a database, I don't want to mess with, I don't want to be a DevOps person. I don't want to know what Kubernetes is and I don't want Helm Charts and I don't want Terraform. Please let me write code, let me do a git push, and let it find its way to production. So it was a lot of DX killers in this category. Other things, we had coupling, as soon as I depend on my work, as soon as I wait for a code review from someone and it takes a little too much time, as soon as I depend on someone to coordinate my work with, it's frustrating, I wait again, I do a context switch, I'm going on another mission.

Yishai: Are you talking about coordination at the level of I have to have his component ready before I can write mine or before I can deploy? Or do I really need input from him about my work?

Dan: So both and, and things in the style of someone breaking my API, I make some kind of change and someone breaks it for me.

Yishai: It never happens (laughs).

Dan: This has never happened to any of us. So coupling, and another thing we heard were problems of knowledge flow. In the end, a lot of the problems we have, also the dependencies, is that I just don't know how to do things, I don't know how to run this pipeline.

Yishai: Ok, so discovery of who is responsible for this, where do I even find an answer to questions about what this service is, who is responsible for it, who knows how to change it or who knew how to give me feedback on what I do there.

Dan: Yes. And the last thing we probably had, and that's why we rolled into our startup, was design problems. That in the end I have a hard time with the code or every task feels like a new adventure to me because I have to deal with some kind of legacy or technical debt that I took or a design problem and I don't know, we made some wrong design decision and now we are dealing with it for a year, two years, three years ahead. So this is how we mapped the world of DX.

Yishai: You say all the places that I pay the accumulated technical debt or the truth is that I only pay the interest.

Dan: Yes exactly.

Yishai: And dealing with problems that they may have made a decision that was right at the time, but now I'm paying the price they took then.

Dan: exactly.

Yishai: And you also mentioned this seam between product and engineering.

Dan: Right.

Yishai: Requirements what, not clear enough?

Dan: Requirements are never clear enough, it is never clear what the definition of done is.

Yishai: Acceptance.

Dan: Exactly. Deadlines, which is a topic in itself, wait, are we doing tests? Are tests considered within the deadline? It is not considered within the deadline? Is the monitoring included? Is it out of scope? So all the friction around the definition of a product can also slow us down a lot.

Yishai: And since we see that this world of DX is suddenly gaining visibility and acceleration, from your experience and your work, in Livecycle it must be in front of customers or prospects, how do you see this change in organizations, in terms of, suddenly there are owners? People that's their job? Are there VPs of Developer Experience? How does this change happen?

Yshay: We see that there are more developers who are platform engineers, who can usually be the customer for our product. We see that there is simply also a much greater awareness of this matter, meaning that those who deal with delivery questions then deal with where the developers are actually wasting time, where there are ping-pongs. What makes them reach as high an efficiency as they can reach, and a lot of these things are really around or things related to the architecture that we really see being talked about at a more advanced stage, meaning that we talked to companies so all the questions that for example if it's a monorepo or how many repositories or how to do CI/CD Or all these things, actually everyone is dealing with these questions, they are questions that seem to be interesting because in the end they want to optimize their delivery process in order to push the business value as quickly as possible. So it seems like it does feel like something that is always interesting at the VP R&D level or even Also, I would say even at every level, even when we talk to the developers themselves these issues,

Yishai: You say that there is awareness and platform engineers are getting more and more tasks or emphasis related to DX, you see but also people who literally seem to define roles around DX? And someone who is an owner?

Yshay: I haven't come across this yet, but it is something that even if it's not within the scope of a job, it's something that happens, maybe the tech leads deal with it, maybe the platform engineers, sometimes it's even DevOps, it's very

Yishai: They are busy with it even if it doesn't always have a name, and it is not called in the title.

Yshay: Yes.

Yishai: What do you see Dan?

Dan: I actually see that it is something that flickers from below, usually there will be some kind of champion within the company, it will be some kind of maybe even IC or team lead who takes it upon himself to raise the awareness of the issue of DX within the company. Then we see it in several ways, or that it really comes from below, and there is someone who is now the owner of it and this is added to the position. Or there are actually teams, we have seen companies that actually have a Head of Developer Experience, in some companies it is called Platform Engineering, in other companies it is a team that is only responsible for the - CICD, say at wix, their DX team is mainly responsible for the CI/CD. In other companies they are also responsible for the training of the developers, that is, it is a very, very broad field, not so well defined, changing, it is converging towards of platform engineering, of infrastructures, and this is what we see, and another model that we see is something in the middle of guilds, we see many companies that are now establishing a guild whose area of ​​responsibility is developer experience. To locate the problems and find solutions on an ongoing basis in order to increase the productivity of Developers in the company.

Yishai: Have you come across or heard from people, developers, maybe seniors who are starting to look at developer experience as another input when they decide where to go to work? I mean I'm going to work where the experience is good? Or there used to be Joel Sapolsky's 12 points, in the early 2000s, you can already see such a trend that people say I'm going to work where they solved the XYZ and the experience is good, I can mainly focus and not bother with these pains.

Dan: I can say that we are seeing a trend perhaps, the same trend but from its other angle. That we see companies that invest in developer experience and that's how they attract talent or the reason they invest in it is to increase the retention of their employees, even in the current climate.

Yishai: So they feel that employees leave or choose also on questions of developer experience.

Dan: Yes, and I think it also ultimately makes sense because you don't want to get up in the morning and feel like you're struggling with your code to get the task done. You want to feel that you are solving problems, that you are giving value to the company, to the customers. You don't want to feel that you are fighting with the logs and you are fighting with the infrastructure of the data bases or that there is a lot of friction, so companies work to reduce this friction.

Yishai: Also for questions of hiring and retention, not only for productivity to bring out the value, but they also understand that the developers are starting to look at this as another parameter in their decision.

Dan: Yes, and if you ask me, I think that might be the number one reason to invest in developer experience. In the end, it's like we're constantly busy, isn't it, all our companies are busy increasing velocity, that's what we want to improve, and if we want to improve velocity, probably one of the most significant ways to do it--I put a question mark here, you are welcome to say In your opinion--it is simply to increase the, that employees will stay longer in the company, as if in the end when an employee leaves after a year and a half or after two years, he takes knowledge with him, he takes methods with him, whoever enters his code later will do rework or something refactor. If we can influence the retention of an employee in a workplace through the developer experience, through the fact that we give him the right tools and infrastructure, we have gained, we have improved the velocity.

Yshay: Yes, I think that developer experience also comes with a lot of people, as if together with the higher ownership that developers have, and in fact also the ability to give much more impact, and these things really help with retention, in the end if I am not able to brainstorm or release in my day to day Features or I feel like I'm messing around take care of And not mainly, so these things have an effect. In addition to that, a lot of the developer experience also comes with the use of stacks that are more modern, say, that already thought about developer experience in the early stage. Let's say if I look at the front end, you can look at Vite and tools that are becoming very popular today that take care of it for example that hot reloading will be really fast, like really fast, it wasn't fast enough before, we're going to improve it. And developers often do not like to feel that they are left behind, that they are, say, developing with tools that are old, just as they do not like that there is a legacy or things that are slowing us down. So I think all these things come together and in the end it seems like an organization that these things are ticking and that it can also do some of these things is to see how many changes you can introduce to the organization to improve the developer experience, because it's not something that ends. So the more the organization invests in it and the developers feel it and feel that they are also undergoing a kind of evolution in how their ability to make an impact or in the tools they use, then they stay longer in the organization.

Dan: The truth is that one of the companies we were with inDark Mode She shared that at some point they decided that they simply rewrite their entire codebase, they switched from Angular I think to React, because they saw that they had a problem recruiting people, because people said we don't want to work in Angular. Like it's not a base code that I want to get into, and they just made the decision and worked for two weeks so that from now on it will be possible to put React code into their framework.

(transitional music)

Yishai: Towards the end, I would like to ask you how developer experience is measured, how do I know if my situation is good, not good, has improved, do you have any ideas on how to measure it? Besides asking everyone, are you satisfied and getting answers like that from the gut?

Yshay: You can look at delivery metrics, many times as said, the ability to release things to production usually requires a good level of developer experience because otherwise things are simply stuck. Maybe also look at how long it takes for a review to be happy, like you look at DORA Metrics say in a world of DevOps, I also think about it at the level of principle and also something that you feel talking to the team, if I look at Daily and I ask people about DSM. Everyone tells what they have been through, then suddenly several times they say I messed with something that I shouldn't mess with in such a nervous manner, the environment I got stuck, I couldn't release anything.

Yishai: Okay, so you're saying a combination of metrics on the delivery process, we all here assume that a better developer experience is aligned with the ability to work faster and more frequently, perhaps also with higher production confidence. And combine it with simply asking people, hearing what they are frustrated about.

Dan: I think that, I want to connect with what you said, I think confidence is the key word here. We want to measure the confidence we have in making changes. In the end, the better my developer experience is, the more confident I feel entering the code, making changes, it goes hand in hand with other things like tests and other things, but confidence is something that is important to measure. This can be done using a simple Google Form. And the second thing I think, is sub-context here. Because there are so many problems with DX and there are so many things that can go wrong in the development process, it is very important to ask questions that are contextual and specific. In other words, because in the end the problems in DX are hidden, it's in the small details. It's that the logs, I had a bug now, and my logs were on the face, It slowed me down. I had to make a new feature and it took me a lot of time to set up the infrastructure of the database and the microservice and I needed approvals from here and approvals from there, I think that contextual questions will help us overcome the problems we have in DX.

Yishai: But if I look at a slightly larger organization and someone, even VP Engineering looks and says wait, I hear from the field that there are problems, I want to make an orderly investment in the developer experience, maybe even appoint a team and tell them they want improvements. How do I know after a quarter, after two, that we have improved? As if people will always complain and there is always something to improve, it will never be perfect, so how can I create a baseline for myself or some kind of understanding that is a little based on data that says voila, we started, we invested and it's worth it, just questionnaires? Just asking as if to ask people their opinion? How do I do it at scale and with confidence that I'm doing it right?

Dan: It's a good question, I think questionnaires will help you understand where the problems are, and in the end you'll have to determine some kind of metrics, I'm not sure that DORA Metrics is like the metric I'd use to measure developer experience, because I feel it's a bit too narrow in developer experience. But surely this and maybe other metrics that are contextual, that is, if I now have a problem with CI/CD, then I will measure it, and if I know that my problem is in the infrastructures, then I will perhaps create some kind of specific metric for this, I think that in the end it does depend That you ask the people.

Yishai: So maybe I can produce some, talk about a vector of I don't know, say 10 different metrics, in some organizations these metrics will be great, but flakey tests I can measure, or how long CI/CD takes to run.

Dan: Yes Yes.

Yishai: And I can say okay, for me it takes 20 seconds, everything is fine, if it takes me two hours I'll probably eat it in the developer experience. If the flakey tests are above X level, I should probably invest there. So do you think it is possible to capture with enough slams an interesting space of DX or should always go to forms and questionnaires as well as the software.

Dan: This is a question, like if possible, at the end of developer experience it touches people. So the question is whether it is possible to bring here some hard metric that will indicate, that will say whether our DX is good or not, I don't know.

Yshay: I also think of it in a similar way, meaning that a lot of these things are also really relative. So I can say for example a slow CI/CD, if I managed to improve it then as if I had already made a very positive impact here. But in the end it's like, I don't know if it's the thing that developers seem to dwell on or if now it's still fast enough, because in the end it's also an individual matter, I can say that now 10 minutes CI is slow, and someone else can say that a minute is slow.

Yishai: Depends on what he got used to.

Yshay: Yes, and there is a lot of interest here that is from an ongoing process. I do think that as an organization a lot of the questions that deal with what frustrates people will be things that can be pointed out because people will report the same problems. If for that matter, for example, the environment is complex and difficult, let's say setup for a new position. So I'll say something that the way I would measure it later if I were to get into it, it's just new developers, how long did it take to do onboarding to their environment for example. If my problem is related to analytics or monitoring or the Ribio code, then anything like that can be talked about specifically Do a metric and see it, but in the end the whole organization suffers as if it seems to me that things are a bit different then,

Yishai: Yes, you talked about 81 points, that's already a lot, and it's hard to talk about such a space of dimensions. To me, this is a super interesting question, the ability to say here, there is some kind of set of best practices or a set of benchmarks even, again, I return to Joel Sapolsky's example, you can perhaps imagine 12 new points that are related to the developer experience, and that they will catch most cases, It will never capture everything, but it gives a picture of what's going on, it's probably problems or challenges that are common to most development processes, and now each organization might also add questionnaires, maybe even a microservice, tell me how you felt about this specific task, now.

Dan: That's really the point I think, yes.

Yishai: And do you think the developers like to give feedback? Will they cooperate with such questionnaires? Will they really give what hurts them? Or they'll say it's bothering me now, it's another problem in the developer experience, who are pestering me with questions about how it was.

Dan: You know, I think it depends, I think that developers actually like to give feedback, obviously you can speak in generalities and there are and there are, but I think it really depends on what they will do with this feedback.

Yishai: I mean if you ask then do something with the answers.

Dan: If you're asking then do something about it or at least reflect on why you're not doing it. As if there is a lot here, there is a challenge of communication here, the truth is, we talked about DX teams earlier, so when we met them, these teams, we hear from them that there really is a challenge of communication. There are 500 problems, why are we working on problem 7 and not on problem 8. So if you are already asking, then ask contextually and make sure to reflect what you did with the one you asked.

Yishai: Walla.

Yshay: I also think that teams are full of times, and as if on a daily basis some kind of past haunts them, decisions that were in the past or legacy code or problems that are there. And I always find it interesting as a MAN programmer, the question of if tomorrow we were to do it again, how would we do it, so that it would be the best experience, and from that they also have the solution and also what are the problems we are suffering from, as if getting in the way.

Yishai: Great, so in closing I want to ask each of you a suggestion for someone in the organization who maybe doesn't, doesn't have a neat DX function or hasn't read a problem in the name, and feels like they want to start touching those areas or move the organization there. What, what one piece of advice or one thing that can be taken practically, not necessarily to improve the DX but how to start bringing the organization into awareness, about what I can do as a developer or as a team lead, how to start. Dan.

Dan: First of all call it by name and form a group which is what she cares about, which is her agenda, find the champion who starts talking about DX in the company.

Yishai: and distribute the links ofDark Mode.

Dan: and distribute the links ofDark Mode, Yes of course.

Yshay: I'm thinking of actually trying to make a situation where we have some kind of small project in the company, if there is any opportunity. I don't know what, something new that can be developed a little differently and try to build how we would like to work and take this thing as a use case and then try to throw it into the other bigger projects.

Yishai: You say it's easier to solve the problem with something new, which is successful, then to say ok, let's apply it to the more things, our legacy.

Yshay: Something new and small, yes.

Dan: The truth is that this is an excellent point because quick wins is perhaps the most important thing in DX, in a world that is so, as if it has so many problems and it is also soft and you can take it in so many directions, so quick wins, find the small thing from which you start and there Make the change, I really think good advice.

Yishai: Quick Wins, great advice. Yeshi and Dan, thank you very much.

Yshay: Thank you.

Dan: Thank you.

Yishai: And it's nice that you came.

Dan: Great fun.

(transitional music)

Go to devinterrupted.com where you will find both our episodes in English and our discord server, and I would like to introduce you to Gitstream, our smart engine for continuous merge, only 2 minutes of installation and of course it is free. Go to gitsream.com I'm Yishai Beeri, we'll hear from you in the next episode.

(closing music)

Links to the nifty tools and resources mentioned in the episode:

• Dark Mode
• Livecycle
• Kubernetes
• Helm
• Vite
• Figma