One evening you’re browsing Twitter and you stumble on a really cool new Open Source tool. The README is intuitive, the installation is seamless and you’re up and running in no time. When using the tool, error messages are clear and how to fix the issues obvious. Before you know it, you’ve achieved what you wanted and you feel like a superstar! But the experience is very different the next day at work. You just spent a couple weeks fiddling to get a project running locally but now you have to jump through hoops to get the application built and deployed with that dreadful internal tool. Why can’t our day time experiences look like our weekend passion projects? It can!
In this session you’ll be introduced to the concept of Developer Experience and why it matters. You’ll then embark on a journey to build a new tool with Developer Experience as a core focus. You’ll learn how certain targeted approaches can improve the Developer Experience through the entire Experience Lifecycle. At the end of the talk you will be equipped with ways to improve the Developer Experience in your work; whether you’re building tools for developers, collaborating with other developers on a business project, or just building a side project one your own.
This is the version of the presentation given at Web Unleashed 2019.
2. User Experience
@amaltson
Speaker Note: Before we start talking about
Developer Experience, let’s start off with a
fairly well know concept, User Experience. We
can over simplify the concept to taking angry
customers and with some research, design,
aesthetics and functionality changes turn them
into happy customers. But User Experience
wasn’t always considered important.
3. User Experience
😡
@amaltson
Speaker Note: Before we start talking about
Developer Experience, let’s start off with a
fairly well know concept, User Experience. We
can over simplify the concept to taking angry
customers and with some research, design,
aesthetics and functionality changes turn them
into happy customers. But User Experience
wasn’t always considered important.
4. User Experience
😡😄
@amaltson
Speaker Note: Before we start talking about
Developer Experience, let’s start off with a
fairly well know concept, User Experience. We
can over simplify the concept to taking angry
customers and with some research, design,
aesthetics and functionality changes turn them
into happy customers. But User Experience
wasn’t always considered important.
5. @amaltson
Speaker Note: Even as recent as 2005 this is
what websites looked like. But in only the
span of a decade and a bit…
8. ✨
✨
✨
✨
@amaltson
Speaker Note: But did this happen because
we sprinkled some magic pixie dust on the
website and made it more functional and
aesthetically pleasing. No! It took a bunch of
research and experimentation through which
we built up a knowledge base. We then took
that knowledge, applied our creativity and
engineering prowess. Did this happen
because of a fundamental technology shift?
Not really, I mean sure JavaScript, HTML, and
CSS have evolved, but much of the underlying
capability was already in place in 2005. What it
required was a prospective change. You’ll note
that I’m talking about MapQuest here and not
Google Maps, because in 2005 Google Maps
looked very similar to how it looks now. They
understood and invested in UX, they had
made the prospective change.
9. ✨
✨
✨
✨
%
@amaltson
Speaker Note: But did this happen because
we sprinkled some magic pixie dust on the
website and made it more functional and
aesthetically pleasing. No! It took a bunch of
research and experimentation through which
we built up a knowledge base. We then took
that knowledge, applied our creativity and
engineering prowess. Did this happen
because of a fundamental technology shift?
Not really, I mean sure JavaScript, HTML, and
CSS have evolved, but much of the underlying
capability was already in place in 2005. What it
required was a prospective change. You’ll note
that I’m talking about MapQuest here and not
Google Maps, because in 2005 Google Maps
looked very similar to how it looks now. They
understood and invested in UX, they had
made the prospective change.
10. ✨
✨
✨
✨
% 📚
@amaltson
Speaker Note: But did this happen because
we sprinkled some magic pixie dust on the
website and made it more functional and
aesthetically pleasing. No! It took a bunch of
research and experimentation through which
we built up a knowledge base. We then took
that knowledge, applied our creativity and
engineering prowess. Did this happen
because of a fundamental technology shift?
Not really, I mean sure JavaScript, HTML, and
CSS have evolved, but much of the underlying
capability was already in place in 2005. What it
required was a prospective change. You’ll note
that I’m talking about MapQuest here and not
Google Maps, because in 2005 Google Maps
looked very similar to how it looks now. They
understood and invested in UX, they had
made the prospective change.
11. ✨
✨
✨
✨
%
'
📚
@amaltson
Speaker Note: But did this happen because
we sprinkled some magic pixie dust on the
website and made it more functional and
aesthetically pleasing. No! It took a bunch of
research and experimentation through which
we built up a knowledge base. We then took
that knowledge, applied our creativity and
engineering prowess. Did this happen
because of a fundamental technology shift?
Not really, I mean sure JavaScript, HTML, and
CSS have evolved, but much of the underlying
capability was already in place in 2005. What it
required was a prospective change. You’ll note
that I’m talking about MapQuest here and not
Google Maps, because in 2005 Google Maps
looked very similar to how it looks now. They
understood and invested in UX, they had
made the prospective change.
12. ✨
✨
✨
✨
%
'
📚
(+
@amaltson
Speaker Note: But did this happen because
we sprinkled some magic pixie dust on the
website and made it more functional and
aesthetically pleasing. No! It took a bunch of
research and experimentation through which
we built up a knowledge base. We then took
that knowledge, applied our creativity and
engineering prowess. Did this happen
because of a fundamental technology shift?
Not really, I mean sure JavaScript, HTML, and
CSS have evolved, but much of the underlying
capability was already in place in 2005. What it
required was a prospective change. You’ll note
that I’m talking about MapQuest here and not
Google Maps, because in 2005 Google Maps
looked very similar to how it looks now. They
understood and invested in UX, they had
made the prospective change.
13. @amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
14. 💵
@amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
15. 💵 📈
@amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
16. 💵 📈💰💰💰
@amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
17. 💵 📈💰💰💰
@amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
18. 💵 📈💰💰💰
@amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
19. 💵 📈💰💰💰
@amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
20. 💵 📈💰💰💰
@amaltson
Speaker Note: But what caused this change?
Businesses and individuals saw that when you
invest a bit of money in the form of creativity
and developer time into User Experience,
they’d see a big increase in users and make a
huge return on those investments. One of the
earliest companies to see this was Apple when
they took a sledgehammer to the boring
beige boring boxes and as Steve Jobs said,
it’s not just the aesthetics but the functionality,
you need both. But it’s not just Apple saying
it, studies from Google, IBM and many others
point to the importance and RIO focusing on
UX.
21. User Experience
@amaltson
Speaker Note: Looking back on only a
decade, we clearly know how much we missed
out on by not focusing in User Experience and
have remedied that now. The question is, what
are we missing out on by…
23. Developer Experience
😡💻
@amaltson
Speaker Note: Good question, we haven’t
defined it yet. Developer Experience is similar
to User Experience in that we take a frustrate
developer, make a bunch of changes to the
tool or the project they’re working on, and get
a happy developer.
24. Developer Experience
😡💻😄
@amaltson
Speaker Note: Good question, we haven’t
defined it yet. Developer Experience is similar
to User Experience in that we take a frustrate
developer, make a bunch of changes to the
tool or the project they’re working on, and get
a happy developer.
25. @amaltson
Speaker Note: Someone that saw this early
on is was Steve Ballmer with the famous
“developers, developers, developers”. I hope
to not get that sweaty.
26. @amaltson
Speaker Note: Someone that saw this early
on is was Steve Ballmer with the famous
“developers, developers, developers”. I hope
to not get that sweaty.
27. @amaltson
Speaker Note: There’s three main arguments
why Developer Experience is something worth
focusing on and investing in. The first is the
fiscal cost of a poor Developer Experience.
The next is the cost to the mental energy of
developers. And the last is the hit to moral of
a poor developer experience.
28. 💰
@amaltson
Speaker Note: There’s three main arguments
why Developer Experience is something worth
focusing on and investing in. The first is the
fiscal cost of a poor Developer Experience.
The next is the cost to the mental energy of
developers. And the last is the hit to moral of
a poor developer experience.
29. 💰 🧠
@amaltson
Speaker Note: There’s three main arguments
why Developer Experience is something worth
focusing on and investing in. The first is the
fiscal cost of a poor Developer Experience.
The next is the cost to the mental energy of
developers. And the last is the hit to moral of
a poor developer experience.
30. 💰 🧠 😍
@amaltson
Speaker Note: There’s three main arguments
why Developer Experience is something worth
focusing on and investing in. The first is the
fiscal cost of a poor Developer Experience.
The next is the cost to the mental energy of
developers. And the last is the hit to moral of
a poor developer experience.
31. 💰@amaltson
Speaker Note: Technology professionals cost
a lot of money. Overall compared with other
professions we’re doing pretty well. If you
take a group of developers and have them
spend a week on setting up their
workstations, that’s a huge cost.
32. (
💰@amaltson
Speaker Note: Technology professionals cost
a lot of money. Overall compared with other
professions we’re doing pretty well. If you
take a group of developers and have them
spend a week on setting up their
workstations, that’s a huge cost.
33. ( 💰
💰@amaltson
Speaker Note: Technology professionals cost
a lot of money. Overall compared with other
professions we’re doing pretty well. If you
take a group of developers and have them
spend a week on setting up their
workstations, that’s a huge cost.
34. /0
12
( 💰
💰@amaltson
Speaker Note: Technology professionals cost
a lot of money. Overall compared with other
professions we’re doing pretty well. If you
take a group of developers and have them
spend a week on setting up their
workstations, that’s a huge cost.
35. /0
12
💰💰💰
💰💰💰
( 💰
💰@amaltson
Speaker Note: Technology professionals cost
a lot of money. Overall compared with other
professions we’re doing pretty well. If you
take a group of developers and have them
spend a week on setting up their
workstations, that’s a huge cost.
36. 💰 🧠 😍
@amaltson
Speaker Note: That’s the fiscal side, now let’s
talk about the mental energy side.
37. 🧠@amaltson
Speaker Note: To provide a good analogy for
mental energy, let us represent it with a
certain number of coins you start the day with.
Everyone has different energy levels so they’d
start with a different amount. Every decision
we make or frustration we run into will cost
some coins. Steve Jobs recognized this,
choosing to wear the same cloths every day
(black turtle neck and jeans) as a way to
reduce decision points. Imagine how much
energy gets drained frustration with a
corporate proxy or that downstream system
being down.
38. 🧠@amaltson
Speaker Note: To provide a good analogy for
mental energy, let us represent it with a
certain number of coins you start the day with.
Everyone has different energy levels so they’d
start with a different amount. Every decision
we make or frustration we run into will cost
some coins. Steve Jobs recognized this,
choosing to wear the same cloths every day
(black turtle neck and jeans) as a way to
reduce decision points. Imagine how much
energy gets drained frustration with a
corporate proxy or that downstream system
being down.
39. 🧠@amaltson
Speaker Note: To provide a good analogy for
mental energy, let us represent it with a
certain number of coins you start the day with.
Everyone has different energy levels so they’d
start with a different amount. Every decision
we make or frustration we run into will cost
some coins. Steve Jobs recognized this,
choosing to wear the same cloths every day
(black turtle neck and jeans) as a way to
reduce decision points. Imagine how much
energy gets drained frustration with a
corporate proxy or that downstream system
being down.
40. 🧠@amaltson
Speaker Note: To provide a good analogy for
mental energy, let us represent it with a
certain number of coins you start the day with.
Everyone has different energy levels so they’d
start with a different amount. Every decision
we make or frustration we run into will cost
some coins. Steve Jobs recognized this,
choosing to wear the same cloths every day
(black turtle neck and jeans) as a way to
reduce decision points. Imagine how much
energy gets drained frustration with a
corporate proxy or that downstream system
being down.
41. 🧠@amaltson
Speaker Note: To provide a good analogy for
mental energy, let us represent it with a
certain number of coins you start the day with.
Everyone has different energy levels so they’d
start with a different amount. Every decision
we make or frustration we run into will cost
some coins. Steve Jobs recognized this,
choosing to wear the same cloths every day
(black turtle neck and jeans) as a way to
reduce decision points. Imagine how much
energy gets drained frustration with a
corporate proxy or that downstream system
being down.
42. 🧠@amaltson
Speaker Note: To provide a good analogy for
mental energy, let us represent it with a
certain number of coins you start the day with.
Everyone has different energy levels so they’d
start with a different amount. Every decision
we make or frustration we run into will cost
some coins. Steve Jobs recognized this,
choosing to wear the same cloths every day
(black turtle neck and jeans) as a way to
reduce decision points. Imagine how much
energy gets drained frustration with a
corporate proxy or that downstream system
being down.
43. 🧠@amaltson
Speaker Note: To provide a good analogy for
mental energy, let us represent it with a
certain number of coins you start the day with.
Everyone has different energy levels so they’d
start with a different amount. Every decision
we make or frustration we run into will cost
some coins. Steve Jobs recognized this,
choosing to wear the same cloths every day
(black turtle neck and jeans) as a way to
reduce decision points. Imagine how much
energy gets drained frustration with a
corporate proxy or that downstream system
being down.
45. 😍@amaltson
Speaker Note: From a moral prospective,
most developers start off with a lot of
excitement and energy. But as the days and
weeks go by, and the workstation issues drain
the first few weeks, access control the next
week, misleading docs, poor error messages,
and well, eventually you’re punching through
your laptop.
46. 😍
😍@amaltson
Speaker Note: From a moral prospective,
most developers start off with a lot of
excitement and energy. But as the days and
weeks go by, and the workstation issues drain
the first few weeks, access control the next
week, misleading docs, poor error messages,
and well, eventually you’re punching through
your laptop.
47. 😍😀
😍@amaltson
Speaker Note: From a moral prospective,
most developers start off with a lot of
excitement and energy. But as the days and
weeks go by, and the workstation issues drain
the first few weeks, access control the next
week, misleading docs, poor error messages,
and well, eventually you’re punching through
your laptop.
48. 😍😀🙂
😍@amaltson
Speaker Note: From a moral prospective,
most developers start off with a lot of
excitement and energy. But as the days and
weeks go by, and the workstation issues drain
the first few weeks, access control the next
week, misleading docs, poor error messages,
and well, eventually you’re punching through
your laptop.
49. 😍😀🙂🙁
😍@amaltson
Speaker Note: From a moral prospective,
most developers start off with a lot of
excitement and energy. But as the days and
weeks go by, and the workstation issues drain
the first few weeks, access control the next
week, misleading docs, poor error messages,
and well, eventually you’re punching through
your laptop.
50. 😍😀🙂🙁😡
😍@amaltson
Speaker Note: From a moral prospective,
most developers start off with a lot of
excitement and energy. But as the days and
weeks go by, and the workstation issues drain
the first few weeks, access control the next
week, misleading docs, poor error messages,
and well, eventually you’re punching through
your laptop.
51. 😍😀🙂🙁😡
😍@amaltson
Speaker Note: From a moral prospective,
most developers start off with a lot of
excitement and energy. But as the days and
weeks go by, and the workstation issues drain
the first few weeks, access control the next
week, misleading docs, poor error messages,
and well, eventually you’re punching through
your laptop.
54. Developer Experience
💰 🧠
@amaltson
Speaker Note: So why should you care about
developer experience? For fiscal reasons,
optimizing metal energy use and improving
overall moral.
55. Developer Experience
💰 🧠 😍
@amaltson
Speaker Note: So why should you care about
developer experience? For fiscal reasons,
optimizing metal energy use and improving
overall moral.
56. @amaltson
Speaker Note: OK, but now what? Yes it
matters, but how do we even go about
improving developer experience?
57. @amaltson
Speaker Note: OK, but now what? Yes it
matters, but how do we even go about
improving developer experience?
58. @amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
59. 🛠
@amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
60. 🛠 7
@amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
61. Experience Lifecycle
🛠 7
@amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
62. Experience Lifecycle
8
🛠 7
@amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
63. Experience Lifecycle
9
🛠 7
@amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
64. Experience Lifecycle
:
🛠 7
@amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
65. Experience Lifecycle
;
🛠 7
@amaltson
Speaker Note: Before we start improving it,
we need to understand what we’re dealing
with. There’s two distinct facets of developer
experience, one is the developer experience
of using a tool and Developer Experience
working on a project with others. To fully
understand how to improve Developer
Experience in those facets, we need to
understand the entire “Experience Lifecycle”.
From the very beginning, eg. first time you
join the team or just started using that tool. To
your first major change or your first couple
days with the tool. To the day-to-day working
on a code base or using the tool. And finally
to the retirement of the project or your
migration away from the tool you’re using.
66. @amaltson
Speaker Note: The concepts carries over
regardless of whether you’re doing front end
development, backend development or batch,
but the specific implementation will differ
depending on the language.
67. @amaltson
Speaker Note: The concepts carries over
regardless of whether you’re doing front end
development, backend development or batch,
but the specific implementation will differ
depending on the language.
68. @amaltson
Speaker Note: The concepts carries over
regardless of whether you’re doing front end
development, backend development or batch,
but the specific implementation will differ
depending on the language.
69. @amaltson
Speaker Note: The concepts carries over
regardless of whether you’re doing front end
development, backend development or batch,
but the specific implementation will differ
depending on the language.
70. @amaltson
Speaker Note: Our guiding principle for
improving developer experience should be
empathy. Being empathetic with others and
with yourself. We’re not trying to be
sympathetic as in “oh it sucks”, we want to
acknowledge we and others feel and provide
a concrete improvement.
72. @amaltson
Speaker Note: And that specific problem is
how to do pair programs or even mob
programming, but how do you ensure
everyone gets a bit of that sweet, sweet green
GitHub squares?
73. 😿
@amaltson
Speaker Note: You know what I mean, we
want those sweet green squares filling the
whole timeline! We need to attribute work to
everyone mobbing.
74. @amaltson
There are a bunch of tools out there to give
the proper attribution, one of them is called
Pair Up. Pair Up achieves this by using a
little trick in Git, it sets the
GIT_AUTHOR_NAME/EMAIL to the primary
person and the GIT_COMMITTER_NAME/
EMAIL to the pair. But this only works for
pairing, not mobbing since you can only set
for two people. It also doesn’t fully reflect
how the code was written.
75. @amaltson
Speaker Note: Fortunately, a year and a half
ago GitHub added support for the now
standardized “Co-authored-by” syntax in
commit messages, this renders much nicer in
GitHub but the challenge is Pair Up doesn’t
support it.
76. @amaltson
Speaker Note: Fortunately, a year and a half
ago GitHub added support for the now
standardized “Co-authored-by” syntax in
commit messages, this renders much nicer in
GitHub but the challenge is Pair Up doesn’t
support it.
80. Experience Lifecycle
8 9 : ;
🛠 7
@amaltson
Speaker Note: So for this imaginary project,
let’s start by talking about working on a team
with other developers and how to improve the
experience there.
81. Experience Lifecycle
8 9 : ;
7
@amaltson
Speaker Note: So for this imaginary project,
let’s start by talking about working on a team
with other developers and how to improve the
experience there.
82. Getting Started 8
7@amaltson
Speaker Note: The getting started
experience is all about starting on a new
project or code base. The fastest way to have
a terrible start is an empty README. I’m sure
we’ve all see this too often. But let’s be
honest, it’s really hard to write a good
README, especially when starting from an
empty page. Fortunately..
83. Getting Started 8😡
7@amaltson
Speaker Note: The getting started
experience is all about starting on a new
project or code base. The fastest way to have
a terrible start is an empty README. I’m sure
we’ve all see this too often. But let’s be
honest, it’s really hard to write a good
README, especially when starting from an
empty page. Fortunately..
84. Getting Started 8🙁
7@amaltson
Speaker Note: There’s a really great blog post
that I come back to time and time again on
how to write a friendly README that’s
welcoming and helps improve that getting
started experience. But even with a good
README..
85. Getting Started 8🙁
7@amaltson
Speaker Note: .. starting a new code base
often feels like this. Right? Where do you even
start with the code, how do you get in and
start understanding it?
86. Getting Started 8🙁
7@amaltson
Speaker Note: One approach my team and I
have found a lot of success with is using
sequence diagrams. It’s a bit old school, but it
can really help paint a picture of how data
flows through your system at a high level and
that’s really important to know how the code
interacts. Now you might bemoan opening a
diagram drawing tool, and it’s hard to source
control but what you don’t know is that
diagram is generated from source code using
PlantUML.
87. Getting Started 8🙁😐
7@amaltson
Speaker Note: One approach my team and I
have found a lot of success with is using
sequence diagrams. It’s a bit old school, but it
can really help paint a picture of how data
flows through your system at a high level and
that’s really important to know how the code
interacts. Now you might bemoan opening a
diagram drawing tool, and it’s hard to source
control but what you don’t know is that
diagram is generated from source code using
PlantUML.
88. Getting Started 8🙁😐
7@amaltson
Speaker Note: One approach my team and I
have found a lot of success with is using
sequence diagrams. It’s a bit old school, but it
can really help paint a picture of how data
flows through your system at a high level and
that’s really important to know how the code
interacts. Now you might bemoan opening a
diagram drawing tool, and it’s hard to source
control but what you don’t know is that
diagram is generated from source code using
PlantUML.
89. Getting Started 8
7@amaltson
🙂
Speaker Note: The best part is, there’s a
VSCode plugin for PlantUML which live
previews the diagram. Makes it really easy to
author them.
90. 7@amaltson
Speaker Note: Now we need to get the
project running locally. For that we need
workstation setup. Throughout the years I’ve
seen 3 maturity levels for workstation setup.
91. Getting Started 8
7@amaltson
Speaker Note: The first level of maturity is
relying on tribal knowledge. Lore that’s passed
down from one developer to the next, usually
ending with “huh, well that used to work”.
92. Getting Started 8😖
7@amaltson
Speaker Note: The first level of maturity is
relying on tribal knowledge. Lore that’s passed
down from one developer to the next, usually
ending with “huh, well that used to work”.
93. 😖 Getting Started 8
7@amaltson
Speaker Note: The next level is the famous
wiki page of doom with all the manual steps
required to setup your workstation. While
sometimes overwhelming, often out of date,
it’s still better than tribal knowledge.
94. Getting Started 8😅
7@amaltson
Speaker Note: The next level is the famous
wiki page of doom with all the manual steps
required to setup your workstation. While
sometimes overwhelming, often out of date,
it’s still better than tribal knowledge.
95. Getting Started😅 8
7@amaltson
Speaker Note: Finally, the third level of
maturity, and by far the preferred, is a fully
automated setup. It shouldn’t get out of date
because it’s automated and when you keep it
to a one liner, it’s easy to follow.
96. Getting Started😅 8🤩
7@amaltson
Speaker Note: Finally, the third level of
maturity, and by far the preferred, is a fully
automated setup. It shouldn’t get out of date
because it’s automated and when you keep it
to a one liner, it’s easy to follow.
98. Getting Started
• Friendly README
8🤩
7@amaltson
Speaker Note: In order to create an amazing
getting started experience to work together
on mob-up we need to..
99. Getting Started
• Friendly README
• Data Flow Diagram
8🤩
7@amaltson
Speaker Note: In order to create an amazing
getting started experience to work together
on mob-up we need to..
100. Getting Started
• Friendly README
• Data Flow Diagram
• Workstation Setup (that works!)
8🤩
7@amaltson
Speaker Note: In order to create an amazing
getting started experience to work together
on mob-up we need to..
103. First Commit 9😰
7@amaltson
Speaker Note: The first commit is often
anxiety ridden, so the first thing we can do to
ease the concern is ensure the main branch is
always green. Both in your CI/CD server and
on the workstation, the build should work
cleanly. This is critical for building up that
confidence to make that first change and
know that it works.
104. First Commit 9😰
7@amaltson
Speaker Note: The first commit is often
anxiety ridden, so the first thing we can do to
ease the concern is ensure the main branch is
always green. Both in your CI/CD server and
on the workstation, the build should work
cleanly. This is critical for building up that
confidence to make that first change and
know that it works.
105. First Commit 9😰
7@amaltson
Speaker Note: The first commit is often
anxiety ridden, so the first thing we can do to
ease the concern is ensure the main branch is
always green. Both in your CI/CD server and
on the workstation, the build should work
cleanly. This is critical for building up that
confidence to make that first change and
know that it works.
106. First Commit 9😰
7@amaltson
Speaker Note: The first commit is often
anxiety ridden, so the first thing we can do to
ease the concern is ensure the main branch is
always green. Both in your CI/CD server and
on the workstation, the build should work
cleanly. This is critical for building up that
confidence to make that first change and
know that it works.
107. First Commit 9😨
7@amaltson
Speaker Note: The first commit is often
anxiety ridden, so the first thing we can do to
ease the concern is ensure the main branch is
always green. Both in your CI/CD server and
on the workstation, the build should work
cleanly. This is critical for building up that
confidence to make that first change and
know that it works.
108. First Commit 9😌
7@amaltson
Speaker Note: Even once that new team
member has a change ready and working
locally, it’s often stressful to open the Pull
Request because you’re not sure what’s
expected of you. This is where using GitHub’s
awesome Pull Request templates, you can
guide the user through the expectations and
have them feel like a super star.
109. First Commit 9🤩
7@amaltson
Speaker Note: Even once that new team
member has a change ready and working
locally, it’s often stressful to open the Pull
Request because you’re not sure what’s
expected of you. This is where using GitHub’s
awesome Pull Request templates, you can
guide the user through the expectations and
have them feel like a super star.
111. First Commit
• Pipeline Green
9🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the first commit to
mob-up..
112. First Commit
• Pipeline Green
• GitHub Templates
9🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the first commit to
mob-up..
113. 9
7@amaltson
Speaker Note: Alright, that’s the first commit
experience. Let’s now look at improving the
Developer Experience in our day to day.
114. :
7@amaltson
Speaker Note: Alright, that’s the first commit
experience. Let’s now look at improving the
Developer Experience in our day to day.
115. Day to Day🤩 :
7@amaltson
Speaker Note: We’ve all had the day to day
wear off our initial awesome feeling, and why
is that? In Rich Hickey’s awesome talk, Simple
Made Easy, he has a great analogy for what
day to day working with your code feels like.
Think of your code as a member of your
standup, at first it’s kind of shy and off to the
side, not very imposing.
116. Day to Day :😐
7@amaltson
Speaker Note: We’ve all had the day to day
wear off our initial awesome feeling, and why
is that? In Rich Hickey’s awesome talk, Simple
Made Easy, he has a great analogy for what
day to day working with your code feels like.
Think of your code as a member of your
standup, at first it’s kind of shy and off to the
side, not very imposing.
117. Day to Day :😐
7@amaltson
Speaker Note: We’ve all had the day to day
wear off our initial awesome feeling, and why
is that? In Rich Hickey’s awesome talk, Simple
Made Easy, he has a great analogy for what
day to day working with your code feels like.
Think of your code as a member of your
standup, at first it’s kind of shy and off to the
side, not very imposing.
118. Day to Day :😐
7@amaltson
Speaker Note: And that member starts to
grow day by day, interacts with other systems
and becomes an active member of the
standup. But the problem is, it keeps growing
day by day as you add more and more code
until…
119. Day to Day :😐
7@amaltson
Speaker Note: The code eventually crowds
out everything else and consumes all your free
time just feeding the legacy code. Many of
you have probably experienced this, so how
can we make this experience better?
120. Day to Day :😐
7@amaltson
Speaker Note: We start with consistency. You
wouldn’t decorate your bedroom in a goth
style, make the kitchen modern and have your
bathroom in a 18th century style.
121. Day to Day :😐
7@amaltson
Speaker Note: We start with consistency. You
wouldn’t decorate your bedroom in a goth
style, make the kitchen modern and have your
bathroom in a 18th century style.
122. Day to Day :😐
7@amaltson
Speaker Note: We start with consistency. You
wouldn’t decorate your bedroom in a goth
style, make the kitchen modern and have your
bathroom in a 18th century style.
123. Day to Day :😐
7@amaltson
Speaker Note: We start with consistency. You
wouldn’t decorate your bedroom in a goth
style, make the kitchen modern and have your
bathroom in a 18th century style.
124. Day to Day :😐
7@amaltson
Speaker Note: For example, if your codebase
today uses Jasmine for testing but you’re all
excited about introducing Jest, do it at a small
scale and then get the team’s buy in. If
everyone agrees, replace all the tests, don’t
leave it partially done. If the team isn’t bought
in, don’t leave the experiment in, remove it.
Keep it consistent, that’s critical.
125. Day to Day :😐🙂
7@amaltson
Speaker Note: For example, if your codebase
today uses Jasmine for testing but you’re all
excited about introducing Jest, do it at a small
scale and then get the team’s buy in. If
everyone agrees, replace all the tests, don’t
leave it partially done. If the team isn’t bought
in, don’t leave the experiment in, remove it.
Keep it consistent, that’s critical.
126. Day to Day :🙂
7@amaltson
To improve the Developer Experience working
together further, consider keeping a
changelog of what’s been change in the
application. Keep track of changes is hard, but
writing a CHANGELOG shouldn’t be about
expressing that frustration 😉. One aspect
that’s hard with writing a CHANGELOG is
similar to starting a README, a blank page is
hard to fill in. This is where the excellent
keepachangelog.com comes in. It provides a
handy and clean template for standardizing
your CHANGELOG and guiding you through
the process of writing it.
127. Day to Day :🙂
7@amaltson
To improve the Developer Experience working
together further, consider keeping a
changelog of what’s been change in the
application. Keep track of changes is hard, but
writing a CHANGELOG shouldn’t be about
expressing that frustration 😉. One aspect
that’s hard with writing a CHANGELOG is
similar to starting a README, a blank page is
hard to fill in. This is where the excellent
keepachangelog.com comes in. It provides a
handy and clean template for standardizing
your CHANGELOG and guiding you through
the process of writing it.
128. Day to Day :🙂
7@amaltson
To improve the Developer Experience working
together further, consider keeping a
changelog of what’s been change in the
application. Keep track of changes is hard, but
writing a CHANGELOG shouldn’t be about
expressing that frustration 😉. One aspect
that’s hard with writing a CHANGELOG is
similar to starting a README, a blank page is
hard to fill in. This is where the excellent
keepachangelog.com comes in. It provides a
handy and clean template for standardizing
your CHANGELOG and guiding you through
the process of writing it.
129. Day to Day :🙂
7@amaltson
To improve the Developer Experience working
together further, consider keeping a
changelog of what’s been change in the
application. Keep track of changes is hard, but
writing a CHANGELOG shouldn’t be about
expressing that frustration 😉. One aspect
that’s hard with writing a CHANGELOG is
similar to starting a README, a blank page is
hard to fill in. This is where the excellent
keepachangelog.com comes in. It provides a
handy and clean template for standardizing
your CHANGELOG and guiding you through
the process of writing it.
130. Day to Day :🙂😁
7@amaltson
To improve the Developer Experience working
together further, consider keeping a
changelog of what’s been change in the
application. Keep track of changes is hard, but
writing a CHANGELOG shouldn’t be about
expressing that frustration 😉. One aspect
that’s hard with writing a CHANGELOG is
similar to starting a README, a blank page is
hard to fill in. This is where the excellent
keepachangelog.com comes in. It provides a
handy and clean template for standardizing
your CHANGELOG and guiding you through
the process of writing it.
131. Day to Day :🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the day to day in
mob-up..
132. Day to Day
• Consistency
:🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the day to day in
mob-up..
133. Day to Day
• Consistency
• CHANGELOGs
:🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the day to day in
mob-up..
134. :
7@amaltson
Speaker Note: No matter how well we’ve
factored the code is, at one point or another a
project comes to an end and is retired. Let’s
look at how to make a great Developer
Experience for retiring a project like mob up.
135. ;
7@amaltson
Speaker Note: No matter how well we’ve
factored the code is, at one point or another a
project comes to an end and is retired. Let’s
look at how to make a great Developer
Experience for retiring a project like mob up.
136. Retirement ;😔
7@amaltson
Speaker Note: While the team is probably sad
about the project retiring, let’s think about the
developer experience of others who may
stumble on the code later on. They might see
it as a treasure chest of awesome capability,
and get confused when they open it up and
the project hasn’t been touched in some time.
They might even mistakenly send a PR to the
project, then get confused and sad when it’s
not actioned.
137. Retirement ;🧐
7@amaltson
Speaker Note: While the team is probably sad
about the project retiring, let’s think about the
developer experience of others who may
stumble on the code later on. They might see
it as a treasure chest of awesome capability,
and get confused when they open it up and
the project hasn’t been touched in some time.
They might even mistakenly send a PR to the
project, then get confused and sad when it’s
not actioned.
138. Retirement ;
7
🥳
@amaltson
Speaker Note: While the team is probably sad
about the project retiring, let’s think about the
developer experience of others who may
stumble on the code later on. They might see
it as a treasure chest of awesome capability,
and get confused when they open it up and
the project hasn’t been touched in some time.
They might even mistakenly send a PR to the
project, then get confused and sad when it’s
not actioned.
139. Retirement ;
7
🤨
@amaltson
Speaker Note: While the team is probably sad
about the project retiring, let’s think about the
developer experience of others who may
stumble on the code later on. They might see
it as a treasure chest of awesome capability,
and get confused when they open it up and
the project hasn’t been touched in some time.
They might even mistakenly send a PR to the
project, then get confused and sad when it’s
not actioned.
140. Retirement ;
7
😟
@amaltson
Speaker Note: While the team is probably sad
about the project retiring, let’s think about the
developer experience of others who may
stumble on the code later on. They might see
it as a treasure chest of awesome capability,
and get confused when they open it up and
the project hasn’t been touched in some time.
They might even mistakenly send a PR to the
project, then get confused and sad when it’s
not actioned.
141. Retirement ;
7
😟
@amaltson
Speaker Note: How do we turn that frown
upside-down? First thing is first, a clear
deprecation notice on the README. But
unfortunately most developers don’t read the
documentation.
142. Retirement ;
7
😶
@amaltson
Speaker Note: How do we turn that frown
upside-down? First thing is first, a clear
deprecation notice on the README. But
unfortunately most developers don’t read the
documentation.
143. Retirement ;
7
😶
@amaltson
Speaker Note: The next major undertaking to
improve the experience is to leave the project
in a good state. Close off all the issues, maybe
marking them as “won’t fix”, but at least
closing them off. Try to get the open PRs
merged in. Make sure to leave the build
green. Why you may ask? Leaving everything
in a clean state is important not necessarily
because the project may come back, which is
possible, but more because you may come
back and reuse some of the code and leaving
it in a good state will facilitate reuse.
144. Retirement ;
7
🙂
@amaltson
Speaker Note: The next major undertaking to
improve the experience is to leave the project
in a good state. Close off all the issues, maybe
marking them as “won’t fix”, but at least
closing them off. Try to get the open PRs
merged in. Make sure to leave the build
green. Why you may ask? Leaving everything
in a clean state is important not necessarily
because the project may come back, which is
possible, but more because you may come
back and reuse some of the code and leaving
it in a good state will facilitate reuse.
145. Retirement ;
7
✅
😀
@amaltson
Speaker Note: The next major undertaking to
improve the experience is to leave the project
in a good state. Close off all the issues, maybe
marking them as “won’t fix”, but at least
closing them off. Try to get the open PRs
merged in. Make sure to leave the build
green. Why you may ask? Leaving everything
in a clean state is important not necessarily
because the project may come back, which is
possible, but more because you may come
back and reuse some of the code and leaving
it in a good state will facilitate reuse.
146. Retirement ;
7
😀
@amaltson
Speaker Note: And to put a bow on it, use
“Archive this repository” feature in GitHub (if
you use GitHub) and make the project read
only. You can always revive it later, but don’t
delay making the project read only to avoid
those PRs to a decommissioned project. It’s
read only so we can always reuse the code in
the future.
147. Retirement ;
7
😀
@amaltson
Speaker Note: And to put a bow on it, use
“Archive this repository” feature in GitHub (if
you use GitHub) and make the project read
only. You can always revive it later, but don’t
delay making the project read only to avoid
those PRs to a decommissioned project. It’s
read only so we can always reuse the code in
the future.
148. Retirement ;
7
🤩
@amaltson
Speaker Note: And to put a bow on it, use
“Archive this repository” feature in GitHub (if
you use GitHub) and make the project read
only. You can always revive it later, but don’t
delay making the project read only to avoid
those PRs to a decommissioned project. It’s
read only so we can always reuse the code in
the future.
149. Retirement ;🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the retirement of
mob-up, definitely not something we
generally think about.
151. Retirement
• Deprecate clearly
• Leave code in a good state
;🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the retirement of
mob-up, definitely not something we
generally think about.
152. Retirement
• Deprecate clearly
• Leave code in a good state
• Archive it
;🤩
7@amaltson
Speaker Note: In order to create an amazing
Developer Experience for the retirement of
mob-up, definitely not something we
generally think about.
153. Developer Experience7
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
working with other developers on mob-up.
154. Developer Experience7🤩
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
working with other developers on mob-up.
155. Developer Experience7🤩
8
• Friendly README
• Data Flow Diagram
• Workstation Setup (that works!)
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
working with other developers on mob-up.
156. Developer Experience7🤩
9 • Pipeline Green
• GitHub Templates
8
• Friendly README
• Data Flow Diagram
• Workstation Setup (that works!)
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
working with other developers on mob-up.
157. Developer Experience7🤩
9 • Pipeline Green
• GitHub Templates
: • Consistency
• CHANGELOGs8
• Friendly README
• Data Flow Diagram
• Workstation Setup (that works!)
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
working with other developers on mob-up.
158. Developer Experience7🤩
9 • Pipeline Green
• GitHub Templates
: • Consistency
• CHANGELOGs
;
• Deprecate clearly
• Leave code in a good state
• Archive it
8
• Friendly README
• Data Flow Diagram
• Workstation Setup (that works!)
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
working with other developers on mob-up.
159. Experience Lifecycle
8 9 : ;
🛠 7
@amaltson
Speaker Note: Now that we understand how
to improve Developer Experience when
collaborating with others, let’s look how we
can improve the experience as a tool author
building tools for other developers to use.
160. Experience Lifecycle
8 9 : ;
🛠
@amaltson
Speaker Note: Now that we understand how
to improve Developer Experience when
collaborating with others, let’s look how we
can improve the experience as a tool author
building tools for other developers to use.
161. 🛠@amaltson
Speaker Note: And this is where we need to
make a slight tangent, to discuss the type
tools we’re building.
162. 🛠@amaltson
Speaker Note: And this is where we need to
make a slight tangent, to discuss the type
tools we’re building.
166. 🛠
M
@amaltson
Speaker Note: I mean to meet developers
were they are in terms of the tooling they use.
And what tooling is that? Well, most
developers live in their Editor/IDE of choice
writing code, and most of the time running
that code through their trusted terminal.
Therefore, if we’re building a tool for
developers, does it make sense to build it as a
GUI web app or a CLI with maybe integration
into their editor of choice? I’d argue the latter
makes more sense.
167. 🛠
M
@amaltson
Speaker Note: I mean to meet developers
were they are in terms of the tooling they use.
And what tooling is that? Well, most
developers live in their Editor/IDE of choice
writing code, and most of the time running
that code through their trusted terminal.
Therefore, if we’re building a tool for
developers, does it make sense to build it as a
GUI web app or a CLI with maybe integration
into their editor of choice? I’d argue the latter
makes more sense.
168. 🛠
M
@amaltson
Speaker Note: I mean to meet developers
were they are in terms of the tooling they use.
And what tooling is that? Well, most
developers live in their Editor/IDE of choice
writing code, and most of the time running
that code through their trusted terminal.
Therefore, if we’re building a tool for
developers, does it make sense to build it as a
GUI web app or a CLI with maybe integration
into their editor of choice? I’d argue the latter
makes more sense.
169. 🛠
M
GUI
@amaltson
Speaker Note: I mean to meet developers
were they are in terms of the tooling they use.
And what tooling is that? Well, most
developers live in their Editor/IDE of choice
writing code, and most of the time running
that code through their trusted terminal.
Therefore, if we’re building a tool for
developers, does it make sense to build it as a
GUI web app or a CLI with maybe integration
into their editor of choice? I’d argue the latter
makes more sense.
170. 🛠
M
GUI CLI
@amaltson
Speaker Note: I mean to meet developers
were they are in terms of the tooling they use.
And what tooling is that? Well, most
developers live in their Editor/IDE of choice
writing code, and most of the time running
that code through their trusted terminal.
Therefore, if we’re building a tool for
developers, does it make sense to build it as a
GUI web app or a CLI with maybe integration
into their editor of choice? I’d argue the latter
makes more sense.
171. 🛠
M
CLI
@amaltson
Speaker Note: I mean to meet developers
were they are in terms of the tooling they use.
And what tooling is that? Well, most
developers live in their Editor/IDE of choice
writing code, and most of the time running
that code through their trusted terminal.
Therefore, if we’re building a tool for
developers, does it make sense to build it as a
GUI web app or a CLI with maybe integration
into their editor of choice? I’d argue the latter
makes more sense.
172. CLI
🛠@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
173. CLI
🛠
Command Line
Interface
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
174. CLI
🛠
Command Line
Interface
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
175. CLI
🛠
Command Line
Interface
Well Factored Code
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
176. CLI
🛠
Command Line
Interface
Well Factored Code
(
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
177. CLI
🛠
Command Line
Interface
Well Factored Code
Web App
(
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
178. CLI
🛠
Command Line
Interface
Well Factored Code
Web App
(
N
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
179. CLI
🛠
Command Line
Interface
Well Factored Code
Editor PluginWeb App
(
N
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
180. CLI
🛠
Command Line
Interface
Well Factored Code
Editor PluginWeb App
M
(
N
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
181. CLI
🛠
Command Line
Interface
Well Factored Code
Editor PluginWeb App Electron App
M
(
N
2
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
182. CLI
🛠
Command Line
Interface
Well Factored Code
Editor PluginWeb App Electron App
M
(
N
2
O
@amaltson
Speaker Note: One last thing on CLIs, there’s
a great blog post from a while back (can’t find
it) that argued building a CLI doesn’t preclude
building a GUI, but building a GUI often
precludes building a CLI. Therefore, it’s best
to start CLI first. Once you’ve built a CLI, many
devs can start using it. And if you’ve built on
top of a well factored code base, other devs
can jump in and maybe get excited and build
a GUI for business users. After some time you
might build an editor plugin leveraging the
CLI to make it easier, which brings in other
devs. They might get excited and build an
advanced GUI on top of Electron for more
advanced users. Point is, if you start CLI first,
you get the best of both worlds.
183. CLI
🛠@amaltson
Speaker Note: So in our examples going
forward we will assume we are build a CLI and
talk about Developer Experience with a CLI.
184. Experience Lifecycle
8 9 : ;
🛠
@amaltson
Speaker Note: Alright, tangent done, let’s get
back to looking how to improve the
Developer Experience in the lifecycle of using
a tool.
185. Getting Started 8😡
🛠@amaltson
Speaker Note: Let’s start with looking at how
we can improve the initial getting started
experience. We’ve already talked about the
need to have a good README, but what users
are looking for in that initial README is how
to install and get started.
186. Getting Started 8😡
🛠@amaltson
Speaker Note: Let’s start with looking at how
we can improve the initial getting started
experience. We’ve already talked about the
need to have a good README, but what users
are looking for in that initial README is how
to install and get started.
187. Getting Started 8😡
🛠@amaltson
Speaker Note: And nothing makes that initial
getting started experience painful like having
a laundry list of prerequisites, like installing
some language you’re not familiar with and
manually installing third party dependencies.
And once you get over that hump, the
instructions for tool installation are a multi-
step process.
188. Getting Started 8😡
🛠@amaltson
Speaker Note: And nothing makes that initial
getting started experience painful like having
a laundry list of prerequisites, like installing
some language you’re not familiar with and
manually installing third party dependencies.
And once you get over that hump, the
instructions for tool installation are a multi-
step process.
189. Getting Started 8🙂
🛠@amaltson
Speaker Note: A better approach is to
provide installation options developers
expect. Whether it’s Homebrew on the Mac, a
native package for various OS flavours, or
what SecOps consider the devil’s package
manager, a curl bash install (you install blindly
with no vetting of the shell script).
190. Getting Started 8🙂
🛠@amaltson
Speaker Note: A better approach is to
provide installation options developers
expect. Whether it’s Homebrew on the Mac, a
native package for various OS flavours, or
what SecOps consider the devil’s package
manager, a curl bash install (you install blindly
with no vetting of the shell script).
191. Getting Started 8🙂
🛠@amaltson
Speaker Note: A better approach is to
provide installation options developers
expect. Whether it’s Homebrew on the Mac, a
native package for various OS flavours, or
what SecOps consider the devil’s package
manager, a curl bash install (you install blindly
with no vetting of the shell script).
192. Getting Started 8🙂
🛠@amaltson
Speaker Note: A better approach is to
provide installation options developers
expect. Whether it’s Homebrew on the Mac, a
native package for various OS flavours, or
what SecOps consider the devil’s package
manager, a curl bash install (you install blindly
with no vetting of the shell script).
193. Getting Started 8😁
🛠@amaltson
Speaker Note: The best part is, modern
tooling like Omnibus makes it easier to make
native packages. With custom Homebrew
taps, you can provide your own recipes AND
probably my favourite tip, you can even tap
internal private Git repositories, we use this
regularly ourselves.
194. Getting Started 8😁
🛠@amaltson
Speaker Note: The best part is, modern
tooling like Omnibus makes it easier to make
native packages. With custom Homebrew
taps, you can provide your own recipes AND
probably my favourite tip, you can even tap
internal private Git repositories, we use this
regularly ourselves.
195. Getting Started 8😁
🛠@amaltson
Speaker Note: The best part is, modern
tooling like Omnibus makes it easier to make
native packages. With custom Homebrew
taps, you can provide your own recipes AND
probably my favourite tip, you can even tap
internal private Git repositories, we use this
regularly ourselves.
196. Getting Started 8😁
🛠
$ brew tap homebrew/acme https://git.acme.com
$ brew install acme-awesome-tool
@amaltson
Speaker Note: The best part is, modern
tooling like Omnibus makes it easier to make
native packages. With custom Homebrew
taps, you can provide your own recipes AND
probably my favourite tip, you can even tap
internal private Git repositories, we use this
regularly ourselves.
197. Getting Started 8🤩
🛠@amaltson
Speaker Note: But all of those installation
techniques work really well when tool is
written in a way that it compiles to a nice
binary format, like with Go or Rust. But when
it doesn’t, things can go up in flames fast.
198. Getting Started 8🤩
🛠
📦
@amaltson
Speaker Note: But all of those installation
techniques work really well when tool is
written in a way that it compiles to a nice
binary format, like with Go or Rust. But when
it doesn’t, things can go up in flames fast.
199. Getting Started 8🤩
🛠
📦
@amaltson
Speaker Note: But all of those installation
techniques work really well when tool is
written in a way that it compiles to a nice
binary format, like with Go or Rust. But when
it doesn’t, things can go up in flames fast.
200. Getting Started 8🤩
🛠
📦
@amaltson
Speaker Note: But all of those installation
techniques work really well when tool is
written in a way that it compiles to a nice
binary format, like with Go or Rust. But when
it doesn’t, things can go up in flames fast.
201. Getting Started 8🤩
🛠
📦 🔥🔥
@amaltson
Speaker Note: But all of those installation
techniques work really well when tool is
written in a way that it compiles to a nice
binary format, like with Go or Rust. But when
it doesn’t, things can go up in flames fast.
202. Getting Started 8🤩
🛠
📦
@amaltson
Speaker Note: To not have that happen,
we’re going to take our application and put it
into a larger package, a Docker container. And
then using a tiny bit of shell scripting, we can
make an “executable” that looks and feels like
a binary package and allows you to control all
the dependencies you need. I’ve found this
particular trick very handy for packaging Ruby
and Python programs. Best part is, they’re
always up to date!
203. Getting Started 8🤩
🛠
📦
@amaltson
Speaker Note: To not have that happen,
we’re going to take our application and put it
into a larger package, a Docker container. And
then using a tiny bit of shell scripting, we can
make an “executable” that looks and feels like
a binary package and allows you to control all
the dependencies you need. I’ve found this
particular trick very handy for packaging Ruby
and Python programs. Best part is, they’re
always up to date!
204. Getting Started 8🤩
🛠
📦
@amaltson
Speaker Note: To not have that happen,
we’re going to take our application and put it
into a larger package, a Docker container. And
then using a tiny bit of shell scripting, we can
make an “executable” that looks and feels like
a binary package and allows you to control all
the dependencies you need. I’ve found this
particular trick very handy for packaging Ruby
and Python programs. Best part is, they’re
always up to date!
206. Getting Started
• Friendly README
8🤩
🛠@amaltson
Speaker Note: Quick summary for making an
amazing getting started experience for your
tool.
207. Getting Started
• Friendly README
• Provide one liner installation
8🤩
🛠@amaltson
Speaker Note: Quick summary for making an
amazing getting started experience for your
tool.
208. Getting Started
• Friendly README
• Provide one liner installation
• If not easily installable, use Docker!
8🤩
🛠@amaltson
Speaker Note: Quick summary for making an
amazing getting started experience for your
tool.
211. First Contact 9😨
🛠@amaltson
Speaker Note: That’s what we can think of as
first contact. It’s the first experience the
developer has using your tool, after getting it
installed that is. This is most nerve wracking
part of using a new tool.
212. First Contact 9
🛠
😌
@amaltson
Speaker Note: To make that experience
smooth, we should take into consider the rest
of the ecosystem and attempt to integrate
where it makes sense. Since we’re building a
replacement for Pair Up, we should be able to
parse and support the Pair Up format, and
maybe provide a nice migration.
213. First Contact 9
🛠
😌😊
@amaltson
Speaker Note: To make that experience
smooth, we should take into consider the rest
of the ecosystem and attempt to integrate
where it makes sense. Since we’re building a
replacement for Pair Up, we should be able to
parse and support the Pair Up format, and
maybe provide a nice migration.
214. First Contact 9
🛠
😊
@amaltson
Speaker Note: But how do we get that wow
experience? We could consider doing work on
behalf of the user. Imagine instead of asking
all the contact details like Pair Up does
today…
215. First Contact 9
🛠
😊
@amaltson
Speaker Note: But how do we get that wow
experience? We could consider doing work on
behalf of the user. Imagine instead of asking
all the contact details like Pair Up does
today…
216. First Contact 9
🛠
😊
@amaltson
Speaker Note: We go out and use the GitHub
API and find the user’s name and email
automatically. Now that’s a wow experience.
217. First Contact 9
🛠
😊
@amaltson
Speaker Note: We go out and use the GitHub
API and find the user’s name and email
automatically. Now that’s a wow experience.
218. First Contact 9
🛠
🤩
@amaltson
Speaker Note: We go out and use the GitHub
API and find the user’s name and email
automatically. Now that’s a wow experience.
220. First Contact
• Migration from existing systems
9🤩
🛠@amaltson
Speaker Note: So to have an awesome “first
contact” experience, we need to have…
221. First Contact
• Migration from existing systems
• Do work on the user’s behalf
9🤩
🛠@amaltson
Speaker Note: So to have an awesome “first
contact” experience, we need to have…
222. 9
🛠@amaltson
Speaker Note: Now our user has started
using our tool, how can we improve the day to
day Developer Experience?
223. :
🛠@amaltson
Speaker Note: Now our user has started
using our tool, how can we improve the day to
day Developer Experience?
224. Day to Day :
🛠@amaltson
Speaker Note: Improving our day to day
experience, we need to think of the source of
frustration for most users, and that’s often
unclear error messages.
225. Day to Day :😩
🛠@amaltson
Speaker Note: Improving our day to day
experience, we need to think of the source of
frustration for most users, and that’s often
unclear error messages.
226. Day to Day :😩
🛠@amaltson
Speaker Note: Improving our day to day
experience, we need to think of the source of
frustration for most users, and that’s often
unclear error messages.
227. Day to Day :
🛠
🙂
@amaltson
Speaker Note: You’ve probably seen this from
Git when you mistype a command, but how
do they do it and can we use it for our
application?
228. Day to Day :🙂
🛠@amaltson
Speaker Note: The answer is yes, we need to
use something called Levenshtein distance.
Which is a simple… err not so simple
mathematical formula. But before you throw
me off the stage…
229. Day to Day :🙂
🛠
Levenshtein distance
@amaltson
Speaker Note: The answer is yes, we need to
use something called Levenshtein distance.
Which is a simple… err not so simple
mathematical formula. But before you throw
me off the stage…
230. Day to Day :🙂
🛠
Levenshtein distance
@amaltson
Speaker Note: The answer is yes, we need to
use something called Levenshtein distance.
Which is a simple… err not so simple
mathematical formula. But before you throw
me off the stage…
231. Day to Day :
🛠
Levenshtein distance
😱
@amaltson
Speaker Note: The answer is yes, we need to
use something called Levenshtein distance.
Which is a simple… err not so simple
mathematical formula. But before you throw
me off the stage…
232. Day to Day :😱
🛠
Levenshtein distance
@amaltson
Speaker Note: … the big value with the
formula is getting a single number
representation of how close two words are.
Take this example where the distance
between “kitten” and “sitting” is 3 because
you need to substitute 3 letters in “kitten” to
make it “sitting”. Not so bad right?
233. Day to Day :
🛠
Levenshtein distance
😅
@amaltson
Speaker Note: … the big value with the
formula is getting a single number
representation of how close two words are.
Take this example where the distance
between “kitten” and “sitting” is 3 because
you need to substitute 3 letters in “kitten” to
make it “sitting”. Not so bad right?
234. Day to Day :🙂
🛠
Levenshtein distance
@amaltson
Speaker Note: We can then use this handy
algorithm to really turn up our Developer
Experience to 11. Catch and lint configuration
items, commands, etc and provide suggested
fixes.
235. Day to Day :🙂
🛠
Levenshtein distance
@amaltson
Speaker Note: We can then use this handy
algorithm to really turn up our Developer
Experience to 11. Catch and lint configuration
items, commands, etc and provide suggested
fixes.
236. Day to Day :
🛠
🥰
Levenshtein distance
@amaltson
Speaker Note: We can then use this handy
algorithm to really turn up our Developer
Experience to 11. Catch and lint configuration
items, commands, etc and provide suggested
fixes.
237. Day to Day :🤩
🛠@amaltson
Speaker Note: Recapping, to have an
awesome day to day Developer Experience
we should …
238. Day to Day
• Meaningful error messages
:🤩
🛠@amaltson
Speaker Note: Recapping, to have an
awesome day to day Developer Experience
we should …
239. Day to Day
• Meaningful error messages
• Lint and shift feedback left
:🤩
🛠@amaltson
Speaker Note: Recapping, to have an
awesome day to day Developer Experience
we should …
240. Day to Day
• Meaningful error messages
• Lint and shift feedback left
• Levenshtein distance suggestions
:🤩
🛠@amaltson
Speaker Note: Recapping, to have an
awesome day to day Developer Experience
we should …
241. :
🛠@amaltson
Speaker Note: As much blood, sweat and
tears we put into a tool, at some point all
good things come to an end.
242. ;
🛠@amaltson
Speaker Note: As much blood, sweat and
tears we put into a tool, at some point all
good things come to an end.
243. 🛠@amaltson
Speaker Note: Provide a bridge from the
current tool and to the next one, if it exists. If
there’s multiple, look at the most promising
one and direct users. Imagine how the user
feels, they’re now aware your tool is getting
deprecated and confused where to go next.
We need to provide that guidance to
gracefully retire the tool. But how do we get
that “wow” experience?
244. Retirement ;😓
@amaltson
Speaker Note: We’ve provided a path
forward and suggested a tool, but that’s still a
lot of work. Our users would really love it if
someone would help them out. That someone
needs to be us. For the optimal retirement,
consider partnering with the authors of the
new tool and build a migration tool. Worst
case scenario, build the tool for them.
Remember, as a tool author you’re the force
multiplier, you make one change and you can
potentially save hundreds of hours for teams.
🛠
245. Retirement ;🥺
@amaltson
Speaker Note: We’ve provided a path
forward and suggested a tool, but that’s still a
lot of work. Our users would really love it if
someone would help them out. That someone
needs to be us. For the optimal retirement,
consider partnering with the authors of the
new tool and build a migration tool. Worst
case scenario, build the tool for them.
Remember, as a tool author you’re the force
multiplier, you make one change and you can
potentially save hundreds of hours for teams.
🛠
246. Retirement ;🤩
@amaltson
Speaker Note: We’ve provided a path
forward and suggested a tool, but that’s still a
lot of work. Our users would really love it if
someone would help them out. That someone
needs to be us. For the optimal retirement,
consider partnering with the authors of the
new tool and build a migration tool. Worst
case scenario, build the tool for them.
Remember, as a tool author you’re the force
multiplier, you make one change and you can
potentially save hundreds of hours for teams.
🛠
248. Retirement
• Clear migration path
;🤩
🛠@amaltson
Speaker Note: To provide an amazing
Developer Experience for retiring a tool, we
need to..
249. Retirement
• Clear migration path
• Automate the migration
;🤩
🛠@amaltson
Speaker Note: To provide an amazing
Developer Experience for retiring a tool, we
need to..
250. Experience Lifecycle 🛠
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
building mob-up for others to use.
251. Experience Lifecycle 🛠🤩
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
building mob-up for others to use.
252. Experience Lifecycle 🛠🤩
8
• Friendly README
• Provide one liner installation
• If not easily installable, use Docker!
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
building mob-up for others to use.
253. Experience Lifecycle 🛠🤩
9 • Migration from existing systems
• Do work on the user’s behalf
8
• Friendly README
• Provide one liner installation
• If not easily installable, use Docker!
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
building mob-up for others to use.
254. Experience Lifecycle 🛠🤩
9 • Migration from existing systems
• Do work on the user’s behalf
:
• Meaningful error messages
• Lint and shift feedback left
• Levenshtein distance suggestions
8
• Friendly README
• Provide one liner installation
• If not easily installable, use Docker!
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
building mob-up for others to use.
255. Experience Lifecycle 🛠🤩
9 • Migration from existing systems
• Do work on the user’s behalf
:
• Meaningful error messages
• Lint and shift feedback left
• Levenshtein distance suggestions
; • Clear migration path
• Automate the migration
8
• Friendly README
• Provide one liner installation
• If not easily installable, use Docker!
@amaltson
Speaker Note: Let’s do a quick review of how
to make an amazing Developer Experience
throughout the Experience Lifecycle when
building mob-up for others to use.
265. Developer Experience
💰 🧠 😍
@amaltson
Speaker Note: We then discussed the three
costs of not focusing on Developer
Experience now; monetary, mental energy and
moral.
266. Experience Lifecycle 7🤩
9
• Pipeline Green
• GitHub Templates
• Quality of PR
:
• Consistency
• CHANGELOGs
• Smooth migrations
;
• Deprecate clearly
• Leave code in a good state
• Archive it
8
• Friendly README
• Data Flow Diagram
• Workstation Setup (that works!)
@amaltson
Speaker Note: We went through some
practical tips to improve Developer
Experience when working with others.
267. Experience Lifecycle 🛠🤩
9
• Beautiful init experience
• Migration from existing systems
• Do work on the user’s behalf
:
• Meaningful error messages
• Lint and shift feedback left
• Levenshtein distance suggestions
;
• Visible deprecation warnings
• Clear migration path
• Automate the migration
8
• Friendly README
• Provide one liner installation
• If not easily installable, use Docker!
@amaltson
Speaker Note: We went through some
practical tips to improve Developer
Experience when building a tool for others to
use.