Tweet
Tweet

Slide 1

Slide 1 text

Built With ❤ Why Developer Experience Matters Arthur Maltson @amaltson

Slide 2

Slide 2 text

Built With ❤ Why Developer/Designers/ Operators/Tool Users Experience Matters Arthur Maltson @amaltson

Slide 3

Slide 3 text

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.

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

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.

Slide 6

Slide 6 text

@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…

Slide 7

Slide 7 text

@amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.

Slide 8

Slide 8 text

@amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.

Slide 9

Slide 9 text

✨ ✨ ✨ ✨ @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?

Slide 10

Slide 10 text

✨ ✨ ✨ ✨ @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?

Slide 11

Slide 11 text

✨ ✨ ✨ ✨ @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?

Slide 12

Slide 12 text

✨ ✨ ✨ ✨ @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?

Slide 13

Slide 13 text

✨ ✨ ✨ ✨ + @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?

Slide 14

Slide 14 text

@amaltson Speaker Note: Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, Google had made the prospective change.

Slide 15

Slide 15 text

@amaltson Speaker Note: Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, Google had made the prospective change.

Slide 16

Slide 16 text

@amaltson Speaker Note: Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, Google had made the prospective change.

Slide 17

Slide 17 text

@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.

Slide 18

Slide 18 text

@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.

Slide 19

Slide 19 text

@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.

Slide 20

Slide 20 text

@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.

Slide 21

Slide 21 text

@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.

Slide 22

Slide 22 text

@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.

Slide 23

Slide 23 text

@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.

Slide 24

Slide 24 text

@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.

Slide 25

Slide 25 text

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…

Slide 26

Slide 26 text

Developer Experience @amaltson Speaker Note: … not focusing on Developer Experience now? Wait, hold on, what is Developer Experience? Good question, we haven’t defined it yet. Developer Experience is similar to User Experience in that…

Slide 27

Slide 27 text

Developer Experience @amaltson Speaker Note: … we take a frustrate developer, make a bunch of changes to the tool or project they're working on, and get a happy developer.

Slide 28

Slide 28 text

Developer Experience @amaltson Speaker Note: … we take a frustrate developer, make a bunch of changes to the tool or project they're working on, and get a happy developer.

Slide 29

Slide 29 text

@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.

Slide 30

Slide 30 text

@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.

Slide 31

Slide 31 text

@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.

Slide 32

Slide 32 text

@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.

Slide 33

Slide 33 text

@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.

Slide 34

Slide 34 text

@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.

Slide 35

Slide 35 text

@amaltson Speaker Note: Technology professionals cost a lot of money. Overall compared with other professions we’re doing pretty well. If you take a group of developers and have them spend a week on setting up their workstations, that’s a huge cost where they’re not working on the next feature.

Slide 36

Slide 36 text

@amaltson Speaker Note: Technology professionals cost a lot of money. Overall compared with other professions we’re doing pretty well. If you take a group of developers and have them spend a week on setting up their workstations, that’s a huge cost where they’re not working on the next feature.

Slide 37

Slide 37 text

@amaltson Speaker Note: Technology professionals cost a lot of money. Overall compared with other professions we’re doing pretty well. If you take a group of developers and have them spend a week on setting up their workstations, that’s a huge cost where they’re not working on the next feature.

Slide 38

Slide 38 text

@amaltson Speaker Note: Technology professionals cost a lot of money. Overall compared with other professions we’re doing pretty well. If you take a group of developers and have them spend a week on setting up their workstations, that’s a huge cost where they’re not working on the next feature.

Slide 39

Slide 39 text

@amaltson Speaker Note: Technology professionals cost a lot of money. Overall compared with other professions we’re doing pretty well. If you take a group of developers and have them spend a week on setting up their workstations, that’s a huge cost where they’re not working on the next feature.

Slide 40

Slide 40 text

@amaltson Speaker Note: That’s the fiscal side, now let’s talk about the mental energy side.

Slide 41

Slide 41 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 42

Slide 42 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 43

Slide 43 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 44

Slide 44 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 45

Slide 45 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 46

Slide 46 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 47

Slide 47 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 48

Slide 48 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 49

Slide 49 text

@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. For our American friends, these are Canadian one dollar coins, also known a loonie because they have a loon on the front, not because they’re loony, though they could be. Fun fact, we also have a toonie for 2 dollars, but I digress. Anyway, everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.

Slide 50

Slide 50 text

@amaltson Speaker Note: That’s the mental energy aspect, now let’s talk about moral.

Slide 51

Slide 51 text

@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.

Slide 52

Slide 52 text

@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.

Slide 53

Slide 53 text

@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.

Slide 54

Slide 54 text

@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.

Slide 55

Slide 55 text

@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.

Slide 56

Slide 56 text

@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.

Slide 57

Slide 57 text

@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.

Slide 58

Slide 58 text

Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.

Slide 59

Slide 59 text

Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.

Slide 60

Slide 60 text

Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.

Slide 61

Slide 61 text

Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

@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.

Slide 65

Slide 65 text

@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.

Slide 66

Slide 66 text

@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.

Slide 67

Slide 67 text

Experience Lifecycle @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to- day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.

Slide 68

Slide 68 text

Experience Lifecycle @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to- day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.

Slide 69

Slide 69 text

Experience Lifecycle @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to- day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.

Slide 70

Slide 70 text

Experience Lifecycle @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to- day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.

Slide 71

Slide 71 text

Experience Lifecycle @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to- day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.

Slide 72

Slide 72 text

@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.

Slide 73

Slide 73 text

@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.

Slide 74

Slide 74 text

@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.

Slide 75

Slide 75 text

@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or DevOps tooling, but the specific implementation will differ depending on the language.

Slide 76

Slide 76 text

@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.

Slide 77

Slide 77 text

@amaltson Speaker Note: Let’s put on our construction boots and get more concrete and discuss a specific problem.

Slide 78

Slide 78 text

@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?

Slide 79

Slide 79 text

@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.

Slide 80

Slide 80 text

@amaltson Speaker Note: There are a bunch of tools out there to give the proper attribution, one of them is called Pair Up. Pair Up achieves this by using a little trick in Git, it sets the GIT_AUTHOR_NAME/EMAIL to the primary person and the GIT_COMMITTER_NAME/ EMAIL to the pair. But this only works for pairing, not mobbing since you can only set for two people. It also doesn’t fully reflect how the code was written.

Slide 81

Slide 81 text

@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.

Slide 82

Slide 82 text

@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.

Slide 83

Slide 83 text

@amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!

Slide 84

Slide 84 text

Pair Up Up @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!

Slide 85

Slide 85 text

Mob Up @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!

Slide 86

Slide 86 text

Experience Lifecycle @amaltson Speaker Note: So for this imaginary project, let’s start by talking about working on mob-up in team with other developers and how to improve the experience there.

Slide 87

Slide 87 text

Experience Lifecycle @amaltson Speaker Note: So for this imaginary project, let’s start by talking about working on mob-up in team with other developers and how to improve the experience there.

Slide 88

Slide 88 text

Getting Started @amaltson Speaker Note: When introducing a new developer to the mob up code base, the reaction to new code is often like this. Right? Where do you even start with the code, how do you get in and start understanding what’s happening?

Slide 89

Slide 89 text

Getting Started @amaltson Speaker Note: When introducing a new developer to the mob up code base, the reaction to new code is often like this. Right? Where do you even start with the code, how do you get in and start understanding what’s happening?

Slide 90

Slide 90 text

Getting Started @amaltson Speaker Note: When introducing a new developer to the mob up code base, the reaction to new code is often like this. Right? Where do you even start with the code, how do you get in and start understanding what’s happening?

Slide 91

Slide 91 text

Getting Started @amaltson Speaker Note: One approach my team and I have found a lot of success with is using sequence diagrams. It’s a bit old school, but it can really help paint a picture of how data flows through your system at a high level and that’s really important to know how the code interacts. Now you might bemoan opening a diagram drawing tool, and it’s hard to source control but what you don’t know is that diagram is generated from source code using PlantUML.

Slide 92

Slide 92 text

Getting Started @amaltson Speaker Note: One approach my team and I have found a lot of success with is using sequence diagrams. It’s a bit old school, but it can really help paint a picture of how data flows through your system at a high level and that’s really important to know how the code interacts. Now you might bemoan opening a diagram drawing tool, and it’s hard to source control but what you don’t know is that diagram is generated from source code using PlantUML.

Slide 93

Slide 93 text

Getting Started @amaltson Speaker Note: The best part is, there’s a VSCode plugin for PlantUML which live previews the diagram. Makes it really easy to author them.

Slide 94

Slide 94 text

Getting Started @amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..

Slide 95

Slide 95 text

Getting Started • Data flow sequence diagrams @amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..

Slide 96

Slide 96 text

@amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.

Slide 97

Slide 97 text

@amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.

Slide 98

Slide 98 text

First Commit @amaltson Speaker Note: The first commit is often anxiety ridden. Even if the new member has made the mob-up changes locally and got the build green, there’s still a matter of proposing that first change. What’s expected of you?

Slide 99

Slide 99 text

First Commit @amaltson Speaker Note: The first commit is often anxiety ridden. Even if the new member has made the mob-up changes locally and got the build green, there’s still a matter of proposing that first change. What’s expected of you?

Slide 100

Slide 100 text

First Commit @amaltson Speaker Note: To ease that anxiety and also maintain consistency across the whole project, we can introduce a Pull Requests checklist to mob-up. We can use the PR checklist to guide new people and remind old hats what’s required to get a successful merge. And we all know checking off check lists makes you feel like a super star!

Slide 101

Slide 101 text

First Commit @amaltson Speaker Note: To ease that anxiety and also maintain consistency across the whole project, we can introduce a Pull Requests checklist to mob-up. We can use the PR checklist to guide new people and remind old hats what’s required to get a successful merge. And we all know checking off check lists makes you feel like a super star!

Slide 102

Slide 102 text

First Commit @amaltson Speaker Note: To ease that anxiety and also maintain consistency across the whole project, we can introduce a Pull Requests checklist to mob-up. We can use the PR checklist to guide new people and remind old hats what’s required to get a successful merge. And we all know checking off check lists makes you feel like a super star!

Slide 103

Slide 103 text

First Commit @amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..

Slide 104

Slide 104 text

First Commit • Pull Request checklist @amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..

Slide 105

Slide 105 text

@amaltson Speaker Note: Alright, that’s the first commit experience. Let’s now look at improving the Developer Experience in our day to day.

Slide 106

Slide 106 text

@amaltson Speaker Note: Alright, that’s the first commit experience. Let’s now look at improving the Developer Experience in our day to day.

Slide 107

Slide 107 text

Day to Day @amaltson Speaker Note: As we work day to day on a project like mob-up, it’s hard to keep track of all the changes happening especially if there are more than a couple developers on the project. It’s hard to remember what’s changed.

Slide 108

Slide 108 text

Day to Day @amaltson Speaker Note: As we work day to day on a project like mob-up, it’s hard to keep track of all the changes happening especially if there are more than a couple developers on the project. It’s hard to remember what’s changed.

Slide 109

Slide 109 text

Day to Day @amaltson Speaker Note: As we work day to day on a project like mob-up, it’s hard to keep track of all the changes happening especially if there are more than a couple developers on the project. It’s hard to remember what’s changed.

Slide 110

Slide 110 text

Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration . One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.

Slide 111

Slide 111 text

Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration . One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.

Slide 112

Slide 112 text

Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration . One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.

Slide 113

Slide 113 text

Day to Day @amaltson Speaker Note: To improve the experience, consider keeping a changelog of what’s been change in the application. Keeping track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration . One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.

Slide 114

Slide 114 text

Day to Day @amaltson Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..

Slide 115

Slide 115 text

Day to Day • Keep a CHANGELOG @amaltson Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..

Slide 116

Slide 116 text

@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.

Slide 117

Slide 117 text

@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.

Slide 118

Slide 118 text

Retirement @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the Developer Experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.

Slide 119

Slide 119 text

Retirement @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the Developer Experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.

Slide 120

Slide 120 text

Retirement @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the Developer Experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.

Slide 121

Slide 121 text

Retirement @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the Developer Experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.

Slide 122

Slide 122 text

Retirement @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the Developer Experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.

Slide 123

Slide 123 text

Retirement @amaltson Speaker Note: The major undertaking to improve the experience is to leave the project in a good state. Close off all the issues, maybe marking them as “won’t fix”, but at least closing them off. Try to get the open PRs merged in. Make sure to leave the build green. Why you may ask? Leaving everything in a clean state is important not necessarily because the project may come back, which is possible, but more because you may come back and reuse some of the code and leaving it in a good state will facilitate reuse.

Slide 124

Slide 124 text

Retirement @amaltson Speaker Note: The major undertaking to improve the experience is to leave the project in a good state. Close off all the issues, maybe marking them as “won’t fix”, but at least closing them off. Try to get the open PRs merged in. Make sure to leave the build green. Why you may ask? Leaving everything in a clean state is important not necessarily because the project may come back, which is possible, but more because you may come back and reuse some of the code and leaving it in a good state will facilitate reuse.

Slide 125

Slide 125 text

Retirement ✅ @amaltson Speaker Note: The major undertaking to improve the experience is to leave the project in a good state. Close off all the issues, maybe marking them as “won’t fix”, but at least closing them off. Try to get the open PRs merged in. Make sure to leave the build green. Why you may ask? Leaving everything in a clean state is important not necessarily because the project may come back, which is possible, but more because you may come back and reuse some of the code and leaving it in a good state will facilitate reuse.

Slide 126

Slide 126 text

Retirement @amaltson Speaker Note: And to put a bow on it, use “Archive this repository” feature in GitHub (if you use GitHub) and make the project read only. You can always revive it later, but don’t delay making the project read only to avoid those PRs to a decommissioned project. It’s read only so we can always reuse the code in the future.

Slide 127

Slide 127 text

Retirement @amaltson Speaker Note: And to put a bow on it, use “Archive this repository” feature in GitHub (if you use GitHub) and make the project read only. You can always revive it later, but don’t delay making the project read only to avoid those PRs to a decommissioned project. It’s read only so we can always reuse the code in the future.

Slide 128

Slide 128 text

Retirement @amaltson Speaker Note: And to put a bow on it, use “Archive this repository” feature in GitHub (if you use GitHub) and make the project read only. You can always revive it later, but don’t delay making the project read only to avoid those PRs to a decommissioned project. It’s read only so we can always reuse the code in the future.

Slide 129

Slide 129 text

Retirement @amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.

Slide 130

Slide 130 text

Retirement • Leave code in a good state @amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.

Slide 131

Slide 131 text

Retirement • Leave code in a good state • Archive it @amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.

Slide 132

Slide 132 text

Developer Experience @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.

Slide 133

Slide 133 text

Developer Experience @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.

Slide 134

Slide 134 text

Developer Experience • Data flow sequence diagrams @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.

Slide 135

Slide 135 text

Developer Experience • Pull Request checklist • Data flow sequence diagrams @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.

Slide 136

Slide 136 text

Developer Experience • Pull Request checklist • Keep a CHANGELOG • Data flow sequence diagrams @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.

Slide 137

Slide 137 text

Developer Experience • Pull Request checklist • Keep a CHANGELOG • Leave code in a good state • Archive it • Data flow sequence diagrams @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.

Slide 138

Slide 138 text

Experience Lifecycle @amaltson Speaker Note: Now that we understand how to improve Developer Experience when collaborating with others, let’s look how we can improve the experience as a tool author building tools for other developers to use.

Slide 139

Slide 139 text

Experience Lifecycle @amaltson Speaker Note: Now that we understand how to improve Developer Experience when collaborating with others, let’s look how we can improve the experience as a tool author building tools for other developers to use.

Slide 140

Slide 140 text

@amaltson Speaker Note: And this is where we need to make a slight tangent, to discuss the type tools we’re building.

Slide 141

Slide 141 text

@amaltson Speaker Note: And this is where we need to make a slight tangent, to discuss the type tools we’re building.

Slide 142

Slide 142 text

@amaltson Speaker Note: I believe it’s important to meet developers we’re there at…

Slide 143

Slide 143 text

@amaltson Speaker Note: In their mother’s basement… no wait.

Slide 144

Slide 144 text

@amaltson Speaker Note: At a Star Trek convention… no no. I’m joking of course.

Slide 145

Slide 145 text

@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.

Slide 146

Slide 146 text

@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.

Slide 147

Slide 147 text

@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.

Slide 148

Slide 148 text

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.

Slide 149

Slide 149 text

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.

Slide 150

Slide 150 text

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.

Slide 151

Slide 151 text

CLI @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 152

Slide 152 text

CLI Command Line Interface @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 153

Slide 153 text

CLI Command Line Interface @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 154

Slide 154 text

CLI Command Line Interface Well Factored Code @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 155

Slide 155 text

CLI Command Line Interface Well Factored Code @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 156

Slide 156 text

CLI Command Line Interface Well Factored Code Web App @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 157

Slide 157 text

CLI Command Line Interface Well Factored Code Web App @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 158

Slide 158 text

CLI Command Line Interface Well Factored Code Editor Plugin Web App @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 159

Slide 159 text

CLI Command Line Interface Well Factored Code Editor Plugin Web App @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 160

Slide 160 text

CLI Command Line Interface Well Factored Code Editor Plugin Web App Electron App @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 161

Slide 161 text

CLI Command Line Interface Well Factored Code Editor Plugin Web App Electron App @amaltson Speaker Note: One could argue that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users.

Slide 162

Slide 162 text

CLI @amaltson Speaker Note: Point is, if you start CLI first, you get the best of both worlds. So our examples going forward we will assume we are build a CLI and talk about Developer Experience with a CLI.

Slide 163

Slide 163 text

Experience Lifecycle @amaltson Speaker Note: Alright, tangent done, let’s get back to looking how to improve the Developer Experience in the lifecycle of using a tool.

Slide 164

Slide 164 text

Getting Started @amaltson Speaker Note: And nothing makes that initial getting started experience painful like having a laundry list of prerequisites, like installing some language you’re not familiar with and manually installing third party dependencies. And once you get over that hump, the instructions for tool installation are a multi- step process.

Slide 165

Slide 165 text

Getting Started @amaltson Speaker Note: And nothing makes that initial getting started experience painful like having a laundry list of prerequisites, like installing some language you’re not familiar with and manually installing third party dependencies. And once you get over that hump, the instructions for tool installation are a multi- step process.

Slide 166

Slide 166 text

Getting Started @amaltson Speaker Note: And nothing makes that initial getting started experience painful like having a laundry list of prerequisites, like installing some language you’re not familiar with and manually installing third party dependencies. And once you get over that hump, the instructions for tool installation are a multi- step process.

Slide 167

Slide 167 text

Getting Started @amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).

Slide 168

Slide 168 text

Getting Started @amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).

Slide 169

Slide 169 text

Getting Started @amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).

Slide 170

Slide 170 text

Getting Started @amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).

Slide 171

Slide 171 text

Getting Started @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.

Slide 172

Slide 172 text

Getting Started @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.

Slide 173

Slide 173 text

Getting Started @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.

Slide 174

Slide 174 text

Getting Started @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.

Slide 175

Slide 175 text

Getting Started @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it’s written in something else, especially that needs a native OS dependency, things can go up in flames fast.

Slide 176

Slide 176 text

Getting Started @amaltson Speaker Note: To not have that happen, we’re going to take our application and put it into a larger package, a Docker container. And then using a tiny bit of shell scripting, we can make an “executable” that looks and feels like a binary package and allows you to control all the dependencies you need. I’ve found this particular trick very handy for packaging Ruby and Python programs. Best part is, they’re always up to date!

Slide 177

Slide 177 text

Getting Started @amaltson Speaker Note: To not have that happen, we’re going to take our application and put it into a larger package, a Docker container. And then using a tiny bit of shell scripting, we can make an “executable” that looks and feels like a binary package and allows you to control all the dependencies you need. I’ve found this particular trick very handy for packaging Ruby and Python programs. Best part is, they’re always up to date!

Slide 178

Slide 178 text

Getting Started @amaltson Speaker Note: To not have that happen, we’re going to take our application and put it into a larger package, a Docker container. And then using a tiny bit of shell scripting, we can make an “executable” that looks and feels like a binary package and allows you to control all the dependencies you need. I’ve found this particular trick very handy for packaging Ruby and Python programs. Best part is, they’re always up to date!

Slide 179

Slide 179 text

Getting Started @amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.

Slide 180

Slide 180 text

Getting Started • Provide one liner installation @amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.

Slide 181

Slide 181 text

Getting Started • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

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

Slide 184

Slide 184 text

First Contact @amaltson Speaker Note: That’s what we can think of as first contact. It’s the first experience the developer has using your tool, after getting it installed that is. This is most nerve wracking part of using a new tool.

Slide 185

Slide 185 text

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

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

First Contact @amaltson Speaker Note: We go out and use the GitHub API and find the user’s name and email automatically. Now that’s a wow experience.

Slide 188

Slide 188 text

First Contact @amaltson Speaker Note: We go out and use the GitHub API and find the user’s name and email automatically. Now that’s a wow experience.

Slide 189

Slide 189 text

First Contact @amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…

Slide 190

Slide 190 text

First Contact • Do work on the user’s behalf @amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…

Slide 191

Slide 191 text

@amaltson Speaker Note: Now our user has started using our tool, how can we improve the day to day Developer Experience?

Slide 192

Slide 192 text

@amaltson Speaker Note: Now our user has started using our tool, how can we improve the day to day Developer Experience?

Slide 193

Slide 193 text

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.

Slide 194

Slide 194 text

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.

Slide 195

Slide 195 text

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.

Slide 196

Slide 196 text

Day to Day @amaltson Speaker Note: But many tools have really good error messages. You’ve probably seen this from Git when you mistype a command. Not only do they clearly explain what the problem is, but also suggests how to fix it. Can we do something like this for mob-up?

Slide 197

Slide 197 text

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…

Slide 198

Slide 198 text

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…

Slide 199

Slide 199 text

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…

Slide 200

Slide 200 text

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?

Slide 201

Slide 201 text

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?

Slide 202

Slide 202 text

Day to Day Levenshtein distance @amaltson Speaker Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Since we know all of our keywords, for example in configuration we have “name”, “email”, “timeout”, etc, we can run a Levenshtein distance of a misconfigured word against all the keywords and the one with the lowest score (least transformations, up to a threshold of course) is probably the one they meant!

Slide 203

Slide 203 text

Day to Day Levenshtein distance @amaltson Speaker Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Since we know all of our keywords, for example in configuration we have “name”, “email”, “timeout”, etc, we can run a Levenshtein distance of a misconfigured word against all the keywords and the one with the lowest score (least transformations, up to a threshold of course) is probably the one they meant!

Slide 204

Slide 204 text

Day to Day @amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …

Slide 205

Slide 205 text

Day to Day • Levenshtein distance suggestions @amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …

Slide 206

Slide 206 text

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

Slide 207

Slide 207 text

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

Slide 208

Slide 208 text

@amaltson Retirement Speaker Note: Provide a bridge from the current tool and to the next one, if it exists. If there’s multiple, look at the most promising one and direct users. Imagine how the user feels, they’re now aware your tool is getting deprecated and confused where to go next. We need to provide that guidance to gracefully retire the tool. But how do we get that “wow” experience?

Slide 209

Slide 209 text

Retirement @amaltson Speaker Note: Our users would really love it if someone would help them out. That someone needs to be us. For the optimal retirement, consider partnering with the authors of the new tool and build a migration tool. Worst case scenario, build the tool for them. Remember, as a tool author you’re the force multiplier, you make one change and you can potentially save hundreds of hours for teams.

Slide 210

Slide 210 text

Retirement @amaltson Speaker Note: Our users would really love it if someone would help them out. That someone needs to be us. For the optimal retirement, consider partnering with the authors of the new tool and build a migration tool. Worst case scenario, build the tool for them. Remember, as a tool author you’re the force multiplier, you make one change and you can potentially save hundreds of hours for teams.

Slide 211

Slide 211 text

Retirement @amaltson Speaker Note: Recapping, to have an awesome Developer Experience retiring a tool we should …

Slide 212

Slide 212 text

Retirement • Clear and automated migration @amaltson Speaker Note: Recapping, to have an awesome Developer Experience retiring a tool we should …

Slide 213

Slide 213 text

Developer Experience @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for other developers to use.

Slide 214

Slide 214 text

Developer Experience @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for other developers to use.

Slide 215

Slide 215 text

Developer Experience • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for other developers to use.

Slide 216

Slide 216 text

Developer Experience • Do work on the user’s behalf • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for other developers to use.

Slide 217

Slide 217 text

Developer Experience • Do work on the user’s behalf • Levenshtein distance suggestions • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for other developers to use.

Slide 218

Slide 218 text

Developer Experience • Do work on the user’s behalf • Levenshtein distance suggestions • Clear and automated migration • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for other developers to use.

Slide 219

Slide 219 text

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

Slide 220

Slide 220 text

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

Slide 221

Slide 221 text

@amaltson Speaker Note: Let’s tie this all together with a quick replay.

Slide 222

Slide 222 text

@amaltson Speaker Note: Let’s tie this all together with a quick replay.

Slide 223

Slide 223 text

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.

Slide 224

Slide 224 text

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.

Slide 225

Slide 225 text

Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.

Slide 226

Slide 226 text

Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.

Slide 227

Slide 227 text

Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.

Slide 228

Slide 228 text

Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now: monetary, mental energy and moral.

Slide 229

Slide 229 text

Developer Experience • Pull Request checklist • Keep a CHANGELOG • Leave code in a good state • Archive it • Data flow sequence diagrams @amaltson Speaker Note: We went through some practical tips to improve Developer Experience when working with others.

Slide 230

Slide 230 text

Developer Experience • Do work on the user’s behalf • Levenshtein distance suggestions • Clear and automated migration • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: We then went through some practical tips to improve Developer Experience when building a tool for others to use.

Slide 231

Slide 231 text

@amaltson Speaker Note: So I ask, what are you waiting for to start improving…

Slide 232

Slide 232 text

Developer Experience @amaltson Speaker Note: … the Developer Experience of what you’re working on. Introduce just one or two of these ideas..

Slide 233

Slide 233 text

Developer Experience @amaltson Speaker Note: … and start improving the Developer Experience and turn your angry developers into happy developers.

Slide 234

Slide 234 text

Developer Experience @amaltson Speaker Note: … and start improving the Developer Experience and turn your angry developers into happy developers.

Slide 235

Slide 235 text

Arthur Maltson @amaltson maltson.com Capital One Sr. Manager - Software Engineer 70% Dev, 30% Ops Full Time DadOps

Slide 236

Slide 236 text

@amaltson

Slide 237

Slide 237 text

• Slides: https://www.slideshare.net/ArthurMaltson • Mob Up (someday): https://github.com/amaltson/mob-up • GitHub PR Templates • Keep A Changelog • PlantUML sequence diagram syntax • PlantUML VS Code Plugin • PairUp, Git Duel (actively maintained), and Git Mob (has VS Code plugin) Arthur Maltson We’re Hiring! @amaltson

Slide 238

Slide 238 text

Credits • assorted-color yarns, Karly Santiago, https://unsplash.com/photos/E7zsz8JA8FM • MapQuest in 2005, Wayback Machine Internet Archive, https://web.archive.org/web/20050625054602/http://www.mapquest.com/ • MapQuest in 2019, MapQuest, https://www.mapquest.com • Google_Maps_Beta, Wikimedia, https://en.wikipedia.org/wiki/File:Google_Maps_Beta.png • Calculate RIO, https://uxplanet.org/how-to-calculate-the-roi-of-your-ux-activities-b7ba7023246a • Users love simple and familiar designs – Why websites need to make a great first impression, https://ai.googleblog.com/2012/08/users-love-simple-and-familiar-designs.html • Canadian_Dollar_-_reverse, Wikimedia, https://en.wikipedia.org/wiki/File:Canadian_Dollar_-_reverse.png • Toonie.2012.design.reverse, Wikimedia, https://en.wikipedia.org/wiki/File:Toonie.2012.design.reverse.png • Empathic: https://www.grammarly.com/blog/empathetic • Cecily Strong Shrug Gif By Saturday Night Live, Saturday Night Live, https://gph.is/2d1eSi8 • Co-authored-by instructions: https://github.blog/2018-01-29-commit-together-with-co-authors/ • Working on new code base Tweet, Sarah Drasner, https://twitter.com/sarah_edo/status/1172210626573111296?s=21 • I Have No Memory Of This Place, gifbay, https://giphy.com/gifs/lost-gandalf-memory-FPjbHO0jJxGsE • Funny changelog: https://www.androidpit.com/here-are-the-most-hilarious-change-logs-ever-written • brown wooden trunk, Lena De Fanti, https://unsplash.com/photos/W4HtdHYqmUg • Home Office Remodeling Project (23), Michael Sauers, https://flic.kr/p/7xqsxK • Borg trekkie?, Nathan Rupert, https://flic.kr/p/cAfMoj • Typing Montage GIF, ReactionsEditor, https://gph.is/2oW0XKw • Homebrew logo, Homebrew, https://brew.sh • Debian logo, Wikimedia, https://commons.wikimedia.org/wiki/File:Debian-OpenLogo.svg • Red Hat logo, Wikimedia, https://en.wikipedia.org/wiki/File:Red_Hat_Logo_2019.svg • Curl Logo, Curl, https://curl.haxx.se/logo/ • Go gopher, Renee French, https://github.com/golang-samples/gopher-vector • Rust logo, Rust Lang, https://github.com/rust-lang/rust-artwork • Moby logo, Docker Inc, https://www.docker.com/company/newsroom/media-resources • Arrival still, Paramount Pictures, https://www.wired.co.uk/article/arrival-science-fact-fiction • Levenshtein distance, Wikipedia, https://en.wikipedia.org/wiki/Levenshtein_distance • Bicentennial Trail, Michael Hicks, https://flic.kr/p/assieJ • Dog Puppy Gif, Giphy, https://gph.is/1ko3wyq • Toronto Raptors Gif, Giphy, https://gph.is/g/aK5By84