Before we start, how many of you, that's really loud.
How many of you this is your first positive, amazing, amazing.
How many have been here more than five times?
Okay.
Any more than that?
You're just, you might as well live here.
Okay.
Well, we'll go ahead and get started.
We're going to talk about, well, if the, hey, look at that, we're going to talk about
the developer experience and how it is more than just productivity metrics.
They're not the same.
They might have, they might share a word, but they're not the same.
So we've all had that experience.
Using a tool that or service, that was a disaster, I'm sure if I asked, you know, everybody
just say it the same time of a tool or service, you could probably come up with one off
top of your head.
But that experience could be maybe your worst deployment process.
You've ever seen could be the most painful code base that you've seen, hopefully you
haven't looked at mine.
Or it's maybe documentation.
It's so confusing that you don't even know how you're supposed to, you know, use what
the tool is doing.
Who has had that kind of an experience?
Yeah.
Like it's pretty, it's pretty common.
There are also plenty of examples, though, that we could point to, that really kind of illustrate
a good developer experience.
How many of you could also come up with a tool or so that you're like, I really enjoy
using that?
Yeah.
They're very, they stick in our minds.
One that for me, always comes to mind is, you know, think it back about Haroku, back
in the day, and I say back in the day, 10, 15 years ago, you could, you know, as simple
as get push, who wrote who main and you would have whatever you were building was now
up running as simple as that.
It was one of the simplest ways for, you know, developers to spend something up, really
get started without a whole lot of, of headache.
Now they've since made some changes.
They're not as, you know, as easy as they used to be, but that was the core of that service.
There's others that have now kind of come along, like, you know, NetLify kind of has
the push, you know, push button, and now you can deploy a site.
There's a lot of the same kind of idea, but the, you know, they're not the only game
in town now that has kind of the idea of trying to make it as simple as possible for
a developer to, to do their work and get it out there.
My name is Jeremy Meese, a developer, head of direct, head of developer experience and
developer relations at a company called One Stream Software.
I also help organize step-up stays in Kansas City, and I am a CDF ambassador, so I'm glad
to be here.
Okay, so, because developer experiences self is such an integral part of, you know,
like the entire development lifecycle, and yes, this is an AI-generated image, it's going
to have all sorts of issues, it's just meant to be there.
It means that, like, the ease of use, sort of reliability, you know, how accessible and
understandable the documentation is, how efficient our processes are, the effectiveness of,
like, our frameworks, and, you know, even the smoothness of those development procedures
that we've talked about, all of those things have an impact on the overall experience that
we have as developers.
So I want to start with kind of a definition of, like, developer experience and developer
productivity, kind of level set, kind of the differences that we're talking about here.
So developer experience really is that journey that developers have as they are learning
and deploying technology and developer productivity comes to how effective and efficient
they are at producing.
One is about that experience, the other one is about the bottom line, really, for the company,
how can they make money as quickly as possible?
They're definitely different.
And also, I will have the slides you've already posted up and shared, so you'll be able
to get those as well.
But there's this subtle difference between, you know, developer experience, developer productivity,
developer productivity is really, you know, how effective efficient,
DevEx is the, you know, experience they have, and it's at its core, it's about the
practitioner, it's about that developer, whether they are, you know, in the back end,
maybe the front end, wherever they are within that cycle, those things, you know, they're
not the same, developer experience and productivity, developer productivity is a metric
where as developer experience is a feeling, it's at experience, what they're feeling
as they are working.
So sustainable productivity itself is not going to be forced.
You're not going, you know, it's a natural outcome of a superior developer experience.
It's, you know, DevEx is that leading indicator of kind of what the success of your organization
is going to be, because you're really focusing on that developers, the, the lived reality
they have as, you know, within your organization, well, the productivity is kind of lags
behind.
You don't know how productive things are going to be until you start to see the money
in the bank, highly simplified, but it measures really that ultimate business impact.
But developer experience itself is not really a new thing.
The first mention of, you know, developer experience as a concept was in a paper that
presented at the 2012 IEEE International Conference on Software and System Process in ZERC.
In this paper, which I do have a link to that you can download or if you get downloaded,
you can see me and I can get it to you, so you don't have to go through the IEEE process.
There are references in that paper, though, that go back to some concepts and ideas
back from 1985 that talk about like programmer performance and effects of the works.
So we were thinking about this, you know, even 10, 20, 30 years ago, or 40, if I think
about math correctly in 1985, 41 years.
A few things do stand out in this paper that I'll share really quickly.
The first is where, you know, it talks about these new ways of working where development
was globally distributed and integrating, you know, self-motivated external developers
into software ecosystems and would require a better and more comprehensive understanding
of developers' feelings, their perspectives, motivation, identification with the tasks
in the respective project environments.
All that sounds great.
Like that's what we want good experience for developers.
The second thing that we really kind of stood out in this paper was that, you know,
Devx could be a means for capturing how Devs think and feel about their activities at work
and that improving their experience impacts things like sustained team and project performance.
So this idea, the developer experience really over the last five, six years has really
started to become a more talked about thing, people have, you know, developer experience
engineers within their departments, the organizations now.
But it is largely, you know, driven by companies that are trying to sell something.
There's a lot of different tools out there that, hey, we're going to improve your developer
experience or, you know, different frameworks that we're going to talk about here in a
minute.
But, you know, it doesn't mean that there's not good value in those things.
But in a lot of those cases, they are more touching on that productivity and less about
what is a good experience look like.
So for decades, we've seen engineering leaders kind of grapple with, how do we measure
productivity?
You know, often relying on flawed metrics.
Like who here has ever been judged by or graded or rated on how many commits you push
to production right or, you know, how many changes to documentation or, you know, these
are metrics that are easily gained.
Like you can easily make yourself out to be a great developer within your organization
because you've pushed, you know, 25 commits in a day when all it was, you're changing
just a few things.
That's, that's not good productivity, but it's a way to gain the metric.
We have some frameworks now that are kind of shifted that focus to like the entire value
stream itself.
And with a lot of research around them, like Dora, Space, GetDX has kind of core for them.
And they're all research back, but they really still are on that performance view.
They have shifted that conversation from a lot of that pipeline metrics to more focusing
on business align kind of metrics.
When you look at these, you know, the shifts, some being more on the, like engineer side
to all of a sudden, more, or the getDX side is more on the, you know, what does it look like
for the bottom line for the C-Suite, you know, chief executive officers and whatnot.
So what we've seen with these measurement frameworks in 2014, who's here as heard of
Dora report, sure, yeah, it established really kind of this gold standard of, you know,
how we measure DevOps pipelines to start out that way, giving, you know, proven it speed
and stability are not really things that you are not trade-offs and that you can provide
engineering teams with, you know, quantitative kind of evidence backed language for software
delivery performance.
That was the kind of goal at the, when it started, the Space Framework that was introduced
in 2021 kind of came through collaboration with Microsoft, and it built on Dora, adding
in some kind of more holistic human-centric kind of models that argue that productivity
is really multi-dimensional.
It's not just one, or, you know, or getself, but it's, you know, the importance of the satisfaction.
They did add some experience pieces, the well-being, how your developers are actually working,
our critical components of performance, and then getDX in 2024, a few years ago, they kind
of tried to add a lot more business kind of impact to it, and their biggest thing was,
like, practical, prescriptive frameworks that you can kind of put all of these things together,
creating kind of that direct link between, okay, here's what your department can get the
value to the bottom line, how you can report up to the executives based on how your teams
are performing.
So, kind of tried to draw that direct line, but it was more like ROI and revenue, and less
about, like, how are people actually working and how are they enjoying their jobs and
how well are they actually being efficient as a result of the things they enjoy doing?
So, building a great developer experience is not something that comes by accident.
It's built with, you know, the developer in mind.
People are actually using the tools that you have inside your organization.
I mean, here has a tool that you're using that was kind of forced upon you, and you know
that it doesn't work great, but because somebody, you know, swipe the card and said, okay,
we got to use that tool now, yeah, like, we've all kind of had something that we wish
we were using some other tool.
So, you know, a good developer experience is minimizing a lot of that friction, reducing
the mental overhead, and enabling a lot of deep, focused work.
So, we'll dive into each of these pieces and add some actual, you know, some key steps
you can take, and then we'll talk about what kind of some good baselines are for how you
can get a measurement about developer experience.
So, that'll be our kind of end result here from here.
So, a core developer experience and really devops in anything related with the software
development pipeline is going to be fast high quality feedback loops.
Being able to have, you know, some ways you can put this in a practice would be, you know,
you can have visual regression testing now within your CIC pipeline.
You can have it to where, you know, tools like Backstop, Percy, Appletools, they all have
ways that you can take like a screenshot as part of the process of the, you know, your
UI to compare it against kind of that baseline to see was there a regression change.
Catch some of those before they go to production.
You can integrate a lot of static analysis in linting tools like ESLIN, SONERCube, check
style in your developer IDE's before things even get to production.
Husky and conventional commits are great ways to kind of standardize your commit messages
so that you can kind of, and help you focus on like some of those code style variations
that make it hard to review to you set a lot of that stuff at the beginning.
And then implementing, you know, robust monitoring systems, canary deployments you hear
it uses progressive delivery or like feature flag kind of things, yeah, like that type
of thing can really help you, you know, catch a lot of those issues, measure your deployments
over time, dedicating you know, specific time slots during your sprints or during a
week for, you know, pair programming sessions that you can kind of come up with new ideas
makes, you know, help with kind of force yourself and your organization into some really
good ways to help onboard new developers and also help the juniors learn and become senior
and senior, you know, learn from that as well, but that immediate feedback really helps
with development, you know, instead of having to wait for a review or something later
down the line.
And then like bug bash events, I've had, I've seen some companies over the years that
will, uh, something that I've even worked at that would do like, hey, once a month, we're
going to just, we're going to, on one day, we're going to just spend time dealing, going
through all the issues.
We're going to beat those bush, the beat those bugs down.
We're going to, you know, that was actually the term that was used, uh, but like this, this
way of looking kind of, uncover some issues that might be found earlier, or might be
found later, kind of get them done, find them and get them done all at once.
Those are good ways to boost that feedback loop, which gives them a lot better experience
for a developer than to have to wait until they've context switched and forgot what
they did back then.
And now we have to, you know, just take longer.
Uh, we think about like low cognitive load for your teams.
That is your, you know, implementing and forcing consistent code style.
So, you know, we talked about ESLent, there's, you know, prettier, some other, like things
that are out there for different, whatever your team might be using from a programming
language perspective.
You can also, like, you've, hopefully, I would think at this point, everybody's using
version control in some, some way.
Uh, so you can put in, you know, like, those commit message hooks to make sure that, you
know, you have some uniform format.
So when you're looking at your commits, it's easy to see what's actually happened.
It's not just some, you know, a couple lines of, you know, if you look at my commit histories
of, like, well, F, EAML, and that, like, you actually have the idea of what's actually,
what was done, what work was done, so it's easier to review.
Also, having, you know, those times in your sprint address technical debt as part of your
sprint.
I know people are like, oh, we could do, we'll push technical debt later.
Like, it's easier to deal with it now than to deal with it a year or two later, uh,
it's always cost more, um, a single source of truth for all project documentation.
Um, how many of you have here, have something like that so that you know what, when
you're building a project, like, with all the decisions that are made and all of the, uh,
the template that you're going to use for the project or, uh, just the decisions that, uh,
when you are encountered this, here's how we're going to handle it.
Like, who has projects documented in the way that you know right now where you're going
to go get it, just a couple.
Okay.
It's a great way to reduce a lot of that, uh, uh, have documentation as part of the workflow.
I know as engineers and such, like, we don't like doing documentation, but some simple
ways to just keep things documented is going to help, uh, everybody in the long run.
Um, make sure you do a lot of automated tests, unit integration, uh, end to end, all those
type of testing.
Hopefully everybody's doing testing and just nod your head just so I feel better
that we're testing our things, uh, beginning that rapid feedback as part is going to, uh,
going to really help us with that, we don't have to think as much about what again, what
do we do six months ago, we're catching it early.
Um, there you are, uh, and then improving your flow state, that is, you know, how many,
are, uh, get frustrated with all of the notifications you're getting, not just from your
phone, or I even get happy, everybody's like, yes, me, uh, like, constantly inundated with
a notification about this build or about, you know, some email you got to go to or some,
like, we're just, notification overload, uh, so getting away from, especially within your
development teams from, like, everything gets emailed out or everything gets notified
doesn't have to be an email note itself, it could be a slack, you're always getting
message and slack for everything, um, only notify from things that break.
That's where you should be worried about it, not that, hey, this build, uh, you know, it
worked or there's been a comment and it has nothing to do with anything else, like, assume,
uh, you know, uh, make the decision based off of, why does it really matter?
Does that notification really matter for me?
Or is this something that we don't have to tell everybody about and maybe we just have
a small group and not everybody joins, like, don't have to notify and everything.
The amount of time we have to get break our flow when we're working, uh, come pounds
the amount of time we've lost and wasted.
Uh, have a code review process.
That's prioritizing your speed and constructive feedback, uh, like, put guidelines for
how the code reviews are done, uh, so that there is, like, clarity, you can maintain it.
There's kind of architectural consistency with how it goes through, like, how many of you
have just one person, your organization, your team that does code reviews?
Okay, just a couple of you, how many have, like, a team of people that it goes through,
yeah, somebody that's just, just me, uh, having, putting an, in fact, GitHub does this
now.
There's other ways you can do it to, that when there, you request a code review, it can
do a group, pick from a group of people, kind of do a round robin, instead of it being
the same person, uh, that cognitive load of always having to review, uh, gets us, we're
humans.
We're not great at repetitive tasks, uh, so break that up, have someone else do it.
And make sure that, you know, there's a, um, that there, there's actual suggestions.
It's not just nitpicking, uh, things that actually matter, because you've set up the structure
of how you're going to do your code reviews and how, what they're the things you're
checking for, uh, make those go a lot quicker, and you're not just getting nitpick comments
that don't really matter, uh, ensure everyone's working from the same baseline and standards.
So have that, like, development environments, everybody's on the same, have a, you know,
special with onboarding, you make sure everybody knows, here's where we go, this, again,
goes back to having good project documentation, uh, break, work down into a lot more manageable,
uh, chunks, um, there's ways like Pomodoro technique where you can kind of, just take
a short period of time to work on this, and then go take a break, and then come back
so that you're not just, uh, losing focus, you know, maintain focus, there's other different
ways to do that prevent, uh, burn out, have that be a structure to approach that everyone
uses and not just something you suggest, um, encourage asking questions, like how many feel
like within your organization, you could be asking questions, uh, and not feel like, uh,
somebody's shining a spotlight on you that you don't know what you're doing.
Okay. Good. Um, having that space, if you're an engineering leader, uh, within your
organization, like make sure there's that space for those questions, and that every question,
uh, is treated with the same kind of respect. Uh, yeah. Uh, but when you introduce a measurement
system or any way of trying to track something, uh, there is that inherent, uh, risk of misuse,
um, good hearts law who are here is heard of good hearts law before. Okay. It is really that
idea that, um, you know, when a metric becomes a target for, you know, performance evaluation,
it's ceased to be a good measure because you can gain it. You can do the things that's going
to make it look better, and other plate things are going to suffer. Um, so if you're incentivizing
those things that are based on like a number, uh, it's very simple to just do what it takes to hit
that number. Uh, so, you know, we're, it's imperative that we look about at DevEx, and even
with productivity metrics that we're using them as tools for systemic, uh, you know, improvement,
not as like this instrument for judging or ranking things. Uh, it's important to keep that in mind.
Okay. So when we think about like moving from the abstract to, uh, actionable, uh, you really want
these kind of metrics, these are kind of, uh, like conversation starters and not just like,
hey, this is always going to be the thing. Use these, you know, to start those conversations,
not just for judgment. Um, these are some six that we'll touch on really quickly. Uh, I want to
stress these are not like one size fits all, uh, just because there might be a number here. It's
going to be a baseline. Always look for what your baseline is, and then adjust from there, not trying
to hit something that's, uh, mythical that you might have read on a blog post or heard some
speaker say you should, uh, go for, uh, sorry point, not an end point. So cycle time, it's that,
uh, time it takes to go for my data production. Uh, so, you know, having small batch sizes,
uh, test automation, CIC pipelines, like, you know, hopefully preaching of the choir there, uh,
you know, have in development environments set up in standardization, everybody's in the same,
uh, using the same things, developing the same way, uh,
proactively identifying remove those issues that kind of, you're always having to ask questions.
You're always having to depend on someone else's work, minimize, or, uh, you know, remove those,
PR review time. That's, you know, that also plays into the cycle time. So that's, you know,
make sure you have guidelines around smaller PRs where it's possible. Um, automate those as
possible, uh, have that reviewer rotation we talked about, mandate clear in concise PR restrictions,
have SLAs for, you know, poor request, poor request reviews, make that visible. Uh, especially if you have
a organization that's, you know, there's a lot of poor requests out there, uh, to good kind of
way to help raise the, that there's a lot of cognitive load happening, and that you need to, uh,
help drive some change instead of keeping that in that cycle. Uh, rework rate is really that
percentage of work that has to be read done. How many times have you had to read done a,
redo a, a commit to redo a poor request, uh, maybe because scope changes, because that's happens a lot.
This is a good way to keep track of how often is that happening. Uh, that would be a negative
that would not get great metric to have that you have a high rework rate. So, you know,
that can help with user stories, uh, have you can also look at that as, you know, help with better
tooling, uh, have a robust definition of what done looks like, uh, as opposed to, uh, with a lot of
sprints, it's like, uh, we're never done, uh, that's not actually great, uh, enforce that kind of
what does it look like to be done? Uh, you can also improve your feedback loops and communication
is a result of understanding what your rework rate is. Uh, also we talked about, like, how many people
spend more time on meetings than actual development? That's, yes. Uh, so have a meeting free day,
or even just an afternoon or something that blocks out that time, so you don't have to have those meetings,
have standard meeting agendas, uh, make sure that, uh, you know, you're auditing who gets invited,
how many people are actually participating, uh, because, like, not 15 people don't need to be there.
It might just be free and really else can actually do work, uh, have a meeting budget that if you've
already meet that, met that? Well, catch me next month. Uh, new hire onboarding, uh, making sure
that you have that going, uh, so that's really good there. We'll get through the last, we'll give
this last little slide, uh, there. So these are the quick breakdown, uh, and, uh, yeah, just establish
that baseline, know where you're at and adjust from there. Uh, there's a few other things that are
in the slides, but, uh, really want to focus on, like, get, remove the barriers that get in the way
of your developers being successful and it's important to understand how they're working and how
that influences the productivity as well. So with that, thank you.