SlideShare ist ein Scribd-Unternehmen logo

Built With ❤ - Why Developer Experience Matters - Web Unleashed 2019

•
•
A
Arthur Maltson

One evening you’re browsing Twitter and you stumble on a really cool new Open Source tool. The README is intuitive, the installation is seamless and you’re up and running in no time. When using the tool, error messages are clear and how to fix the issues obvious. Before you know it, you’ve achieved what you wanted and you feel like a superstar! But the experience is very different the next day at work. You just spent a couple weeks fiddling to get a project running locally but now you have to jump through hoops to get the application built and deployed with that dreadful internal tool. Why can’t our day time experiences look like our weekend passion projects? It can! In this session you’ll be introduced to the concept of Developer Experience and why it matters. You’ll then embark on a journey to build a new tool with Developer Experience as a core focus. You’ll learn how certain targeted approaches can improve the Developer Experience through the entire Experience Lifecycle. At the end of the talk you will be equipped with ways to improve the Developer Experience in your work; whether you’re building tools for developers, collaborating with other developers on a business project, or just building a side project one your own. This is the version of the presentation given at Web Unleashed 2019.

Technologie
1 von 280
Downloaden Sie, um offline zu lesen
Built With ❤ Why Developer Experience Matters Arthur Maltson @amaltson
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.
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.
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.
@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…
@amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.
@amaltson Speaker Note: Websites look completely different. They’re even responsive and mobile friendly.
✨ ✨ ✨ ✨ @amaltson Speaker Note: But did this happen because we sprinkled some magic pixie dust on the website and made it more functional and aesthetically pleasing. No! It took a bunch of research and experimentation through which we built up a knowledge base. We then took that knowledge, applied our creativity and engineering prowess. Did this happen because of a fundamental technology shift? Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, they had made the prospective change.
✨ ✨ ✨ ✨ % @amaltson Speaker Note: But did this happen because we sprinkled some magic pixie dust on the website and made it more functional and aesthetically pleasing. No! It took a bunch of research and experimentation through which we built up a knowledge base. We then took that knowledge, applied our creativity and engineering prowess. Did this happen because of a fundamental technology shift? Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, they had made the prospective change.
✨ ✨ ✨ ✨ % 📚 @amaltson Speaker Note: But did this happen because we sprinkled some magic pixie dust on the website and made it more functional and aesthetically pleasing. No! It took a bunch of research and experimentation through which we built up a knowledge base. We then took that knowledge, applied our creativity and engineering prowess. Did this happen because of a fundamental technology shift? Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, they had made the prospective change.
✨ ✨ ✨ ✨ % ' 📚 @amaltson Speaker Note: But did this happen because we sprinkled some magic pixie dust on the website and made it more functional and aesthetically pleasing. No! It took a bunch of research and experimentation through which we built up a knowledge base. We then took that knowledge, applied our creativity and engineering prowess. Did this happen because of a fundamental technology shift? Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, they had made the prospective change.
✨ ✨ ✨ ✨ % ' 📚 (+ @amaltson Speaker Note: But did this happen because we sprinkled some magic pixie dust on the website and made it more functional and aesthetically pleasing. No! It took a bunch of research and experimentation through which we built up a knowledge base. We then took that knowledge, applied our creativity and engineering prowess. Did this happen because of a fundamental technology shift? Not really, I mean sure JavaScript, HTML, and CSS have evolved, but much of the underlying capability was already in place in 2005. What it required was a prospective change. You’ll note that I’m talking about MapQuest here and not Google Maps, because in 2005 Google Maps looked very similar to how it looks now. They understood and invested in UX, they had made the prospective change.
@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.
💵 @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.
💵 📈 @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.
💵 📈💰💰💰 @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.
💵 📈💰💰💰 @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.
💵 📈💰💰💰 @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.
💵 📈💰💰💰 @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.
💵 📈💰💰💰 @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.
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…
Developer Experience @amaltson Speaker Note: … not focusing on Developer Experience now? Wait, hold on, what is Developer Experience?
Developer Experience 😡💻 @amaltson Speaker Note: Good question, we haven’t defined it yet. Developer Experience is similar to User Experience in that we take a frustrate developer, make a bunch of changes to the tool or the project they’re working on, and get a happy developer.
Developer Experience 😡💻😄 @amaltson Speaker Note: Good question, we haven’t defined it yet. Developer Experience is similar to User Experience in that we take a frustrate developer, make a bunch of changes to the tool or the project they’re working on, and get a happy developer.
@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.
@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.
@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.
💰 @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.
💰 🧠 @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.
💰 🧠 😍 @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.
💰@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.
( 💰@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.
( 💰 💰@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.
/0 12 ( 💰 💰@amaltson Speaker Note: Technology professionals cost a lot of money. Overall compared with other professions we’re doing pretty well. If you take a group of developers and have them spend a week on setting up their workstations, that’s a huge cost.
/0 12 💰💰💰 💰💰💰 ( 💰 💰@amaltson Speaker Note: Technology professionals cost a lot of money. Overall compared with other professions we’re doing pretty well. If you take a group of developers and have them spend a week on setting up their workstations, that’s a huge cost.
💰 🧠 😍 @amaltson Speaker Note: That’s the fiscal side, now let’s talk about the mental energy side.
🧠@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. Everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.
🧠@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. Everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.
🧠@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. Everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.
🧠@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. Everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.
🧠@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. Everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.
🧠@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. Everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.
🧠@amaltson Speaker Note: To provide a good analogy for mental energy, let us represent it with a certain number of coins you start the day with. Everyone has different energy levels so they’d start with a different amount. Every decision we make or frustration we run into will cost some coins. Steve Jobs recognized this, choosing to wear the same cloths every day (black turtle neck and jeans) as a way to reduce decision points. Imagine how much energy gets drained frustration with a corporate proxy or that downstream system being down.
💰 🧠 😍 @amaltson Speaker Note: That’s the mental energy aspect, now let’s talk about moral.
😍@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.
😍 😍@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.
😍😀 😍@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.
😍😀🙂 😍@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.
😍😀🙂🙁 😍@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.
😍😀🙂🙁😡 😍@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.
😍😀🙂🙁😡 😍@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.
Developer Experience @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
Developer Experience 💰 @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
Developer Experience 💰 🧠 @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
Developer Experience 💰 🧠 😍 @amaltson Speaker Note: So why should you care about developer experience? For fiscal reasons, optimizing metal energy use and improving overall moral.
@amaltson Speaker Note: OK, but now what? Yes it matters, but how do we even go about improving developer experience?
@amaltson Speaker Note: OK, but now what? Yes it matters, but how do we even go about improving developer experience?
@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.
🛠 @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.
🛠 7 @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to-day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.
Experience Lifecycle 🛠 7 @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to-day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.
Experience Lifecycle 8 🛠 7 @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to-day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.
Experience Lifecycle 9 🛠 7 @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to-day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.
Experience Lifecycle : 🛠 7 @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to-day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.
Experience Lifecycle ; 🛠 7 @amaltson Speaker Note: Before we start improving it, we need to understand what we’re dealing with. There’s two distinct facets of developer experience, one is the developer experience of using a tool and Developer Experience working on a project with others. To fully understand how to improve Developer Experience in those facets, we need to understand the entire “Experience Lifecycle”. From the very beginning, eg. first time you join the team or just started using that tool. To your first major change or your first couple days with the tool. To the day-to-day working on a code base or using the tool. And finally to the retirement of the project or your migration away from the tool you’re using.
@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or batch, but the specific implementation will differ depending on the language.
@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or batch, but the specific implementation will differ depending on the language.
@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or batch, but the specific implementation will differ depending on the language.
@amaltson Speaker Note: The concepts carries over regardless of whether you’re doing front end development, backend development or batch, but the specific implementation will differ depending on the language.
@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.
@amaltson Speaker Note: Let’s put on our construction boots and get more concrete and discuss a specific problem.
@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?
😿 @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.
@amaltson There are a bunch of tools out there to give the proper attribution, one of them is called Pair Up. Pair Up achieves this by using a little trick in Git, it sets the GIT_AUTHOR_NAME/EMAIL to the primary person and the GIT_COMMITTER_NAME/ EMAIL to the pair. But this only works for pairing, not mobbing since you can only set for two people. It also doesn’t fully reflect how the code was written.
@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.
@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.
@amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
Pair UpUp @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
Mob Up @amaltson Speaker Note: But to rebuild Pair Up, we’ll need a snazzy new name… hmm.. I know! Mob Up!
Experience Lifecycle 8 9 : ; 🛠 7 @amaltson Speaker Note: So for this imaginary project, let’s start by talking about working on a team with other developers and how to improve the experience there.
Experience Lifecycle 8 9 : ; 7 @amaltson Speaker Note: So for this imaginary project, let’s start by talking about working on a team with other developers and how to improve the experience there.
Getting Started 8 7@amaltson Speaker Note: The getting started experience is all about starting on a new project or code base. The fastest way to have a terrible start is an empty README. I’m sure we’ve all see this too often. But let’s be honest, it’s really hard to write a good README, especially when starting from an empty page. Fortunately..
Getting Started 8😡 7@amaltson Speaker Note: The getting started experience is all about starting on a new project or code base. The fastest way to have a terrible start is an empty README. I’m sure we’ve all see this too often. But let’s be honest, it’s really hard to write a good README, especially when starting from an empty page. Fortunately..
Getting Started 8🙁 7@amaltson Speaker Note: There’s a really great blog post that I come back to time and time again on how to write a friendly README that’s welcoming and helps improve that getting started experience. But even with a good README..
Getting Started 8🙁 7@amaltson Speaker Note: .. starting a new code base often feels like this. Right? Where do you even start with the code, how do you get in and start understanding it?
Getting Started 8🙁 7@amaltson Speaker Note: One approach my team and I have found a lot of success with is using sequence diagrams. It’s a bit old school, but it can really help paint a picture of how data flows through your system at a high level and that’s really important to know how the code interacts. Now you might bemoan opening a diagram drawing tool, and it’s hard to source control but what you don’t know is that diagram is generated from source code using PlantUML.
Getting Started 8🙁😐 7@amaltson Speaker Note: One approach my team and I have found a lot of success with is using sequence diagrams. It’s a bit old school, but it can really help paint a picture of how data flows through your system at a high level and that’s really important to know how the code interacts. Now you might bemoan opening a diagram drawing tool, and it’s hard to source control but what you don’t know is that diagram is generated from source code using PlantUML.
Getting Started 8🙁😐 7@amaltson Speaker Note: One approach my team and I have found a lot of success with is using sequence diagrams. It’s a bit old school, but it can really help paint a picture of how data flows through your system at a high level and that’s really important to know how the code interacts. Now you might bemoan opening a diagram drawing tool, and it’s hard to source control but what you don’t know is that diagram is generated from source code using PlantUML.
Getting Started 8 7@amaltson 🙂 Speaker Note: The best part is, there’s a VSCode plugin for PlantUML which live previews the diagram. Makes it really easy to author them.
7@amaltson Speaker Note: Now we need to get the project running locally. For that we need workstation setup. Throughout the years I’ve seen 3 maturity levels for workstation setup.
Getting Started 8 7@amaltson Speaker Note: The first level of maturity is relying on tribal knowledge. Lore that’s passed down from one developer to the next, usually ending with “huh, well that used to work”.
Getting Started 8😖 7@amaltson Speaker Note: The first level of maturity is relying on tribal knowledge. Lore that’s passed down from one developer to the next, usually ending with “huh, well that used to work”.
😖 Getting Started 8 7@amaltson Speaker Note: The next level is the famous wiki page of doom with all the manual steps required to setup your workstation. While sometimes overwhelming, often out of date, it’s still better than tribal knowledge.
Getting Started 8😅 7@amaltson Speaker Note: The next level is the famous wiki page of doom with all the manual steps required to setup your workstation. While sometimes overwhelming, often out of date, it’s still better than tribal knowledge.
Getting Started😅 8 7@amaltson Speaker Note: Finally, the third level of maturity, and by far the preferred, is a fully automated setup. It shouldn’t get out of date because it’s automated and when you keep it to a one liner, it’s easy to follow.
Getting Started😅 8🤩 7@amaltson Speaker Note: Finally, the third level of maturity, and by far the preferred, is a fully automated setup. It shouldn’t get out of date because it’s automated and when you keep it to a one liner, it’s easy to follow.
Getting Started 8🤩 7@amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..
Getting Started • Friendly README 8🤩 7@amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..
Getting Started • Friendly README • Data Flow Diagram 8🤩 7@amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..
Getting Started • Friendly README • Data Flow Diagram • Workstation Setup (that works!) 8🤩 7@amaltson Speaker Note: In order to create an amazing getting started experience to work together on mob-up we need to..
8 7@amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.
9 7@amaltson Speaker Note: Alright, that’s the getting started experience. Let’s now look at making our first commit.
First Commit 9😰 7@amaltson Speaker Note: The first commit is often anxiety ridden, so the first thing we can do to ease the concern is ensure the main branch is always green. Both in your CI/CD server and on the workstation, the build should work cleanly. This is critical for building up that confidence to make that first change and know that it works.
First Commit 9😰 7@amaltson Speaker Note: The first commit is often anxiety ridden, so the first thing we can do to ease the concern is ensure the main branch is always green. Both in your CI/CD server and on the workstation, the build should work cleanly. This is critical for building up that confidence to make that first change and know that it works.
First Commit 9😰 7@amaltson Speaker Note: The first commit is often anxiety ridden, so the first thing we can do to ease the concern is ensure the main branch is always green. Both in your CI/CD server and on the workstation, the build should work cleanly. This is critical for building up that confidence to make that first change and know that it works.
First Commit 9😰 7@amaltson Speaker Note: The first commit is often anxiety ridden, so the first thing we can do to ease the concern is ensure the main branch is always green. Both in your CI/CD server and on the workstation, the build should work cleanly. This is critical for building up that confidence to make that first change and know that it works.
First Commit 9😨 7@amaltson Speaker Note: The first commit is often anxiety ridden, so the first thing we can do to ease the concern is ensure the main branch is always green. Both in your CI/CD server and on the workstation, the build should work cleanly. This is critical for building up that confidence to make that first change and know that it works.
First Commit 9😌 7@amaltson Speaker Note: Even once that new team member has a change ready and working locally, it’s often stressful to open the Pull Request because you’re not sure what’s expected of you. This is where using GitHub’s awesome Pull Request templates, you can guide the user through the expectations and have them feel like a super star.
First Commit 9🤩 7@amaltson Speaker Note: Even once that new team member has a change ready and working locally, it’s often stressful to open the Pull Request because you’re not sure what’s expected of you. This is where using GitHub’s awesome Pull Request templates, you can guide the user through the expectations and have them feel like a super star.
First Commit 9🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..
First Commit • Pipeline Green 9🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..
First Commit • Pipeline Green • GitHub Templates 9🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the first commit to mob-up..
9 7@amaltson Speaker Note: Alright, that’s the first commit experience. Let’s now look at improving the Developer Experience in our day to day.
: 7@amaltson Speaker Note: Alright, that’s the first commit experience. Let’s now look at improving the Developer Experience in our day to day.
Day to Day🤩 : 7@amaltson Speaker Note: We’ve all had the day to day wear off our initial awesome feeling, and why is that? In Rich Hickey’s awesome talk, Simple Made Easy, he has a great analogy for what day to day working with your code feels like. Think of your code as a member of your standup, at first it’s kind of shy and off to the side, not very imposing.
Day to Day :😐 7@amaltson Speaker Note: We’ve all had the day to day wear off our initial awesome feeling, and why is that? In Rich Hickey’s awesome talk, Simple Made Easy, he has a great analogy for what day to day working with your code feels like. Think of your code as a member of your standup, at first it’s kind of shy and off to the side, not very imposing.
Day to Day :😐 7@amaltson Speaker Note: We’ve all had the day to day wear off our initial awesome feeling, and why is that? In Rich Hickey’s awesome talk, Simple Made Easy, he has a great analogy for what day to day working with your code feels like. Think of your code as a member of your standup, at first it’s kind of shy and off to the side, not very imposing.
Day to Day :😐 7@amaltson Speaker Note: And that member starts to grow day by day, interacts with other systems and becomes an active member of the standup. But the problem is, it keeps growing day by day as you add more and more code until…
Day to Day :😐 7@amaltson Speaker Note: The code eventually crowds out everything else and consumes all your free time just feeding the legacy code. Many of you have probably experienced this, so how can we make this experience better?
Day to Day :😐 7@amaltson Speaker Note: We start with consistency. You wouldn’t decorate your bedroom in a goth style, make the kitchen modern and have your bathroom in a 18th century style.
Day to Day :😐 7@amaltson Speaker Note: We start with consistency. You wouldn’t decorate your bedroom in a goth style, make the kitchen modern and have your bathroom in a 18th century style.
Day to Day :😐 7@amaltson Speaker Note: We start with consistency. You wouldn’t decorate your bedroom in a goth style, make the kitchen modern and have your bathroom in a 18th century style.
Day to Day :😐 7@amaltson Speaker Note: We start with consistency. You wouldn’t decorate your bedroom in a goth style, make the kitchen modern and have your bathroom in a 18th century style.
Day to Day :😐 7@amaltson Speaker Note: For example, if your codebase today uses Jasmine for testing but you’re all excited about introducing Jest, do it at a small scale and then get the team’s buy in. If everyone agrees, replace all the tests, don’t leave it partially done. If the team isn’t bought in, don’t leave the experiment in, remove it. Keep it consistent, that’s critical.
Day to Day :😐🙂 7@amaltson Speaker Note: For example, if your codebase today uses Jasmine for testing but you’re all excited about introducing Jest, do it at a small scale and then get the team’s buy in. If everyone agrees, replace all the tests, don’t leave it partially done. If the team isn’t bought in, don’t leave the experiment in, remove it. Keep it consistent, that’s critical.
Day to Day :🙂 7@amaltson To improve the Developer Experience working together further, consider keeping a changelog of what’s been change in the application. Keep track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration 😉. One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.
Day to Day :🙂 7@amaltson To improve the Developer Experience working together further, consider keeping a changelog of what’s been change in the application. Keep track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration 😉. One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.
Day to Day :🙂 7@amaltson To improve the Developer Experience working together further, consider keeping a changelog of what’s been change in the application. Keep track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration 😉. One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.
Day to Day :🙂 7@amaltson To improve the Developer Experience working together further, consider keeping a changelog of what’s been change in the application. Keep track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration 😉. One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.
Day to Day :🙂😁 7@amaltson To improve the Developer Experience working together further, consider keeping a changelog of what’s been change in the application. Keep track of changes is hard, but writing a CHANGELOG shouldn’t be about expressing that frustration 😉. One aspect that’s hard with writing a CHANGELOG is similar to starting a README, a blank page is hard to fill in. This is where the excellent keepachangelog.com comes in. It provides a handy and clean template for standardizing your CHANGELOG and guiding you through the process of writing it.
Day to Day :🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..
Day to Day • Consistency :🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..
Day to Day • Consistency • CHANGELOGs :🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the day to day in mob-up..
: 7@amaltson Speaker Note: No matter how well we’ve factored the code is, at one point or another a project comes to an end and is retired. Let’s look at how to make a great Developer Experience for retiring a project like mob up.
; 7@amaltson Speaker Note: No matter how well we’ve factored the code is, at one point or another a project comes to an end and is retired. Let’s look at how to make a great Developer Experience for retiring a project like mob up.
Retirement ;😔 7@amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the developer experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.
Retirement ;🧐 7@amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the developer experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.
Retirement ; 7 🥳 @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the developer experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.
Retirement ; 7 🤨 @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the developer experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.
Retirement ; 7 😟 @amaltson Speaker Note: While the team is probably sad about the project retiring, let’s think about the developer experience of others who may stumble on the code later on. They might see it as a treasure chest of awesome capability, and get confused when they open it up and the project hasn’t been touched in some time. They might even mistakenly send a PR to the project, then get confused and sad when it’s not actioned.
Retirement ; 7 😟 @amaltson Speaker Note: How do we turn that frown upside-down? First thing is first, a clear deprecation notice on the README. But unfortunately most developers don’t read the documentation.
Retirement ; 7 😶 @amaltson Speaker Note: How do we turn that frown upside-down? First thing is first, a clear deprecation notice on the README. But unfortunately most developers don’t read the documentation.
Retirement ; 7 😶 @amaltson Speaker Note: The next major undertaking to improve the experience is to leave the project in a good state. Close off all the issues, maybe marking them as “won’t fix”, but at least closing them off. Try to get the open PRs merged in. Make sure to leave the build green. Why you may ask? Leaving everything in a clean state is important not necessarily because the project may come back, which is possible, but more because you may come back and reuse some of the code and leaving it in a good state will facilitate reuse.
Retirement ; 7 🙂 @amaltson Speaker Note: The next major undertaking to improve the experience is to leave the project in a good state. Close off all the issues, maybe marking them as “won’t fix”, but at least closing them off. Try to get the open PRs merged in. Make sure to leave the build green. Why you may ask? Leaving everything in a clean state is important not necessarily because the project may come back, which is possible, but more because you may come back and reuse some of the code and leaving it in a good state will facilitate reuse.
Retirement ; 7 ✅ 😀 @amaltson Speaker Note: The next major undertaking to improve the experience is to leave the project in a good state. Close off all the issues, maybe marking them as “won’t fix”, but at least closing them off. Try to get the open PRs merged in. Make sure to leave the build green. Why you may ask? Leaving everything in a clean state is important not necessarily because the project may come back, which is possible, but more because you may come back and reuse some of the code and leaving it in a good state will facilitate reuse.
Retirement ; 7 😀 @amaltson Speaker Note: And to put a bow on it, use “Archive this repository” feature in GitHub (if you use GitHub) and make the project read only. You can always revive it later, but don’t delay making the project read only to avoid those PRs to a decommissioned project. It’s read only so we can always reuse the code in the future.
Retirement ; 7 😀 @amaltson Speaker Note: And to put a bow on it, use “Archive this repository” feature in GitHub (if you use GitHub) and make the project read only. You can always revive it later, but don’t delay making the project read only to avoid those PRs to a decommissioned project. It’s read only so we can always reuse the code in the future.
Retirement ; 7 🤩 @amaltson Speaker Note: And to put a bow on it, use “Archive this repository” feature in GitHub (if you use GitHub) and make the project read only. You can always revive it later, but don’t delay making the project read only to avoid those PRs to a decommissioned project. It’s read only so we can always reuse the code in the future.
Retirement ;🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.
Retirement • Deprecate clearly ;🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.
Retirement • Deprecate clearly • Leave code in a good state ;🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.
Retirement • Deprecate clearly • Leave code in a good state • Archive it ;🤩 7@amaltson Speaker Note: In order to create an amazing Developer Experience for the retirement of mob-up, definitely not something we generally think about.
Developer Experience7 @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.
Developer Experience7🤩 @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.
Developer Experience7🤩 8 • Friendly README • Data Flow Diagram • Workstation Setup (that works!) @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.
Developer Experience7🤩 9 • Pipeline Green • GitHub Templates 8 • Friendly README • Data Flow Diagram • Workstation Setup (that works!) @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.
Developer Experience7🤩 9 • Pipeline Green • GitHub Templates : • Consistency • CHANGELOGs8 • Friendly README • Data Flow Diagram • Workstation Setup (that works!) @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.
Developer Experience7🤩 9 • Pipeline Green • GitHub Templates : • Consistency • CHANGELOGs ; • Deprecate clearly • Leave code in a good state • Archive it 8 • Friendly README • Data Flow Diagram • Workstation Setup (that works!) @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when working with other developers on mob-up.
Experience Lifecycle 8 9 : ; 🛠 7 @amaltson Speaker Note: Now that we understand how to improve Developer Experience when collaborating with others, let’s look how we can improve the experience as a tool author building tools for other developers to use.
Experience Lifecycle 8 9 : ; 🛠 @amaltson Speaker Note: Now that we understand how to improve Developer Experience when collaborating with others, let’s look how we can improve the experience as a tool author building tools for other developers to use.
🛠@amaltson Speaker Note: And this is where we need to make a slight tangent, to discuss the type tools we’re building.
🛠@amaltson Speaker Note: And this is where we need to make a slight tangent, to discuss the type tools we’re building.
🛠 M @amaltson Speaker Note: I believe it’s important to meet developers we’re there at…
🛠@amaltson Speaker Note: In their mother’s basement… no wait.
🛠@amaltson Speaker Note: At a Star Trek convention… no no. I’m joking of course.
🛠 M @amaltson Speaker Note: I mean to meet developers were they are in terms of the tooling they use. And what tooling is that? Well, most developers live in their Editor/IDE of choice writing code, and most of the time running that code through their trusted terminal. Therefore, if we’re building a tool for developers, does it make sense to build it as a GUI web app or a CLI with maybe integration into their editor of choice? I’d argue the latter makes more sense.
🛠 M @amaltson Speaker Note: I mean to meet developers were they are in terms of the tooling they use. And what tooling is that? Well, most developers live in their Editor/IDE of choice writing code, and most of the time running that code through their trusted terminal. Therefore, if we’re building a tool for developers, does it make sense to build it as a GUI web app or a CLI with maybe integration into their editor of choice? I’d argue the latter makes more sense.
🛠 M @amaltson Speaker Note: I mean to meet developers were they are in terms of the tooling they use. And what tooling is that? Well, most developers live in their Editor/IDE of choice writing code, and most of the time running that code through their trusted terminal. Therefore, if we’re building a tool for developers, does it make sense to build it as a GUI web app or a CLI with maybe integration into their editor of choice? I’d argue the latter makes more sense.
🛠 M GUI @amaltson Speaker Note: I mean to meet developers were they are in terms of the tooling they use. And what tooling is that? Well, most developers live in their Editor/IDE of choice writing code, and most of the time running that code through their trusted terminal. Therefore, if we’re building a tool for developers, does it make sense to build it as a GUI web app or a CLI with maybe integration into their editor of choice? I’d argue the latter makes more sense.
🛠 M GUI CLI @amaltson Speaker Note: I mean to meet developers were they are in terms of the tooling they use. And what tooling is that? Well, most developers live in their Editor/IDE of choice writing code, and most of the time running that code through their trusted terminal. Therefore, if we’re building a tool for developers, does it make sense to build it as a GUI web app or a CLI with maybe integration into their editor of choice? I’d argue the latter makes more sense.
🛠 M CLI @amaltson Speaker Note: I mean to meet developers were they are in terms of the tooling they use. And what tooling is that? Well, most developers live in their Editor/IDE of choice writing code, and most of the time running that code through their trusted terminal. Therefore, if we’re building a tool for developers, does it make sense to build it as a GUI web app or a CLI with maybe integration into their editor of choice? I’d argue the latter makes more sense.
CLI 🛠@amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code ( 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code Web App ( 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code Web App ( N 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code Editor PluginWeb App ( N 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code Editor PluginWeb App M ( N 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code Editor PluginWeb App Electron App M ( N 2 @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠 Command Line Interface Well Factored Code Editor PluginWeb App Electron App M ( N 2 O @amaltson Speaker Note: One last thing on CLIs, there’s a great blog post from a while back (can’t find it) that argued building a CLI doesn’t preclude building a GUI, but building a GUI often precludes building a CLI. Therefore, it’s best to start CLI first. Once you’ve built a CLI, many devs can start using it. And if you’ve built on top of a well factored code base, other devs can jump in and maybe get excited and build a GUI for business users. After some time you might build an editor plugin leveraging the CLI to make it easier, which brings in other devs. They might get excited and build an advanced GUI on top of Electron for more advanced users. Point is, if you start CLI first, you get the best of both worlds.
CLI 🛠@amaltson Speaker Note: So in our examples going forward we will assume we are build a CLI and talk about Developer Experience with a CLI.
Experience Lifecycle 8 9 : ; 🛠 @amaltson Speaker Note: Alright, tangent done, let’s get back to looking how to improve the Developer Experience in the lifecycle of using a tool.
Getting Started 8😡 🛠@amaltson Speaker Note: Let’s start with looking at how we can improve the initial getting started experience. We’ve already talked about the need to have a good README, but what users are looking for in that initial README is how to install and get started.
Getting Started 8😡 🛠@amaltson Speaker Note: Let’s start with looking at how we can improve the initial getting started experience. We’ve already talked about the need to have a good README, but what users are looking for in that initial README is how to install and get started.
Getting Started 8😡 🛠@amaltson Speaker Note: And nothing makes that initial getting started experience painful like having a laundry list of prerequisites, like installing some language you’re not familiar with and manually installing third party dependencies. And once you get over that hump, the instructions for tool installation are a multi- step process.
Getting Started 8😡 🛠@amaltson Speaker Note: And nothing makes that initial getting started experience painful like having a laundry list of prerequisites, like installing some language you’re not familiar with and manually installing third party dependencies. And once you get over that hump, the instructions for tool installation are a multi- step process.
Getting Started 8🙂 🛠@amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
Getting Started 8🙂 🛠@amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
Getting Started 8🙂 🛠@amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
Getting Started 8🙂 🛠@amaltson Speaker Note: A better approach is to provide installation options developers expect. Whether it’s Homebrew on the Mac, a native package for various OS flavours, or what SecOps consider the devil’s package manager, a curl bash install (you install blindly with no vetting of the shell script).
Getting Started 8😁 🛠@amaltson Speaker Note: The best part is, modern tooling like Omnibus makes it easier to make native packages. With custom Homebrew taps, you can provide your own recipes AND probably my favourite tip, you can even tap internal private Git repositories, we use this regularly ourselves.
Getting Started 8😁 🛠@amaltson Speaker Note: The best part is, modern tooling like Omnibus makes it easier to make native packages. With custom Homebrew taps, you can provide your own recipes AND probably my favourite tip, you can even tap internal private Git repositories, we use this regularly ourselves.
Getting Started 8😁 🛠@amaltson Speaker Note: The best part is, modern tooling like Omnibus makes it easier to make native packages. With custom Homebrew taps, you can provide your own recipes AND probably my favourite tip, you can even tap internal private Git repositories, we use this regularly ourselves.
Getting Started 8😁 🛠 $ brew tap homebrew/acme https://git.acme.com $ brew install acme-awesome-tool @amaltson Speaker Note: The best part is, modern tooling like Omnibus makes it easier to make native packages. With custom Homebrew taps, you can provide your own recipes AND probably my favourite tip, you can even tap internal private Git repositories, we use this regularly ourselves.
Getting Started 8🤩 🛠@amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in flames fast.
Getting Started 8🤩 🛠 📦 @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in flames fast.
Getting Started 8🤩 🛠 📦 @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in flames fast.
Getting Started 8🤩 🛠 📦 @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in flames fast.
Getting Started 8🤩 🛠 📦 🔥🔥 @amaltson Speaker Note: But all of those installation techniques work really well when tool is written in a way that it compiles to a nice binary format, like with Go or Rust. But when it doesn’t, things can go up in flames fast.
Getting Started 8🤩 🛠 📦 @amaltson Speaker Note: To not have that happen, we’re going to take our application and put it into a larger package, a Docker container. And then using a tiny bit of shell scripting, we can make an “executable” that looks and feels like a binary package and allows you to control all the dependencies you need. I’ve found this particular trick very handy for packaging Ruby and Python programs. Best part is, they’re always up to date!
Getting Started 8🤩 🛠 📦 @amaltson Speaker Note: To not have that happen, we’re going to take our application and put it into a larger package, a Docker container. And then using a tiny bit of shell scripting, we can make an “executable” that looks and feels like a binary package and allows you to control all the dependencies you need. I’ve found this particular trick very handy for packaging Ruby and Python programs. Best part is, they’re always up to date!
Getting Started 8🤩 🛠 📦 @amaltson Speaker Note: To not have that happen, we’re going to take our application and put it into a larger package, a Docker container. And then using a tiny bit of shell scripting, we can make an “executable” that looks and feels like a binary package and allows you to control all the dependencies you need. I’ve found this particular trick very handy for packaging Ruby and Python programs. Best part is, they’re always up to date!
Getting Started 8🤩 🛠@amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
Getting Started • Friendly README 8🤩 🛠@amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
Getting Started • Friendly README • Provide one liner installation 8🤩 🛠@amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
Getting Started • Friendly README • Provide one liner installation • If not easily installable, use Docker! 8🤩 🛠@amaltson Speaker Note: Quick summary for making an amazing getting started experience for your tool.
8 🛠@amaltson Speaker Note: Alright, that’s getting started. Once we have the tool installed, we want to start using it.
9 🛠@amaltson Speaker Note: Alright, that’s getting started. Once we have the tool installed, we want to start using it.
First Contact 9😨 🛠@amaltson Speaker Note: That’s what we can think of as first contact. It’s the first experience the developer has using your tool, after getting it installed that is. This is most nerve wracking part of using a new tool.
First Contact 9 🛠 😌 @amaltson Speaker Note: To make that experience smooth, we should take into consider the rest of the ecosystem and attempt to integrate where it makes sense. Since we’re building a replacement for Pair Up, we should be able to parse and support the Pair Up format, and maybe provide a nice migration.
First Contact 9 🛠 😌😊 @amaltson Speaker Note: To make that experience smooth, we should take into consider the rest of the ecosystem and attempt to integrate where it makes sense. Since we’re building a replacement for Pair Up, we should be able to parse and support the Pair Up format, and maybe provide a nice migration.
First Contact 9 🛠 😊 @amaltson Speaker Note: But how do we get that wow experience? We could consider doing work on behalf of the user. Imagine instead of asking all the contact details like Pair Up does today…
First Contact 9 🛠 😊 @amaltson Speaker Note: But how do we get that wow experience? We could consider doing work on behalf of the user. Imagine instead of asking all the contact details like Pair Up does today…
First Contact 9 🛠 😊 @amaltson Speaker Note: We go out and use the GitHub API and find the user’s name and email automatically. Now that’s a wow experience.
First Contact 9 🛠 😊 @amaltson Speaker Note: We go out and use the GitHub API and find the user’s name and email automatically. Now that’s a wow experience.
First Contact 9 🛠 🤩 @amaltson Speaker Note: We go out and use the GitHub API and find the user’s name and email automatically. Now that’s a wow experience.
First Contact 9🤩 🛠@amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…
First Contact • Migration from existing systems 9🤩 🛠@amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…
First Contact • Migration from existing systems • Do work on the user’s behalf 9🤩 🛠@amaltson Speaker Note: So to have an awesome “first contact” experience, we need to have…
9 🛠@amaltson Speaker Note: Now our user has started using our tool, how can we improve the day to day Developer Experience?
: 🛠@amaltson Speaker Note: Now our user has started using our tool, how can we improve the day to day Developer Experience?
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.
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.
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.
Day to Day : 🛠 🙂 @amaltson Speaker Note: You’ve probably seen this from Git when you mistype a command, but how do they do it and can we use it for our application?
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…
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…
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…
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…
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?
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?
Day to Day :🙂 🛠 Levenshtein distance @amaltson Speaker Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Catch and lint configuration items, commands, etc and provide suggested fixes.
Day to Day :🙂 🛠 Levenshtein distance @amaltson Speaker Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Catch and lint configuration items, commands, etc and provide suggested fixes.
Day to Day : 🛠 🥰 Levenshtein distance @amaltson Speaker Note: We can then use this handy algorithm to really turn up our Developer Experience to 11. Catch and lint configuration items, commands, etc and provide suggested fixes.
Day to Day :🤩 🛠@amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
Day to Day • Meaningful error messages :🤩 🛠@amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
Day to Day • Meaningful error messages • Lint and shift feedback left :🤩 🛠@amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
Day to Day • Meaningful error messages • Lint and shift feedback left • Levenshtein distance suggestions :🤩 🛠@amaltson Speaker Note: Recapping, to have an awesome day to day Developer Experience we should …
: 🛠@amaltson Speaker Note: As much blood, sweat and tears we put into a tool, at some point all good things come to an end.
; 🛠@amaltson Speaker Note: As much blood, sweat and tears we put into a tool, at some point all good things come to an end.
🛠@amaltson Speaker Note: Provide a bridge from the current tool and to the next one, if it exists. If there’s multiple, look at the most promising one and direct users. Imagine how the user feels, they’re now aware your tool is getting deprecated and confused where to go next. We need to provide that guidance to gracefully retire the tool. But how do we get that “wow” experience?
Retirement ;😓 @amaltson Speaker Note: We’ve provided a path forward and suggested a tool, but that’s still a lot of work. Our users would really love it if someone would help them out. That someone needs to be us. For the optimal retirement, consider partnering with the authors of the new tool and build a migration tool. Worst case scenario, build the tool for them. Remember, as a tool author you’re the force multiplier, you make one change and you can potentially save hundreds of hours for teams. 🛠
Retirement ;🥺 @amaltson Speaker Note: We’ve provided a path forward and suggested a tool, but that’s still a lot of work. Our users would really love it if someone would help them out. That someone needs to be us. For the optimal retirement, consider partnering with the authors of the new tool and build a migration tool. Worst case scenario, build the tool for them. Remember, as a tool author you’re the force multiplier, you make one change and you can potentially save hundreds of hours for teams. 🛠
Retirement ;🤩 @amaltson Speaker Note: We’ve provided a path forward and suggested a tool, but that’s still a lot of work. Our users would really love it if someone would help them out. That someone needs to be us. For the optimal retirement, consider partnering with the authors of the new tool and build a migration tool. Worst case scenario, build the tool for them. Remember, as a tool author you’re the force multiplier, you make one change and you can potentially save hundreds of hours for teams. 🛠
Retirement ;🤩 🛠@amaltson Speaker Note: To provide an amazing Developer Experience for retiring a tool, we need to..
Retirement • Clear migration path ;🤩 🛠@amaltson Speaker Note: To provide an amazing Developer Experience for retiring a tool, we need to..
Retirement • Clear migration path • Automate the migration ;🤩 🛠@amaltson Speaker Note: To provide an amazing Developer Experience for retiring a tool, we need to..
Experience Lifecycle 🛠 @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for others to use.
Experience Lifecycle 🛠🤩 @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for others to use.
Experience Lifecycle 🛠🤩 8 • Friendly README • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for others to use.
Experience Lifecycle 🛠🤩 9 • Migration from existing systems • Do work on the user’s behalf 8 • Friendly README • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for others to use.
Experience Lifecycle 🛠🤩 9 • Migration from existing systems • Do work on the user’s behalf : • Meaningful error messages • Lint and shift feedback left • Levenshtein distance suggestions 8 • Friendly README • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for others to use.
Experience Lifecycle 🛠🤩 9 • Migration from existing systems • Do work on the user’s behalf : • Meaningful error messages • Lint and shift feedback left • Levenshtein distance suggestions ; • Clear migration path • Automate the migration 8 • Friendly README • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: Let’s do a quick review of how to make an amazing Developer Experience throughout the Experience Lifecycle when building mob-up for others to use.
@amaltson Speaker Note: Well that was a whirl wind tour of tips and tricks to improve developer experience.
@amaltson Speaker Note: Well that was a whirl wind tour of tips and tricks to improve developer experience.
@amaltson Speaker Note: Let’s tie this all together with a quick replay.
@amaltson Speaker Note: Let’s tie this all together with a quick replay.
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.
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.
Developer Experience @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now; monetary, mental energy and moral.
Developer Experience 💰 @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now; monetary, mental energy and moral.
Developer Experience 💰 🧠 @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now; monetary, mental energy and moral.
Developer Experience 💰 🧠 😍 @amaltson Speaker Note: We then discussed the three costs of not focusing on Developer Experience now; monetary, mental energy and moral.
Experience Lifecycle 7🤩 9 • Pipeline Green • GitHub Templates • Quality of PR : • Consistency • CHANGELOGs • Smooth migrations ; • Deprecate clearly • Leave code in a good state • Archive it 8 • Friendly README • Data Flow Diagram • Workstation Setup (that works!) @amaltson Speaker Note: We went through some practical tips to improve Developer Experience when working with others.
Experience Lifecycle 🛠🤩 9 • Beautiful init experience • Migration from existing systems • Do work on the user’s behalf : • Meaningful error messages • Lint and shift feedback left • Levenshtein distance suggestions ; • Visible deprecation warnings • Clear migration path • Automate the migration 8 • Friendly README • Provide one liner installation • If not easily installable, use Docker! @amaltson Speaker Note: We went through some practical tips to improve Developer Experience when building a tool for others to use.
@amaltson Speaker Note: So I ask, what are you waiting for to start improving…
Developer Experience @amaltson Speaker Note: … Developer Experience…
Developer Experience 😡💻 @amaltson Speaker Note: … And start turning those unhappy developers into happy ones.
Developer Experience 😡💻😄 @amaltson Speaker Note: … And start turning those unhappy developers into happy ones.
@amaltson
Arthur Maltson @amaltson maltson.com Capital One Sr. Manager - Software Engineer 70% Dev, 30% Ops Full Time DadOps
@amaltson@amaltson
@amaltson@amaltson
@amaltson@amaltson
@amaltson@amaltson
WE’RE HIRING @amaltson@amaltson
• Slides: https://www.slideshare.net/ArthurMaltson • Mob Up (someday): https://github.com/amaltson/mob-up • Friendly READMEs • GitHub PR Templates • Keep A Changelog • PlantUML sequence diagram syntax • PlantUML VS Code Plugin • PairUp, Git Duel (actively maintained), and Git Mob (has VS Code plugin) Arthur Maltson We’re Hiring!@amaltson
Credits • assorted-color yarns, Karly Santiago, https://unsplash.com/photos/E7zsz8JA8FM • MapQuest in 2005, Wayback Machine Internet Archive, https://web.archive.org/web/20050625054602/http://www.mapquest.com/ • MapQuest in 2019, MapQuest, https://www.mapquest.com • Calculate RIO, https://uxplanet.org/how-to-calculate-the-roi-of-your-ux-activities-b7ba7023246a • Users love simple and familiar designs – Why websites need to make a great first impression, https://ai.googleblog.com/2012/08/users-love-simple-and-familiar-designs.html • Workbench, https://flic.kr/p/3aLRao • Lakota Native American Man at Pow Wow, Andrew James, https://unsplash.com/photos/ehdsg7SHm6A • Funny changelog: https://www.androidpit.com/here-are-the-most-hilarious-change-logs-ever-written • Empathic: https://www.grammarly.com/blog/empathetic • brown wooden trunk, Lena De Fanti, https://unsplash.com/photos/W4HtdHYqmUg • Deprecation README, nhsuk, https://github.com/nhsuk/profiles • Home Office Remodeling Project (23), Michael Sauers, https://flic.kr/p/7xqsxK • Borg trekkie?, Nathan Rupert, https://flic.kr/p/cAfMoj • Co-authored-by instructions: https://github.blog/2018-01-29-commit-together-with-co-authors/ • Cecily Strong Shrug Gif By Saturday Night Live, Saturday Night Live, https://gph.is/2d1eSi8 • Typing Montage GIF, ReactionsEditor, https://gph.is/2oW0XKw • Homebrew logo, Homebrew, https://brew.sh • Debian logo, Wikimedia, https://commons.wikimedia.org/wiki/File:Debian-OpenLogo.svg • Red Hat logo, Wikimedia, https://en.wikipedia.org/wiki/File:Red_Hat_Logo_2019.svg • Curl Logo, Curl, https://curl.haxx.se/logo/ • Go gopher, Renee French, https://github.com/golang-samples/gopher-vector • Rust logo, Rust Lang, https://github.com/rust-lang/rust-artwork • Moby logo, Docker Inc, https://www.docker.com/company/newsroom/media-resources • Arrival still, Paramount Pictures, https://www.wired.co.uk/article/arrival-science-fact-fiction • screenshot, Yeoman, https://github.com/yeoman/yo/blob/master/screenshot.png • Levenshtein distance, Wikipedia, https://en.wikipedia.org/wiki/Levenshtein_distance • Smooth path: https://flic.kr/p/assieJ • Dog Puppy Gif, Giphy, https://gph.is/1ko3wyq • Toronto Raptors Gif, Giphy, https://gph.is/g/aK5By84 • Uncle Sam Meme, imgflip, https://imgflip.com/memegenerator/Uncle-Sam

Empfohlen

Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019
Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019
Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019Arthur Maltson
 
Wireframe and prototyping google Campus talk by Zoe Guiraudon
Wireframe and prototyping google Campus talk by Zoe GuiraudonWireframe and prototyping google Campus talk by Zoe Guiraudon
Wireframe and prototyping google Campus talk by Zoe GuiraudonZoé Guiraudon
 
Portfolio draft
Portfolio draftPortfolio draft
Portfolio draftneileverette
 
Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)Alex Cowan
 
Prototyping Interaction with Video Scenarios
Prototyping Interaction with Video ScenariosPrototyping Interaction with Video Scenarios
Prototyping Interaction with Video ScenariosDavid Sherwin
 
You’ve Only Got Two Eyeballs: Designing Products for the Responsive Web
You’ve Only Got Two Eyeballs: Designing Products for the Responsive WebYou’ve Only Got Two Eyeballs: Designing Products for the Responsive Web
You’ve Only Got Two Eyeballs: Designing Products for the Responsive WebDavid Sherwin
 
Venture Design Module 4: Designing the Right Product
Venture Design Module 4: Designing the Right ProductVenture Design Module 4: Designing the Right Product
Venture Design Module 4: Designing the Right ProductAlex Cowan
 
Lean Startup Workshop for Startup Leadership Program
Lean Startup Workshop for Startup Leadership ProgramLean Startup Workshop for Startup Leadership Program
Lean Startup Workshop for Startup Leadership ProgramAlex Cowan
 

Empfohlen

Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019
Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019
Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019Arthur Maltson
 
Wireframe and prototyping google Campus talk by Zoe Guiraudon
Wireframe and prototyping google Campus talk by Zoe GuiraudonWireframe and prototyping google Campus talk by Zoe Guiraudon
Wireframe and prototyping google Campus talk by Zoe GuiraudonZoé Guiraudon
 
Portfolio draft
Portfolio draftPortfolio draft
Portfolio draftneileverette
 
Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Wed. AM Session)Alex Cowan
 
Prototyping Interaction with Video Scenarios
Prototyping Interaction with Video ScenariosPrototyping Interaction with Video Scenarios
Prototyping Interaction with Video ScenariosDavid Sherwin
 
You’ve Only Got Two Eyeballs: Designing Products for the Responsive Web
You’ve Only Got Two Eyeballs: Designing Products for the Responsive WebYou’ve Only Got Two Eyeballs: Designing Products for the Responsive Web
You’ve Only Got Two Eyeballs: Designing Products for the Responsive WebDavid Sherwin
 
Venture Design Module 4: Designing the Right Product
Venture Design Module 4: Designing the Right ProductVenture Design Module 4: Designing the Right Product
Venture Design Module 4: Designing the Right ProductAlex Cowan
 
Lean Startup Workshop for Startup Leadership Program
Lean Startup Workshop for Startup Leadership ProgramLean Startup Workshop for Startup Leadership Program
Lean Startup Workshop for Startup Leadership ProgramAlex Cowan
 
Flaneur
Flaneur Flaneur
Flaneur stowlson
 
Orta Therox
Orta TheroxOrta Therox
Orta TheroxCodeFest
 
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product Camp
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product CampHow to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product Camp
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product CampDan Olsen
 
Venture Design Module 3: Engineering Your Business Model (GA)
Venture Design Module 3: Engineering Your Business Model (GA)Venture Design Module 3: Engineering Your Business Model (GA)
Venture Design Module 3: Engineering Your Business Model (GA)Alex Cowan
 
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"Mark Graban
 
The DevOps Imperative
The DevOps ImperativeThe DevOps Imperative
The DevOps ImperativeIBM UrbanCode Products
 
Venture Design Crash Course: Prep for Startup Weekend Oakland
Venture Design Crash Course: Prep for Startup Weekend OaklandVenture Design Crash Course: Prep for Startup Weekend Oakland
Venture Design Crash Course: Prep for Startup Weekend OaklandAlex Cowan
 
SDL added strategists to a UX team (UX STRAT Europe 2015)
SDL added strategists to a UX team (UX STRAT Europe 2015)SDL added strategists to a UX team (UX STRAT Europe 2015)
SDL added strategists to a UX team (UX STRAT Europe 2015)Peter Boersma
 
VenuesToday05-16_QA_Tim_Romani
VenuesToday05-16_QA_Tim_RomaniVenuesToday05-16_QA_Tim_Romani
VenuesToday05-16_QA_Tim_RomaniT. Wayne Waters
 
Disruptive Innovation (is the new punk rock)
Disruptive Innovation (is the new punk rock)Disruptive Innovation (is the new punk rock)
Disruptive Innovation (is the new punk rock)Geoffrey Colon
 
IQb project (Rubiks cube size projector)
IQb project (Rubiks cube size projector)IQb project (Rubiks cube size projector)
IQb project (Rubiks cube size projector)mc04451431
 
Lens Interactive Corporate_Profile
Lens Interactive Corporate_ProfileLens Interactive Corporate_Profile
Lens Interactive Corporate_ProfileAshok Mohanty
 
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)Alex Cowan
 
Undestanding UX: TBTF technology executive council meeting
Undestanding UX: TBTF technology executive council meetingUndestanding UX: TBTF technology executive council meeting
Undestanding UX: TBTF technology executive council meetingKrissy Scoufis
 
Web Design for SEO
Web Design for SEOWeb Design for SEO
Web Design for SEOMichael King
 
DevDay 2013 - Building Startups and Minimum Viable Products
DevDay 2013 - Building Startups and Minimum Viable ProductsDevDay 2013 - Building Startups and Minimum Viable Products
DevDay 2013 - Building Startups and Minimum Viable ProductsBen Hall
 
All onboard! (Mobilize Dublin 202001)
All onboard! (Mobilize Dublin 202001)All onboard! (Mobilize Dublin 202001)
All onboard! (Mobilize Dublin 202001)Mathew Cropper
 
Prioritising User Experience
Prioritising User ExperiencePrioritising User Experience
Prioritising User ExperiencePatrick Kennedy
 
Mindmeister Case Study En.Key
Mindmeister Case Study En.KeyMindmeister Case Study En.Key
Mindmeister Case Study En.Keymindmeister
 
How Startups May Build Your UX Competencies - Hire or Just a Myth?
How Startups May Build Your UX Competencies - Hire or Just a Myth?How Startups May Build Your UX Competencies - Hire or Just a Myth?
How Startups May Build Your UX Competencies - Hire or Just a Myth?UX Consulting Pte Ltd
 
Prototyping a service
Prototyping a servicePrototyping a service
Prototyping a serviceClizia Welker
 
Style Guide Best Practices
Style Guide Best PracticesStyle Guide Best Practices
Style Guide Best PracticesBrad Frost
 

Weitere ähnliche Inhalte

Was ist angesagt?

Orta Therox
Orta TheroxOrta Therox
Orta TheroxCodeFest
 
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product Camp
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product CampHow to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product Camp
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product CampDan Olsen
 
Venture Design Module 3: Engineering Your Business Model (GA)
Venture Design Module 3: Engineering Your Business Model (GA)Venture Design Module 3: Engineering Your Business Model (GA)
Venture Design Module 3: Engineering Your Business Model (GA)Alex Cowan
 
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"Mark Graban
 
Venture Design Crash Course: Prep for Startup Weekend Oakland
Venture Design Crash Course: Prep for Startup Weekend OaklandVenture Design Crash Course: Prep for Startup Weekend Oakland
Venture Design Crash Course: Prep for Startup Weekend OaklandAlex Cowan
 
SDL added strategists to a UX team (UX STRAT Europe 2015)
SDL added strategists to a UX team (UX STRAT Europe 2015)SDL added strategists to a UX team (UX STRAT Europe 2015)
SDL added strategists to a UX team (UX STRAT Europe 2015)Peter Boersma
 
VenuesToday05-16_QA_Tim_Romani
VenuesToday05-16_QA_Tim_RomaniVenuesToday05-16_QA_Tim_Romani
VenuesToday05-16_QA_Tim_RomaniT. Wayne Waters
 
Disruptive Innovation (is the new punk rock)
Disruptive Innovation (is the new punk rock)Disruptive Innovation (is the new punk rock)
Disruptive Innovation (is the new punk rock)Geoffrey Colon
 
IQb project (Rubiks cube size projector)
IQb project (Rubiks cube size projector)IQb project (Rubiks cube size projector)
IQb project (Rubiks cube size projector)mc04451431
 
Lens Interactive Corporate_Profile
Lens Interactive Corporate_ProfileLens Interactive Corporate_Profile
Lens Interactive Corporate_ProfileAshok Mohanty
 
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)Alex Cowan
 

Was ist angesagt? (13)

Flaneur
Flaneur Flaneur
Flaneur
 
Orta Therox
Orta TheroxOrta Therox
Orta Therox
 
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product Camp
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product CampHow to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product Camp
How to Be a UX Design Army of One by Dan Olsen at Silicon Valley Product Camp
 
Venture Design Module 3: Engineering Your Business Model (GA)
Venture Design Module 3: Engineering Your Business Model (GA)Venture Design Module 3: Engineering Your Business Model (GA)
Venture Design Module 3: Engineering Your Business Model (GA)
 
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"
 
The DevOps Imperative
The DevOps ImperativeThe DevOps Imperative
The DevOps Imperative
 
Venture Design Crash Course: Prep for Startup Weekend Oakland
Venture Design Crash Course: Prep for Startup Weekend OaklandVenture Design Crash Course: Prep for Startup Weekend Oakland
Venture Design Crash Course: Prep for Startup Weekend Oakland
 
SDL added strategists to a UX team (UX STRAT Europe 2015)
SDL added strategists to a UX team (UX STRAT Europe 2015)SDL added strategists to a UX team (UX STRAT Europe 2015)
SDL added strategists to a UX team (UX STRAT Europe 2015)
 
VenuesToday05-16_QA_Tim_Romani
VenuesToday05-16_QA_Tim_RomaniVenuesToday05-16_QA_Tim_Romani
VenuesToday05-16_QA_Tim_Romani
 
Disruptive Innovation (is the new punk rock)
Disruptive Innovation (is the new punk rock)Disruptive Innovation (is the new punk rock)
Disruptive Innovation (is the new punk rock)
 
IQb project (Rubiks cube size projector)
IQb project (Rubiks cube size projector)IQb project (Rubiks cube size projector)
IQb project (Rubiks cube size projector)
 
Lens Interactive Corporate_Profile
Lens Interactive Corporate_ProfileLens Interactive Corporate_Profile
Lens Interactive Corporate_Profile
 
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)
Venture Design Crash Course: UVA iLab (June-2014; Thurs. AM Session)
 

Ähnlich wie Built With ❤ - Why Developer Experience Matters - Web Unleashed 2019

Undestanding UX: TBTF technology executive council meeting
Undestanding UX: TBTF technology executive council meetingUndestanding UX: TBTF technology executive council meeting
Undestanding UX: TBTF technology executive council meetingKrissy Scoufis
 
Web Design for SEO
Web Design for SEOWeb Design for SEO
Web Design for SEOMichael King
 
DevDay 2013 - Building Startups and Minimum Viable Products
DevDay 2013 - Building Startups and Minimum Viable ProductsDevDay 2013 - Building Startups and Minimum Viable Products
DevDay 2013 - Building Startups and Minimum Viable ProductsBen Hall
 
All onboard! (Mobilize Dublin 202001)
All onboard! (Mobilize Dublin 202001)All onboard! (Mobilize Dublin 202001)
All onboard! (Mobilize Dublin 202001)Mathew Cropper
 
Prioritising User Experience
Prioritising User ExperiencePrioritising User Experience
Prioritising User ExperiencePatrick Kennedy
 
Mindmeister Case Study En.Key
Mindmeister Case Study En.KeyMindmeister Case Study En.Key
Mindmeister Case Study En.Keymindmeister
 
How Startups May Build Your UX Competencies - Hire or Just a Myth?
How Startups May Build Your UX Competencies - Hire or Just a Myth?How Startups May Build Your UX Competencies - Hire or Just a Myth?
How Startups May Build Your UX Competencies - Hire or Just a Myth?UX Consulting Pte Ltd
 
Prototyping a service
Prototyping a servicePrototyping a service
Prototyping a serviceClizia Welker
 
Style Guide Best Practices
Style Guide Best PracticesStyle Guide Best Practices
Style Guide Best PracticesBrad Frost
 
DevLearn 2018 - Designing AR Experiences for Performance Support
DevLearn 2018 - Designing AR Experiences for Performance SupportDevLearn 2018 - Designing AR Experiences for Performance Support
DevLearn 2018 - Designing AR Experiences for Performance SupportChad Udell
 
Digital transformation; or how I learnt to stop worrying and love the bots!
Digital transformation; or how I learnt to stop worrying and love the bots!Digital transformation; or how I learnt to stop worrying and love the bots!
Digital transformation; or how I learnt to stop worrying and love the bots!Sayan Ghosh
 
Innovation - road to value TopConf Nov2015
Innovation - road to value TopConf Nov2015Innovation - road to value TopConf Nov2015
Innovation - road to value TopConf Nov2015Alek Kozlov
 
Developing for the Unknown
Developing for the UnknownDeveloping for the Unknown
Developing for the Unknownnolly00
 
Design Myths in Enterprise Software
Design Myths in Enterprise SoftwareDesign Myths in Enterprise Software
Design Myths in Enterprise SoftwareGanesh Burle
 
Challenges Developing Realtime Web Apps
Challenges Developing Realtime Web AppsChallenges Developing Realtime Web Apps
Challenges Developing Realtime Web AppsUffe Björklund
 
Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...
Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...
Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...Mohamed Mahdy
 
Mobile App Feature Configuration and A/B Experiments
Mobile App Feature Configuration and A/B ExperimentsMobile App Feature Configuration and A/B Experiments
Mobile App Feature Configuration and A/B Experimentslacyrhoades
 
Full stack conference talk slides
Full stack conference talk slidesFull stack conference talk slides
Full stack conference talk slidesSameer Al-Sakran
 
So, You Wannna Be a CTO - Romain Cochet
So, You Wannna Be a CTO - Romain Cochet So, You Wannna Be a CTO - Romain Cochet
So, You Wannna Be a CTO - Romain Cochet WithTheBest
 

Ähnlich wie Built With ❤ - Why Developer Experience Matters - Web Unleashed 2019 (20)

Undestanding UX: TBTF technology executive council meeting
Undestanding UX: TBTF technology executive council meetingUndestanding UX: TBTF technology executive council meeting
Undestanding UX: TBTF technology executive council meeting
 
Web Design for SEO
Web Design for SEOWeb Design for SEO
Web Design for SEO
 
DevDay 2013 - Building Startups and Minimum Viable Products
DevDay 2013 - Building Startups and Minimum Viable ProductsDevDay 2013 - Building Startups and Minimum Viable Products
DevDay 2013 - Building Startups and Minimum Viable Products
 
All onboard! (Mobilize Dublin 202001)
All onboard! (Mobilize Dublin 202001)All onboard! (Mobilize Dublin 202001)
All onboard! (Mobilize Dublin 202001)
 
Prioritising User Experience
Prioritising User ExperiencePrioritising User Experience
Prioritising User Experience
 
Mindmeister Case Study En.Key
Mindmeister Case Study En.KeyMindmeister Case Study En.Key
Mindmeister Case Study En.Key
 
How Startups May Build Your UX Competencies - Hire or Just a Myth?
How Startups May Build Your UX Competencies - Hire or Just a Myth?How Startups May Build Your UX Competencies - Hire or Just a Myth?
How Startups May Build Your UX Competencies - Hire or Just a Myth?
 
Prototyping a service
Prototyping a servicePrototyping a service
Prototyping a service
 
Style Guide Best Practices
Style Guide Best PracticesStyle Guide Best Practices
Style Guide Best Practices
 
GeoFocus
GeoFocusGeoFocus
GeoFocus
 
DevLearn 2018 - Designing AR Experiences for Performance Support
DevLearn 2018 - Designing AR Experiences for Performance SupportDevLearn 2018 - Designing AR Experiences for Performance Support
DevLearn 2018 - Designing AR Experiences for Performance Support
 
Digital transformation; or how I learnt to stop worrying and love the bots!
Digital transformation; or how I learnt to stop worrying and love the bots!Digital transformation; or how I learnt to stop worrying and love the bots!
Digital transformation; or how I learnt to stop worrying and love the bots!
 
Innovation - road to value TopConf Nov2015
Innovation - road to value TopConf Nov2015Innovation - road to value TopConf Nov2015
Innovation - road to value TopConf Nov2015
 
Developing for the Unknown
Developing for the UnknownDeveloping for the Unknown
Developing for the Unknown
 
Design Myths in Enterprise Software
Design Myths in Enterprise SoftwareDesign Myths in Enterprise Software
Design Myths in Enterprise Software
 
Challenges Developing Realtime Web Apps
Challenges Developing Realtime Web AppsChallenges Developing Realtime Web Apps
Challenges Developing Realtime Web Apps
 
Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...
Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...
Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...
 
Mobile App Feature Configuration and A/B Experiments
Mobile App Feature Configuration and A/B ExperimentsMobile App Feature Configuration and A/B Experiments
Mobile App Feature Configuration and A/B Experiments
 
Full stack conference talk slides
Full stack conference talk slidesFull stack conference talk slides
Full stack conference talk slides
 
So, You Wannna Be a CTO - Romain Cochet
So, You Wannna Be a CTO - Romain Cochet So, You Wannna Be a CTO - Romain Cochet
So, You Wannna Be a CTO - Romain Cochet
 

Kürzlich hochgeladen

What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?Antenna Manufacturer Coco
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Scriptwesley chun
 
🐬 The future of MySQL is Postgres 🐘
🐬 The future of MySQL is Postgres 🐘🐬 The future of MySQL is Postgres 🐘
🐬 The future of MySQL is Postgres 🐘RTylerCroy
 
CNv6 Instructor Chapter 6 Quality of Service
CNv6 Instructor Chapter 6 Quality of ServiceCNv6 Instructor Chapter 6 Quality of Service
CNv6 Instructor Chapter 6 Quality of Servicegiselly40
 
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking MenDelhi Call girls
 
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc
 
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...apidays
 
Scaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organizationScaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organizationRadu Cotescu
 
08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking MenDelhi Call girls
 
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUnderstanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUK Journal
 
Data Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt RobisonData Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt RobisonAnna Loughnan Colquhoun
 
Tech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdfTech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdfhans926745
 
Strategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a FresherStrategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a FresherRemote DBA Services
 
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoffsammart93
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerThousandEyes
 
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Miguel Araújo
 
Histor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slideHistor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slidevu2urc
 
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdfhans926745
 
IAC 2024 - IA Fast Track to Search Focused AI Solutions
IAC 2024 - IA Fast Track to Search Focused AI SolutionsIAC 2024 - IA Fast Track to Search Focused AI Solutions
IAC 2024 - IA Fast Track to Search Focused AI SolutionsEnterprise Knowledge
 
Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024The Digital Insurer
 

Kürzlich hochgeladen (20)

What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?What Are The Drone Anti-jamming Systems Technology?
What Are The Drone Anti-jamming Systems Technology?
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Script
 
🐬 The future of MySQL is Postgres 🐘
🐬 The future of MySQL is Postgres 🐘🐬 The future of MySQL is Postgres 🐘
🐬 The future of MySQL is Postgres 🐘
 
CNv6 Instructor Chapter 6 Quality of Service
CNv6 Instructor Chapter 6 Quality of ServiceCNv6 Instructor Chapter 6 Quality of Service
CNv6 Instructor Chapter 6 Quality of Service
 
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
08448380779 Call Girls In Diplomatic Enclave Women Seeking Men
 
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law DevelopmentsTrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
TrustArc Webinar - Stay Ahead of US State Data Privacy Law Developments
 
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
 
Scaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organizationScaling API-first – The story of a global engineering organization
Scaling API-first – The story of a global engineering organization
 
08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men
 
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUnderstanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
 
Data Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt RobisonData Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt Robison
 
Tech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdfTech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdf
 
Strategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a FresherStrategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a Fresher
 
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
 
Histor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slideHistor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slide
 
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf
 
IAC 2024 - IA Fast Track to Search Focused AI Solutions
IAC 2024 - IA Fast Track to Search Focused AI SolutionsIAC 2024 - IA Fast Track to Search Focused AI Solutions
IAC 2024 - IA Fast Track to Search Focused AI Solutions
 
Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024
 

Built With ❤ - Why Developer Experience Matters - Web Unleashed 2019

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