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.
Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019Arthur Maltson
The document discusses the importance of developer experience (DX), drawing parallels to user experience (UX). It notes that focusing on UX led to significant returns for companies like Apple and Google. Three reasons are given for why DX matters: 1) the fiscal costs of poor DX in terms of lost developer productivity; 2) the toll on developers' mental energy from frustrations; and 3) impacts to developer morale. The document advocates investing in DX to realize benefits similar to those seen from investments in UX.
Wireframe and prototyping google Campus talk by Zoe GuiraudonZoé Guiraudon
Zoe Guiraudon gave an introductory presentation on user experience design, wireframing, and prototyping. She discussed what user experience is, why it's important, and how designers use techniques like wireframing and prototyping to design for the user experience. Zoe explained the process from sketching initial ideas on paper to creating higher fidelity digital prototypes. She emphasized testing prototypes with users to evaluate things like usability and the overall user experience. Zoe also shared some of the tools she uses for wireframing and prototyping like Sketch, Marvel, and InVision.
Neil Everette led the product design for Red Hat Marketplace, which aimed to create a software store where developers could discover, purchase, and deploy applications to any cloud with just a few clicks. Everette created an initial story map and wireframes to plan the user experience. He then worked with partners to develop a product demo for IBM leadership that secured approval and funding for the project. The marketplace aimed to help IBM compete in the multi-cloud market by enabling applications to be built once and deployed anywhere.
This document provides information about design thinking and venture design workshops led by Alex Cowan. It discusses creating effective personas, which are detailed representations of target customer types. Good personas tell vivid stories about people's lives and make their needs, behaviors and goals clear. They should be based on real research and observation rather than assumptions. The document emphasizes the importance of personas being actionable, detailed, identifiable, distinct and realistic. It provides tips for persona creation, such as using a "Think-See-Feel-Do" framework, and suggests an exercise where participants generate personas and imagine a day in their lives.
Prototyping Interaction with Video ScenariosDavid Sherwin
Aaron Rincover and I presented this workshop at Seattle Make-a-Thon on November 6, 2010, sponsored by IxDA Seattle, AIGA Seattle, and Interact.
When designing interactions that transcend singular devices and form the basis of device ecosystems, wireframes just don’t cut it. Much of the interactions you’re looking to define and refine are evoked through motion, sound, haptics, and other variables that can’t be easily documented without "dancing about architecture." In these situations, it’s often most effective to create video scenarios that describe how an interaction would happen out in the real world. These scenarios are useful not only for explaining ideas to your clients—they’re an effective way of capturing prototypes to see if they make sense and feel real.
Over the course of this workshop, we explored the various flavors of video scenario that you can create, depending on the design problems you’re seeking to solve. Then we’ll spent the balance of our time working in small teams to create a short interaction vignette about gestural input to activate a teleportation device.
You’ve Only Got Two Eyeballs: Designing Products for the Responsive WebDavid Sherwin
People expect to access and use the products that they love everywhere that they go. With an ever-increasing number of different smartphones, tablets, computers, wearables, and televisions that allow us to view websites, this makes our jobs as interactive designers even more challenging. Are you helping them focus on what they really need to get done, on the devices where they need that functionality the most?
In this workshop from HOW Design Live 2016, which was led by David Sherwin and Drew Bridewell with about 250 people, we shared techniques to help teams:
● Prioritize what product features will have the most value for your users across smartphone, tablet, desktop, TV, wearables, and other devices—so you’re investing your time and energy into the right features in the right places
● Validate your product assumptions and hypotheses through paper and digital prototypes, so you can start building those features intelligently
● Plan the implementation of your product features for development in a modular, componentized manner that makes them easier to test and scale
Along with workshop activities rooted in the above techniques, we shared how we used similar approaches in a redesign of the learning experience of Lynda.com as a responsive web product.
Venture Design Module 4: Designing the Right ProductAlex Cowan
This document provides an overview of agile product design and development. It discusses topics like user stories, storyboarding, wireframing, and prototyping. The document uses a case study of an HR screening tool to illustrate concepts like writing user stories and epics, creating a storyboard for an epic, identifying needs and comparable applications for prototyping, and documenting assumptions. The overall message is that early-stage product design should involve iterative experimentation through techniques like storytelling, wireframing, and quick prototyping in order to validate assumptions and gather user feedback before investing heavily in development.
Built With ❤ - Why Developer Experience Matters - DevOps Days Boston 2019Arthur Maltson
The document discusses the importance of developer experience (DX), drawing parallels to user experience (UX). It notes that focusing on UX led to significant returns for companies like Apple and Google. Three reasons are given for why DX matters: 1) the fiscal costs of poor DX in terms of lost developer productivity; 2) the toll on developers' mental energy from frustrations; and 3) impacts to developer morale. The document advocates investing in DX to realize benefits similar to those seen from investments in UX.
Wireframe and prototyping google Campus talk by Zoe GuiraudonZoé Guiraudon
Zoe Guiraudon gave an introductory presentation on user experience design, wireframing, and prototyping. She discussed what user experience is, why it's important, and how designers use techniques like wireframing and prototyping to design for the user experience. Zoe explained the process from sketching initial ideas on paper to creating higher fidelity digital prototypes. She emphasized testing prototypes with users to evaluate things like usability and the overall user experience. Zoe also shared some of the tools she uses for wireframing and prototyping like Sketch, Marvel, and InVision.
Neil Everette led the product design for Red Hat Marketplace, which aimed to create a software store where developers could discover, purchase, and deploy applications to any cloud with just a few clicks. Everette created an initial story map and wireframes to plan the user experience. He then worked with partners to develop a product demo for IBM leadership that secured approval and funding for the project. The marketplace aimed to help IBM compete in the multi-cloud market by enabling applications to be built once and deployed anywhere.
This document provides information about design thinking and venture design workshops led by Alex Cowan. It discusses creating effective personas, which are detailed representations of target customer types. Good personas tell vivid stories about people's lives and make their needs, behaviors and goals clear. They should be based on real research and observation rather than assumptions. The document emphasizes the importance of personas being actionable, detailed, identifiable, distinct and realistic. It provides tips for persona creation, such as using a "Think-See-Feel-Do" framework, and suggests an exercise where participants generate personas and imagine a day in their lives.
Prototyping Interaction with Video ScenariosDavid Sherwin
Aaron Rincover and I presented this workshop at Seattle Make-a-Thon on November 6, 2010, sponsored by IxDA Seattle, AIGA Seattle, and Interact.
When designing interactions that transcend singular devices and form the basis of device ecosystems, wireframes just don’t cut it. Much of the interactions you’re looking to define and refine are evoked through motion, sound, haptics, and other variables that can’t be easily documented without "dancing about architecture." In these situations, it’s often most effective to create video scenarios that describe how an interaction would happen out in the real world. These scenarios are useful not only for explaining ideas to your clients—they’re an effective way of capturing prototypes to see if they make sense and feel real.
Over the course of this workshop, we explored the various flavors of video scenario that you can create, depending on the design problems you’re seeking to solve. Then we’ll spent the balance of our time working in small teams to create a short interaction vignette about gestural input to activate a teleportation device.
You’ve Only Got Two Eyeballs: Designing Products for the Responsive WebDavid Sherwin
People expect to access and use the products that they love everywhere that they go. With an ever-increasing number of different smartphones, tablets, computers, wearables, and televisions that allow us to view websites, this makes our jobs as interactive designers even more challenging. Are you helping them focus on what they really need to get done, on the devices where they need that functionality the most?
In this workshop from HOW Design Live 2016, which was led by David Sherwin and Drew Bridewell with about 250 people, we shared techniques to help teams:
● Prioritize what product features will have the most value for your users across smartphone, tablet, desktop, TV, wearables, and other devices—so you’re investing your time and energy into the right features in the right places
● Validate your product assumptions and hypotheses through paper and digital prototypes, so you can start building those features intelligently
● Plan the implementation of your product features for development in a modular, componentized manner that makes them easier to test and scale
Along with workshop activities rooted in the above techniques, we shared how we used similar approaches in a redesign of the learning experience of Lynda.com as a responsive web product.
Venture Design Module 4: Designing the Right ProductAlex Cowan
This document provides an overview of agile product design and development. It discusses topics like user stories, storyboarding, wireframing, and prototyping. The document uses a case study of an HR screening tool to illustrate concepts like writing user stories and epics, creating a storyboard for an epic, identifying needs and comparable applications for prototyping, and documenting assumptions. The overall message is that early-stage product design should involve iterative experimentation through techniques like storytelling, wireframing, and quick prototyping in order to validate assumptions and gather user feedback before investing heavily in development.
Digital technology provided advantages and disadvantages at various stages of the media production process. Wikipedia and Google were useful for initial research but lacked specificity. YouTube helped find film examples but yielded unrelated results for broad searches. IMDB and BFI provided targeted industry data. Blogger allowed planning work to be shared globally and received feedback. Final Cut Express and LiveType enabled advanced editing but required a learning curve. Overall, the technology facilitated high quality results but software limitations and learning curves sometimes slowed the process.
Orta Therox runs a development team at Artsy that aims to make all the world's art accessible online. He advocates for open sourcing apps by default to increase transparency, help other developers, and have a broader impact. While commercial concerns around certain apps require discussion, most "pretty pictures of data" apps could be open sourced without risk. Openness combats secrecy that allows anti-user behavior and helps ensure high-quality, ethical code and decision-making.
Venture Design Module 3: Engineering Your Business Model (GA)Alex Cowan
This document outlines an agenda for a session on engineering a business model. It discusses using a business model canvas to detail the business model and remaining assumptions. It also discusses designing the right product by pairing learnings from personas and hypotheses with user stories and wireframes for product development and validation. The document provides templates for the business model canvas and discusses various elements of the canvas like customer segments, value propositions, relationships and channels.
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"Mark Graban
This transcript summarizes a podcast interview between Mark Graban and Eric Ries about Lean startup methodology. Eric got introduced to Lean thinking through his experience with Agile software development and saw parallels between reducing batch sizes and Lean principles. He realized the wrong manufacturing metaphor of waterfall was being used for startups and that Lean principles could be applied if adapted for the high uncertainty of startups. Eric defines a Lean startup as using rapid iteration and continuous customer feedback to reduce uncertainty and determine where to invest resources under conditions of uncertainty. The interview discusses how Lean startup principles can apply to both startups and large companies developing new products.
Why is DevOps all the rage? In this presentation I argued that operations is under a great deal of pressure from changing infrastructure and business climates.
Operations is going to need to change, and the core changes it needs to make are in line with the foundations of DevOps.
This presentation has a number of "image" slides. If you want to hear the words that go with thing, watch the replay of the presentation. Available here: http://www.urbancode.com/html/resources/webinars/The_DevOps_Imperative.html
Venture Design Crash Course: Prep for Startup Weekend OaklandAlex Cowan
This document provides an agenda for a crash course workshop on venture design. The workshop will cover topics like personas, problem scenarios, value propositions, business model canvases, and customer discovery ideas. It will involve tutorials, examples, and exercises for participants to develop their first take on various venture design deliverables. The goal is to help participants learn techniques from design thinking and the lean startup method to hypothesize, learn from experiments, and iterate on their venture ideas.
SDL added strategists to a UX team (UX STRAT Europe 2015)Peter Boersma
This presentation shows how UX strategists contribute to the way SDL helps the world's best brands deliver exceptional customer experiences. Using several of our enterprise software product releases as examples, Peter shows how he and his fellow UX strategists are promoting service design and design thinking, how they develop visions and roadmaps for products and cross-product capabilities, and how they collect user and usage data. He also talks about the link between UX Strategy and Product Management, and the future of UX Strategists at SDL.
Tim Romani discusses the changes in the venue industry over the past 30 years and Icon Venue Group's history and future plans. Some of the biggest changes have been a focus on enhancing the fan experience through more sophisticated technology and building systems. Icon was originally a joint venture with AEG but became independently owned in 2012. Icon was recently purchased by CAA Sports, which Romani believes will help Icon expand into new areas of business. Icon will continue operating as an expert in project management and owner representation for sports and entertainment venues.
Disruptive Innovation (is the new punk rock)Geoffrey Colon
How does business compete in the era of niche? One theory: disruptive innovation. Create products and services at the lower end of the market that large corporations ignore, make them go mainstream, dominate. For more on disruptive innovation follow Geoffrey Colon on Twitter @djgeoffe or listen to his podcast on Spreaker.com
At the start of this project we have been informed about our upcoming brief; which was to create a publication; could have been any sort of publication with any sort of media as long as it showed a publication, another thing we have been told we are in charge of what our publication is going to be about therefore we could have create any sort of article which we thought would be interesting.
Once the briefing was done, we got told to form a group no bigger than 4. I chose to work with Bank, Ryan and Saad as we all are good friends but also we have similar interest which I thought would come in handy.
Once we sorted our groups we have been told to research into design practice which interests us and we would like to work in.
Lens Interactive is a leading user experience and design firm with offices in Bangalore and Mumbai, India. It has worked with over 200 clients on more than 500 projects across various industries. The company focuses on user experience design, websites, branding, and developed an educational mobile app called YooYoo Kids. It has a team of over 20 employees with expertise in design, development, and project management tools.
The document provides an overview of various business model canvas templates and topics related to developing a business model. It includes templates for sections of the business model canvas like customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships, and cost structure. It also discusses topics like customer development, mapping customer segments to value propositions, and conceptualizing customer relationships and channels. The templates and discussions are intended to help users think through and detail the components of their business model.
Undestanding UX: TBTF technology executive council meetingKrissy Scoufis
Krissy Scoufis is an experienced user experience strategist, researcher, and mentor based in Tampa Bay. She discussed the importance of user experience (UX) in product development. UX involves understanding users through discovery, building the right product through development, and ensuring ongoing success through growth measurement. While some see UX as abstract, it helps reduce risk by truly understanding customers. The future of UX involves specialization across many domains as technology changes how people interact with products and services.
This document provides tips for designing websites with SEO in mind. It discusses using personas and keyword research to understand user intent. The information architecture and content strategy should be mapped to semantic groups and keyword opportunities. Technical implementation includes ensuring images have alt text for accessibility, using responsive designs and standard meta data. Case studies demonstrate how this approach improved rankings and conversions for clients.
DevDay 2013 - Building Startups and Minimum Viable ProductsBen Hall
DevDay (http://devday.pl),
20th of September 2013, Kraków
Video at http://www.youtube.com/watch?v=L4eTOvq2WmM&feature=c4-overview-vl&list=PLBMFXMTB7U74NdDghygvBaDcp67owVUUF
At Mobilize Dublin's January meetup, I shared some of the work we're doing at Intercom to help our customers to give their app users an amazing onboarding experience. I talked about how we explored the problem, decided on a solution, and shared a sneak peak at what we're building right now.
Presented at Ark Group Conference on Information Architecture, 30th September 2009 in Sydney.
* User Experience (UX) is more than just the Information Architecture (IA) of a site
* A good UX addresses the useful as well as the usable
* Thus I will discuss why UX should be prioritised over IA
* To create a good UX we need to do research to uncover the goals, attitudes and behaviours of our audience
* This high level approach can then direct lower level design such as the IA
* However getting user involvement at both the UX and IA levels can be challenging, and organisations often need some encouragement from UX/IA practitioners
* Thus I will also discuss prioritising UX within the organisation
1) MindMeister is a collaborative web-based mind mapping tool created in 2006 by Michael Hollauf and based on Ruby on Rails and AJAX.
2) It started as an idea to combine the collaborative features of Google Docs with the brainstorming abilities of mind mapping software. After several prototypes, it launched a private beta in early 2007 and officially launched in May 2007.
3) The presentation focuses on lessons learned around usability, design, marketing, and business model. Key recommendations include investing in design, targeting non-technical users, and tracking marketing efforts.
How Startups May Build Your UX Competencies - Hire or Just a Myth?UX Consulting Pte Ltd
Raven Chai is a principal UX consultant who has observed common pain points among startups regarding UX competencies. Many startups do not properly define their target users or validate ideas, instead prioritizing features and aesthetics over usability. Job postings also often have unrealistic expectations by requesting a "UX rockstar." Chai recommends startups hire agencies initially, attend conferences to learn, and consider government grants to build internal UX capabilities over time rather than relying on a sole "UX person."
What is service prototyping? How do you do it? When? An introduction to the topic with an overview on a practical case, presented during Rome's Service Design Jam 2017
Brad Frost
Web designer
Style Guide Best Practices
We’re tasked with creating experiences that look and function beautifully across a dizzying array of devices and environments. That’s a tall order in and of itself, but once you factor in other team members, clients, stakeholders, and organizational quirks, things start looking downright intimidating. With so many variables to consider, we need solid ground to stand on. Style guides are quickly proving to be foundational tools for tackling this increasingly-diverse web landscape while still maintaining your sanity. Style guides promote consistency, establish a shared vocabulary, make testing easier, and lay a future-friendly foundation. This session will detail best practices and considerations for creating and maintaining style guides, so you can set up your organization for success.
Digital technology provided advantages and disadvantages at various stages of the media production process. Wikipedia and Google were useful for initial research but lacked specificity. YouTube helped find film examples but yielded unrelated results for broad searches. IMDB and BFI provided targeted industry data. Blogger allowed planning work to be shared globally and received feedback. Final Cut Express and LiveType enabled advanced editing but required a learning curve. Overall, the technology facilitated high quality results but software limitations and learning curves sometimes slowed the process.
Orta Therox runs a development team at Artsy that aims to make all the world's art accessible online. He advocates for open sourcing apps by default to increase transparency, help other developers, and have a broader impact. While commercial concerns around certain apps require discussion, most "pretty pictures of data" apps could be open sourced without risk. Openness combats secrecy that allows anti-user behavior and helps ensure high-quality, ethical code and decision-making.
Venture Design Module 3: Engineering Your Business Model (GA)Alex Cowan
This document outlines an agenda for a session on engineering a business model. It discusses using a business model canvas to detail the business model and remaining assumptions. It also discusses designing the right product by pairing learnings from personas and hypotheses with user stories and wireframes for product development and validation. The document provides templates for the business model canvas and discusses various elements of the canvas like customer segments, value propositions, relationships and channels.
Lean Blog Podcast #115 - Mark Graban Interviews Eric Ries on "The Lean Startup"Mark Graban
This transcript summarizes a podcast interview between Mark Graban and Eric Ries about Lean startup methodology. Eric got introduced to Lean thinking through his experience with Agile software development and saw parallels between reducing batch sizes and Lean principles. He realized the wrong manufacturing metaphor of waterfall was being used for startups and that Lean principles could be applied if adapted for the high uncertainty of startups. Eric defines a Lean startup as using rapid iteration and continuous customer feedback to reduce uncertainty and determine where to invest resources under conditions of uncertainty. The interview discusses how Lean startup principles can apply to both startups and large companies developing new products.
Why is DevOps all the rage? In this presentation I argued that operations is under a great deal of pressure from changing infrastructure and business climates.
Operations is going to need to change, and the core changes it needs to make are in line with the foundations of DevOps.
This presentation has a number of "image" slides. If you want to hear the words that go with thing, watch the replay of the presentation. Available here: http://www.urbancode.com/html/resources/webinars/The_DevOps_Imperative.html
Venture Design Crash Course: Prep for Startup Weekend OaklandAlex Cowan
This document provides an agenda for a crash course workshop on venture design. The workshop will cover topics like personas, problem scenarios, value propositions, business model canvases, and customer discovery ideas. It will involve tutorials, examples, and exercises for participants to develop their first take on various venture design deliverables. The goal is to help participants learn techniques from design thinking and the lean startup method to hypothesize, learn from experiments, and iterate on their venture ideas.
SDL added strategists to a UX team (UX STRAT Europe 2015)Peter Boersma
This presentation shows how UX strategists contribute to the way SDL helps the world's best brands deliver exceptional customer experiences. Using several of our enterprise software product releases as examples, Peter shows how he and his fellow UX strategists are promoting service design and design thinking, how they develop visions and roadmaps for products and cross-product capabilities, and how they collect user and usage data. He also talks about the link between UX Strategy and Product Management, and the future of UX Strategists at SDL.
Tim Romani discusses the changes in the venue industry over the past 30 years and Icon Venue Group's history and future plans. Some of the biggest changes have been a focus on enhancing the fan experience through more sophisticated technology and building systems. Icon was originally a joint venture with AEG but became independently owned in 2012. Icon was recently purchased by CAA Sports, which Romani believes will help Icon expand into new areas of business. Icon will continue operating as an expert in project management and owner representation for sports and entertainment venues.
Disruptive Innovation (is the new punk rock)Geoffrey Colon
How does business compete in the era of niche? One theory: disruptive innovation. Create products and services at the lower end of the market that large corporations ignore, make them go mainstream, dominate. For more on disruptive innovation follow Geoffrey Colon on Twitter @djgeoffe or listen to his podcast on Spreaker.com
At the start of this project we have been informed about our upcoming brief; which was to create a publication; could have been any sort of publication with any sort of media as long as it showed a publication, another thing we have been told we are in charge of what our publication is going to be about therefore we could have create any sort of article which we thought would be interesting.
Once the briefing was done, we got told to form a group no bigger than 4. I chose to work with Bank, Ryan and Saad as we all are good friends but also we have similar interest which I thought would come in handy.
Once we sorted our groups we have been told to research into design practice which interests us and we would like to work in.
Lens Interactive is a leading user experience and design firm with offices in Bangalore and Mumbai, India. It has worked with over 200 clients on more than 500 projects across various industries. The company focuses on user experience design, websites, branding, and developed an educational mobile app called YooYoo Kids. It has a team of over 20 employees with expertise in design, development, and project management tools.
The document provides an overview of various business model canvas templates and topics related to developing a business model. It includes templates for sections of the business model canvas like customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships, and cost structure. It also discusses topics like customer development, mapping customer segments to value propositions, and conceptualizing customer relationships and channels. The templates and discussions are intended to help users think through and detail the components of their business model.
Undestanding UX: TBTF technology executive council meetingKrissy Scoufis
Krissy Scoufis is an experienced user experience strategist, researcher, and mentor based in Tampa Bay. She discussed the importance of user experience (UX) in product development. UX involves understanding users through discovery, building the right product through development, and ensuring ongoing success through growth measurement. While some see UX as abstract, it helps reduce risk by truly understanding customers. The future of UX involves specialization across many domains as technology changes how people interact with products and services.
This document provides tips for designing websites with SEO in mind. It discusses using personas and keyword research to understand user intent. The information architecture and content strategy should be mapped to semantic groups and keyword opportunities. Technical implementation includes ensuring images have alt text for accessibility, using responsive designs and standard meta data. Case studies demonstrate how this approach improved rankings and conversions for clients.
DevDay 2013 - Building Startups and Minimum Viable ProductsBen Hall
DevDay (http://devday.pl),
20th of September 2013, Kraków
Video at http://www.youtube.com/watch?v=L4eTOvq2WmM&feature=c4-overview-vl&list=PLBMFXMTB7U74NdDghygvBaDcp67owVUUF
At Mobilize Dublin's January meetup, I shared some of the work we're doing at Intercom to help our customers to give their app users an amazing onboarding experience. I talked about how we explored the problem, decided on a solution, and shared a sneak peak at what we're building right now.
Presented at Ark Group Conference on Information Architecture, 30th September 2009 in Sydney.
* User Experience (UX) is more than just the Information Architecture (IA) of a site
* A good UX addresses the useful as well as the usable
* Thus I will discuss why UX should be prioritised over IA
* To create a good UX we need to do research to uncover the goals, attitudes and behaviours of our audience
* This high level approach can then direct lower level design such as the IA
* However getting user involvement at both the UX and IA levels can be challenging, and organisations often need some encouragement from UX/IA practitioners
* Thus I will also discuss prioritising UX within the organisation
1) MindMeister is a collaborative web-based mind mapping tool created in 2006 by Michael Hollauf and based on Ruby on Rails and AJAX.
2) It started as an idea to combine the collaborative features of Google Docs with the brainstorming abilities of mind mapping software. After several prototypes, it launched a private beta in early 2007 and officially launched in May 2007.
3) The presentation focuses on lessons learned around usability, design, marketing, and business model. Key recommendations include investing in design, targeting non-technical users, and tracking marketing efforts.
How Startups May Build Your UX Competencies - Hire or Just a Myth?UX Consulting Pte Ltd
Raven Chai is a principal UX consultant who has observed common pain points among startups regarding UX competencies. Many startups do not properly define their target users or validate ideas, instead prioritizing features and aesthetics over usability. Job postings also often have unrealistic expectations by requesting a "UX rockstar." Chai recommends startups hire agencies initially, attend conferences to learn, and consider government grants to build internal UX capabilities over time rather than relying on a sole "UX person."
What is service prototyping? How do you do it? When? An introduction to the topic with an overview on a practical case, presented during Rome's Service Design Jam 2017
Brad Frost
Web designer
Style Guide Best Practices
We’re tasked with creating experiences that look and function beautifully across a dizzying array of devices and environments. That’s a tall order in and of itself, but once you factor in other team members, clients, stakeholders, and organizational quirks, things start looking downright intimidating. With so many variables to consider, we need solid ground to stand on. Style guides are quickly proving to be foundational tools for tackling this increasingly-diverse web landscape while still maintaining your sanity. Style guides promote consistency, establish a shared vocabulary, make testing easier, and lay a future-friendly foundation. This session will detail best practices and considerations for creating and maintaining style guides, so you can set up your organization for success.
DevLearn 2018 - Designing AR Experiences for Performance SupportChad Udell
While many companies are experimenting with AR in the L&D space, there are a number of businesses harnessing the power of AR for enhancing operational performance outside of the training department. How do these experiences differ, and how can you renew your department’s focus on performance by taking on more advanced AR solutions in your efforts?
In this session, you will learn practical approaches for designing effective AR experiences. You’ll discover an approach to strategic implementation of AR by forming a partnership with functional business units. You’ll also explore the difference between simple marker-based AR solutions and more advanced computer vision and machine learning–backed AR. You’ll then look at how you can integrate AR systems with operational business systems in order to maximize return on investment and realize the opportunity that AR-enabled workers represent. Finally, you’ll look at aligning measurement of business task success and AR experience usage in order to align learning and production.
Digital transformation; or how I learnt to stop worrying and love the bots!Sayan Ghosh
The document is a presentation on digital transformation and robotic process automation (RPA) given by Sayan Ghosh. It discusses key concepts around AI, RPA, and cognitive technologies. It outlines a lifecycle approach to automation, including initial, mature, and sustained phases. It also covers using cognitive technologies to complement RPA by automating unstructured content and processes end-to-end. The presentation provides perspectives from industry experts and discusses using tools like process mining to identify automation opportunities and build an effective process pipeline.
This document summarizes Ashley Nolan's presentation about developing for the future by considering legacy. Some key points:
- Developers should think about the legacy they will leave behind on projects and aim to create positive legacies through choices like technologies, code quality, and documentation.
- Projects can easily become "legacy" themselves if not planned properly from the start with a clear structure and workflow. Tools like Gulp can help define workflows consistently.
- Documentation, even just code comments, is important so others understand the code in the future, including the original developers. Without documentation, code may have to be rewritten instead of updated.
As HTML5 and the surrounding API´s has matured and grown in popularity we see more and more web-applications being built for mobile devices replacing old native applications.
In this article I walk through some of the challenges we face when developing real-time web-apps and also show one of the many ways to overcome these challenges.
Is Baidu a copycat? Robin Li explains the biggest difference between Baidu an...Mohamed Mahdy
Robin Li, the founder and CEO of Baidu, explains two key differences between Baidu and Google. In the early PC search era, Baidu focused on user-generated content through forums and wikis, while Google mostly indexed existing web content. In the current mobile era, Baidu aims to directly connect users to services through search, like buying movie tickets, while Google focuses more on indexing information. Li believes meeting users' actual needs, not just providing information, is important for search in China.
Mobile App Feature Configuration and A/B Experimentslacyrhoades
The document discusses feature configuration and A/B testing in mobile apps. It describes how Etsy uses feature flags and continuous experimentation to iteratively develop and test new features. Features can be enabled or disabled for certain users or groups. Experiments follow a process of setting up a feature flag, determining user eligibility, coding the feature, internal testing, then launching the feature to a percentage of users while collecting analytics. This allows gathering feedback to improve products and user experience.
So, You Wannna Be a CTO - Romain Cochet WithTheBest
The document discusses the role and responsibilities of a CTO for an IoT startup. It notes that as CTO, you will need to build a connected product without knowing exactly how yet, and then sell it without knowing who the customers will be or what they will want. It outlines the various stages an IoT startup goes through from prototyping to scaling production. As CTO, you will be responsible for all technical aspects including developing the brand/ecommerce site, mobile app, backend servers, operating system/firmware, electronics, and final product design. The role requires expertise in many different technologies and involves managing both technical and business challenges. It concludes that being a CTO for an IoT startup is a very
Similar to Built With ❤ - Why Developer Experience Matters - Web Unleashed 2019 (20)
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
Why You Should Replace Windows 11 with Nitrux Linux 3.5.0 for enhanced perfor...SOFTTECHHUB
The choice of an operating system plays a pivotal role in shaping our computing experience. For decades, Microsoft's Windows has dominated the market, offering a familiar and widely adopted platform for personal and professional use. However, as technological advancements continue to push the boundaries of innovation, alternative operating systems have emerged, challenging the status quo and offering users a fresh perspective on computing.
One such alternative that has garnered significant attention and acclaim is Nitrux Linux 3.5.0, a sleek, powerful, and user-friendly Linux distribution that promises to redefine the way we interact with our devices. With its focus on performance, security, and customization, Nitrux Linux presents a compelling case for those seeking to break free from the constraints of proprietary software and embrace the freedom and flexibility of open-source computing.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Sudheer Mechineni, Head of Application Frameworks, Standard Chartered Bank
Discover how Standard Chartered Bank harnessed the power of Neo4j to transform complex data access challenges into a dynamic, scalable graph database solution. This keynote will cover their journey from initial adoption to deploying a fully automated, enterprise-grade causal cluster, highlighting key strategies for modelling organisational changes and ensuring robust disaster recovery. Learn how these innovations have not only enhanced Standard Chartered Bank’s data infrastructure but also positioned them as pioneers in the banking sector’s adoption of graph technology.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
Full-RAG: A modern architecture for hyper-personalizationZilliz
Mike Del Balso, CEO & Co-Founder at Tecton, presents "Full RAG," a novel approach to AI recommendation systems, aiming to push beyond the limitations of traditional models through a deep integration of contextual insights and real-time data, leveraging the Retrieval-Augmented Generation architecture. This talk will outline Full RAG's potential to significantly enhance personalization, address engineering challenges such as data management and model training, and introduce data enrichment with reranking as a key solution. Attendees will gain crucial insights into the importance of hyperpersonalization in AI, the capabilities of Full RAG for advanced personalization, and strategies for managing complex data integrations for deploying cutting-edge AI solutions.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
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…
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…
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.
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.
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.
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.
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.
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..
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.
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.
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.
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!
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.
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.
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.
🛠
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.
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.