Weekly Dev Tips 3y4j24

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\nThis is episode 65 on simple and inexpensive A/B testing with Azure, with guest Lars Klint.\r\nThis week\'s tip is brought to you by devBetter.com.\r\nSponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It\'s a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page.\r\nA/B Testing with Azure with guest Lars KlintThis week\'s guest is Lars Klint, a well-known cloud expert, speaker, and trainer who works for training company A Cloud Guru.\r\nShow Resources and LinksLars on Twitter\r\nA Cloud Guru\r\ndevBetter\r\nArdalis Blog\r\nPluralsight Courses\r\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 65 on simple and inexpensive A/B testing with Azure, with guest Lars Klint. This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page. A/B Testing with Azure with guest Lars KlintThis week's guest is Lars Klint, a well-known cloud expert, speaker, and trainer who works for training company A Cloud Guru. Show Resources and LinksLars on Twitter A Cloud Guru devBetter Ardalis Blog Pluralsight Courses That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 64 on team hip with guest Richard Campbell. This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page. Team hip with Guest Richard CampbellThis week's guest is Richard Campbell, known to many .NET developers as co-host of .NET Rocks. He has a tip for us this week on how to participate well within at team. Three concepts: Leadership Authority Influence Show Resources and LinksRichard on Twitter .NET Rocks devBetter Ardalis Blog Pluralsight Courses That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\nThis is episode 64 on team hip with guest Richard Campbell.\r\nThis week\'s tip is brought to you by devBetter.com.\r\nSponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It\'s a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page.\r\nTeam hip with Guest Richard CampbellThis week\'s guest is Richard Campbell, known to many .NET developers as co-host of .NET Rocks. He has a tip for us this week on how to participate well within at team.\r\nThree concepts:\r\nLeadership\r\nAuthority\r\nInfluence\r\nShow Resources and LinksRichard on Twitter\r\n.NET Rocks\r\ndevBetter\r\nArdalis Blog\r\nPluralsight Courses\r\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 63 on managers with guest Troy Hunt. This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page. Managers with guest Troy HuntThis week's guest is security expert, trainer, and international speaker Troy Hunt. He has some tips to share about how deal with s and other secrects. // no transcript Show Resources and Links1 Key devBetter Ardalis Blog Pluralsight Courses That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\nThis is episode 63 on managers with guest Troy Hunt.\r\nThis week\'s tip is brought to you by devBetter.com.\r\nSponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It\'s a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page.\r\n Managers with guest Troy HuntThis week\'s guest is security expert, trainer, and international speaker Troy Hunt. He has some tips to share about how deal with s and other secrects.\r\n// no transcript\r\nShow Resources and Links1\r\nKey\r\ndevBetter\r\nArdalis Blog\r\nPluralsight Courses\r\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 62 on the nature of mapping requirements to our software design and architecture and how we deal with change. This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page. Requirements and Change with guest Juval LöwyThis week's guest is Juval Löwy of IDesign. He has a tip for us this week on how we approach writing software. I'll let him introduce himself and share his tips. // no transcript Thanks, Juval! I've included a link to Juval's book, Righting Software - that's RIGHTing, in the show notes. Juval was kind enough to send me a copy and what I've read so far makes a lot of sense. Show Resources and LinksIDesign Righting Software - on Amazon devBetter Ardalis Blog Pluralsight Courses That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\nThis is episode 62 on the nature of mapping requirements to our software design and architecture and how we deal with change.\r\nThis week\'s tip is brought to you by devBetter.com.\r\nSponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It\'s a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page.\r\nRequirements and Change with guest Juval LöwyThis week\'s guest is Juval Löwy of IDesign. He has a tip for us this week on how we approach writing software. I\'ll let him introduce himself and share his tips.\r\n// no transcript\r\nThanks, Juval! I\'ve included a link to Juval\'s book, Righting Software - that\'s RIGHTing, in the show notes. Juval was kind enough to send me a copy and what I\'ve read so far makes a lot of sense.\r\nShow Resources and LinksIDesign\r\nRighting Software - on Amazon\r\ndevBetter\r\nArdalis Blog\r\nPluralsight Courses\r\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.   This is episode 61.   # Mise en Place   This week's tip is brought to you by devBetter.com.   ## Sponsor - devBetter Group Career Coaching for Developers   What is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out [devBetter.com](https://devbetter.com/) and read the testimonials at the bottom of the page.   # Mise en Place   This week I'm happy to introduce Ryan Lanciaux who has a guest tip to share on mise en place. Ryan runs Spaceship Studio LLC, a consultancy specializing in fast and dynamic web and native mobile applications. Take it away, Ryan!   (no transcript)   Thanks, Ryan! Ryan also recently wrote a blog post on the magic of mise en place if you'd like to learn more. There's a link to it in this episode's show notes on weeklydevtips.com.   ## Show Resources and Links   -[Follow Ryan on Twitter](https://twitter.com/ryanlanciaux) -[The Magic of Mise-en-Place](http://ryanlanciaux.com/blog/2019/09/20/the-magic-of-a-mise-en-place-mindset-for-frontend-development/) -[devBetter](https://devbetter.com) -[Ardalis Blog](https://ardalis.com/blog) -[Pluralsight Courses](https://www.pluralsight.com/authors/steve-smith)   That’s it for this week. If you want to hear more from me, go to [ardalis.com/tips](https://ardalis.com/tips) to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on [twitch.tv/ardalis](https://twitch.tv/ardalis) most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.  

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\n\r\n \r\nThis is episode 61.\r\n\r\n \r\n# Mise en Place\r\n\r\n \r\nThis week\'s tip is brought to you by devBetter.com.\r\n\r\n \r\n## Sponsor - devBetter Group Career Coaching for Developers\r\n\r\n \r\nWhat is devBetter? It\'s a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out [devBetter.com](https://devbetter.com/) and read the testimonials at the bottom of the page.\r\n\r\n \r\n# Mise en Place\r\n\r\n \r\nThis week I\'m happy to introduce Ryan Lanciaux who has a guest tip to share on mise en place. Ryan runs Spaceship Studio LLC, a consultancy specializing in fast and dynamic web and native mobile applications. Take it away, Ryan!\r\n\r\n \r\n(no transcript)\r\n\r\n \r\nThanks, Ryan! Ryan also recently wrote a blog post on the magic of mise en place if you\'d like to learn more. There\'s a link to it in this episode\'s show notes on weeklydevtips.com.\r\n\r\n \r\n## Show Resources and Links\r\n\r\n \r\n-[Follow Ryan on Twitter](https://twitter.com/ryanlanciaux)\r\n-[The Magic of Mise-en-Place](http://ryanlanciaux.com/blog/2019/09/20/the-magic-of-a-mise-en-place-mindset-for-frontend-development/)\r\n-[devBetter](https://devbetter.com)\r\n-[Ardalis Blog](https://ardalis.com/blog)\r\n-[Pluralsight Courses](https://www.pluralsight.com/authors/steve-smith)\r\n\r\n \r\nThat’s it for this week. If you want to hear more from me, go to [ardalis.com/tips](https://ardalis.com/tips) to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on [twitch.tv/ardalis](https://twitch.tv/ardalis) most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n\r\n \r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 60. How Developers FailThis week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It's a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page. How Developers FailI'm fond of saying "Developers fail in two ways: either we build the thing wrong or we build the wrong thing." I like the word play, which helps make the quote more memorable. It's very similar to the adage that "if you don't like where you work, you can change your organization, or you can change organizations." But it also strikes me that that most developers focus more on one problem than the other. In my experience, both personally and with others I've worked with, more junior programmers are most concerned with how to build the thing. There's a technical challenge there, and figuring it out is something many of us enjoy, like solving a puzzle. But as you gain experience, you find that often the thing you or your team built isn't actually the thing the customer wanted. And this kind of failure is both more difficult to detect and often more expensive to address after the fact. Building the Thing WrongLet's focus for a moment on the first kind of failure, building the thing wrong. It's intentionally vague. The thing is whatever the software is you're building. And wrong in this case means any kind of technical defect that results in the system not meeting its s' needs. Maybe there's a critical bug that results in the system crashing. Maybe the architecture doesn't scale. Maybe there are massive performance or resource problems or memory leaks that make the system unusable. It could even be a security flaw that allows a malicious to take down the system, or compromise its private data. These are all the kinds of things we tend to think of when we think about flaws or defects or bugs in software applications. Sometimes, quite often in fact, these failures are quite minor. They may be caught by a build server or during manual testing before end s ever see them. Other times, the failures may be quite expensive, with no easy fix. Some bugs are inevitable, which is why we design software processes to expect, detect, and correct them. Our engineering practices are very often designed to find system defects as quickly as possible, since we know correcting a defect moments after its introduction is orders of magnitude less expensive than after it's been shipped to production. Make no mistake, preventing the shipping of defects is a very worthwhile activity for software teams. Another more subtle way in which we might build things wrong is architecturally or from the standpoint of quality. Certain decisions made early on about the system architecture might turn out to be "wrong" later on when they prevent us from responding to customer demands. Technical debt in the form of shortcuts taken can have a similar impact later in the life of a system. Though more insidious than the release of -observable defects, these too are examples of building things wrong. Building the Wrong ThingSo what about the second class of failure, building the wrong thing? Why would we do that? It turns out communication is hard. Customers and s don't always communicate what they want clearly. We don't always listen well. Or we forget. Or we build what we think they want - or what we would want - instead of what they say they want. Sometimes that even works, but most of the time it's an example of forgetting that you are not the . Oftentimes the wants to solve a problem, but when they see part of what your software-based solution looks like, it triggers new ideas about how to better solve the problem. It's not that they didn't know what they wanted, but rather that the iterative process of deg a solution has revealed a better approach they was apparent at the outset. The worst thing we can do as software developers is to force the production of a mediocre solution because we are not open to a great one that our efforts made apparent later in the development process. To that end, it's important to communicate frequently, to validate our assumptions, and to allow the customers and stakeholders to respond to our work as it progresses. Be willing to change direction and be open to new ideas in order to maximize the value of the solution you deliver. Being able to build a thing right is generally a question of technical competence. Once you reach a certain skill threshold, you have confidence in your ability to do it. Building the right thing requires additional skills and may depend on that technical competence. Beyond building software right, you must now be able to communicate quickly and effectively and pivot the direction of your solution as needed based on the latest information. Only then can you be confident that you're building the right thing right. Show Resources and LinksdevBetter Ardalis Blog Pluralsight Courses That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\nThis is episode 60.\r\nHow Developers FailThis week\'s tip is brought to you by devBetter.com.\r\nSponsor - devBetter Group Career Coaching for DevelopersWhat is devBetter? It\'s a private group coaching community geared toward accelerating developer careers. We meet weekly for live Q&A sessions and have an active Discord-based discussion the rest of the week. Topics range from coding skills to interviewing and personal branding. Check out devBetter.com and read the testimonials at the bottom of the page.\r\nHow Developers FailI\'m fond of saying \"Developers fail in two ways: either we build the thing wrong or we build the wrong thing.\" I like the word play, which helps make the quote more memorable. It\'s very similar to the adage that \"if you don\'t like where you work, you can change your organization, or you can change organizations.\" But it also strikes me that that most developers focus more on one problem than the other. In my experience, both personally and with others I\'ve worked with, more junior programmers are most concerned with how to build the thing. There\'s a technical challenge there, and figuring it out is something many of us enjoy, like solving a puzzle. But as you gain experience, you find that often the thing you or your team built isn\'t actually the thing the customer wanted. And this kind of failure is both more difficult to detect and often more expensive to address after the fact.\r\nBuilding the Thing WrongLet\'s focus for a moment on the first kind of failure, building the thing wrong. It\'s intentionally vague. The thing is whatever the software is you\'re building. And wrong in this case means any kind of technical defect that results in the system not meeting its s\' needs. Maybe there\'s a critical bug that results in the system crashing. Maybe the architecture doesn\'t scale. Maybe there are massive performance or resource problems or memory leaks that make the system unusable. It could even be a security flaw that allows a malicious to take down the system, or compromise its private data. These are all the kinds of things we tend to think of when we think about flaws or defects or bugs in software applications.\r\nSometimes, quite often in fact, these failures are quite minor. They may be caught by a build server or during manual testing before end s ever see them. Other times, the failures may be quite expensive, with no easy fix. Some bugs are inevitable, which is why we design software processes to expect, detect, and correct them. Our engineering practices are very often designed to find system defects as quickly as possible, since we know correcting a defect moments after its introduction is orders of magnitude less expensive than after it\'s been shipped to production. Make no mistake, preventing the shipping of defects is a very worthwhile activity for software teams.\r\nAnother more subtle way in which we might build things wrong is architecturally or from the standpoint of quality. Certain decisions made early on about the system architecture might turn out to be \"wrong\" later on when they prevent us from responding to customer demands. Technical debt in the form of shortcuts taken can have a similar impact later in the life of a system. Though more insidious than the release of -observable defects, these too are examples of building things wrong.\r\nBuilding the Wrong ThingSo what about the second class of failure, building the wrong thing? Why would we do that? It turns out communication is hard. Customers and s don\'t always communicate what they want clearly. We don\'t always listen well. Or we forget. Or we build what we think they want - or what we would want - instead of what they say they want. Sometimes that even works, but most of the time it\'s an example of forgetting that you are not the .\r\nOftentimes the wants to solve a problem, but when they see part of what your software-based solution looks like, it triggers new ideas about how to better solve the problem. It\'s not that they didn\'t know what they wanted, but rather that the iterative process of deg a solution has revealed a better approach they was apparent at the outset. The worst thing we can do as software developers is to force the production of a mediocre solution because we are not open to a great one that our efforts made apparent later in the development process. To that end, it\'s important to communicate frequently, to validate our assumptions, and to allow the customers and stakeholders to respond to our work as it progresses. Be willing to change direction and be open to new ideas in order to maximize the value of the solution you deliver.\r\nBeing able to build a thing right is generally a question of technical competence. Once you reach a certain skill threshold, you have confidence in your ability to do it. Building the right thing requires additional skills and may depend on that technical competence. Beyond building software right, you must now be able to communicate quickly and effectively and pivot the direction of your solution as needed based on the latest information.\r\nOnly then can you be confident that you\'re building the right thing right.\r\nShow Resources and LinksdevBetter\r\nArdalis Blog\r\nPluralsight Courses\r\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.   This is episode 59, on versioning and semver, with guest Jon Skeet.   # Versioning   This week's tip is brought to you by devBetter.com.   ## Sponsor - devBetter Group Career Coaching for Developers   devBetter is a career coaching group I started last year. It gives you direct access to me as well as a group of peers with a diverse range of experience, with a shared goal of improving. We talk about code, careers, and more each week in our private online community and weekly live coaching sessions. Read the testimonials on [devBetter.com](https://devbetter.com/) and see what you think.   This week I'm excited to introduce Jon Skeet, who works for Google and is renowned for his Stack Overflow reputation. Jon's going to share some of his knowledge about versioning software, which can certainly be tricky business. I'll let him take it from here.   # Versioning with Jon Skeet   (no transcript available - some selected quotes)   "Versioning is all about what you do guarantee for future versions and how they relate to previous versions."   # Back to Steve   Thanks, Jon! I definitely learned something from that, and I'm sure many of my listeners did as well. I've added a link to your book web site and twitter profile to the show notes.   ## Show Resources and Links   -[Jon Skeet on Twitter](https://twitter.com/jonskeet) -[Jon's book, C# in Depth](https://csharpindepth.com/) -[devBetter](https://devbetter.com)   That’s it for this week. If you want to hear more from me, go to [ardalis.com/tips](https://ardalis.com/tips) to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on [twitch.tv/ardalis](https://twitch.tv/ardalis) most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.  

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\n\r\n \r\nThis is episode 59, on versioning and semver, with guest Jon Skeet.\r\n\r\n \r\n# Versioning\r\n\r\n \r\nThis week\'s tip is brought to you by devBetter.com.\r\n\r\n \r\n## Sponsor - devBetter Group Career Coaching for Developers\r\n\r\n \r\ndevBetter is a career coaching group I started last year. It gives you direct access to me as well as a group of peers with a diverse range of experience, with a shared goal of improving. We talk about code, careers, and more each week in our private online community and weekly live coaching sessions. Read the testimonials on [devBetter.com](https://devbetter.com/) and see what you think.\r\n\r\n \r\nThis week I\'m excited to introduce Jon Skeet, who works for Google and is renowned for his Stack Overflow reputation. Jon\'s going to share some of his knowledge about versioning software, which can certainly be tricky business. I\'ll let him take it from here.\r\n\r\n \r\n# Versioning with Jon Skeet\r\n\r\n \r\n(no transcript available - some selected quotes)\r\n\r\n \r\n\"Versioning is all about what you do guarantee for future versions and how they relate to previous versions.\"\r\n\r\n \r\n# Back to Steve\r\n\r\n \r\nThanks, Jon! I definitely learned something from that, and I\'m sure many of my listeners did as well. I\'ve added a link to your book web site and twitter profile to the show notes.\r\n\r\n \r\n## Show Resources and Links\r\n\r\n \r\n-[Jon Skeet on Twitter](https://twitter.com/jonskeet)\r\n-[Jon\'s book, C# in Depth](https://csharpindepth.com/)\r\n-[devBetter](https://devbetter.com)\r\n\r\n \r\nThat’s it for this week. If you want to hear more from me, go to [ardalis.com/tips](https://ardalis.com/tips) to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on [twitch.tv/ardalis](https://twitch.tv/ardalis) most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n\r\n \r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 58, on the concept of boundaries, with guest James Hickey. Boundaries This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Need to level up your career? Looking for a mentor or a the of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help improve. Read some of the testimonials on devBetter.com and see if it sounds like it you might be a good fit. This week we have our first returning guest, James Hickey. James was on the show earlier for episode 48 on how to accelerate your career. This week, he's back to talk about boundaries withing software systems. James is a software developer working remotely in eastern Canada. He's recently written a book about keeping your code clean called "Refactoring TypeScript" (https://leanpub.com/refactoringtypescript). He's also the author of an open-source .NET Core library called Coravel, which provides advanced capabilities to web applications. Welcome back, James! Boundaries Hi! I'm James Hickey. I'm a software developer working remotely in eastern Canada. When I started my career as a software developer I was thrust into a large codebase for a SAAS that helped automotive manufacturers perform analytics on their financial data. The way the codebase was organized is probably familiar to most developers - especially those with a background in enterprise-y companies. The solution was organized into 3 main projects: business, DAL (data-access), and "core" (which was just a bunch of classes having no business logic full of public getters and setters). At the end of the day, all the real business logic was mostly found within stored procedures in the database. So, all those layers didn't serve any real purpose. Business-oriented classes would just call a function from the DAL layer, and that method would call a stored procedure. As a fresh-out-of-school developer who's trying to learn "how the pros do it", I didn't question this way of organizing code. Eventually, though, I came to realize that this way of organizing code was terrible. It was hard to find code for specific features. You end up having to switch contexts between multiple projects when working on the same feature. A Better Way I've also been in projects having very different ways of organizing code, yet suffered from the same kinds of issues. Throughout this time, I had a hunch that there was a common issue that was causing these difficulties. It didn't matter how well classes or sub-systems were designed, because, in the grand scheme of things, it was still hard to deal with the codebase as a whole. As I read books and blogs and listened to well-known industry experts share their knowledge about software design, I came across better techniques and patterns for organizing code and deg software well. Then, I discovered domain-driven design. DDD DDD is a pretty huge subject, but at the heart of the entire philosophy is the idea that the most important thing about managing complexity in software is around putting up boundaries. In these other systems I've mentioned, the boundaries were enforced the wrong way. Instead of slicing our solutions by technical concerns (like by data-access, objects, interfaces, etc.), DDD teaches us to slice our solutions by business functionality (like shipping, search, billing, etc.) Since then, I've had the opportunity to learn about other approaches to software design and have formed some opinions around what works well and what generally doesn't work out so well. Out of all of these ideas, the most important one I've learned and have seen the effects of within real software projects is this idea of creating boundaries. Different Boundary Types You might be familiar with the concept called Bounded Contexts. In a nutshell, these are isolated sub-systems or bubbles that you design and build individually. Instead of creating one codebase and shoving all your code into it, you create a codebase or application per specific business feature or area of functionality. Multiple boundaries can communicate with each other, but not by traditional means. In projects like the ones I mentioned at the beginning, if shipping needed information from the payments feature, it would just reach into the database and query the payments table! These more strict boundaries mean you can't just reach into another feature's data or code. This has many benefits. Mainly, it allows the inside of each boundary to attack its core business problem head-on and not worry about secondary concerns like persistence and what other business problems require. And it decouples all your different bubbles or contexts. Inside each bounded context are these other boundaries called aggregates. These are objects that represent transactional boundaries. The details are not important, but what is important is that each aggregate does not directly call another aggregate's methods and grab its data. Usually, aggregates will emit events to communicate with each other. I use domain-driven design as the first example because the idea of boundaries is so fundamental to it. But there are other ways to enforce boundaries. Some prefer to create an isolated component, module, package or assembly (depending on what language you are in) and expose all the functionality of that isolated component as a facade. In this case, you might have one class that has all the publicly accessible behaviours or functions. None of the internal classes are exposed. When looking at architectures like Clean Architecture, all business functionality might be exposed as use cases. Each use case, like " new ", would be modelled as a single class. This class would not expose any domain objects or objects from modules farther down the chain. It would expose it's own specific models or DTOs. This is a way to enforce a boundary so that the outside world doesn't know about the internal details of specific modules or components. Similarly, if you are building a web API then you might want to enforce boundaries by using view models or DTOs which are used for sending data to your clients. This way, internal details like specific domain classes aren't exposed and you can modify or version each endpoint without affecting the other modules or projects that depend on it. Using specific classes dedicated for use in HTTP POST data binding also helps keep boundaries around each specific end-point. You also get the added security benefit of not "over posting." Duplication? Whenever you share code you are introducing some form of coupling. This, in turn, is the opposite of putting up boundaries. Let's say, for example, I have a class. This class is used within the profile logic and the authentication logic for an application. If I need to add new behaviours to the authentication flow, does it make sense that the same functionality is now available for use in the profile scenario? Since both features are sharing the same class, this is possible. This approach of trying to share as much code as possible throughout our apps is what causes spaghetti code and bugs galore. This is probably the biggest issue I come across in codebases. We think that sharing everything is good. But it's not. It creates a tangled mess of dependencies that, over time, cause businesses who want to be agile to sluggishly attempt to keep up with customer and market needs. Instead, if we isolate each of these features and NOT share that class, then changes from one feature won't affect the other. Sure, you might end up creating two different classes that have what look like duplicated fields, but that's OK. You aren't duplicating logic because these classes represent different things. The logic for the profile screen is going to be different than authentication logic by definition. There is a place for shared behaviour, like sharing how you might display a 's name in your application's UI. But fundamentally, we should seek to create boundaries around the different parts of our codebases. Conclusion Next time you find yourself having to start a new project or product, think about how you can isolate that product or feature from the rest of your codebase. Maybe you want to build it as a completely separate assembly or project? In this case, you could use an event-driven means of communication. Or, maybe expose a public API as a facade. If that doesn't make sense or isn't possible, you can at least create a new folder structure that makes it very clear what business functionality exists in that place. I've written more about this last point over at builtwithdot.net if you are curious. Thanks for listening in! Thanks, James. I've added a link to your blog to the show notes. Listeners interested in learning more about Domain-Driven Design and Clean Architecture will find additional resources in the show notes as well. Show Resources and Links devBetter Changing How Your Code is Organized Could Speed Development Clean Architecture on GitHub DDD Fundamentals That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\n\nThis is episode 58, on the concept of boundaries, with guest James Hickey.\r\n\nBoundaries\nThis week\'s tip is brought to you by devBetter.com.\r\n\nSponsor - devBetter Group Career Coaching for Developers\nNeed to level up your career? Looking for a mentor or a the of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help improve. Read some of the testimonials on devBetter.com and see if it sounds like it you might be a good fit.\r\n\nThis week we have our first returning guest, James Hickey. James was on the show earlier for episode 48 on how to accelerate your career. This week, he\'s back to talk about boundaries withing software systems. James is a software developer working remotely in eastern Canada. He\'s recently written a book about keeping your code clean called "Refactoring TypeScript" (https://leanpub.com/refactoringtypescript). He\'s also the author of an open-source .NET Core library called Coravel, which provides advanced capabilities to web applications. Welcome back, James!\r\n\nBoundaries\nHi! I\'m James Hickey.\r\n\nI\'m a software developer working remotely in eastern Canada.\r\n\nWhen I started my career as a software developer I was thrust into a large codebase for a SAAS that helped automotive manufacturers perform analytics on their financial data.\r\n\nThe way the codebase was organized is probably familiar to most developers - especially those with a background in enterprise-y companies. The solution was organized into 3 main projects: business, DAL (data-access), and "core" (which was just a bunch of classes having no business logic full of public getters and setters).\r\n\nAt the end of the day, all the real business logic was mostly found within stored procedures in the database. So, all those layers didn\'t serve any real purpose. Business-oriented classes would just call a function from the DAL layer, and that method would call a stored procedure.\r\n\nAs a fresh-out-of-school developer who\'s trying to learn "how the pros do it", I didn\'t question this way of organizing code.\r\n\nEventually, though, I came to realize that this way of organizing code was terrible. It was hard to find code for specific features. You end up having to switch contexts between multiple projects when working on the same feature.\r\n\nA Better Way\nI\'ve also been in projects having very different ways of organizing code, yet suffered from the same kinds of issues.\r\n\nThroughout this time, I had a hunch that there was a common issue that was causing these difficulties. It didn\'t matter how well classes or sub-systems were designed, because, in the grand scheme of things, it was still hard to deal with the codebase as a whole.\r\n\nAs I read books and blogs and listened to well-known industry experts share their knowledge about software design, I came across better techniques and patterns for organizing code and deg software well.\r\n\nThen, I discovered domain-driven design.\r\n\nDDD\nDDD is a pretty huge subject, but at the heart of the entire philosophy is the idea that the most important thing about managing complexity in software is around putting up boundaries.\r\n\nIn these other systems I\'ve mentioned, the boundaries were enforced the wrong way. Instead of slicing our solutions by technical concerns (like by data-access, objects, interfaces, etc.), DDD teaches us to slice our solutions by business functionality (like shipping, search, billing, etc.)\r\n\nSince then, I\'ve had the opportunity to learn about other approaches to software design and have formed some opinions around what works well and what generally doesn\'t work out so well.\r\n\nOut of all of these ideas, the most important one I\'ve learned and have seen the effects of within real software projects is this idea of creating boundaries.\r\n\nDifferent Boundary Types\nYou might be familiar with the concept called Bounded Contexts. In a nutshell, these are isolated sub-systems or bubbles that you design and build individually. Instead of creating one codebase and shoving all your code into it, you create a codebase or application per specific business feature or area of functionality.\r\n\nMultiple boundaries can communicate with each other, but not by traditional means. In projects like the ones I mentioned at the beginning, if shipping needed information from the payments feature, it would just reach into the database and query the payments table!\r\n\nThese more strict boundaries mean you can\'t just reach into another feature\'s data or code.\r\n\nThis has many benefits. Mainly, it allows the inside of each boundary to attack its core business problem head-on and not worry about secondary concerns like persistence and what other business problems require. And it decouples all your different bubbles or contexts.\r\n\nInside each bounded context are these other boundaries called aggregates. These are objects that represent transactional boundaries.\r\n\nThe details are not important, but what is important is that each aggregate does not directly call another aggregate\'s methods and grab its data. Usually, aggregates will emit events to communicate with each other.\r\n\nI use domain-driven design as the first example because the idea of boundaries is so fundamental to it.\r\n\nBut there are other ways to enforce boundaries.\r\n\nSome prefer to create an isolated component, module, package or assembly (depending on what language you are in) and expose all the functionality of that isolated component as a facade. In this case, you might have one class that has all the publicly accessible behaviours or functions. None of the internal classes are exposed.\r\n\nWhen looking at architectures like Clean Architecture, all business functionality might be exposed as use cases. Each use case, like " new ", would be modelled as a single class. This class would not expose any domain objects or objects from modules farther down the chain. It would expose it\'s own specific models or DTOs. This is a way to enforce a boundary so that the outside world doesn\'t know about the internal details of specific modules or components.\r\n\nSimilarly, if you are building a web API then you might want to enforce boundaries by using view models or DTOs which are used for sending data to your clients. This way, internal details like specific domain classes aren\'t exposed and you can modify or version each endpoint without affecting the other modules or projects that depend on it.\r\n\nUsing specific classes dedicated for use in HTTP POST data binding also helps keep boundaries around each specific end-point. You also get the added security benefit of not "over posting."\r\n\nDuplication?\nWhenever you share code you are introducing some form of coupling. This, in turn, is the opposite of putting up boundaries.\r\n\nLet\'s say, for example, I have a class. This class is used within the profile logic and the authentication logic for an application.\r\n\nIf I need to add new behaviours to the authentication flow, does it make sense that the same functionality is now available for use in the profile scenario? Since both features are sharing the same class, this is possible.\r\n\nThis approach of trying to share as much code as possible throughout our apps is what causes spaghetti code and bugs galore. This is probably the biggest issue I come across in codebases. We think that sharing everything is good. But it\'s not. It creates a tangled mess of dependencies that, over time, cause businesses who want to be agile to sluggishly attempt to keep up with customer and market needs.\r\n\nInstead, if we isolate each of these features and NOT share that class, then changes from one feature won\'t affect the other.\r\n\nSure, you might end up creating two different classes that have what look like duplicated fields, but that\'s OK. You aren\'t duplicating logic because these classes represent different things. The logic for the profile screen is going to be different than authentication logic by definition.\r\n\nThere is a place for shared behaviour, like sharing how you might display a \'s name in your application\'s UI. But fundamentally, we should seek to create boundaries around the different parts of our codebases.\r\n\nConclusion\nNext time you find yourself having to start a new project or product, think about how you can isolate that product or feature from the rest of your codebase.\r\n\nMaybe you want to build it as a completely separate assembly or project? In this case, you could use an event-driven means of communication. Or, maybe expose a public API as a facade.\r\n\nIf that doesn\'t make sense or isn\'t possible, you can at least create a new folder structure that makes it very clear what business functionality exists in that place.\r\n\nI\'ve written more about this last point over at builtwithdot.net if you are curious.\r\n\nThanks for listening in!\r\n\nThanks, James. I\'ve added a link to your blog to the show notes. Listeners interested in learning more about Domain-Driven Design and Clean Architecture will find additional resources in the show notes as well.\r\n\nShow Resources and Links\n\ndevBetter\r\n\nChanging How Your Code is Organized Could Speed Development\r\n\nClean Architecture on GitHub\r\n\nDDD Fundamentals\r\n\n\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 57, on the Dependency Inversion principle. Dependency Inversion PrincipleThis week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for DevelopersNeed to level up your career? Looking for a mentor or a the of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help improve. Interested? Check it out at devBetter.com. Show Notes / TranscriptOk, now we've reached the last and in my opinion the most important of the SOLID principles, D for Dependency Inversion. The Dependency Inversion Principle, or DIP for short, has a longer definition that most of the other principles and is often conflated with the related coding technique, dependency inversion, or DI. The principle states that High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces or abstract types). and further, Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. Let's look quickly at each of these two parts. The first part talks about high level and low level modules. The "level" of a module has to do with how near or far it is from some kind of I/O device. That could be the interface or it could be a local file or a database server. Low level modules deal directly with these kinds of I/O devices or destinations. High level modules do not know about or deal with specific kinds of I/O. These are things like business logic classes and behavior that model how a system works. In many systems that don't use abstractions, high level modules depend on low level modules, or the high level logic is mixed in with low level concerns in the same modules. Both of these approaches violate the Dependency Inversion Principle. Instead, these modules should communicate with one another using abstractions like C# or Java interfaces. Both kinds of modules would depend on a common interface, typically with the low level module implementing the interface and the high level module calling it. The second part suggests that abstractions - interfaces typically - should not depend on details. So an example of this would be if you had an interface for fetching information about a customer. One approach would be to write the interface so that it returned a SqlDataReader as its return type, where the data reader had the customer info. This exposes the details of how the data is stored, since you would only use a SqlDataReader to fetch the data from a SQL database. One benefit of following the Dependency Inversion principle is modularity. You could change that interface to return a simple List type and that List could come from any number of storage locations, from databases, to files to in-memory stores or web APIs. So, that covers how abstractions should not depend on details - what about the last bit that says details should depend on abstractions? That's talking about your low-level modules that actually communicate with I/O. These should depend on your interfaces by implementing them. If you're build a system composed of multiple projects it can be extremely difficult to follow the Dependency Inversion principle if you don't structure your project dependencies appropriately. This means ensuring that your abstractions - your interfaces - live in a project alongside your business model entities and that your implementation details live in another project that references this one. I have a GitHub repository and solution template called Clean Architecture that you can use as a starting point for new ASP.NET Core applications that need to follow SOLID principles and use clean architecture. You'll find a link to it in the show notes or just google ardalis clean architecture. A key benefit of Clean Architecture that is enabled by following the Dependency Inversion Principle is that your business model has no dependencies on external infrastructure concerns. These dependencies are a huge part of why legacy codebases are often difficult or impossible to write unit tests for. By keeping these dependencies separate and in their own project that other projects do not depend upon, it makes it much easier to unit test the most important part of your application: its business domain model. I talk more about this in my DDD Fundamentals course with Julie Lerman on Pluralsight if you want to see this in action. You can also check out the eShopOnWeb reference application that I built for Microsoft and its companion book, Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure. Show Resources and LinksdevBetter Clean Architecture on GitHub SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle DDD Fundamentals eShopOnWeb Reference Application That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\nThis is episode 57, on the Dependency Inversion principle.\r\nDependency Inversion PrincipleThis week\'s tip is brought to you by devBetter.com.\r\nSponsor - devBetter Group Career Coaching for DevelopersNeed to level up your career? Looking for a mentor or a the of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet for weekly group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help improve. Interested? Check it out at devBetter.com.\r\nShow Notes / TranscriptOk, now we\'ve reached the last and in my opinion the most important of the SOLID principles, D for Dependency Inversion. The Dependency Inversion Principle, or DIP for short, has a longer definition that most of the other principles and is often conflated with the related coding technique, dependency inversion, or DI. The principle states that High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces or abstract types). and further, Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.\r\nLet\'s look quickly at each of these two parts. The first part talks about high level and low level modules. The \"level\" of a module has to do with how near or far it is from some kind of I/O device. That could be the interface or it could be a local file or a database server. Low level modules deal directly with these kinds of I/O devices or destinations. High level modules do not know about or deal with specific kinds of I/O. These are things like business logic classes and behavior that model how a system works. In many systems that don\'t use abstractions, high level modules depend on low level modules, or the high level logic is mixed in with low level concerns in the same modules. Both of these approaches violate the Dependency Inversion Principle. Instead, these modules should communicate with one another using abstractions like C# or Java interfaces. Both kinds of modules would depend on a common interface, typically with the low level module implementing the interface and the high level module calling it.\r\nThe second part suggests that abstractions - interfaces typically - should not depend on details. So an example of this would be if you had an interface for fetching information about a customer. One approach would be to write the interface so that it returned a SqlDataReader as its return type, where the data reader had the customer info. This exposes the details of how the data is stored, since you would only use a SqlDataReader to fetch the data from a SQL database. One benefit of following the Dependency Inversion principle is modularity. You could change that interface to return a simple List type and that List could come from any number of storage locations, from databases, to files to in-memory stores or web APIs. So, that covers how abstractions should not depend on details - what about the last bit that says details should depend on abstractions? That\'s talking about your low-level modules that actually communicate with I/O. These should depend on your interfaces by implementing them.\r\nIf you\'re build a system composed of multiple projects it can be extremely difficult to follow the Dependency Inversion principle if you don\'t structure your project dependencies appropriately. This means ensuring that your abstractions - your interfaces - live in a project alongside your business model entities and that your implementation details live in another project that references this one. I have a GitHub repository and solution template called Clean Architecture that you can use as a starting point for new ASP.NET Core applications that need to follow SOLID principles and use clean architecture. You\'ll find a link to it in the show notes or just google ardalis clean architecture.\r\nA key benefit of Clean Architecture that is enabled by following the Dependency Inversion Principle is that your business model has no dependencies on external infrastructure concerns. These dependencies are a huge part of why legacy codebases are often difficult or impossible to write unit tests for. By keeping these dependencies separate and in their own project that other projects do not depend upon, it makes it much easier to unit test the most important part of your application: its business domain model. I talk more about this in my DDD Fundamentals course with Julie Lerman on Pluralsight if you want to see this in action. You can also check out the eShopOnWeb reference application that I built for Microsoft and its companion book, Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure.\r\nShow Resources and LinksdevBetter\r\nClean Architecture on GitHub\r\nSOLID Principles for C# Developers\r\nSOLID Principles of Object Oriented Design -and the DRY Principle\r\nDDD Fundamentals\r\neShopOnWeb Reference Application\r\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 56, on the importance of having a simple way to build, test, and run your application locally. One Step Build Test Run This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Need to level up your career? Looking for a mentor or a the of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet weekly for group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help improve. Interested? Check it out at devBetter.com. Show Notes / Transcript I've worked on a lot of projects for a lot of different companies and teams. One thing that dramatically increases the friction of becoming productive on a project is the number of manual and often undocumented steps required to take a new developer on a new machine and get them up and running the application from its source code locally. A lot of the time the developers on the team don't even recognize this as an issue because they've all been there long enough that they've absorbed the knowledge that's been ed down through shared oral history since the ancient times. But new developers, and especially new developers on distributed teams, weren't there last week when someone said "Oh yeah, I changed this thing so now you have to install this tool before you run the app on your machine". They don't just magically know the arcane command line scripts that must be run from 4 different nested subfolders of the application's source code in order to get the system up and running. As soon as you have one new remote team member, it exposes all the implicit knowledge-sharing and manual steps that have taken root in the team's processes and, hopefully, forces the team to make these steps explicit and then to automate them as much as possible. Simple projects don't require much, if any, documentation or automation. If you have an application that is so simple that any new developer can pull it down from source, use the default compilation step for the platform, like dotnet run for .NET Core or F5 for a Visual Studio-based solution, then you may not need any more documentation or automation than that. But when it's not that simple, you'll make everybody's life easier if you document and automate the steps. Documentation should be first, since it just makes the steps explicit, and sometimes automation can be difficult to achieve, especially if you need it to work across different operating systems. This is getting easier, though. Once you have the steps documented, you should strive to automate them to the point where common tasks are a single step. Ideally you want a One Step Build Test Run script that does all of these things: builds the app, runs tests against it, runs the app. But before we get that far, let's talk about how to document the process a bit more. Today, GitHub has become the standard for open source software projects. And GitHub has essentially codified the standard that projects should have REE.md files in their root that describe what the project is. Even if you're not hosting your application's code on GitHub, it's a good guess that your dev team has looked at projects on GitHub and is familiar with this convention. Thus, purely from a discoverability standpoint, the best place to put important steps for building and running your app is in its REE file in the root of the repo. If you have a lot of repositories that all use the same steps and you don't want that duplication, then put a link to the shared docs into each REE. What about wikis? Wikis are less discoverable. They're not right there in your face when you hit the home page of a repo, and they're not right there with your code when you're looking at the source in your favorite editor like a REE file is. You can put more detailed documentation and steps into a wiki if you like, but to make it discoverable you should put links to it in the REE file. If you use some CMS system or project management system the answer's the same - use the REE as the place to include the links to the relevant information so new team don't have to try and find it themselves. HTML s hyperlinks for a reason. Probably the worst thing you can do in documenting your local build/test/run process is to start by putting it in the REE file and then later decide to put the process in a wiki or another location, but not update the REE. This will cause team to use the REE and not discover the new location, wasting lots of their time. Bad information is worse than no information. Put a link to the new process documentation location in the REE. Show Resources and Links devBetter Really old blog post on one-click builds That’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I'm also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.\r\n\nThis is episode 56, on the importance of having a simple way to build, test, and run your application locally.\r\n\nOne Step Build Test Run\nThis week\'s tip is brought to you by devBetter.com.\r\n\nSponsor - devBetter Group Career Coaching for Developers\nNeed to level up your career? Looking for a mentor or a the of some motivated, tech-savvy peers? devBetter is a group coaching program I started last year. We meet weekly for group Q&A sessions and have an ongoing private Slack channel the rest of the week. I offer advice, networking opportunities, coding exercises, marketing and branding tips, and occasional assignments to help improve. Interested? Check it out at devBetter.com.\r\n\nShow Notes / Transcript\nI\'ve worked on a lot of projects for a lot of different companies and teams. One thing that dramatically increases the friction of becoming productive on a project is the number of manual and often undocumented steps required to take a new developer on a new machine and get them up and running the application from its source code locally. A lot of the time the developers on the team don\'t even recognize this as an issue because they\'ve all been there long enough that they\'ve absorbed the knowledge that\'s been ed down through shared oral history since the ancient times. But new developers, and especially new developers on distributed teams, weren\'t there last week when someone said "Oh yeah, I changed this thing so now you have to install this tool before you run the app on your machine". They don\'t just magically know the arcane command line scripts that must be run from 4 different nested subfolders of the application\'s source code in order to get the system up and running. As soon as you have one new remote team member, it exposes all the implicit knowledge-sharing and manual steps that have taken root in the team\'s processes and, hopefully, forces the team to make these steps explicit and then to automate them as much as possible.\r\n\nSimple projects don\'t require much, if any, documentation or automation. If you have an application that is so simple that any new developer can pull it down from source, use the default compilation step for the platform, like dotnet run for .NET Core or F5 for a Visual Studio-based solution, then you may not need any more documentation or automation than that.\r\n\nBut when it\'s not that simple, you\'ll make everybody\'s life easier if you document and automate the steps. Documentation should be first, since it just makes the steps explicit, and sometimes automation can be difficult to achieve, especially if you need it to work across different operating systems. This is getting easier, though. Once you have the steps documented, you should strive to automate them to the point where common tasks are a single step. Ideally you want a One Step Build Test Run script that does all of these things: builds the app, runs tests against it, runs the app.\r\n\nBut before we get that far, let\'s talk about how to document the process a bit more. Today, GitHub has become the standard for open source software projects. And GitHub has essentially codified the standard that projects should have REE.md files in their root that describe what the project is. Even if you\'re not hosting your application\'s code on GitHub, it\'s a good guess that your dev team has looked at projects on GitHub and is familiar with this convention. Thus, purely from a discoverability standpoint, the best place to put important steps for building and running your app is in its REE file in the root of the repo. If you have a lot of repositories that all use the same steps and you don\'t want that duplication, then put a link to the shared docs into each REE.\r\n\nWhat about wikis? Wikis are less discoverable. They\'re not right there in your face when you hit the home page of a repo, and they\'re not right there with your code when you\'re looking at the source in your favorite editor like a REE file is. You can put more detailed documentation and steps into a wiki if you like, but to make it discoverable you should put links to it in the REE file. If you use some CMS system or project management system the answer\'s the same - use the REE as the place to include the links to the relevant information so new team don\'t have to try and find it themselves. HTML s hyperlinks for a reason.\r\n\nProbably the worst thing you can do in documenting your local build/test/run process is to start by putting it in the REE file and then later decide to put the process in a wiki or another location, but not update the REE. This will cause team to use the REE and not discover the new location, wasting lots of their time. Bad information is worse than no information. Put a link to the new process documentation location in the REE.\r\n\nShow Resources and Links\n\ndevBetter\r\n\nReally old blog post on one-click builds\r\n\n\nThat’s it for this week. If you want to hear more from me, go to ardalis.com/tips to sign up for a free tip in your inbox every Wednesday. I\'m also streaming programming topics on twitch.tv/ardalis most Fridays at noon Eastern Time. Thank you for subscribing to Weekly Dev Tips, and I\'ll see you next week with another great developer tip.\r\n