Lead Software Engineer: Why You Can Write the Code in a Day but Ship in a Month

That's what dev X or develop experience is all about, finding those friction points in the complete software development life cycle. So that goes all the way from onboarding to debugging systems in production and everything in between. People are not so much tied to a hypothesis, but they're usually very tied to their opinions. Instead of saying our CICD pipeline is slow, we need to fix it like this, You could say, I think if we change this, our

pipeline will become 30% faster. And then you have an experiment. Writing code is never been the biggest bottleneck, right? You are still responsible for what you put in the PR and you're responsible for understanding the solution that the LLM came up with. Because in the end, you know that the LLM is not going to get paid at 3:00 AM at night, but you are. If you're curious about developer experience then this episode is for you. Especially nowadays with the genetic tooling in the mix.

I'm joined by Buster Rd., he's tech lead software engineer and has always been in between hands on roles, developer experience and platform engineering, which makes him the right person to talk to. So enjoy.

I had this conversation on the podcast and it was quite controversial, especially in the comment section where people say, well, if we don't accommodate for the future to a certain degree, and in this case we can say hexagonal architecture, then moving towards that, either it's never going to get prioritized or we're going to have too much sunken cost in a certain way that it's very hard to steer. But I'm hearing you say there's a there's a different way.

Yeah, I think this is the the discussion you always have with your team, right? And something you have to fix within your team, I think. And then to choose a part that works for for everyone, I would say. But I've seen over the course of the past 10 years so many times that you accommodated for future change that never came. But you do get all the all the downsides. Like just the other day we had, we had to build a feature to import either ACSV file or an XML file.

Don't get me started on that. But what's the requirement and why? Also, so you made this nice, nice interface so you accommodate for both of the file types and while you were finishing up the CSV part, the XML part got scrapped. OK, so now we have this interface that accommodates for both, but we only use one, right. And that that's, that was even something that was planned. Yeah. And even then you don't need it in the end, so.

What did you do then? Did you scrap the XML part even though you built it or was the team like, well, we, we obviously didn't scrap it. No, see, I would have scrapped it. It's like we're never going to use this. Yeah, this is a funny, but it like people are so opinionated. I feel like it's very inherent. And I also like that. Let's have a solid discussion. The hard part is people don't budget right. In the end, someone needs to make a decision.

Do we go for simplicity or do we indeed develop the feature with future in mind? And then there's a fine line. It's not that black and white that you could just be like, we do this or we do that. There's a lot of grey in the middle and in the end you have to compromise somewhere. But it's very hard to bump heads and like find a resolution within a team. For sure, as I think it's very interesting point because you see this so often, right, that

you have this discretion. And I, what I really like is have fair discussions where indeed, if you have good arguments, people are able to change their mind and go another direction, even if it wasn't, even if that was not the direction they originally thought of. And I think what really helps to achieve that is to form hypothesis over opinions. So instead of saying or CICD

pipeline is slow, we need to fix it like this. You could say, I think if we change this, our pipeline will become 30% faster. And then you have an experiment. And if it doesn't work out, you know, people are not so much tied to a hypothesis, but they're usually very tied to their opinions. I like that a lot. I always think that the people I want to work with, I want them to be open minded and I also want them to be opinionated,

right? But if you combine the 2, I feel like I as a person, I'm very stubborn, but I have no trouble saying, well, I believe this and then I get proven otherwise. I'm like, well, I've changed my mind. I agree with this. It's I have no issues with that. But now to be honest, like that. And I want the people that have the flexibility that I can also say, OK, I was wrong, right?

And with new insights, with proven results, I now have a different mindset because we've shown results and that fits in this context. And maybe in another context it's different. But I want people to think like that and also introspect and not be afraid to say, well I was wrong in this case and it doesn't matter in the end. Yeah, exactly. You don't want to get married to

your solutions, right? In the end, you want to be able to experiment and change things if the reality is a bit different than what you thought it was. Yeah, yeah. I think developer experience is is very interesting nowadays. You already mentioned that if you buy into a certain complexity for the future. I've been in that situation and then developing new features

with my reference. I feel like I could, I can go really fast, but then through the architecture choices or through the complexity we already have inherently at a very early stage projects. I've had examples where I'm just slowed down or I have to do many things to get one thing in order on different places. And I'm like, well, this should not be the case at this stage yet. We should be able to fly because we're in Greenfield, but certain architectural decisions prevent us from doing so.

And I, I cannot do that for long. I've noticed like I will fight and be like, we need to simplify because this cannot stand for a long time. Yeah. What has been your experience so far with battling complexity and developer experience? I think it's much broader than just architecture. So if you if you take a step back and see how we got here, right, we had the whole DevOps movement.

I think what was it 1015 years ago that it started a little bit like that and DevOps brings like so many advantages.

Yeah, but we're shifting everything left. So there's coming that that much more burden on the on the software engineers because in the past you just write your code and throw it over the fence and some teams can deploy it for you. And now you need to know about of course your code, but also Kubernetes, the cloud stuff, database, Estella form, etcetera, etcetera. It's a lot. It's it's really a lot. Yeah. I had a colleague, she used to say a shift left until there's only shift left.

OK. And it's it's it's kind of true, I think because there's so much burden on these developers and that's what Dev X or developer experience is all about. It's about finding those friction points in the complete software development life cycle. So that goes all the way from on boarding, like your first day at a new client or a new project all the way to debugging systems in production and everything in

between. So the very technical stuff like your architectural decisions, but also more the social stuff, it's also very important. So it's not just about tooling or CLIS or technologies, but also about, hey, do I actually get solid requirements? Yeah, how how many times do I deliver a feature and it needs to rework because the the requirements weren't crystal clear at the beginning, for example. Yeah. So that that's what Dev X is all about for me.

It's about removing those fiction points from the entire software development life cycle, and not just on the technical side. Yeah, I had a conversation, this was yesterday actually. And when you're listening to this aired last week, but it was a, it was about platform

engineering. And then we were discussing indeed very similar to developer experience, friction somewhere in the development life cycle going from idea to production, but then very specifically for tooling, I was like, why is this not called developer experience in the 1st place? Why is it platform engineering? And they mentioned that what we do focus a lot on tooling. There's a big emphasis on

tooling. And when the problem is then process, when people only can spend 10 percent, 20% of their time hands on coding and 80% they just get dragged into meetings because of middle management or because of bad processes, then that's also a bigger part than just platform engineering. That's all of developer experience. I feel like in bigger organizations, the more you focus on developer experience.

If you have a lot of engineers and you can make all of them a little bit more efficient or a little bit more effective, if we're talking about small percentages, then that's going to pay dividends. But I'm curious, from your perspective, even in the smallest organizations with only a few engineers, does developer experience matter and who should focus on Dev X in the first place? I think there is like a flipping point at around 50 engineers.

I would say I only did Dev X at companies of yeah, with with 200

or more engineers, SO2234500 engineers. And there you can get in a very big benefits if you make small gains because they're compound. But I think at around 50 engineers, it's a bit like a guest guest for me. I'm not entirely sure because I never tried it, but I can imagine the flipping point is around somewhere that that stage, you know, that stage where you can't just where you're big enough so that you just can't just get everything

done on the fly, right. If you're responsible for provisioning databases, and I'm in the development team, and if you're a small company, I can just send you a select message, say, hey man, can we know the best from you? Yeah, we know each other. And there's only like maybe two or three other development teams, right? So if they all ask you for a database, you're not kind of

swamped in work. But if there's 10 or 20 development teams and you have to provision databases for all of those, you're not going to be happy. That's our database profiter. The people that focus on developer experience, their knowledge also needs to be quite broad. Do they typically come from a hands on role? Do they come from a product or process role? Or who is typically responsible

for developer experience? I think it really helps to have a deep technical understanding of how code is being written and how the software development life cycle works. Yeah, that's, that's for sure, for sure for a valuable because in the end what you want to do is or what we usually do is we start measuring the state of the effects within a company. So by usually by doing surveys and just getting sentimental data on a lot of possible friction points.

So for example, you ask like how confident are you in shipping changes that nothing breaks and a whole bunch of other questions. And what you get then is a set of sentiments basically. And we allow the respondents also to rank the items in what I think is most important. So in the end, you have this list of sentiments and ranked based on importance. So you are looking for things that have low sentiment for whatever reason and have a

high-ranking on priority. And once you have that list, yeah, you know, there's a friction point somewhere, but you don't know what is causing it. So the next step is to talk to engineers and of course the survey part you can do pretty well if you have the questions

without any technical knowledge. But then the part where you talk to engineers and to interviews, yeah, you will need a lot of technical knowledge if the if the friction point is technical, of course, to determine what is actually causing it and how to possibly fix it. Those surveys, are they templates that you have online or do you make them custom for an organization that you've been involved with? How do the questions actually make sense in the end?

Yeah, there's, there's different approaches you can take. So there's a couple of open source, how do you say it frameworks you can use. So there's the hard framework. I think there's a space framework. I also always forget what the abbreviation stands for. But there's, there's a pretty well documented and they explain you what, what kind of questions you can ask and how you can

build this survey. And it's also commercial tooling like DX, which was accompanied by of acquired by Atlassian not a long ago. And I think that's, I think that's a great tool to do those surface because they spend a lot of time on the questions and yeah, the tooling itself, which is really nice to use. And what, what I think is really cool about DX also is that they gather like a lot of data from

different companies. And of course I anonymize it, but you're able to compare yourself to other companies. So for example, you can you have this topic of requirements quality and you can compare your scores to the scores of other companies. And of course, you don't see the company names, but you can see in what percentile, yeah, you are scoring. Which is pretty cool. So if what we have is normal or is really just skewed? In a yeah, or maybe really good. Right.

Yeah, that's interesting. I'm on Reddit a lot and I just get spammed with DX advertisement. Oh, really? Yeah, yeah, yeah. So when you said that, I was like, I know that whole yeah, that's really funny. In those conversations that you have, let's say we have a problem and you go to teams to kind of figure out what their workflow looks like and what that bottleneck actually is. How do you approach this interview or discovery conversation with them?

Usually really open, right, because you have this list of where you have to survey results and usually they are are anonymised. So yeah, maybe send out a Slack message to an entire company saying, hey, we, we saw this in the server results. If you think this is interesting, you want to talk about it, you know, let's let's have a chat and that's usually the way we we get started.

And then your interview like maybe, yeah, depending on the company size, maybe 5-6, seven different people and doing start hearing the same things over and over again and they usually know you have enough information. And then of course, it's really dependent on what the issue is. Now you're going to fix it. Yeah, interesting. I had a person on that was responsible for product at VID VID. Is this in the browser video editing tool, which is the

largest one out there right now. And he said for us in a company, it's really important to talk to customers and they do discovery those interviews and they record the transcript of those conversations and they put it in a location somewhere. They do, if a lot of people do them weekly, you get a lot of transcripts of a lot of conversations, and then they built an AI tool that goes through all of the transcripts and finds like commonalities of user problems and stuff like

that. When the organization gets that big in conversations with engineers, kind of scale to fix developer issues. I think that's a very interesting approach, but I haven't seen that applied to that level yet. I do feel like developers are the people that typically have a solution in their mind, but for some reason they're not enabled or they don't get the time to

actually apply that. But then those solutions might also be incorrect sometimes and they don't really know what the problem actually is, which is the same as any other user to be honest. Is that also what you've seen? I really like the idea of, you know, recording those conversations and then putting it in an LLMI think that's, you know, I'm going to take that with me, I guess. So thanks for. Sure. Yeah, yeah, great. Sorry, what was the question

again? The developers, I think they typically have a solution in mind, but they could either be on the spot and they're just not enabled to act upon that, or they don't have time, or they're not in a department to fix that, or they're actually incorrect and the problem is elsewhere. I'm wondering what your experience has been.

Yeah, that's also why it's so valuable to start measuring those things because in those measurements without those measurements like dev access, abstract concepts of which we all think it should be improved, but you nobody knows quite how you know, you don't know if you start turning some knobs, what's going to happen and if it has the effect that you want.

So by measuring it like continuously, like every quarter, every every six months, you get this very nice baseline in, in this tracking system to see if your improvements also make sense. Right. And I think one of the examples we had at the company is that we there was, there was like this already this idea that the gate lab pipelines were not so optimal because there were no spot instances and sometimes build builds would get killed

halfway during the builds. You have to research builds quite annoying, takes a lot of time. Feedback loops are slow. It's not what you want. And it was not, it was a known problem, right? Or at least it there was a problem known to a lot of engineers. And then we did this survey and

because we already knew there might be a friction point there, we ask a question in that direction. And we indeed saw like a huge percentage of the respondees saying, Hey, this is need a problem. And now we had like this, this data bit that we could take to the team responsible for the GitLab runners and say, hey, maybe we should have a look at this. And they made some fixes and they allowed GitLab runners to

run on non spot instances. And in the next survey, we asked the question again and we see a huge improvement on that, on that specific topic. And now of course, this is a very, this is a thing you might not be able to change if you have much more local scope, like if you are an engineer in a team, you might not be able to make these kinds of changes. But I think a lot of effective defects initiatives, they start very much from bottom up. So they start really small.

And I think a great way to make improvements for you as a team is just to take your refinement and ask like what slowed you down in the past quarter or in the past month or something. I see if if there are friction points that are small enough for your for your own team to solve. You know, because you might be able to write rewrite your whole CICD setup, but you might be able to make huge improvements to your test suite speeds for example. Yeah, I like that a lot.

Is this survey that you mentioned you do quarterly or maybe a little less frequent, is that the most important way for you that gathers data that you've seen? Because I've also heard quantitative data durometrics, and I'm not sure how much people manipulate those to actually skew to the right way, but the survey seems very interesting actually. Yeah, the the the good thing about the surface, it's low cost. It's really easy to get started with you.

You usually don't need a lot of permissions to send out the survey within your company. Dora metrics are also great, but

I think they're way more valuable to measure how far along a company is into watch moving to a DevOps way of working. Because once you've hit that DevOps way of working, you're deploying multiple times to production a day. You're not going to see huge shifts in your Dora metrics, hopefully. So then your friction points will become a bit harder to detect because in Dora, you only have, I think, 4 metrics that

you can use. And with the survey, you can have much more touch points of course. But the survey is really important and easy to get started with low cost. I think if you move along a little further in your defect journey, you also want to start looking at system data. And that sounds maybe more complicated than it is because you can get started pretty easily, right? If you are using Gitap or GitLab, there's already metrics there that for example track how

many PRS people are doing. Not to measure individual productivity, but measuring time to 10 PR from people onboarding is a really good indicator of how good your onboarding process is. So it's not measuring like how fast can this guy do 10 PRS, but it's about how well are we able as your company to onboard new people because by the time they made that 10 PR, you can be pretty sure they're are working

on their own. Exactly, I'm wondering what you think of people nowadays have an opinion on developer productivity. Right? There's a lot of agentic tooling and people can vibe code that are non-technical and they can show a feature and they'll be like, well why doesn't this happen within the team or why is the team estimation 2 weeks and I can do it in two days, for example. I've seen a lot of those conversations and they're quite funny to be honest.

But yeah, it does say something about the organization, a big oil tanker versus an individual that just goes Greenfield and shows results in that way. But it forms opinions and all of a sudden people are more. So I think rather than bottom up being enabled, also top down, there's this expectation of we need to be more productive as an organization because if I talk to other people, they're doing the same thing in other organisations, they're trying to find the gold as well.

I'm curious what you've seen so far. I I think like writing code is never been the biggest bottleneck, right? There's, like I said in the beginning, defects is about more than just tooling or technologies or coding. A lot of it is also processes, for example. Yeah, so let's say you come in on Monday morning and you're tasked with building a new Greenfield project. Very nice, right? Cool project. So you start building, you're

happy, and at some point you need a database because every good product needs a needs a database at some point. And you start looking at documentation, trying to see how you need to request this database. And in the end you find some doc that's outdated and who knows what. And in the end, you find someone that can actually explain to you, hey, you need to create a ticket in the ticketing system to request a database. Of course, the ticketing system is already the place where

innovation dies usually. But fine, you know, you put the ticket in, you wait for a couple of days, nothing happens because it turns out you also need to submit an e-mail to some other department for your ticket to be picked up. And then in the end, it turns out there's this sacred cloud committee that's meet once a month. It's a group of non-technical stakeholders and they're going to decide if your database is worthy of existence. And of course, you're in a last meeting last yesterday.

So you have to wait a full month for the next meeting. So you you could have written all the code for the application in maybe a couple of days. But because of this very yeah, bad process, it's going to take a full month for you to deploy your service. Yeah, when when you were describing that, I was just laughing. I I feel like I would really experience a lot of pain going through this process and a lot of frustration to be honest.

Now of course it's an execuration, but for waiting full month of course of the Sacred Cloud committee. But yeah, there's, there's a lot of ticket OPS still going on. A lot of companies you have to supply a ticket, wait for a bit, and then yeah, you get your database or you don't get it and it it wrecks team autonomy. Really. Yeah. Have you seen people? Because I was wondering if I I'm in a consultancy, I go from project to project, so I kind of get a look behind the scenes in

a lot of organisations. So then I get a preference because I want to work in an organization and I'm going to compare to the best experience I've had developer experience wise. So I'm going to bring that to an organization and be like, well why don't we have this or what

can we do to improve? But if I've been in the same organization for a long, long time, ticket OPS, this is the way it is, I don't think I'll know what a better way of working would be or what kind of other organisations are doing out there or what I could improve locally. Then I'm just going to kind of do the status quo, to be honest, because this is it and maybe it doesn't get better than this.

I think it's interesting that if you have the ability to switch between companies, then that is going to give you a lot of insights on that aspect. But yeah, there's also benefits in staying with the same org, just maybe not with regards to the way of working or innovating. Is that also how you've experienced it?

Yeah, I think that's what you'll see also see in the interviews I have with with engineers like the people that that not only the consultants, but also the people that change maybe employers every five or six years. They get to see more internals from different companies and they usually have more ideas on how things could be or can be. So yeah, you definitely see a difference there.

Yeah, for sure. Yeah. It's interesting that you can you can leverage seeing different organisations and then applying that in this org. The team that is responsible for Dev X, do they only focus on Dev X or is that like a side thing to also do in product? Or how's typically the balance with regards to what they do? Oh, it's really different for for each company.

Of course, sometimes you have like a dedicated Dev X team, sometimes they're part of platform teams because yeah, like you said before, Devx and platform, they're they're quite closely related. Yeah, for both your customers are the engineers within your company. Yeah, yeah, I've, I've worked in both Ryan's and I think having a dedicated Devx team was really was great because you can really focus on on the essence of of the whole thing.

But then you still have a lot of collaboration with, for example platform and with engineers. Yeah. How does a Dev X team in the end when we're talking about from the standpoint of investments, if I am owner of a business or the owner of a certain department And I do think we need to focus on Dev X, but we don't have any metrics yet.

So we don't have a baseline. But I do think we need to focus on a few things because there's a lot of signals and a lot of symptoms that I think we can improve. I will start with either a small Dev X responsibility person or a team, but in the end there will need to be certain measurements and then people are going to move towards certain outcomes. But I also have to have trust that this in the end is going to

be a better outcome. So metrics help, but how do you typically see people get buy in or people get investments towards certain initiatives that actually move organizations? Yeah, can you can start very small bottom up.

So even if you don't have like a very good baseline of the whole company and how they're performing, if you would in your team can make some local changes and you can measure improvements there because you probably have the data and things that weren't going so well before because that's why you're going to change something. You can make the changes there.

And then you have, you might have a business case, right? If you can speed up your CCICD pipelines by X percent, or you can lower your memory consumption by X percent or whatever, you might have a business case. Interesting. I'm interested in more about you personally because you've been in Dev X teams, you said you've seen different organisations a lot as well. Where do you get your energy from or what still gives you energy when you're part of that Dev X teams specifically?

I yeah, I just like coding a lot still. Yeah. And like you said, like yourself, I worked as a consultant for my entire career. And you're constantly comparing, Indeed your experience to the best companies you've worked at. And I know how nice it was to work with those companies where I could be super effective as a software engineer. So I think what gives me most energy is trying to achieve that for other engineers or different companies as well. And how do you then get the

feeling of fulfilment? Is that when you see people really fly based on the changes that you've made? Yeah. So it's when you, when you do defx work, the feedback loops are completely different than what you have as a software engineer, right? Because you run your tests and they go green or red.

Green is good and green is good usually or you're, you would do your and it takes maybe a couple of seconds while you do your deployment to acceptance or pro op might take 10 minutes, 20 minutes if you're a bit unlucky and you have your feedback for defx work because it's much different. I had to get used to that a little bit in the beginning because you'll make some changes and then usually if you don't hear anything for for a while, then it's good.

Oh, it's good. Because if people are not happy, they're you're going to hear them. They're vocal, yeah, they're vocal about it. And yeah, it doesn't happen often, but sometimes people are so happy with the changes they they will come to you say, hey man, I'm really happy with this or with this bit of documentation and great job. But that doesn't happen so much. That's right. Usually silence is, is good. And then hopefully you see the results in the surface or in the

metrics that you are tracking. Yeah, so that's what you get your fulfilment then out of. If it's silence, you're like, it's quite as good. Yeah, it sounds a bit disappointing, but. That was really funny. Like I, I started my career in operations and to be honest, with a really good operations team, the dream is you don't really need a lot of operations or people being standby, right? Because if you have great systems, then you don't actually need to do a lot when you're standby.

That's the dream. And if no one finds out, then just keep quiet basically. Exactly. I feel like developer experience is, is interesting. I am wondering though, because I'm getting really enthusiastic about Dev X in the first place, if I specialized in this, if I become a person that can orchestrate surveys, that can show metrics, that can communicate and get by in, will I tie myself to be most effective in big organisations? Will that prevent me from going to smaller organisations or how

do you view that? I guess it depends how you what you find a small organization. Like I said, 50 people instead of the 100 people instead 10. Yeah. Any of that or even start-ups? Yeah. Yeah, I think for start-ups there's a little less need for a dedicated defects team because as you already manage it like you're going to get the biggest results if your company's a bit bigger and where you can make small changes and they compound, you know, your time or money or whatever.

But still, by working on these defects issues or these defects friction points, you experience so many different issues people have in their sofa development life cycle. And you learn a lot just by looking at those things. Because when I look at myself, the times I've learnt the most is when you're solving nasty issues. And that's basically what you're doing all the time. Yeah, if you're if you're doing Devx in a more dedicated manner.

Interesting, you also mentioned that you really get joy out of coding specifically, but how much do you actually do hands on stuff when you're responsible for devx?

Do you still dive deep when it matters? But you're not really creating I think as much. Yeah, that's true. So you dive deep when it matters and there's of course a social side, also the technical side. And for the technical side, you might have to do some coding, right. So I'm thinking of an example. I had a company where they were using, I think Datadog, and the company's running a lot of Scala code.

For some reason, the, the tracing didn't work quite all right in Datadog for, for Scala applications with a certain framework. And then we spent quite some time coding to fix that issue actually. Gotcha. Yeah. Is that then because there's no one is responsible for that bit or they lack the expertise? Because I'm wondering why that goes to the Dev X team and not there's not a team or ownership there without it. Yeah, that's a good question. I think it's, it's a bit of both, right.

So it was a quite a complicated problem. So in the end, what we did, we started a working group with some very experienced scholar developers as well to work together to just fix this issue. But by starting this this working group, we also got some mandates and some budget to actually work on this fix in a dedicated manner. Because otherwise you have all these scatter teams that all off the issue and they're gonna you know, maybe stare at each other and say maybe they're gonna fix it.

Maybe they are gonna fix it. And then just. They're gonna wait. No one fixes it, no ownership. I like this concept of task force and I, I'm now at Iholt and Iholt. They also have that for specific initiatives, people come together from a dispersed group of teams, start a task force, solve the issue, go back and it's the first time I've actually seen a really good like orchestrated process around solving root cause problems.

I feel like if I have a lot of symptoms and that kind of in inhibits my way of working, it's very hard if I don't feel empowered to fix it. I don't think I could last like years and years on end like I see other people do it. I've always given the example of I started out in operations and then before going manually into orders and changing things because they were ending up in an error directory. I was like, I already week one. I was like, I cannot see myself

doing this. Like I'm a big fan of automating and solving problems and developer experience or teams that are dedicated for that, also orchestrating task forces, fixing technical problems, but also non-technical. I think it's just very cool that people are spending time and attention towards that because yeah, if you have 1000 engineers, it's just a lot of people to make more effective and small changes can have big benefits. Yeah, for sure, for sure. I think that that sums it up

quite nicely. Yeah, yeah, yeah, definitely. The part with AI tooling for me is just very interesting. And I'm wondering for you is that if people already have a really good way of looking at developer experience and then they add AI tooling in the mix, I'm assuming it's nothing new than just any other tool. But for companies that don't have that, then adding AI on top of it might just create more chaos. How do you see that?

Yeah, The funny thing is that most friction points that hurt humans also hurt agents, right? If you have very unclear processes or slow feedback loops or flaky tests killing for agents, of course, flaky testing. What else do we have? Port documentation? Out of date documentation that also, yeah, it's also going to hurt agents, It's going to hurt humans, also going to hurt agents. And then I think it's even more important to have good baseline measurements.

So if you start introducing AI within your company and you don't have these baseline measurement measurements, how are you going to determine if the cost, because those tokens are not free, right, that you sent to your LLM, How are you going to determine that they actually bring value? Because indeed, maybe you might see features get completed faster, but maybe there's a big increase in production

incidents. Yeah, I was talking to a person recently and they were talking about a governance framework because people are being a enabled with a gentic tooling and things are accelerating. But their governance framework was indeed for I principle with regards to pull requests, not being able to push the main directly. And I was like, well, nothing of this is new. There was also something additionally that was a list of check boxes that developer would be like, yeah, I've reviewed

this even though it was AI code. And I'm like, man, then you're just trying to finger point to the problem that people actually constantly do something. I'm like, I don't know if this is the way. Like I don't know what the way is. I don't think there needs to be anything extra. Like I haven't seen anything extra that needs to be there from a process perspective with agents in the mix other than if you are really have autonomous

agents specifically. But then your your code review process should be able to catch that I would think. So I haven't seen anything new that needs to be added. But then, are the code reviews done by humans or agents? Yeah, that's an interesting one. I would say right now they're done by humans, but I think they can done be done by both. If I have an agent that reviews and then another agent that picks up those reviews at some point will come into a state

where a human can actually look. Doesn't have to be first pass, but it can be a LastPass if we need to. And then if people have so much confidence in due to setting up agents with regards to specific context, specific knowledge and conventions, strong conventions, that they have high confidence that if an agent says it's good, then it's good, then I think it should be good. And if it's not, then we will experience, but we do need to own those problems.

Yeah, for sure for for us, the team I'm working right now, we're not there yet to have that much confidence in the agents. So what we did, what we saw a few weeks back is that a lot more codes being produced by Junie, the LLM from Jetbrains. And what we noticed in interviews happening a bit more is that you would would flag something in a in a code review saying, hey, why is this like this and this?

And then the person would play. Yeah, Junie. Junie made that. OK. E so that yeah, you know, and then we, we had to talk about it with the team and update their golden guidelines a little bit. And we said, OK, using LLM to to generate code is perfectly fine, right? I think think it's a good idea. But in the end, you are the expert in the lead and you are still responsible for what you put in the PR and you're responsible for understanding the solution that the LLM came

up with. Yeah, because in the end, you know, the LLM is not going to get paid at 3:00 AM at night, but you are. Yeah, Hey, I had a conversation with Gregor Hope I, I don't think I shared that podcast with you, but I definitely would recommend it. It's really funny how he put it. He said either the tool's really good, which means we don't need you, so if you don't do anything, then we just use the tool. Or he says the tool's not that good and you don't do anything

and you're still responsible. So that's that's your problem. Basically, it's one of those two. You have to add value on top. For sure, yeah. Yeah, that's also how I view it. And I think if we put it in that way, people will, it really resonates with people. You mentioned that you like still the hands on part, the coding part specifically, but I feel like that's going away.

Are you on board with regards to agentic workflows or how do you view that and how do you get fulfilment out of that part? I still do get a little fulfillment out of just thinking about how a solution should be, right? Yeah, maybe not about just typing the code letter by letter. And I'm not not quite sure if it ever was like the the fulfilling part. Yeah, now that I think about it. But I think a lot of the fun for me also to think about how, you know, what's going to go wrong

with the solution. You know, what are their unhappy parts? How does this tie into our domain? What kind of other things that we need to consider to make a good solution? And I still get that with agentic coding, at least for now. Yeah, yeah, same here. I did like always being a good hands on on the keyboard, but that's just to accelerate the process. And now I have a process that accelerates it even further.

So then I really get enjoyment out of solving problems and working towards outcomes to the point where now I've downloaded this tool. I'll show it to you after it downloads a local speech to text model. And I just talk because a lot of prompting I'm typing and I'm like, I can talk way faster than type. So that's my latest optimization. And I'm also using it in Teams where people, I'm interacting with a lot of people and I'm just speech to text. Let's go speech to text, let's go.

Great. It's actually quite fun. And because everything is local, I'm like, yeah, I get the local transcripts. I can even read the way I talk. If I see a lot of the Fiddler words, I try and improve my speech, which then comes back to the podcast. Yeah, I'm having fun, to be honest. Yeah. How happy are people would you when you work in an open office and you were. Oh, no, I, I actually, I, this is the part I don't like. I don't like going to the Openoffice anymore because maybe

it's, I'm a bit awkward. I don't like it when people call in an open office or something like that. So I was trying to find a quiet spot and then I talked to my laptop. I, I saw 2A while back and I think it's called whisper AI or something. And you can like in the in the prompt by voice. Yeah, I don't know, whispering tone, which my I I didn't try it. It felt too uncomfortable, but.

Yeah, that feels, I, I know whisper flow, but then I have to pay really quickly and because it's a SAS, I'm like, I don't want to pay monthly. So I found this tool, it's a one time payment and then I have it and I'm using it. Cool. Yeah, you, you have to show me afterwards. Sam, I will. Do you have any tools that you've really fallen in love with lately? Lately I just start using open code, which I think is really nice.

I've heard it's good, but I still have to set up the workflow with all the skills and everything because that's, that's something I'm seeing also in the community right now. There's so much tooling, so much new tooling, but the golden part on how to use the tool, those tools are not, are not yet really crystallized yet. So you have to figure it out yourself a little bit, try what works for you. And I'm, yeah, also liking that experimental process.

But yeah, it's it's three or an hour, a little bit for now. Yeah, definitely. I'm wondering if we ever get kind of a platform engineering for AI tooling, because DevOps was kind of introducing a lot of tools in that aspects and platform engineering is trying to fix that. I feel like AI tools are just popping up like mushrooms, but I still want to see in the end what sticks and there are just

more and more. So wondering if there needs to be, Yeah, kind of a golden path for that as well in the end, maybe a few years down the line, which could be interesting. Yeah. And I think also you have different levels, right. So if you have the the open code or cloud code skills, you of course can share them with your team or maybe with your company or there's a lot of lot of different levels of abstraction you have there as well.

Yeah, definitely. We've shared a lot about developer experience and I feel like we've covered a lot of bases. Is there anything we didn't discuss that you still want to add before we round off? Nothing that comes to mind right now. Probably like after after we sign off, immediately after. Recording. That's always how this goes. And thank you so much, Buzz. This is real fun. Thank you. Cool.

We'll round it off here. If you're still with us, let me know in the comments section what you thought of this episode and we'll see you in the next one.