DevOpsDays Boston 2019 – Built With Love – Why Developer Experience Matters by Arthur Maltson

DevOpsDays Boston 2019 – Built With Love – Why Developer Experience Matters by Arthur Maltson


Awesome. I didn’t know there would be a stage there
like this, otherwise I would have done everything in song and dance form. We’ll have to settle for just a talk. Awesome. As Laura said, I’m Arthur Maltson and I’m
here to talk to you about built with love why developer experience matters. When I say developer, I don’t just mean developer,
I mean operators, designers. Basically any technical tool user. So I’m just using developer as a shorthand. And before we start talking about developer
experience, I want to start with something that’s probably closer and more familiar,
and that’s user experience. And if we boil down and over simplify user
experience, the idea is to take an customer and apply functionality, aesthetics, design
and turn them into happy. So if we look back really not even that long
ago, to 2005, the web used to look like this. Right? And sense then something like MapQuest looks
like this in the modern day and it’s of course mobile friendly and scales and so forth. But how did we get there? Did we just sprinkle a bunch of magic pixie
dust on the website and turn it into this awesome experience? No. Of course not. We did a bunch of research, which was then
in knowledge that people later took their design and creative skills, combined with
engineering prowess to get to build these awesome experiences. But if you think about it, has the web fundamentally
changed since 2005? I mean, we still have Javascript and TSS is
more fancy, but fundamentally the web of 2005 still had many of the same building blocks
we have today. What it took was a perspective change that
user experience is important and that we should invest in it. And you’ll note, I put up MapQuest and people
are like who the hell cares about MapQuest. But if you look in 2005 when Google maps launched,
it wasn’t that drastic of a difference. It didn’t have traffic and so forth. But the thing is, Google had made the perspective
change that user experience is important and building on the same core technologies that
MapQuest was using, they’re able to build a much better experience. The question is why did this change? What was the drastic change since then and
now. Companies found with a little bit of investment
they saw a huge increase in usage which then led to return on investment. A company that saw this early on before the
dawn of the Internet was Apple with their famous presentation. They looked across the industry and saw all
those beige, boring, PC boxes and said we need to do something different. We need to have something that’s not only
more aesthetically pleasing but more functional. Steve Jobs talked about it’s not just aesthetics,
it’s also the functionality. It’s not just Apple. Google talks about how in the first 50miliseconds
a customer will get a gut feel for your website and whether to trust it or not. And in my favorite quote they talk about how
with every dollar invested in ease in use, they saw a 10 or $100 return on investment. So that’s user experience. Looking back a bit more than a decade we see
all of the value we kind of left at the table by not investing in user experience. The question is, what are we missing out on
today by not investing in developer experience. Before we get there, you might be wondering
what is developer experience. If we boil it down, it’s taking an angry develop
ever who’s not happy with the tool that they’re using, applying a bunch of techniques, some
of which we’ll talk about here, and talking them into happy users. And someone who saw this early on —
So what are we missing out on by not focusing on developer experience today? I’m going to argue we’re missing out on three
key things. The first is fiscal, the next is mental energy,
and the last is developer morale or decrease in morale. Developers in this field, I’m using developers
in shorthand, make pretty good money. All things considered, this is a good field
to be in. Obviously a team of developers cost a lot
of money. And if you have a team of developers spending
most of their time, two weeks, for example, configuring their work station, that’s a huge
investment in not working on the product and adding new features. That’s the fiscal side. Let’s look at the mental energy. There’s a really good analogy out there about
representing everybody’s mental energy in the form of coins. And every day, depending how you’re feeling,
you wake up with a different set of coins that you can spend on decisions and actions. For many of you here in the U.S. you may be
wondering what the heck are those. Those are the dollar coin in Canada. They’re called loonies because they have a
loon on them. They might also be loony, I’m not sure. Fun fact, we also have toonies. But I digress. Every time you make a decision or get frustrated
by something and have to get distracted and diverted, you’re spending a coin. And somebody who saw early on the importance
of this, and optimizing your decision-making is Steve Jobs. One of the things that he talked about in
his biography is he wore the black turtleneck and jeans every day, that was all he had,
so he didn’t have to spend decision energy on what he’s going to wear that day. So next time you run into an error and you
have to Google it on stack overflow, that’s a coin. Maybe you bang your head against a missing
semi-colon for three hours and you spend coins. Having that core developer experience makes
you spend a lot of mental energy. And the last one is morale, right? Every time we started a new company or on
a new project, we’re often really excited. Some new and build something exciting. And as the poor developer experience of the
tools we use continues to grind on us, we’re just ready to — that’s kind of a morale aspect. So again, not investing in developer experience
today is costing us, at least from my perspective, fiscal mental energy and morale. But what do we do about it? That sounds great, but what do we do in there’s
a lot we can do. Before we start looking at what we can do,
we need to break down developer experience into two main categories. The first category is developer experience
of you as a tool author building tools for other developers to use it. And the second, and a major facet is working
with other developers on a project. So the developer experience is working on
a project together. And the reason I split this into two main
categories will become more evident as we look at the specific implementation and improvements. And if we look at how do we improve it, we
need to look at the experience lifecycle. And what I mean by that is from the start
of using a project or starting to work on a project with somebody else to maybe making
that first commit or making that first change, to your day-to-day interactions on the tool,
and finally, to the retirement. Because everything kind of comes to an end. And we often don’t talk about that. So everything we’re going to talk about today,
all the concepts are going to be translatable, whether you’re a front-end developer, a back-end
developer or working on DevOps tooling, the specific implementation is going to be different,
obviously depending on the tool, but the concept should be translatable. And finally, the lens that we need to take
every time we’re trying to improve developer experience, is one of empathy. I really love this graphic from this comic
from grammarly that kind of distinguishes sympathy and empathy. We don’t want to say that sucks and leave
it at that. We want to say yeah, that sucks and let’s
work together to improve it. That’s the heart of developer experience is
bringing empathy to our customers and to ourselves as well. All right. Let’s get concrete. Let’s put on our steel-toed boots, let’s talk
about a specific problem that we’re going to solve developer. That problem is pair programming. As you probably know one of the big problems
with pair programming is getting that proper attribution. Those sweet GitHub squares. How do you get attributed for the pairing
that you’re doing. There’s a lot of tools out there today and
one of them is called Pair Up. Pair Up has been around for a while. It changes its git author name and author
email name to the different people that are pairing. Now as you can probably tell, one of the problems
with that is going to be you can only pair. Because there’s only two switches there in
git. It doesn’t accurately represent how the work
is being done. It’s not saying two people authored it. Fortunately, about a year and a half ago,
GitHub released a feature that’s considered a standard in the git community where you
add this common trailer that said co-authored by, and that attributes the commit to multiple
authors. And the best part of that is that you can
actually do as many author commits as you want. Up to 12, 14 people and it works beautifully. But the challenge is, Pair Up doesn’t support
this. What we’re going to do together, and again,
I’m just using this as an example, as a scaffold to show you how to improve developer experience. We’re going to build a new tool that replaces
Pair Up and uses this coauthored by concepts. Now the first thing we need to build a new
tool is a snazzy name. What can we call it? Let’s go with Mob Up. Let’s keep it simple. So we’re going to talk about improving or
building Mob Up together and looking at how do we improve the developer experience throughout
the experience lifecycle and we’re going to start working together. So when we get started, one of the first things
we feel when we open up a new code base and we’re working together on something like mob
up is like where the hell am I. It’s a new code base, how does data flow through
the system, this is often a big problem. How do we improve this developer experience? Well, we can use sequence diagrams. I know, a little old school. But with a light touch, we could model something
like pair-up like this, where we can model the interaction and the collaboration of classes
or objects or whatever you want to call them across the data going through the system. And you might bemoan that I have to open up
MS Paint and start drawing it. Fear not you can model all of this as code
using a tool. And my favorite part is pledge has a VS plug-in
that automatically renders the sequence diagram. Awesome develop experience would be to have
data flow diagram showing you how data flows through the system and how the classes interact. We’re ready to make our first commit and our
first pull request. Even if we have the builds all working locally,
this is still kind of a nervous action to make that first pull request. You’re not sure did I miss anything. This is where a really cool feature in GitHub
and GitLab and also a bunch of others have it called pull request templates and using
that to model a checklist that looks like this. As humans, filling of checklist is super gratifying. We can help guide not only new contributors
but also old hats to remind you of what things you might have missed. Consider adding a pull request check. Moving on to our day-to-day interactions,
working together on a tool like Mob Up. What does that look like? Well, one of the first things to kind of help
improve working together, once you have a team that’s larger than a couple of people,
it’s really hard to keep track of what’s happening, what’s been changing. And one of the things that has helped people
a lot over the years is writing a change log. Writing change logs are frustrating. Please don’t take out that frustration when
you write the change log. But one of the things that’s frustrated with
writing a change log is the same thing that’s frustrating you have a blank sheet of paper. What do you do with it. It’s not actually paper, but you know what
I mean. So fortunately there’s a lot of really good
guides out there, my favorite is keep a change log. And once you have some structure, it’s actually
pretty easy to start to fill out what’s been changing. And for a tool like mob up isn’t only helpful
for people like us, but it also helps our users to know what’s happening and what’s
changing. All right. Having an awesome day-to-day experience, keep
a change log. So last part. No matter how much we work on something at
some point, it’s going to be retired. I know this isn’t something we often think
about. But one of the big things with retirement
code base is even if we’re kind of disappointed and sad that it’s changing, if we just leave
the project as is, in the future somebody might stumble on it and think, hm, this is
an interesting chest of information and they may open it up and say look at all this code
that I can start using and they’re getting excited. They may be making a pull request to it and
nobody is responding. So how do we tie up our project and retire
it in a nice, clean fashion. Well, the first thing is aside from marking
it as deprecated, one of the things that I think is valuable to do, is make sure to close
off all the issues that shows that the project isn’t active. People can get confused. But the other aspect of doing that is to keep
the code in a clean state. Not only because you might come back to it
in years from the future. Maybe Mob Up will become popular again and
we’ll want to add to it, but also because as developers we often go back and copy-paste
our old code. And if we keep that old code in a good working
state, that makes it easier for us. And it makes it obvious to other people that
it’s not in use. And the other big one is archive the project. Many of today’s source control systems have
this feature. Archive it and mark it as read only. So having an awesome developer experience,
retiring the project. We want to leave the code in a good working
state, and you want to archive it. So let’s look over how do we have an awesome
developer experience working on a tool like mobup? First we have a data sequence program, a check
log and a code state. Let’s move on to the next aspect. And that is improving the experience working
as a tool author for the people who are working on our tool. Before we do that we’re going to have to do
a tangent. Bear with me. We need a tangent to determine what kind of
tool we’re going to build. And my argument is we should build tools that
meet developers where they’re at. In their mother’s basement? No. I mean at a start-up conference? No no. You can find developers there. But what I really mean is meeting developers
where they’re at in terms of the tools they’re using. And that’s day-to-day, they’re in the text
editor or IDE of choice and they’re running or testing their application in their terminal
of choice. If we think long and hard if we’re building
a new tool for developers, do we start the GUI first or do we start CLI first? So if we’re going to meet developers where
they’re at, my argument is we start CLI first. My arguments is starting with CLI first does
not preclude building a UI later, but starting with a UI first often precludes building a
CLI afterwards. And as developers, we’re probably working
on web apps most of the time, so we feel more comfortable in that realm. But when we use tools, think about it the
tools you’re using to build those web apps are usually CLI tools. So let’s have that empathy and meet developers
where they’re at. The best part is we can have developers start
using it right away, right? And if we build that CLI on a well-factored
code base, we may have another developer who joins who’s really interested in the internals
of mob up and she might build a web app for a business user to use. A business user who wants to see who’s mobbing. And how long they’re mobbing for. Later you might build an IDE plugin or whatever
that’s built on top of the CLI which brings in a whole bunch of other developers. The point is, starting CLI first kind of gives
you the best of both worlds. Because you can start to meet developers where
they’re at, but it does not preclude you from building it later on. So with that tangent out of the way, let’s
look at how do weigh improve the developer experience as a tool author for other people
using our tool. So getting started with a new tool is often
a frustrating experience, because we’re looking to figure out how to install the tool. That’s our first interaction. And if you provide your developer with a big
checklist of install this programming language, these dependencies, et cetera, guess what? They’re not going to be very happy. So again, we’re bringing empathy, we’re trying
to meet developers where they’re add and that means providing a tool where developers are
familiar with. Something like a whole new package, a native
package, or the devil’s tool. If you’re not sure why, it’s. . . Anyway. All of those are really great if your tool
fits into a nice binary package that’s easy to install across OS’s and usually if you’ve
built a tool. If you’ve built a tool on something else,
lake many tools are built, the installation process might be a bit more with terrible. How do we solve that? How do we make that really awesome developer
experience regardless of the tool you build it in? Well, it wouldn’t be a DevOps conference if
I didn’t bring up docker. We take our tool and package it into another
tool. If we throw a little shell script on top of
our image, all of a sudden we can provide this shell script as the executable, and it
feels and behaves just like a CLI, but under the hood it’s running an image. And we found this super valuable especially
if you need OS’s that are difficult to install. This is a great way to package your tool and
it’s cross platform and works the same way. So that’s how we make an awesome getting started
experience with their tool. So package it in or meet developers where
they’re at with a one-liner install, and if it’s not easy to install. Moving on, to that first experience of using
the tool. So when we use the tool, I like to think of
that tool as first contact. That’s our first interaction. And just the first commit, first contact is
often I don’t know, is this going to work or not. So what we need to do is we need to take the
nervous part out of that by helping guide the user with that initial interaction. So if instead of the way Pair Up works today,
we ask the user for all of the details for how to configure and pair with somebody, what
if instead as an awesome developer experience, we do the work on the users we have, and we
go and we talk to say GitHub API offer whatever internal API and get their full name and email. Until even we’re taking the nervous part out
of it, we’re driving the users, making it a much nicer and cleaner experience. That’s how weigh make an awesome developer
experience for that first commit. Moving on to the day-to-day. So what is the best way to make developers
frustrated in their day-to-day interaction with your tool? It’s by having bad error messages. Those don’t help guide you. Many of you have probably seen these kind
of error messages, and if you wonder not only is it telling me what’s wrong, but it also
tells me what to do, can I actually do that myself? The answer is yes. And the way we do that, and I’m not sure this
is the way GitHub has implemented it. But the way that we can do that is using something
called Levenshtein which is something not so simple mathematical formula, before you
throw me off the stage, let’s look at an example. So a Levenshtein distance formula, what it
does, it takes two words and you plug it into this algorithm and out pops a number. So in this example, we start with the word
kitten and we see what the leverage and distance is to sitting. And it’s 3. We changed three characters and it becomes
sitting. You might be wondering do I have to implement
this myself? No you don’t. Many programming languages if you look it
up, Levenshtein is implemented. So we can pull a tool off the Internet and
we can use it in a — we can use it in our CLI to do something like this. For example, configurations are often fraught
with typos and other errors. And most tools just explode and say oh, something
is wrong. So instead of just exploding and saying something
is wrong, we can actually take — we know what the key words are for our configuration. We need name, email, timeouts, whatever. There’s a finite set of words. We run a Levenshtein distance against each
of those keywords. Whichever is closest we say use this one. We have useful messages how to guide you. We can do that with mob up and make that awesome
developer experience in that day-to-day interaction catching errors and guiding users how to improve
it. Remember, empathy. Finally, regardless of the blood, sweat and
tears we put into our tool, at some point it’s going to be retired. So how do we include the retirement of our
tools for other users. Often times tools are retired because there
are another tool that’s replacing it. Our role, what we need to do for our users,
is to provide that bridge for that next tool. You might look, there’s three other tools
that replace the tool that we’re using, make the evaluation, find the one you think is
best for your users, and clearly communicate the best tool to go to. But to take it up a notch, we should do the
migration for the user. If we deprecate something like mob up, can’t
read this blog post online, we’ve identified this as the replacement and do you want me
to do the migration for you and guide the user to the next step of getting started. That’s how we make a graceful retirement as
a tool author. Clear migration off of the tool. How do we make an awesome developer experience. You provide one-line installs, we do the work
on the users we have, we Levenshtein distance and finally a clear migration path. That was a lot to cover. Let’s do a quick replay of what we just did. So we started off with user experience, in
talking about how over the last decade we’ve missed out on a lot by not focusing on user
experience. We then discussed what are the various aspects
that we’re missing out on. Monetary, mental energy and morale. We saw some tactical, specific ways to address
developer experience working together, and working on the tool. So other developers are using it. So really I ask you, what are you waiting
for to improve developer experience today? Take one or two of these tips, apply them,
and turn your angry developers into happy developers. I’m Arthur Maltson. I work at Capital One. And thank you. [ Applause ]
We are hiring, we’re opening a Boston office. I’m going to quickly plug that. I will post this version of the slides there
on the slide share. Other links, Mob Up is empty rate now. Maybe at some point I’ll work on it. Any questions?>>You have like two minutes. ARTHUR: Questions?>>Audience: I had a question for you. When you talk about building on the CLI tools,
is there a platform you go to for the some of the base CLI functionality? Do you know libraries or — what’s your tool
chain for that. ARTHUR: So personally we use a lot of python. Click is a really awesome CLI library. I know for go language we hope to go to later
as cobra which is really great. I do think if you’re starting out super small
start with what’s built in. As soon as you start to get into a more complex
library, I highly recommend using — more complex CLI, I highly recommend using a library
for that.>>Just a reminder, if you could please talk
into the microphone, not only can everyone can hear but also our lovely recording folks
can record this. ARTHUR: The question was what library does
the person recommend for building CLIs. Any other questions? All right. Well, thank you everybody. Really appreciate it. As I said I’ll post the slides. Feel free to come and talk to me after the
talk. Thank you so much. [ Applause ]

Leave a Reply

Your email address will not be published. Required fields are marked *