Built With ❤️ - Why Developer Experience Matters

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.

Presentation given at:

- Web Unleashed 2019
- Keynote at DevOps Days Boston 2019

Transcript

1. Built With ❤ Why Developer Experience Matters Arthur Maltson @amaltson
2. Built With ❤ Why Developer/Designers/ Operators/Tool Users Experience Matters Arthur Maltson @amaltson
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. 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.
6. @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…
7. @amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.
8. @amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.
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?
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?
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?
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?
13. ✨ ✨ ✨ ✨ + @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?
14. @amaltson Speaker Note: 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, Google had made the prospective change.
15. @amaltson Speaker Note: 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, Google had made the prospective change.
16. @amaltson Speaker Note: 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, Google had made the prospective change.
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. @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.
22. @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.
23. @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.
24. @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.
25. 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…
26. Developer Experience @amaltson Speaker Note: … not focusing on Developer Experience now? Wait, hold on, what is Developer Experience? Good question, we haven’t defined it yet. Developer Experience is similar to User Experience in that…
27. Developer Experience @amaltson Speaker Note: … we take a frustrate developer, make a bunch of changes to the tool or project they're working on, and get a happy developer.
28. Developer Experience @amaltson Speaker Note: … we take a frustrate developer, make a bunch of changes to the tool or project they're working on, and get a happy developer.
29. @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.
30. @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.
31. @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.
32. @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.
33. @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.
34. @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.
35. @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 where they’re not working on the next feature.
36. @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 where they’re not working on the next feature.
37. @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 where they’re not working on the next feature.
38. @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 where they’re not working on the next feature.
39. @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 where they’re not working on the next feature.
40. @amaltson Speaker Note: That’s the fiscal side, now let’s talk about the mental energy side.
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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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.
44. @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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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.
46. @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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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.
47. @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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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.
48. @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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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.
49. @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. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, 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.
50. @amaltson Speaker Note: That’s the mental energy aspect, now let’s talk about moral.
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.
52. @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.
53. @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. @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.
55. @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.
56. @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.
57. @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.
58. Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
59. Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
60. Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
61. Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
62. @amaltson Speaker Note: OK, but now what? Yes it matters, but how do we even go about improving developer experience?
63. @amaltson Speaker Note: OK, but now what? Yes it matters, but how do we even go about improving developer experience?
64. @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. @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: 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.
67. Experience Lifecycle @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.
68. Experience Lifecycle @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.
69. Experience Lifecycle @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.
70. Experience Lifecycle @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.
71. Experience Lifecycle @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.
72. @amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.
73. @amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.
74. @amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.
75. @amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.
76. @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.
77. @amaltson Speaker Note: Let’s put on our construction boots and get more concrete and discuss a specific problem.
78. @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?
79. @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.
80. @amaltson Speaker Note: 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.
81. @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.
82. @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.
83. @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
84. Pair Up Up @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
85. Mob Up @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
86. Experience Lifecycle @amaltson Speaker Note: So for this imaginary project, let’s start by talking about working on mob-up in team with other developers and how to improve the experience there.
87. Experience Lifecycle @amaltson Speaker Note: So for this imaginary project, let’s start by talking about working on mob-up in team with other developers and how to improve the experience there.
88. Getting Started @amaltson Speaker Note: When introducing a new developer to the mob up code base, the reaction to new code is often like this. Right? Where do you even start with the code, how do you get in and start understanding what’s happening?
89. Getting Started @amaltson Speaker Note: When introducing a new developer to the mob up code base, the reaction to new code is often like this. Right? Where do you even start with the code, how do you get in and start understanding what’s happening?
90. Getting Started @amaltson Speaker Note: When introducing a new developer to the mob up code base, the reaction to new code is often like this. Right? Where do you even start with the code, how do you get in and start understanding what’s happening?
91. Getting Started @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.
92. Getting Started @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.
93. Getting Started @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.
94. Getting Started @amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..
95. Getting Started • Data flow sequence diagrams @amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..
96. @amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.
97. @amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.
98. First Commit @amaltson Speaker Note: The first commit is often anxiety ridden. Even if the new member has made the mob-up changes locally and got the build green, there’s still a matter of proposing that first change. What’s expected of you?
99. First Commit @amaltson Speaker Note: The first commit is often anxiety ridden. Even if the new member has made the mob-up changes locally and got the build green, there’s still a matter of proposing that first change. What’s expected of you?
100. First Commit @amaltson Speaker Note: To ease that anxiety and also maintain consistency across the whole project, we can introduce a Pull Requests checklist to mob-up. We can use the PR checklist to guide new people and remind old hats what’s required to get a successful merge. And we all know checking off check lists makes you feel like a super star!
101. First Commit @amaltson Speaker Note: To ease that anxiety and also maintain consistency across the whole project, we can introduce a Pull Requests checklist to mob-up. We can use the PR checklist to guide new people and remind old hats what’s required to get a successful merge. And we all know checking off check lists makes you feel like a super star!
102. First Commit @amaltson Speaker Note: To ease that anxiety and also maintain consistency across the whole project, we can introduce a Pull Requests checklist to mob-up. We can use the PR checklist to guide new people and remind old hats what’s required to get a successful merge. And we all know checking off check lists makes you feel like a super star!
103. First Commit @amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..
104. First Commit • Pull Request checklist @amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..
105. @amaltson Speaker Note: Alright, that’s the first commit experience. Let’s now look at improving the Developer Experience in our day to day.
106. @amaltson Speaker Note: Alright, that’s the first commit experience. Let’s now look at improving the Developer Experience in our day to day.
107. Day to Day @amaltson Speaker Note: As we work day to day on a project like mob-up, it’s hard to keep track of all the changes happening especially if there are more than a couple developers on the project. It’s hard to remember what’s changed.
108. Day to Day @amaltson Speaker Note: As we work day to day on a project like mob-up, it’s hard to keep track of all the changes happening especially if there are more than a couple developers on the project. It’s hard to remember what’s changed.
109. Day to Day @amaltson Speaker Note: As we work day to day on a project like mob-up, it’s hard to keep track of all the changes happening especially if there are more than a couple developers on the project. It’s hard to remember what’s changed.
110. Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping 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.
111. Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping 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.
112. Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping 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.
113. Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping 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.
114. Day to Day @amaltson Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..
115. Day to Day • Keep a CHANGELOG @amaltson Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..
116. @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.
117. @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.
118. Retirement @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.
119. Retirement @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.
120. Retirement @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.
121. Retirement @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.
122. Retirement @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.
123. Retirement @amaltson Speaker Note: The 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.
124. Retirement @amaltson Speaker Note: The 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.
125. Retirement ✅ @amaltson Speaker Note: The 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.
126. Retirement @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.
127. Retirement @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.
128. Retirement @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.
129. Retirement @amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.
130. Retirement • Leave code in a good state @amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.
131. Retirement • Leave code in a good state • Archive it @amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.
132. Developer Experience @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.
133. Developer Experience @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.
134. Developer Experience • Data flow sequence diagrams @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.
135. Developer Experience • Pull Request checklist • Data flow sequence diagrams @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.
136. Developer Experience • Pull Request checklist • Keep a CHANGELOG • Data flow sequence diagrams @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.
137. Developer Experience • Pull Request checklist • Keep a CHANGELOG • Leave code in a good state • Archive it • Data flow sequence diagrams @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.
138. Experience Lifecycle @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.
139. Experience Lifecycle @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.
140. @amaltson Speaker Note: And this is where we need to make a slight tangent, to discuss the type tools we’re building.
141. @amaltson Speaker Note: And this is where we need to make a slight tangent, to discuss the type tools we’re building.
142. @amaltson Speaker Note: I believe it’s important to meet developers we’re there at…
143. @amaltson Speaker Note: In their mother’s basement… no wait.
144. @amaltson Speaker Note: At a Star Trek convention… no no. I’m joking of course.
145. @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.
146. @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.
147. @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.
148. 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.
149. 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.
150. 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.
151. CLI @amaltson Speaker Note: One could argue 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.
152. CLI Command Line Interface @amaltson Speaker Note: One could argue 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.
153. CLI Command Line Interface @amaltson Speaker Note: One could argue 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.
154. CLI Command Line Interface Well Factored Code @amaltson Speaker Note: One could argue 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.
155. CLI Command Line Interface Well Factored Code @amaltson Speaker Note: One could argue 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.
156. CLI Command Line Interface Well Factored Code Web App @amaltson Speaker Note: One could argue 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.
157. CLI Command Line Interface Well Factored Code Web App @amaltson Speaker Note: One could argue 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.
158. CLI Command Line Interface Well Factored Code Editor Plugin Web App @amaltson Speaker Note: One could argue 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.
159. CLI Command Line Interface Well Factored Code Editor Plugin Web App @amaltson Speaker Note: One could argue 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.
160. CLI Command Line Interface Well Factored Code Editor Plugin Web App Electron App @amaltson Speaker Note: One could argue 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.
161. CLI Command Line Interface Well Factored Code Editor Plugin Web App Electron App @amaltson Speaker Note: One could argue 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.
162. CLI @amaltson Speaker Note: Point is, if you start CLI first, you get the best of both worlds. So our examples going forward we will assume we are build a CLI and talk about Developer Experience with a CLI.
163. Experience Lifecycle @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.
164. Getting Started @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.
165. Getting Started @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.
166. Getting Started @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.
167. Getting Started @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).
168. Getting Started @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).
169. Getting Started @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).
170. Getting Started @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).
171. Getting Started @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’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.
172. Getting Started @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’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.
173. Getting Started @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’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.
174. Getting Started @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’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.
175. Getting Started @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’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.
176. Getting Started @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!
177. Getting Started @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!
178. Getting Started @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!
179. Getting Started @amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
180. Getting Started • Provide one liner installation @amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
181. Getting Started • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
182. @amaltson Speaker Note: Alright, that’s getting started. Once we have the tool installed, we want to start using it.
183. @amaltson Speaker Note: Alright, that’s getting started. Once we have the tool installed, we want to start using it.
184. First Contact @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.
185. First Contact @amaltson Speaker Note: How do we get that wow experience and reduce the nervous experience? We could consider doing work on behalf of the user. Imagine instead of asking all the contact details like Pair Up does today…
186. First Contact @amaltson Speaker Note: How do we get that wow experience and reduce the nervous experience? We could consider doing work on behalf of the user. Imagine instead of asking all the contact details like Pair Up does today…
187. First Contact @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.
188. First Contact @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.
189. First Contact @amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…
190. First Contact • Do work on the user’s behalf @amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…
191. @amaltson Speaker Note: Now our user has started using our tool, how can we improve the day to day Developer Experience?
192. @amaltson Speaker Note: Now our user has started using our tool, how can we improve the day to day Developer Experience?
193. 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.
194. 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.
195. 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.
196. Day to Day @amaltson Speaker Note: But many tools have really good error messages. You’ve probably seen this from Git when you mistype a command. Not only do they clearly explain what the problem is, but also suggests how to fix it. Can we do something like this for mob-up?
197. 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…
198. 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…
199. 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…
200. 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?
201. 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?
202. Day to Day Levenshtein distance @amaltson Speaker Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Since we know all of our keywords, for example in configuration we have “name”, “email”, “timeout”, etc, we can run a Levenshtein distance of a misconfigured word against all the keywords and the one with the lowest score (least transformations, up to a threshold of course) is probably the one they meant!
203. Day to Day Levenshtein distance @amaltson Speaker Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Since we know all of our keywords, for example in configuration we have “name”, “email”, “timeout”, etc, we can run a Levenshtein distance of a misconfigured word against all the keywords and the one with the lowest score (least transformations, up to a threshold of course) is probably the one they meant!
204. Day to Day @amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
205. Day to Day • Levenshtein distance suggestions @amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
206. @amaltson Speaker Note: As much blood, sweat and tears we put into a tool, at some point all good things come to an end.
207. @amaltson Speaker Note: As much blood, sweat and tears we put into a tool, at some point all good things come to an end.
208. @amaltson Retirement 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?
209. Retirement @amaltson Speaker Note: 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.
210. Retirement @amaltson Speaker Note: 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.
211. Retirement @amaltson Speaker Note: Recapping, to have an awesome Developer Experience retiring a tool we should …
212. Retirement • Clear and automated migration @amaltson Speaker Note: Recapping, to have an awesome Developer Experience retiring a tool we should …
213. Developer Experience @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 other developers to use.
214. Developer Experience @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 other developers to use.
215. Developer Experience • 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 other developers to use.
216. Developer Experience • Do work on the user’s behalf • 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 other developers to use.
217. Developer Experience • Do work on the user’s behalf • Levenshtein distance suggestions • 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 other developers to use.
218. Developer Experience • Do work on the user’s behalf • Levenshtein distance suggestions • Clear and automated migration • 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 other developers to use.
219. @amaltson Speaker Note: Well that was a whirl wind tour of tips and tricks to improve developer experience.
220. @amaltson Speaker Note: Well that was a whirl wind tour of tips and tricks to improve developer experience.
221. @amaltson Speaker Note: Let’s tie this all together with a quick replay.
222. @amaltson Speaker Note: Let’s tie this all together with a quick replay.
223. User Experience @amaltson Speaker Note: Looking back now, we know we left a lot of value on the table by not focusing on User Experience a decade ago.
224. User Experience @amaltson Speaker Note: Looking back now, we know we left a lot of value on the table by not focusing on User Experience a decade ago.
225. Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.
226. Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.
227. Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.
228. Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.
229. Developer Experience • Pull Request checklist • Keep a CHANGELOG • Leave code in a good state • Archive it • Data flow sequence diagrams @amaltson Speaker Note: We went through some practical tips to improve Developer Experience when working with others.
230. Developer Experience • Do work on the user’s behalf • Levenshtein distance suggestions • Clear and automated migration • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: We then went through some practical tips to improve Developer Experience when building a tool for others to use.
231. @amaltson Speaker Note: So I ask, what are you waiting for to start improving…
232. Developer Experience @amaltson Speaker Note: … the Developer Experience of what you’re working on. Introduce just one or two of these ideas..
233. Developer Experience @amaltson Speaker Note: … and start improving the Developer Experience and turn your angry developers into happy developers.
234. Developer Experience @amaltson Speaker Note: … and start improving the Developer Experience and turn your angry developers into happy developers.
235. Arthur Maltson @amaltson maltson.com Capital One Sr. Manager - Software Engineer 70% Dev, 30% Ops Full Time DadOps
236. @amaltson
237. • Slides: https://www.slideshare.net/ArthurMaltson • Mob Up (someday): https://github.com/amaltson/mob-up • GitHub PR Templates • Keep A Changelog • PlantUML sequence diagram syntax • PlantUML VS Code Plugin • PairUp, Git Duel (actively maintained), and Git Mob (has VS Code plugin) Arthur Maltson We’re Hiring! @amaltson
238. Credits • assorted-color yarns, Karly Santiago, https://unsplash.com/photos/E7zsz8JA8FM • MapQuest in 2005, Wayback Machine Internet Archive, https://web.archive.org/web/20050625054602/http://www.mapquest.com/ • MapQuest in 2019, MapQuest, https://www.mapquest.com • Google_Maps_Beta, Wikimedia, https://en.wikipedia.org/wiki/File:Google_Maps_Beta.png • Calculate RIO, https://uxplanet.org/how-to-calculate-the-roi-of-your-ux-activities-b7ba7023246a • Users love simple and familiar designs – Why websites need to make a great first impression, https://ai.googleblog.com/2012/08/users-love-simple-and-familiar-designs.html • Canadian_Dollar_-_reverse, Wikimedia, https://en.wikipedia.org/wiki/File:Canadian_Dollar_-_reverse.png • Toonie.2012.design.reverse, Wikimedia, https://en.wikipedia.org/wiki/File:Toonie.2012.design.reverse.png • Empathic: https://www.grammarly.com/blog/empathetic • Cecily Strong Shrug Gif By Saturday Night Live, Saturday Night Live, https://gph.is/2d1eSi8 • Co-authored-by instructions: https://github.blog/2018-01-29-commit-together-with-co-authors/ • Working on new code base Tweet, Sarah Drasner, https://twitter.com/sarah_edo/status/1172210626573111296?s=21 • I Have No Memory Of This Place, gifbay, https://giphy.com/gifs/lost-gandalf-memory-FPjbHO0jJxGsE • Funny changelog: https://www.androidpit.com/here-are-the-most-hilarious-change-logs-ever-written • brown wooden trunk, Lena De Fanti, https://unsplash.com/photos/W4HtdHYqmUg • Home Office Remodeling Project (23), Michael Sauers, https://flic.kr/p/7xqsxK • Borg trekkie?, Nathan Rupert, https://flic.kr/p/cAfMoj • Typing Montage GIF, ReactionsEditor, https://gph.is/2oW0XKw • Homebrew logo, Homebrew, https://brew.sh • Debian logo, Wikimedia, https://commons.wikimedia.org/wiki/File:Debian-OpenLogo.svg • Red Hat logo, Wikimedia, https://en.wikipedia.org/wiki/File:Red_Hat_Logo_2019.svg • Curl Logo, Curl, https://curl.haxx.se/logo/ • Go gopher, Renee French, https://github.com/golang-samples/gopher-vector • Rust logo, Rust Lang, https://github.com/rust-lang/rust-artwork • Moby logo, Docker Inc, https://www.docker.com/company/newsroom/media-resources • Arrival still, Paramount Pictures, https://www.wired.co.uk/article/arrival-science-fact-fiction • Levenshtein distance, Wikipedia, https://en.wikipedia.org/wiki/Levenshtein_distance • Bicentennial Trail, Michael Hicks, https://flic.kr/p/assieJ • Dog Puppy Gif, Giphy, https://gph.is/1ko3wyq • Toronto Raptors Gif, Giphy, https://gph.is/g/aK5By84