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.