Built With ❤ - Why Developer Experience Matters - Web Unleashed 2019
- 1. Built With ❤ Why Developer Experience Matters Arthur Maltson @amaltson
- 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…
- 6. @amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.
- 7. @amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.
- 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…
- 22. Developer Experience @amaltson Speaker Note: … not focusing on Developer Experience now? Wait, hold on, what is Developer Experience?
- 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.
- 44. 💰 🧠 😍 @amaltson Speaker Note: That’s the mental energy aspect, now let’s talk about moral.
- 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.
- 52. Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
- 53. Developer Experience 💰 @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
- 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.
- 71. @amaltson Speaker Note: Let’s put on our construction boots and get more concrete and discuss a specific problem.
- 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.
- 77. @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
- 78. Pair UpUp @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
- 79. Mob Up @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
- 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.
- 97. Getting Started 8🤩 7@amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..
- 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..
- 101. 8 7@amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.
- 102. 9 7@amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.
- 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.
- 110. First Commit 9🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..
- 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.
- 150. Retirement • Deprecate clearly ;🤩 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.
- 163. 🛠 M @amaltson Speaker Note: I believe it’s important to meet developers we’re there at…
- 164. 🛠@amaltson Speaker Note: In their mother’s basement… no wait.
- 165. 🛠@amaltson Speaker Note: At a Star Trek convention… no no. I’m joking of course.
- 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!
- 205. Getting Started 8🤩 🛠@amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
- 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.
- 209. 8 🛠@amaltson Speaker Note: Alright, that’s getting started. Once we have the tool installed, we want to start using it.
- 210. 9 🛠@amaltson Speaker Note: Alright, that’s getting started. Once we have the tool installed, we want to start using it.
- 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.
- 219. First Contact 9🤩 🛠@amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…
- 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. 🛠
- 247. Retirement ;🤩 🛠@amaltson Speaker Note: To provide an amazing Developer Experience for retiring a tool, we need to..
- 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.
- 256. @amaltson Speaker Note: Well that was a whirl wind tour of tips and tricks to improve developer experience.
- 257. @amaltson Speaker Note: Well that was a whirl wind tour of tips and tricks to improve developer experience.
- 258. @amaltson Speaker Note: Let’s tie this all together with a quick replay.
- 259. @amaltson Speaker Note: Let’s tie this all together with a quick replay.
- 260. 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.
- 261. 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.
- 262. Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now; monetary, mental energy and moral.
- 263. Developer Experience 💰 @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now; monetary, mental energy and moral.
- 264. Developer Experience 💰 🧠 @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now; monetary, mental energy and moral.
- 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.
- 268. @amaltson Speaker Note: So I ask, what are you waiting for to start improving…
- 269. Developer Experience @amaltson Speaker Note: … Developer Experience…
- 270. Developer Experience 😡💻 @amaltson Speaker Note: … And start turning those unhappy developers into happy ones.
- 271. Developer Experience 😡💻😄 @amaltson Speaker Note: … And start turning those unhappy developers into happy ones.
- 272. @amaltson
- 273. Arthur Maltson @amaltson maltson.com Capital One Sr. Manager - Software Engineer 70% Dev, 30% Ops Full Time DadOps
- 274. @amaltson@amaltson
- 275. @amaltson@amaltson
- 276. @amaltson@amaltson
- 277. @amaltson@amaltson
- 279. • Slides: https://www.slideshare.net/ArthurMaltson • Mob Up (someday): https://github.com/amaltson/mob-up • Friendly READMEs • 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
- 280. 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 • 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 • Workbench, https://flic.kr/p/3aLRao • Lakota Native American Man at Pow Wow, Andrew James, https://unsplash.com/photos/ehdsg7SHm6A • Funny changelog: https://www.androidpit.com/here-are-the-most-hilarious-change-logs-ever-written • Empathic: https://www.grammarly.com/blog/empathetic • brown wooden trunk, Lena De Fanti, https://unsplash.com/photos/W4HtdHYqmUg • Deprecation README, nhsuk, https://github.com/nhsuk/profiles • Home Office Remodeling Project (23), Michael Sauers, https://flic.kr/p/7xqsxK • Borg trekkie?, Nathan Rupert, https://flic.kr/p/cAfMoj • Co-authored-by instructions: https://github.blog/2018-01-29-commit-together-with-co-authors/ • Cecily Strong Shrug Gif By Saturday Night Live, Saturday Night Live, https://gph.is/2d1eSi8 • 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 • screenshot, Yeoman, https://github.com/yeoman/yo/blob/master/screenshot.png • Levenshtein distance, Wikipedia, https://en.wikipedia.org/wiki/Levenshtein_distance • Smooth path: https://flic.kr/p/assieJ • Dog Puppy Gif, Giphy, https://gph.is/1ko3wyq • Toronto Raptors Gif, Giphy, https://gph.is/g/aK5By84 • Uncle Sam Meme, imgflip, https://imgflip.com/memegenerator/Uncle-Sam