Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Built With ❤️ - Why Developer Experience Matter...

Built With ❤️ - Why Developer Experience Matters - GitHub Universe

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: GitHub Universe 2023

Arthur Maltson

November 04, 2023
Tweet

More Decks by Arthur Maltson

Other Decks in Programming

Transcript

  1. Built With ❤ 
 Why Developer Experience Ma tt ers

    @amaltson Arthur Maltson Distinguished Engineer - Capital One
  2. @amaltson Developer Experience 🐝 🐝 🐝 🐝 🐝 🐝 🐝

    Speaker Note: So why all the buzz around Developer Experience lately? And how does it relate to User Experience?
  3. @amaltson User Experience @amaltson Speaker Note: Well, Developer Experience is

    really a subset of user experience, many of the same principles apply.
  4. @amaltson 😡 User Experience @amaltson Speaker Note: We take an

    angry customer and with research, design, friction removal, and functionality changes turn them into happy customers.
  5. @amaltson 😡 😄 User Experience @amaltson Speaker Note: We take

    an angry customer and with research, design, friction removal, and functionality changes turn them into happy customers.
  6. @amaltson Speaker Note: But we don’t hear much about MapQuest

    now a days. It has to do with the fact that in 2005 when MapQuest looked like this, Google came out with Google Maps, which had a fundamental focus on user experience and ultimately ate MapQuest's lunch, even though they both had access to the same browser technologies.
  7. @amaltson Speaker Note: But we don’t hear much about MapQuest

    now a days. It has to do with the fact that in 2005 when MapQuest looked like this, Google came out with Google Maps, which had a fundamental focus on user experience and ultimately ate MapQuest's lunch, even though they both had access to the same browser technologies.
  8. @amaltson Speaker Note: But we don’t hear much about MapQuest

    now a days. It has to do with the fact that in 2005 when MapQuest looked like this, Google came out with Google Maps, which had a fundamental focus on user experience and ultimately ate MapQuest's lunch, even though they both had access to the same browser technologies.
  9. @amaltson Speaker Note: Which is why businesses and individuals started

    to invest in UX. They understood they could invest a bit of money in the form of creativity and developer time, which would see a big increase in users and make a huge return on those investments. Countless studies have shown this to be true.
  10. @amaltson 💵 Speaker Note: Which is why businesses and individuals

    started to invest in UX. They understood they could invest a bit of money in the form of creativity and developer time, which would see a big increase in users and make a huge return on those investments. Countless studies have shown this to be true.
  11. @amaltson 💵 📈 Speaker Note: Which is why businesses and

    individuals started to invest in UX. They understood they could invest a bit of money in the form of creativity and developer time, which would see a big increase in users and make a huge return on those investments. Countless studies have shown this to be true.
  12. @amaltson 💵 📈💰💰💰 Speaker Note: Which is why businesses and

    individuals started to invest in UX. They understood they could invest a bit of money in the form of creativity and developer time, which would see a big increase in users and make a huge return on those investments. Countless studies have shown this to be true.
  13. @amaltson User Experience Speaker Note: Looking back almost two decades,

    we clearly know how much we missed out by not focusing in User Experience early on. The question is, what are we missing out on by…
  14. @amaltson Developer Experience 🐝 🐝 🐝 🐝 🐝 🐝 🐝

    Speaker Note: And that’s why I think there’s so much buzz around Developer Experience now a days.
  15. End of slide show, click to exit Speaker Note: And

    actually… that’s all I had to say. Any questions?
  16. @amaltson 😡💻 Developer Experience Speaker Note: Wait, hold on, I’m

    just joking. I made some of you mad now, and that’s actually the essence of Developer Experience… we take a frustrated developer, make a bunch of changes to the tools and projects they're working on, and get a happy developer.
  17. @amaltson 😡💻 😄 Developer Experience Speaker Note: Wait, hold on,

    I’m just joking. I made some of you mad now, and that’s actually the essence of Developer Experience… we take a frustrated developer, make a bunch of changes to the tools and projects they're working on, and get a happy developer.
  18. @amaltson Speaker Note: There’s three main arguments why Developer Experience

    is something worth focusing on and investing in. The fi rst is the fi scal cost of a poor Developer Experience. The next is the cost to the mental energy or cognitive load for developers. And the last is the hit to morale of a poor developer experience.
  19. @amaltson 💰 Speaker Note: There’s three main arguments why Developer

    Experience is something worth focusing on and investing in. The fi rst is the fi scal cost of a poor Developer Experience. The next is the cost to the mental energy or cognitive load for developers. And the last is the hit to morale of a poor developer experience.
  20. @amaltson 💰 🧠 Speaker Note: There’s three main arguments why

    Developer Experience is something worth focusing on and investing in. The fi rst is the fi scal cost of a poor Developer Experience. The next is the cost to the mental energy or cognitive load for developers. And the last is the hit to morale of a poor developer experience.
  21. @amaltson 💰 🧠 😍 Speaker Note: There’s three main arguments

    why Developer Experience is something worth focusing on and investing in. The fi rst is the fi scal cost of a poor Developer Experience. The next is the cost to the mental energy or cognitive load for developers. And the last is the hit to morale of a poor developer experience.
  22. @amaltson 💰 Speaker Note: Looking at fi scal fi rst,

    we know that labour costs for technology professionals are often some of the highest, that is to say, we’re pretty lucky.
  23. @amaltson 👩💻 💰 Speaker Note: Looking at fi scal fi

    rst, we know that labour costs for technology professionals are often some of the highest, that is to say, we’re pretty lucky.
  24. @amaltson 👩💻 💰 💰 Speaker Note: Looking at fi scal

    fi rst, we know that labour costs for technology professionals are often some of the highest, that is to say, we’re pretty lucky.
  25. @amaltson Speaker Note: Which means when a single developer waste

    their time waiting on a slow build, or take weeks to get their workstation set up, well that’s a big waste.
  26. @amaltson Speaker Note: Which means when a single developer waste

    their time waiting on a slow build, or take weeks to get their workstation set up, well that’s a big waste.
  27. @amaltson 👩💻 👨💻 👨💻 👩💻 💰💰💰 💰💰💰 👩💻 💰 💰

    Speaker Note: Now multiply that across a team or an entire organization, and that’s a lot of money.
  28. @amaltson 💰 🧠 😍 Speaker Note: That’s the fi scal

    side, now let’s talk about the mental energy side.
  29. @amaltson 🧠 Speaker Note: You may have heard of the

    “spoons” metaphor for representing mental energy. Here we’ll use coins instead, but the idea is they represent the mental energy 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.
  30. @amaltson 🧠 Speaker Note: You may have heard of the

    “spoons” metaphor for representing mental energy. Here we’ll use coins instead, but the idea is they represent the mental energy 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.
  31. @amaltson 🧠 Speaker Note: You may have heard of the

    “spoons” metaphor for representing mental energy. Here we’ll use coins instead, but the idea is they represent the mental energy 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.
  32. @amaltson 🧠 Speaker Note: You may have heard of the

    “spoons” metaphor for representing mental energy. Here we’ll use coins instead, but the idea is they represent the mental energy 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.
  33. @amaltson 🧠 Speaker Note: Anyway, everyone has different energy levels

    so they’d start with different amounts. 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 from fi ghting the corporate proxy or troubleshooting for hours only to fi nd a downstream system is broken.
  34. @amaltson 🧠 Speaker Note: Anyway, everyone has different energy levels

    so they’d start with different amounts. 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 from fi ghting the corporate proxy or troubleshooting for hours only to fi nd a downstream system is broken.
  35. @amaltson 🧠 Speaker Note: Anyway, everyone has different energy levels

    so they’d start with different amounts. 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 from fi ghting the corporate proxy or troubleshooting for hours only to fi nd a downstream system is broken.
  36. @amaltson 🧠 Speaker Note: Anyway, everyone has different energy levels

    so they’d start with different amounts. 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 from fi ghting the corporate proxy or troubleshooting for hours only to fi nd a downstream system is broken.
  37. @amaltson 🧠 Speaker Note: Anyway, everyone has different energy levels

    so they’d start with different amounts. 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 from fi ghting the corporate proxy or troubleshooting for hours only to fi nd a downstream system is broken.
  38. @amaltson 🧠 Speaker Note: Anyway, everyone has different energy levels

    so they’d start with different amounts. 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 from fi ghting the corporate proxy or troubleshooting for hours only to fi nd a downstream system is broken.
  39. @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 fi rst few weeks, access control the next week, misleading docs, poor error messages, and well…
  40. @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 fi rst few weeks, access control the next week, misleading docs, poor error messages, and well…
  41. @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 fi rst few weeks, access control the next week, misleading docs, poor error messages, and well…
  42. @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 fi rst few weeks, access control the next week, misleading docs, poor error messages, and well…
  43. @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 fi rst few weeks, access control the next week, misleading docs, poor error messages, and well…
  44. @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 fi rst few weeks, access control the next week, misleading docs, poor error messages, and well…
  45. @amaltson Developer Experience Speaker Note: So why should you care

    about developer experience? For fi scal reasons, optimizing metal energy or reducing cognitive load and improving overall morale.
  46. @amaltson Developer Experience 💰 Speaker Note: So why should you

    care about developer experience? For fi scal reasons, optimizing metal energy or reducing cognitive load and improving overall morale.
  47. @amaltson Developer Experience 💰 🧠 Speaker Note: So why should

    you care about developer experience? For fi scal reasons, optimizing metal energy or reducing cognitive load and improving overall morale.
  48. @amaltson Developer Experience 💰 🧠 😍 Speaker Note: So why

    should you care about developer experience? For fi scal reasons, optimizing metal energy or reducing cognitive load and improving overall morale.
  49. @amaltson @amaltson Speaker Note: OK, but now what? Yes it

    matters, but how do we even go about improving developer experience?
  50. @amaltson @amaltson Speaker Note: OK, but now what? Yes it

    matters, but how do we even go about improving developer experience?
  51. @amaltson Going Deep Speaker Note: Well buckle up, because we’re

    going to start going deep now, like looking at code deep. We started high level to understand why developer experience matters, and hopefully that resonates, but now I want to leave you with ideas how to make it better. You may have heard of some of these, but hopefully you’ll fi nd a nugget here and there that’s new to you. With that said, let’s dive in.
  52. @amaltson Going Deep Speaker Note: Well buckle up, because we’re

    going to start going deep now, like looking at code deep. We started high level to understand why developer experience matters, and hopefully that resonates, but now I want to leave you with ideas how to make it better. You may have heard of some of these, but hopefully you’ll fi nd a nugget here and there that’s new to you. With that said, let’s dive in.
  53. @amaltson Speaker Note: To improve Developer Experience we can look

    at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  54. @amaltson 🛠 Speaker Note: To improve Developer Experience we can

    look at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  55. @amaltson 🛠 👨💻 Speaker Note: To improve Developer Experience we

    can look at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  56. @amaltson Experience Lifecycle 🛠 👨💻 Speaker Note: To improve Developer

    Experience we can look at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  57. @amaltson Experience Lifecycle 👶 🛠 👨💻 Speaker Note: To improve

    Developer Experience we can look at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  58. @amaltson Experience Lifecycle 🧒 🛠 👨💻 Speaker Note: To improve

    Developer Experience we can look at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  59. @amaltson Experience Lifecycle 👩💼 🛠 👨💻 Speaker Note: To improve

    Developer Experience we can look at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  60. @amaltson Experience Lifecycle 👵 🛠 👨💻 Speaker Note: To improve

    Developer Experience we can look at it from two distinct facets, one is the developer experience of using a tool and the other is the experience working on a project with others. We’ll look at how to improve the experience across the “Experience Lifecycle”. From the very beginning, eg. fi rst time you join the team or installing that tool. To your fi rst major change
  61. @amaltson Speaker Note: The concepts carry over regardless of whether

    you’re doing front end development, backend development or DevOps tooling, but the speci fi c implementation may differ.
  62. @amaltson Speaker Note: The concepts carry over regardless of whether

    you’re doing front end development, backend development or DevOps tooling, but the speci fi c implementation may differ.
  63. @amaltson Speaker Note: The concepts carry over regardless of whether

    you’re doing front end development, backend development or DevOps tooling, but the speci fi c implementation may differ.
  64. @amaltson Speaker Note: The concepts carry over regardless of whether

    you’re doing front end development, backend development or DevOps tooling, but the speci fi c implementation may differ.
  65. @amaltson @amaltson Speaker Note: We have two guiding principles for

    improving developer experience, and the big one is empathy. Empathy is the super power that’ll let you see friction and pain points where others don’t. And we’re not trying to be sympathetic as in “oh that sucks”, we want to acknowledge and provide concrete improvements.
  66. @amaltson Speaker Note: The second guiding principle is what’s called

    the the pit of success, that means even if you make a mistake and fall, you get caught and succeed. Characterized another way, making the right way, the easy way. And this is a theme you’ll see throughout, the right way the easy way.
  67. @amaltson The right way The easy way Speaker Note: The

    second guiding principle is what’s called the the pit of success, that means even if you make a mistake and fall, you get caught and succeed. Characterized another way, making the right way, the easy way. And this is a theme you’ll see throughout, the right way the easy way.
  68. @amaltson @amaltson Speaker Note: Finally, let’s put on our construction

    boots and get more concrete and discuss a speci fi c problem.
  69. @amaltson Speaker Note: And that speci fi c problem is

    how to ensure everyone gets a bit of those sweet, sweet green GitHub squares when pair programming or even mob programming?
  70. @amaltson 😿 Speaker Note: You know what I mean, we

    want those sweet green squares fi lling the whole timeline! We need to attribute work to everyone mobbing.
  71. @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. It also doesn’t fully re fl ect how the code was written.
  72. @amaltson Speaker Note: Fortunately, GitHub has support for the standardized

    “Co-authored- by” syntax in commit messages, this renders much nicer in GitHub but the challenge is Pair Up doesn’t support it.
  73. @amaltson Speaker Note: Fortunately, GitHub has support for the standardized

    “Co-authored- by” syntax in commit messages, this renders much nicer in GitHub but the challenge is Pair Up doesn’t support it.
  74. @amaltson Speaker Note: So that’s our problem statement, building a

    new tool to handle mobbing, we’ll need a snazzy new name… hmm.. I know! Mob Up! OK, not that exciting, moving on.
  75. @amaltson Pair Up Up Speaker Note: So that’s our problem

    statement, building a new tool to handle mobbing, we’ll need a snazzy new name… hmm.. I know! Mob Up! OK, not that exciting, moving on.
  76. @amaltson Mob Up Speaker Note: So that’s our problem statement,

    building a new tool to handle mobbing, we’ll need a snazzy new name… hmm.. I know! Mob Up! OK, not that exciting, moving on.
  77. @amaltson 🛠 Speaker Note: The fi rst thing we need

    to do is fi gure out how we’re going to build it.
  78. @amaltson 👩💻 🛠 Speaker Note: I mean to meet developers

    where they want to spend their time. In their Editor/IDE of choice writing code, and 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, say web app, or a CLI? I’d argue the latter makes more sense.
  79. @amaltson 👩💻 🛠 Speaker Note: I mean to meet developers

    where they want to spend their time. In their Editor/IDE of choice writing code, and 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, say web app, or a CLI? I’d argue the latter makes more sense.
  80. @amaltson 👩💻 🛠 Speaker Note: I mean to meet developers

    where they want to spend their time. In their Editor/IDE of choice writing code, and 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, say web app, or a CLI? I’d argue the latter makes more sense.
  81. @amaltson 👩💻 GUI 🛠 Speaker Note: I mean to meet

    developers where they want to spend their time. In their Editor/IDE of choice writing code, and 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, say web app, or a CLI? I’d argue the latter makes more sense.
  82. @amaltson 👩💻 GUI CLI 🛠 Speaker Note: I mean to

    meet developers where they want to spend their time. In their Editor/IDE of choice writing code, and 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, say web app, or a CLI? I’d argue the latter makes more sense.
  83. @amaltson 👩💻 CLI 🛠 Speaker Note: I mean to meet

    developers where they want to spend their time. In their Editor/IDE of choice writing code, and 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, say web app, or a CLI? I’d argue the latter makes more sense.
  84. @amaltson 🛠 CLI Speaker Note: Starting with a CLI doesn’t

    preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  85. @amaltson Command Line Interface 🛠 CLI Speaker Note: Starting with

    a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  86. @amaltson Command Line Interface 👩💻 🛠 CLI Speaker Note: Starting

    with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  87. @amaltson Command Line Interface Well Factored Code 👩💻 🛠 CLI

    Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  88. @amaltson Command Line Interface Well Factored Code 👩💻 👩💻 🛠

    CLI Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  89. @amaltson Command Line Interface Well Factored Code Web App 👩💻

    👩💻 🛠 CLI Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  90. @amaltson Command Line Interface Well Factored Code Web App 👩💻

    👨💼 👩💻 🛠 CLI Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  91. @amaltson Command Line Interface Well Factored Code Editor Plugin Web

    App 👩💻 👨💼 👩💻 🛠 CLI Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  92. @amaltson Command Line Interface Well Factored Code Editor Plugin Web

    App 👩💻 👩💻 👨💼 👩💻 🛠 CLI Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  93. @amaltson Command Line Interface Well Factored Code Editor Plugin Web

    App Electron App 👩💻 👩💻 👨💼 👩💻 🛠 CLI Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  94. @amaltson Command Line Interface Well Factored Code Editor Plugin Web

    App Electron App 👩💻 👩💻 👨💼 👩💻 👩💼 🛠 CLI Speaker Note: Starting with a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it makes sense to start CLI fi rst. Once you’ve built a CLI, many devs can start using it right away. 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 to use, 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 fi rst, you get the best of both worlds.
  95. @amaltson 🛠 CLI Speaker Note: So in our examples going

    forward we will assume we are building a CLI and talk about Developer Experience with a CLI. That said, most of this is applicable to GUIs too.
  96. @amaltson 🛠 CLI Speaker Note: So in our examples going

    forward we will assume we are building a CLI and talk about Developer Experience with a CLI. That said, most of this is applicable to GUIs too.
  97. @amaltson 👶 🧒 👩💼 👵 Experience Lifecycle 🛠 Speaker Note:

    Alright, with that foundation, let’s get back to looking how to improve the Developer Experience in the lifecycle of using a tool.
  98. @amaltson 👶 🛠 Ge tt ing Started 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.
  99. @amaltson 👶 🙁 🛠 Ge tt ing Started 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.
  100. @amaltson 👶 🙁 🛠 Ge tt ing Started 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.
  101. @amaltson 👶 🙂 🙁 🛠 Ge tt ing Started 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 fl avours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
  102. @amaltson 👶 🙂 🙁 🛠 Ge tt ing Started 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 fl avours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
  103. @amaltson 👶 🙂 🛠 Ge tt ing Started 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 fl avours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
  104. @amaltson 👶 🙂 😈 🛠 Ge tt ing Started 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 fl avours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
  105. @amaltson 👶 🤩 🛠 Ge tt ing Started Speaker Note:

    But all of those installation techniques work really well when the tool is written in a way that compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in fl ames fast.
  106. @amaltson 👶 🤩 📦 🛠 Ge tt ing Started Speaker

    Note: But all of those installation techniques work really well when the tool is written in a way that compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in fl ames fast.
  107. @amaltson 👶 🤩 📦 🛠 Ge tt ing Started Speaker

    Note: But all of those installation techniques work really well when the tool is written in a way that compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in fl ames fast.
  108. @amaltson 👶 🤩 📦 🛠 Ge tt ing Started Speaker

    Note: But all of those installation techniques work really well when the tool is written in a way that compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in fl ames fast.
  109. @amaltson 👶 📦🔥 🔥 😅 🛠 Ge tt ing Started

    Speaker Note: But all of those installation techniques work really well when the tool is written in a way that compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in fl ames fast.
  110. @amaltson 👶 📦 😅 🛠 Ge tt ing Started 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!
  111. @amaltson 👶 📦 😅 🛠 Ge tt ing Started 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!
  112. @amaltson 👶 🤩 📦 🛠 Ge tt ing Started 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!
  113. @amaltson Ge tt ing Started 👶 🤩 👨💻 Speaker Note:

    Quick summary for making an amazing getting started experience for mob- up.
  114. @amaltson Ge tt ing Started 🖱 Provide one liner installation

    👶 🤩 👨💻 Speaker Note: Quick summary for making an amazing getting started experience for mob- up.
  115. @amaltson Ge tt ing Started 🖱 Provide one liner installation

    🐳 If not easily installable, use Docker! 👶 🤩 👨💻 Speaker Note: Quick summary for making an amazing getting started experience for mob- up.
  116. @amaltson 👶 🛠 Speaker Note: Alright, that’s getting started. Once

    we have the tool installed, we want to start using it.
  117. @amaltson 🧒 🛠 Speaker Note: Alright, that’s getting started. Once

    we have the tool installed, we want to start using it.
  118. @amaltson 🧒 😨 🛠 First Contact Speaker Note: We can

    think of as fi rst contact. It’s the fi rst experience the developer has using mob-up, after getting it installed that is. They’re stepping into the unknown.
  119. @amaltson 🧒 😨 🛠 First Contact Speaker Note: How do

    we get that wow experience and reduce the uncertainty? We could consider doing work on behalf of the user. Imagine instead of asking all the contact details like Pair Up does today…
  120. @amaltson 🧒 😨 🛠 First Contact Speaker Note: How do

    we get that wow experience and reduce the uncertainty? We could consider doing work on behalf of the user. Imagine instead of asking all the contact details like Pair Up does today…
  121. @amaltson 🧒 😨 🛠 First Contact Speaker Note: We go

    out and use the GitHub API and fi nd the user’s name and email automatically. Now that’s a wow experience.
  122. @amaltson 🧒 🤩 🛠 First Contact Speaker Note: We go

    out and use the GitHub API and fi nd the user’s name and email automatically. Now that’s a wow experience.
  123. @amaltson First Contact 🧒 📈 🛠 Speaker Note: And while

    not always appropriate, I’ve found that especially for internal developer tools, we’ve gotten good value from adding monitoring and alerting infrastructure. To have that great fi rst contact experience you should proactively fi x issues without waiting for engineers to come to you. The best way to do that is to monitor and alert like we do for customer facing applications.
  124. @amaltson First Contact 🧒 🤩 👨💻 Speaker Note: Quick summary

    for making an amazing fi rst contact experience for mob-up.
  125. @amaltson First Contact 🤖 Do work on the user’s behalf

    🧒 🤩 👨💻 Speaker Note: Quick summary for making an amazing fi rst contact experience for mob-up.
  126. @amaltson First Contact 🤖 Do work on the user’s behalf

    📈 Monitoring and alerting* 🧒 🤩 👨💻 * where appropriate, like internal tools Speaker Note: Quick summary for making an amazing fi rst contact experience for mob-up.
  127. @amaltson 🧒 🛠 Speaker Note: Now our user has started

    using mob-up, how can we improve the day to day Developer Experience?
  128. @amaltson 👩💼 🛠 Speaker Note: Now our user has started

    using mob-up, how can we improve the day to day Developer Experience?
  129. @amaltson 👩💼 🛠 Day to Day Speaker Note: To improve

    their day to day experience, we need to think of the source of frustration for most users, and that’s often unclear error messages.
  130. @amaltson 👩💼 😩 🛠 Day to Day Speaker Note: To

    improve their day to day experience, we need to think of the source of frustration for most users, and that’s often unclear error messages.
  131. @amaltson 👩💼 😩 🛠 Day to Day Speaker Note: To

    improve their day to day experience, we need to think of the source of frustration for most users, and that’s often unclear error messages.
  132. @amaltson 👩💼 🙂 🛠 Day to Day Speaker Note: But

    let’s turn it up a notch. You’ve probably seen this from Git when you mistype a command, but how do they do it? And more importantly, can we use it for mob- up?
  133. @amaltson 👩💼 🙂 🛠 Day to Day 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…
  134. @amaltson 👩💼 🙂 🛠 Day to Day Levenshtein distance 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…
  135. @amaltson 👩💼 😱 🛠 Day to Day Levenshtein distance 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…
  136. @amaltson 👩💼 😱 Levenshtein distance 🛠 Day to Day 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?
  137. @amaltson 👩💼 Levenshtein distance 😅 🛠 Day to Day 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?
  138. @amaltson 👩💼 🙂 🛠 Day to Day Levenshtein distance Speaker

    Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Catch and lint con fi guration items, commands, etc and provide suggested fi xes.
  139. @amaltson 👩💼 🥰 🛠 Day to Day Levenshtein distance Speaker

    Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Catch and lint con fi guration items, commands, etc and provide suggested fi xes.
  140. @amaltson Day to Day 👩💼 💥 🛠 Speaker Note: But

    inevitably something blows up, and an error can’t be easily handled. Ideally, this is where you catch the exception and let the user know something went wrong with a snippet of the stacktrace, but also guide them where to get more help and/or open an issue.
  141. @amaltson Day to Day 👩💼 💥 🛠 Speaker Note: But

    inevitably something blows up, and an error can’t be easily handled. Ideally, this is where you catch the exception and let the user know something went wrong with a snippet of the stacktrace, but also guide them where to get more help and/or open an issue.
  142. @amaltson Day to Day 👩💼 🐛 🛠 Speaker Note: When

    they go to open the issues, we’ll make use of GitHub’s issue templates to guide them to fi ll in enough detail to help troubleshoot the issue. If you can be even more structured, consider using GitHub’s fancy issue form feature.
  143. @amaltson Day to Day 👩💼 🐛 🛠 Speaker Note: When

    they go to open the issues, we’ll make use of GitHub’s issue templates to guide them to fi ll in enough detail to help troubleshoot the issue. If you can be even more structured, consider using GitHub’s fancy issue form feature.
  144. @amaltson Day to Day 👩💼 🐛 🛠 Speaker Note: When

    they go to open the issues, we’ll make use of GitHub’s issue templates to guide them to fi ll in enough detail to help troubleshoot the issue. If you can be even more structured, consider using GitHub’s fancy issue form feature.
  145. @amaltson Day to Day 👩💼 🐛 🛠 Speaker Note: And

    once the bug is vanquished with a merged pull request, you can use something like the semantic-release bot to let the issue fi ler know when the fi x has been released. Now that’s a next level experience.
  146. @amaltson Day to Day 👩💼 🛠 Speaker Note: And once

    the bug is vanquished with a merged pull request, you can use something like the semantic-release bot to let the issue fi ler know when the fi x has been released. Now that’s a next level experience.
  147. @amaltson Day to Day 👩💼 🛠 🤩 Speaker Note: And

    once the bug is vanquished with a merged pull request, you can use something like the semantic-release bot to let the issue fi ler know when the fi x has been released. Now that’s a next level experience.
  148. @amaltson Day to Day 👩💼 🤩 👨💻 Speaker Note: Recapping,

    to have an awesome day to day Developer Experience we should …
  149. @amaltson Day to Day 📐 Levenshtein distance suggestions 👩💼 🤩

    👨💻 Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
  150. @amaltson Day to Day 📐 Levenshtein distance suggestions 🐛 Next

    level bug experience 👩💼 🤩 👨💻 Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
  151. @amaltson 👩💼 🛠 Speaker Note: As much blood, sweat and

    tears we put into a tool, at some point all good things come to an end.
  152. @amaltson 👵 🛠 Speaker Note: As much blood, sweat and

    tears we put into a tool, at some point all good things come to an end.
  153. @amaltson Retirement 👵 🛠 @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 alternative and direct users there. 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?
  154. @amaltson 👵 🛠 Retirement 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 across teams.
  155. @amaltson 👵 🤩 🛠 Retirement 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 across teams.
  156. @amaltson Retirement 👵 🤩 👨💻 Speaker Note: Recapping, to have

    an awesome Developer Experience retiring a tool we should …
  157. @amaltson Retirement ➡ Clear and automated migration 👵 🤩 👨💻

    Speaker Note: Recapping, to have an awesome Developer Experience retiring a tool we should …
  158. @amaltson Developer Experience 👩💼 Levenshtein distance suggestions Next level bug

    experience 👶 Provide one liner installation If not easily installable, use Docker! 👵 Clear and automated migration 🧒 Do work on the user’s behalf Monitoring and alerting* 🛠 🤩 * where appropriate, like internal tools 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.
  159. @amaltson 👶 🧒 👩💼 👵 🛠 👨💻 Experience Lifecycle Speaker

    Note: Mob-up doesn’t come together on it’s own, it’s built in a team. How do we improve the developer experience working together on a team?
  160. @amaltson 👶 🧒 👩💼 👵 👨💻 Experience Lifecycle Speaker Note:

    Mob-up doesn’t come together on it’s own, it’s built in a team. How do we improve the developer experience working together on a team?
  161. @amaltson Ge tt ing Started 👶 👨💻 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? Even with Copilot able to explain the code, you still need to know which code to explain.
  162. @amaltson Ge tt ing Started 👶 😵 👨💻 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? Even with Copilot able to explain the code, you still need to know which code to explain.
  163. @amaltson Ge tt ing Started 👶 😵 👨💻 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? Even with Copilot able to explain the code, you still need to know which code to explain.
  164. @amaltson Ge tt ing Started 👶 😐 👨💻 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 fl ows through your system at a high level. This illustrates how the major components interact. 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 diagram as code built with Mermaid.js.
  165. @amaltson Ge tt ing Started 👶 🤓 👨💻 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 fl ows through your system at a high level. This illustrates how the major components interact. 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 diagram as code built with Mermaid.js.
  166. @amaltson Ge tt ing Started 👶 🤓 👨💻 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 fl ows through your system at a high level. This illustrates how the major components interact. 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 diagram as code built with Mermaid.js.
  167. @amaltson Ge tt ing Started 👶 🤓 👨💻 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 fl ows through your system at a high level. This illustrates how the major components interact. 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 diagram as code built with Mermaid.js.
  168. @amaltson Ge tt ing Started 👶 🤓 👨💻 Speaker Note:

    The best part is, there’s a VSCode plugin for to preview Mermaid.js diagrams in your Markdown docs, making it really easy to author them. Plus they render directly in GitHub.com markdown fi les.
  169. @amaltson Ge tt ing Started 👶 😵 👨💻 Speaker Note:

    Even with a data fl ow diagram in hand, you can still get a bit lost looking through a codebase. Show of hands, who would want a guided tour through a new codebase?
  170. @amaltson Ge tt ing Started 👶 😵 👨💻 Speaker Note:

    Even with a data fl ow diagram in hand, you can still get a bit lost looking through a codebase. Show of hands, who would want a guided tour through a new codebase?
  171. @amaltson Ge tt ing Started 👶 👨💻 ✋ Speaker Note:

    Even with a data fl ow diagram in hand, you can still get a bit lost looking through a codebase. Show of hands, who would want a guided tour through a new codebase?
  172. @amaltson Ge tt ing Started 👶 🤩 👨💻 CodeTour Speaker

    Note: Well you’re in luck, there’s a really awesome plugin out there, called CodeTour from Microsoft, that can let you craft a step by step tour through a code base.
  173. @amaltson Ge tt ing Started 👶 🤩 👨💻 CodeTour Speaker

    Note: Well you’re in luck, there’s a really awesome plugin out there, called CodeTour from Microsoft, that can let you craft a step by step tour through a code base.
  174. @amaltson Ge tt ing Started 👶 🤩 👨💻 CodeTour Speaker

    Note: It even allows users to run CLI commands right from the tour.
  175. @amaltson Ge tt ing Started 👶 🤩 👨💻 CodeTour Speaker

    Note: It even allows users to run CLI commands right from the tour.
  176. @amaltson Ge tt ing Started 👶 🤩 👨💻 Speaker Note:

    In order to create an amazing getting started experience working together on mob-up we need to..
  177. @amaltson Ge tt ing Started ➡ Data fl ow sequence

    diagrams 👶 🤩 👨💻 Speaker Note: In order to create an amazing getting started experience working together on mob-up we need to..
  178. @amaltson Ge tt ing Started ➡ Data fl ow sequence

    diagrams 🗼 Tours through the code base 👶 🤩 👨💻 Speaker Note: In order to create an amazing getting started experience working together on mob-up we need to..
  179. @amaltson 👶 👨💻 Speaker Note: Alright, that’s the getting started

    experience. Let’s now look at making our fi rst commit.
  180. @amaltson 🧒 👨💻 Speaker Note: Alright, that’s the getting started

    experience. Let’s now look at making our fi rst commit.
  181. @amaltson First Commit 🧒 😰 👨💻 Speaker Note: The fi

    rst commit is often anxiety inducing. How do I even check my changes locally and get the build green, what are the steps for getting this set up?
  182. @amaltson First Commit 🧒 😰 👨💻 Speaker Note: The fi

    rst commit is often anxiety inducing. How do I even check my changes locally and get the build green, what are the steps for getting this set up?
  183. @amaltson First Commit 🧒 😰 👨💻 Speaker Note: One approach

    would be to give team members and contributors a long wiki page with all the set up steps needed. OR, we could make use of the awesome DevContainer open standard and build a custom DevContainer for our project that gives engineers a way to spin up their environment with the click of a button or a single CLI execution.
  184. @amaltson First Commit 🧒 😰 👨💻 Speaker Note: One approach

    would be to give team members and contributors a long wiki page with all the set up steps needed. OR, we could make use of the awesome DevContainer open standard and build a custom DevContainer for our project that gives engineers a way to spin up their environment with the click of a button or a single CLI execution.
  185. @amaltson First Commit 🧒 😍 👨💻 Speaker Note: One approach

    would be to give team members and contributors a long wiki page with all the set up steps needed. OR, we could make use of the awesome DevContainer open standard and build a custom DevContainer for our project that gives engineers a way to spin up their environment with the click of a button or a single CLI execution.
  186. @amaltson First Commit 🧒 😍 👨💻 Speaker Note: One approach

    would be to give team members and contributors a long wiki page with all the set up steps needed. OR, we could make use of the awesome DevContainer open standard and build a custom DevContainer for our project that gives engineers a way to spin up their environment with the click of a button or a single CLI execution.
  187. @amaltson First Commit 🧒 😍 👨💻 Speaker Note: And the

    best part is, DevContainers are now a standard and GitHub Codespaces supports it out of the box.
  188. @amaltson First Commit 🧒 🤯 👨💻 Speaker Note: And the

    best part is, DevContainers are now a standard and GitHub Codespaces supports it out of the box.
  189. @amaltson First Pull Request 🧒 😰 👨💻 Speaker Note: OK

    we’re coding away and are able to test our changes, but now our anxiety is back because we’re making our fi rst Pull Request. To ease this anxiety and to 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.
  190. @amaltson First Pull Request 🧒 😰 👨💻 Speaker Note: OK

    we’re coding away and are able to test our changes, but now our anxiety is back because we’re making our fi rst Pull Request. To ease this anxiety and to 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.
  191. @amaltson First Pull Request 🧒 🤩 👨💻 Speaker Note: OK

    we’re coding away and are able to test our changes, but now our anxiety is back because we’re making our fi rst Pull Request. To ease this anxiety and to 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.
  192. @amaltson First Commit 🧒 🤩 👨💻 Speaker Note: In order

    to create an amazing Developer Experience for the fi rst commit to mob-up..
  193. @amaltson First Commit 🐳 Easy workstation setup 🧒 🤩 👨💻

    Speaker Note: In order to create an amazing Developer Experience for the fi rst commit to mob-up..
  194. @amaltson First Commit 🐳 Easy workstation setup 📝 Pull Request

    checklist 🧒 🤩 👨💻 Speaker Note: In order to create an amazing Developer Experience for the fi rst commit to mob-up..
  195. @amaltson 🧒 👨💻 Speaker Note: Alright, that’s the fi rst

    commit experience. Let’s now look at improving the Developer Experience in our day to day.
  196. @amaltson 👩💼 👨💻 Speaker Note: Alright, that’s the fi rst

    commit experience. Let’s now look at improving the Developer Experience in our day to day.
  197. @amaltson Day to Day 👩💼 👨💻 Speaker Note: Now that

    they’ve made their fi rst contribution, many folks are really unsure how that fi rst contribution will go. Aside from being kind during code reviews, and applying general code review best practices.
  198. @amaltson Day to Day 👩💼 🫣 👨💻 Speaker Note: Now

    that they’ve made their fi rst contribution, many folks are really unsure how that fi rst contribution will go. Aside from being kind during code reviews, and applying general code review best practices.
  199. @amaltson Day to Day 👩💼 🫣 👨💻 ❤ Speaker Note:

    Now that they’ve made their fi rst contribution, many folks are really unsure how that fi rst contribution will go. Aside from being kind during code reviews, and applying general code review best practices.
  200. @amaltson Day to Day 👩💼 🫣 👨💻 Speaker Note: You

    can really make them feel welcome and a part of the team or community by acknowledging their contribution, however small, using something like All Contributors.
  201. @amaltson Day to Day 👩💼 👨💻 🥹 Speaker Note: You

    can really make them feel welcome and a part of the team or community by acknowledging their contribution, however small, using something like All Contributors.
  202. @amaltson Day to Day 👩💼 👨💻 🥹 Speaker Note: You

    can really make them feel welcome and a part of the team or community by acknowledging their contribution, however small, using something like All Contributors.
  203. @amaltson Day to Day 👩💼 👨💻 Speaker Note: But as

    the days go by, it starts to get hard to keep track of all the changes happening and we start to forget.
  204. @amaltson Day to Day 👩💼 😵💫 👨💻 Speaker Note: But

    as the days go by, it starts to get hard to keep track of all the changes happening and we start to forget.
  205. @amaltson Day to Day 👩💼 😵💫 👨💻 Speaker Note: But

    as the days go by, it starts to get hard to keep track of all the changes happening and we start to forget.
  206. @amaltson Day to Day 👩💼 🤔 👨💻 To improve the

    experience, consider keeping a changelog of what’s changed 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 fi ll 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. There’s even libraries to generate them now if you have good commit messages, and I’m sure Copilot will help make that even easier soon.
  207. @amaltson Day to Day 👩💼 🤔 👨💻 To improve the

    experience, consider keeping a changelog of what’s changed 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 fi ll 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. There’s even libraries to generate them now if you have good commit messages, and I’m sure Copilot will help make that even easier soon.
  208. @amaltson Day to Day 👩💼 🤔 👨💻 To improve the

    experience, consider keeping a changelog of what’s changed 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 fi ll 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. There’s even libraries to generate them now if you have good commit messages, and I’m sure Copilot will help make that even easier soon.
  209. @amaltson Day to Day 👩💼 🤩 👨💻 To improve the

    experience, consider keeping a changelog of what’s changed 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 fi ll 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. There’s even libraries to generate them now if you have good commit messages, and I’m sure Copilot will help make that even easier soon.
  210. @amaltson Day to Day 👩💼 🤩 👨💻 Speaker Note: In

    order to create an amazing Developer Experience for the day to day in mob-up..
  211. @amaltson Day to Day ⭐ Recognize all contributors 👩💼 🤩

    👨💻 Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..
  212. @amaltson Day to Day ⭐ Recognize all contributors 📝 Keep

    a CHANGELOG 👩💼 🤩 👨💻 Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..
  213. @amaltson 👩💼 👨💻 Speaker Note: No matter how well factored

    the code is, at one point or another a project comes to an end and is retired. Let’s look at how to maintain a great Developer Experience while retiring a project like mob-up.
  214. @amaltson 👵 👨💻 Speaker Note: No matter how well factored

    the code is, at one point or another a project comes to an end and is retired. Let’s look at how to maintain a great Developer Experience while retiring a project like mob-up.
  215. @amaltson Retirement 👵 😔 👨💻 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.
  216. @amaltson Retirement 👵 🧐 👨💻 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.
  217. @amaltson Retirement 👵 🥳 👨💻 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.
  218. @amaltson Retirement 👵 🤨 👨💻 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.
  219. @amaltson Retirement 👵 😟 👨💻 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.
  220. @amaltson Retirement 👵 😟 👨💻 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 fi x”, 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 just because the project may be revived, which is possible, but more because you may come back and reuse some of the code in the future. Leaving it in a good state will facilitate reuse.
  221. @amaltson Retirement 👵 🙂 👨💻 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 fi x”, 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 just because the project may be revived, which is possible, but more because you may come back and reuse some of the code in the future. Leaving it in a good state will facilitate reuse.
  222. @amaltson Retirement 👵 ✅ 😀 👨💻 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 fi x”, 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 just because the project may be revived, which is possible, but more because you may come back and reuse some of the code in the future. Leaving it in a good state will facilitate reuse.
  223. @amaltson Retirement 👵 😀 👨💻 Speaker Note: And to put

    a bow on it, use “Archive this repository” feature in 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.
  224. @amaltson Retirement 👵 😀 👨💻 Speaker Note: And to put

    a bow on it, use “Archive this repository” feature in 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.
  225. @amaltson Retirement 👵 🤩 👨💻 Speaker Note: And to put

    a bow on it, use “Archive this repository” feature in 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.
  226. @amaltson Retirement 👵 🤩 👨💻 Speaker Note: While not something

    we generally think about, we can still create an amazing Developer Experience for the retirement of mob-up.
  227. @amaltson Retirement 🧹 Leave code in a good state 👵

    🤩 👨💻 Speaker Note: While not something we generally think about, we can still create an amazing Developer Experience for the retirement of mob-up.
  228. @amaltson Retirement 🧹 Leave code in a good state 🗃

    Archive it 👵 🤩 👨💻 Speaker Note: While not something we generally think about, we can still create an amazing Developer Experience for the retirement of mob-up.
  229. @amaltson Developer Experience 👩💼 Recognize all contributors Keep a CHANGELOG

    👶 Data fl ow sequence diagrams Tours through the code base 👵 Leave code in a good state Archive it 🧒 Easy workstation setup Pull Request checklist 👨💻 🤩 Speaker Note: Let’s bring it all together and review how we make an amazing developer experience working together on mob-up.
  230. @amaltson @amaltson Speaker Note: Well that was a whirl wind

    tour of tips and tricks to improve developer experience.
  231. @amaltson @amaltson Speaker Note: Well that was a whirl wind

    tour of tips and tricks to improve developer experience.
  232. @amaltson User Experience Speaker Note: Looking back now, we know

    we left a lot of value on the table by not focusing on User Experience a couple decades ago.
  233. @amaltson 💵 📈💰💰💰 User Experience Speaker Note: Looking back now,

    we know we left a lot of value on the table by not focusing on User Experience a couple decades ago.
  234. @amaltson Developer Experience Speaker Note: We now know the three

    costs of not focusing on Developer Experience now: monetary, mental energy and morale.
  235. @amaltson 💰 Developer Experience Speaker Note: We now know the

    three costs of not focusing on Developer Experience now: monetary, mental energy and morale.
  236. @amaltson 💰 🧠 Developer Experience Speaker Note: We now know

    the three costs of not focusing on Developer Experience now: monetary, mental energy and morale.
  237. @amaltson 💰 🧠 😍 Developer Experience Speaker Note: We now

    know the three costs of not focusing on Developer Experience now: monetary, mental energy and morale.
  238. @amaltson Developer Experience 👩💼 Levenshtein distance suggestions Next level bug

    experience 👶 Provide one liner installation If not easily installable, use Docker! 👵 Clear and automated migration 🧒 Do work on the user’s behalf Monitoring and alerting* 🛠 🤩 * where appropriate, like internal tools Speaker Note: We went through some practical tips to improve Developer Experience when building a tool for others to use.
  239. @amaltson Developer Experience 👩💼 Recognize all contributors Keep a CHANGELOG

    👶 Data fl ow sequence diagrams Tours through the code base 👵 Leave code in a good state Archive it 🧒 Easy workstation setup Pull Request checklist 👨💻 🤩 Speaker Note: Then we went through some practical tips to improve Developer Experience when working with others.
  240. @amaltson Developer Experience Speaker Note: … the Developer Experience of

    what you’re working on. Introduce just one or two of these ideas..
  241. @amaltson 😡💻 Developer Experience Speaker Note: … and start improving

    the Developer Experience and turn your frustrated developers into happy developers.
  242. @amaltson 😡💻 😄 Developer Experience Speaker Note: … and start

    improving the Developer Experience and turn your frustrated developers into happy developers.
  243. @amaltson Arthur Maltson We’re Hiring! @amaltson • Slides: h tt

    ps://speakerdeck.com/amaltson/ • Mob Up (someday): h tt ps://github.com/amaltson/mob-up • GitHub Issue Templates and Issue Forms • Semantic Release bot • Mermaid.js sequence diagram syntax • Mermaid.js preview and syntax highlighting VS Code Plugin • CodeTour VS Code Plugin • DevContainers standard • GitHub PR Templates • All Contributors to recognize contributions • Keep A Changelog • PairUp, Git Duel, and Git Mob (has VS Code plugin)
  244. @amaltson Credits • assorted-color yarns, Karly Santiago, h tt ps://unsplash.com/photos/E7zsz8JA8FM

    • MapQuest in 2005, Wayback Machine Internet Archive, h tt ps://web.archive.org/web/20050625054602/h tt p://www.mapquest.com/ • MapQuest in 2019, MapQuest, h tt ps://www.mapquest.com • Google Maps in 2005, Google, h tt ps://blog.google/products/maps/look-back-15-years-mapping-world • Calculate RIO, h tt ps://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, h tt ps://ai.googleblog.com/2012/08/users-love-simple-and-familiar-designs.html • Toonie.2012.design.reverse, Wikimedia, h tt ps://en.wikipedia.org/wiki/File:Toonie.2012.design.reverse.png • Empathic: h tt ps://www.grammarly.com/blog/empathetic • Tree top trekking, Mads Schmidt Rasmussen, h tt ps://unsplash.com/photos/man-in-black-and-white-crew-neck-t-shirt-and-black-shorts-standing-on-brown-wooden-Lz1-gr6-pCk • Cecily Strong Shrug Gif By Saturday Night Live, Saturday Night Live, h tt ps://gph.is/2d1eSi8 • Going deep gif, h tt ps://media.giphy.com/media/MczHh1PkwAqwU/giphy.gif • Co-authored-by instructions: h tt ps://github.blog/2018-01-29-commit-together-with-co-authors/ • Working on new code base Tweet, Sarah Drasner, h tt ps://twi tt er.com/sarah_edo/status/1172210626573111296?s=21 • I Have No Memory Of This Place, gifbay, h tt ps://giphy.com/gifs/lost-gandalf-memory-FPjbHO0jJxGsE • Tour Sign, Tom Brown, h tt ps://unsplash.com/photos/a-stop-sign-with-a-white-arrow-tyEgbBPuPuQ • CodeTour plugin gifs, h tt ps://marketplace.visualstudio.com/items?itemName=vsls-contrib.codetour#navigating-tours • Funny changelog: h tt ps://www.androidpit.com/here-are-the-most-hilarious-change-logs-ever-wri tt en • brown wooden trunk, Lena De Fanti, h tt ps://unsplash.com/photos/W4HtdHYqmUg • Typing Montage GIF, ReactionsEditor, h tt ps://gph.is/2oW0XKw • Homebrew logo, Homebrew, h tt ps://brew.sh • Debian logo, Wikimedia, h tt ps://commons.wikimedia.org/wiki/File:Debian-OpenLogo.svg • Red Hat logo, Wikimedia, h tt ps://en.wikipedia.org/wiki/File:Red_Hat_Logo_2019.svg • Curl Logo, Curl, h tt ps://curl.haxx.se/logo/ • Go gopher, Renee French, h tt ps://github.com/golang-samples/gopher-vector • Rust logo, Rust Lang, h tt ps://github.com/rust-lang/rust-artwork • Moby logo, Docker Inc, h tt ps://www.docker.com/company/newsroom/media-resources • Arrival still, Paramount Pictures, h tt ps://www.wired.co.uk/article/arrival-science-fact-fiction • NewRelic APM dashboard, h tt ps://newrelic.com/blog/best-practices/how-to-manage-an-application-log • Levenshtein distance, Wikipedia, h tt ps://en.wikipedia.org/wiki/Levenshtein_distance • Bicentennial Trail, Michael Hicks, h tt ps:// fl ic.kr/p/assieJ • Dog Puppy Gif, Giphy, h tt ps://gph.is/1ko3wyq • Toronto Raptors Gif, Giphy, h tt ps://gph.is/g/aK5By84 • Code highlight with Carbon.now.sh • Deposit Photos purchased content for everything else.