Weekly Dev Tips

Show Resources and LinksAndrew Lock's blogASP.NET Core in Action by ManningFollow Andrew on TwitterYour Words are Wasted by Scott HanselmandevBetterArdalis BlogThat'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 74 with guest Claire Novotny.On the Dot Net FoundationThis 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.This week my guest is Claire Novotny, Executive Director of the .NET Foundation. We're going to spend a few minutes talking about the foundation.Show Resources and Links.NET FoundationdevBetterArdalis BlogThat'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. Thank you for subscribing to Weekly Dev Tips, and I'll see you next week with another great developer tip.

On Code CommentsThis 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.On Code CommentsClaudio and I discuss code comments and how Claudio's thoughts on them have evolved over the last 15 years or so.Show Resources and LinksClaudio's blogClaudio on twitterNotes and Links from this EpisodedevBetterArdalis BlogThat'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. 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 72 with guest John Papa.GitHub's New Command Line InterfaceThis 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.GitHub's New Command Line InterfaceJohn and I discuss GitHub's new CLI.Show Resources and LinksGitHub CLI DocsTry gh, GitHub's new CLIMoving Express to Azure Functions (Azure Learn Module)devBetterArdalis BlogThat'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. 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 71. This is the first tip I'm recording since going into quarantine lockdown due to the Coronavirus - the last few months were all recorded well ahead of their publication. I hope you're all staying safe and that you're finding these tips helpful. And perhaps you're listening to this from some time in the future, in which case hopefully everything turned out great! Adapter Design Pattern 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 and read the testimonials at the bottom of the page. Adapter Design Pattern This week we're going to talk briefly about the adapter design pattern. This is one of the most common and useful design patterns, so it's a good idea for most developers to be familiar with it. It's described in the Gang of Four's Design Patterns book, linked in the show notes. You can also learn more about it in the great book Head First Design Patterns or my Pluralsight course, also both linked in the show notes. This pattern is designed to solve the problem of incompatible interfaces. Typically this is an issue when you can't or don't want to change a client's expectations to match a service provider's interface. Or vice versa. For instance, let's say you have a large application and throughout it you've made calls to log diagnostic output using a particular named method with certain arguments. Now, you discover that you need to use a different logging solution, but unfortunately its method has a different name and its arguments are in a different order. Do you need to touch everywhere in your application to make the change? Not necessarily. Instead, you can introduce an adapter. The adapter has the same interface as your existing approach, but translates from that interface to the new one behind the scenes. Your code keeps using the method signature it's used to, but you're able to point it at a different end result. Because they usually wrap the incompatible class, adapters are also often referred to as wrappers. With a w - not like rap artists. It's against the rules to talk about the adapter design pattern without comparing it to electrical plug adapters, so here goes. If you've ever traveled and needed to use an adapter to convert your US plug appliance to fit another country's outlet, or vice versa, you've used an adapter. They're also common with electronics, for instance to convert a newer iPhone lightning port to a 3.5mm audio port on devices that lack a headphone jack. Adapters let you evolve the behavior of both the client and the service provider while still allowing incompatible combinations to work together. In this way, they decouple clients from service providers. Although adapters are structurally very similar to decorators and proxies, their intent differs. You can learn more about all of these patterns and see code examples on Pluralsight, or in the books I mentioned earlier. Show Resources and Links Adapter Design Pattern in C# on Pluralsight Domain-Driven Design Fundamentals on Pluralsight Design Patterns on Amazon Head First Design Patterns on Amazon devBetter Ardalis Blog 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 70 on Defense in Depth with guest Matt Eland.Defense in Depth with guest Matt ElandThis 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.Defense in Depth with guest Matt ElandThis week's tip is brought to you by guest Matt Eland. Matt is a teacher, writer, and .NET foundation member who focuses on software quality and improving code. Welcome, Matt!Show Resources and LinksMatt on TwitterdevBetterArdalis BlogPluralsight CoursesThat’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 68 with guest Jimmy Bogard. 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. # Respawn with guest Jimmy Bogard This week's guest is Jimmy Bogard, author of popular OSS projects AutoMapper and MediatR. And less popular project Respawn. ## Show Resources and Links - [Jimmy on Twitter](https://twitter.com/jbogard)- [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.This is episode 67 with guest Chris Klug.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.Abstractions with guest Chris KlugThis week's guest is Chris Klug. Chris is a Swedish .NET developer and Microsoft MVP whom we met up with at NDC London to record this episode on using, and not overusing, abstractions.Show Resources and LinksChris on TwitterdevBetterArdalis BlogPluralsight CoursesThat'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 66 with a Blazor tip from Carl Franklin of .NET Rocks fame.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.Building a Blazor Object Picker with guest Carl FranklinThis week's guest is Carl Franklin, host of .NET Rocks and Blazor trainer. Carl and I discuss Blazor in general and look at how to create a generic object picker control for Blazor.Show Resources and LinksCarl on TwitterBlazor Object PickerdevBetterArdalis BlogPluralsight CoursesThat’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 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 TwitterA Cloud GurudevBetterArdalis BlogPluralsight CoursesThat’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 membership 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 Membership 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:LeadershipAuthorityInfluenceShow Resources and LinksRichard on Twitter.NET RocksdevBetterArdalis BlogPluralsight CoursesThat’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 63 on password 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.Password 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 passwords and other secrects.// no transcriptShow Resources and Links1PasswordKeypassdevBetterArdalis BlogPluralsight CoursesThat’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 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 transcriptThanks, 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 LinksIDesignRighting Software - on AmazondevBetterArdalis BlogPluralsight CoursesThat’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 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.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 users' 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 user 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 users 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 user-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 users 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 user.Oftentimes the user 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 designing 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 LinksdevBetterArdalis BlogPluralsight CoursesThat’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 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. 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 support 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 members 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 designing 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 "register new user", 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 User class. This class is used within the user 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 user 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 User class, then changes from one feature won't affect the other. Sure, you might end up creating two different user 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 user 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 user'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.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 support 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 members 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 user 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 LinksdevBetterClean Architecture on GitHubSOLID Principles for C# DevelopersSOLID Principles of Object Oriented Design -and the DRY PrincipleDDD FundamentalseShopOnWeb Reference ApplicationThat’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 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 support 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 members 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 passed 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 README.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 README 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 README. 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 README 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 README file. If you use some CMS system or project management system the answer's the same - use the README as the place to include the links to the relevant information so new team members don't have to try and find it themselves. HTML supports 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 README file and then later decide to put the process in a wiki or another location, but not update the README. This will cause team members to use the README 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 README. 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. This is episode 55, on the Interface Segregation principle. Interface Segregation Principle This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers You can find help and advice all over today, from twitter to Stack Overflow to various Slack communities. These are great, but if you need more, if you need someone you can count on when you reach out for advice on code or your career, check out devBetter.com. Read the testimonials. Join risk free and see if it's for you. Not only will you learn from me, but if you stay for a while you'll grow and begin to be a mentor for others, gaining valuable confidence and experience. I've watched it happen. Show Notes / Transcript Returning back to the next SOLID principle, this week we're on the I as in Interface. Yes, it's the Interface Segregation Principle! Or ISP for short. Let's start by defining what this principle says. ISP states that no client should be forced to depend on methods it does not use. That's it. You can think of ISP as basically suggesting that you should prefer small, cohesive interfaces to large interfaces. In episode 49, which hopefully you already heard because you're listening to these in sequential order, we talked about the Single Responsibility Principle. These two principles are related! If you have classes that have only one responsibility, they're likely to expose a small, cohesive interface. That might be worth diving into a bit more. I'm guessing that when some developers, especially C# or Java developers, hear about ISP, they immediately map the word 'interface' to the interface type and keyword in these languages. That's not wrong, it's just not fully right, either. The public methods and properties a class exposes are its interface, even if it doesn't implement any interface defined separately. And ISP applies to implicit class interfaces just as much as it does to explicit interface definitions declared with the interface type. If you keep this in mind, it may make it easier to see how SRP and ISP relate, since SRP doesn't make any mention of interface types, only classes. The previous principle we discussed, Liskov Substitution, also relates to ISP. If you have a small, cohesive interface on a class, then when you decide to inherit from it you only have a few methods to worry about. If you have a massive number of methods, and your subtype is only concerned with a subset of them, it's much more likely that you won't fully implement all of the class's methods, potentially leaving some methods to throw NotImplementedException. Thus, it's easier to follow LSP if you first follow ISP. What's the point of having a smaller interface instead of a larger one, though? What's the down side to having fewer, larger classes with many methods on them? Certainly there's an argument to be made, and many have, that it makes it easier to find methods when you don't have so many different classes to search through to find them. The goal of ISP is to reduce dependency between types and especially between components in a system. The more types that depend on a particular type, the more difficult that type is to change. The more inertia it has in the system. If you have a class in your application that's used by 100 other classes, how likely are you to make major changes to its design, compared to one that you just wrote that has literally no other classes using it yet? Of course it's easier and WAY less risky to change classes that have few references to them. Let's say you want to change something fundamental about how that class that's used by 100 other classes works. One way you could do that would be to create a new instance of that class's interface or abstract base class, but then you'd have to implement all of its methods. Odds are, there are a bunch of them. That's not going to be easy - so instead you might just add some more conditional logic to some of the methods. Maybe add a few more method parameters to some methods. Maybe add a couple of new method overloads. And guess what? The problem just got bigger. The class just got bigger. The inertia just grew. By having a small interface and being focused on a small set of functionality, ISP-following classes are easier to change an easier to replace. By being small, they're easier to subtype or implement, making it easier to build systems that are modular. You find a class that has two methods and you want to change how it works in some situations? Just write a new class, implement the two methods, and swap it in where appropriate. Prefer writing new code to change legacy systems rather than modifying existing code. By following ISP, it's easier to replace classes with different variants that implement the same interface, which results in more loosely coupled and modular designs. These designs are easier to maintain and easier to test. You can learn more about ISP and the rest of the SOLID principles from my courses on Pluralsight, linked from this episode's show notes on weeklydevtips.com/episodes/55. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring for C# Developers 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 54, on customizing key bindings in Visual Studio with guest Kendra Havens. Customize Key Mappings with Kendra Havens 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 support 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 members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript This week's guest tip is from Kendra Havens. Kendra is a program manager at Microsoft on the .NET and Visual Studio team, where she focuses on the Visual Studio testing experience and productivity tools. She does videos on .NET, VS Code, and Docker and is a frequent conference presenter as well. In fact, we last met up at a recent DevIntersection conference where we were both presenting, and I invited her to share a favorite tip on the podcast. The nature of describing a visual tool in a podcast is challenging, so I have a link to a video in the show notes if you want to follow up afterward. Welcome, Kendra! Thanks, Kendra! I'll post a link to a video showing how to do this in the show notes for anyone that wants to see it. Show Resources and Links devBetter Kendra on Twitter Visual Studio Productivity Tips - Keyboard Command Mapping 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 53, on the Liskov Substitution principle. Liskov Substitution Principle 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 support 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 members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript We're in the middle of the SOLID principles this week, with the only one who is named after an individual. The Liskov Substitution Principle is named for professor Barbara Liskov, who teaches computer science at MIT. She gave a conference keynote some years ago in which she defined substitutability in object-oriented systems, essentially stating that one type could be considered substitutable for another if there were no situations in which the original type worked but the new one did not. The typical definition used today is that subtypes should always be substitutable for their base types. If this isn't the case, it likely means you have the wrong inheritance relationship, or your interface isn't cohesive enough, or there is some other code smell you should consider addressing through refactoring. So, although it isn't mentioned in the name, LSP is all about inheritance hierarchies. That's the first thing to remember. Many developers, myself included, learned about inheritance with the aid of the IS-A relationship. That is, you can consider using inheritance to model a problem if there are two related concepts and one IS-A more specific version of the other. You might have a Car class, with an SUV subclass. Or an Animal class with a Mammal subclass. These work because an SUV is a car and a mammal is an animal. Sometimes, though, you might have an IS-A relationship, but it's not sufficient and it leads you down the wrong OO design path. The classic geometry examples involve squares and rectangles and circles and ellipses. A square is a rectangle; a circle is an ellipse. But take care if you try and use inheritance to model them, since depending on how you do so you could introduce breaking changes into your application. Imagine if you have applications using your Rectangle type that assume they can independently set the height and width of the rectangle. Then someone introduces the Square type that inherits from Rectangle and implements height and width properties so that setting either one will set the other, too. This ensure the resulting type is always a square. But it also means that a method that takes in a rectangle and modifies its height and width to different values will break, because the first value set will be silently overwritten by the second. Another classic example involves birds. What if your base bird type includes methods like Fly and properties like Altitude? Then, someone introduces subtypes for Ostrich and Penguin. Trying to substitute these in to methods that expect certain behaviors from Fly and Altitude is likely to cause problems. The problem here is that the initial assumption that all birds can fly was inherently flawed. In business software, we don't usually worry about birds or squares, but we often model things like policies, accounts, orders, etc. and often there are different varieties of these concepts. You'll know when you're violating LSP when you see code that shouldn't care about the specific variety of something, but has to run a type check to do its work properly. A method takes in an Account, and then checks to see if Account Is PremiumAccount, for instance. This signals an LSP violation, and can usually be corrected with a refactoring that shifts behavior up or down the inheritance tree. Pretty much the only place where you might have a conditional on the specific type of an instance of a class is in a factory method that's responsible for creating that specific type. Otherwise, the Replace Conditional with Polymorphism refactoring is your friend. Use it to eliminate excessive conditional logic from your code by making proper use of inheritance in your object model. Obviously examples of these principles are tougher to describe in a podcast than in video, so to see them in action check out my courses on Pluralsight on the SOLID principles. I just produced a revised course for 2019, but my original SOLID principles of object-oriented design course is out there as well and uses different examples, so you might get benefit from seeing both of them. You'll find links to both in this episode's show notes. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring 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. This is episode 52, on feedback loops and continuous testing with guest Al Rodriguez. Continuous Testing Continuously 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 support 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 members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript This week's tip is on how to be more productive by reducing feedback loops. Our guest is Al Rodriguez. Al is a multiclassing wizard spending most of his time using .NET wherever possible but levels up in other tools to get the job done. Take it away, Al: Hi. I'm Al Rodriguez and I'm here to talk to you about Continuous Testing. One way to improve development productivity is to reduce the time of your feedback loop. A classic example of this is application startup time to validate a UI change. A 3 minute wait for an application to build and startup feels like an eternity when you've only changed a background color. This is why some tools exist to hot reload only the part of the application that has changed. Thus reducing the time that you, a busy developer, have to wait. We see tools like this all over the development space to reduce the feedback loop time. One example is inside our Text Editors. If you miss a semicolon or misspell a variable name, you immediately get feedback in the form of a red squiggly underline. Another example of this is a Continuous Integration pipeline. Once you check code in, a pipeline is invoked to build your application, run any tests it needs to, and alert the team if there are any issues. All three of these examples I've mentioned have wildly different feedback times because they're for very different types of tasks. But lets move on and talk about unit tests. The common loop I see when working with unit tests is to write the test, then click the button to run it. It's a very manual process. The feedback loop there is usually a couple of seconds. Short and sweet. As time goes on you'll change some code and eventually click the button to run the tests again. But which tests? All of them? One class at a time? The individual tests you think are impacted by your changes? Even worse, what happens if you forget to run the tests? Now you're checking code into source control that hasn't been fully tested. What does the feedback loop look like in that situation? Best case scenario, the tests are run after a few changes are made. Worst case scenario, they're not even run. And that's just you. There's also the scenario of people on your team who don't think to run the tests. On a project with historically low, or no, tests, the idea of running them doesn't cross your mind because it's not part of the normal flow. So new code could have broken the tests, and since they weren't run, no one will find out for a what may be a few weeks. That's fun and all. But you know what's better? What can reduce that feedback loop? What you said is right, sure, but the answer I was looking for is: Not clicking the button. Or more accurately, not having to click the button. Having a tool that will run your tests for you. Continuous Testing is when you have a tool to run your tests as soon as the they are created, changed, or any code impacted by a test has been changed. And if that's not continuous, I don't know what is. Which would be a problem. So if that's not what Continuous means, please let me know. I can't have another situation where I go years using a word wrong. That would be unfortuitous. Other benefits of Continuous Testing tools include a UI element to show the current state of the code under test. For example, when looking at your code there is a visual indicator inside your IDE to show you each line of code that has any failing tests, or if there are no tests for that line. Which is a great reminder that you need to write those tests. If you want to get started with Continuous Testing there are several options depending on your choice of tooling. In the .NET space you can use the Live Testing feature built-in to Visual Studio Enterprise. If you don't have an Enterprise license, another great tool is NCrunch. You can only get NCrunch by purchasing a license, but it's cheaper than upgrading to Visual Studio Enterprise. Which is the reason I use it for my own personal projects. Finally, if you're working with .NET Core you can use the dotnet CLI command: dotnet watch test The watch command listens for file changes. Once a file has changed, the test command is run on that folder. Note that this isn't as efficient as the previous tools because it re-runs all of the tests, not just the ones that have related changes. If you're in the javascript realm you can do something similar with npm's watch package. Using the command npm run test --watch will continually run your test task whenever files change just like we saw with dotnet. In summary, do what you can to reduce your feedback loop with automated tests. And that's all I have to say on this topic. If you'd like, you can find me on twitter under the handle @ProgrammerAl, that's P-R-O-G-R-A-M-M-E-R-A-L. Or you can find me interviewing people on their side projects on the Developer Side Quests podcast. Now go forth and forget where that Run Tests button is. Or even better, remove it from your IDE if that's an option. Thanks for letting me ramble on your show Steve. Back to you! Thanks, Al! Great tips! It's great that CLI tools make it so easy to set up this continuous feedback loop, even for developers who don't have access to great commercial tools like VS Enterprise and NCrunch. I hope a few listeners will give continuous testing a try, and if they have any questions or feedback, leave it on the show's page at weeklydevtips.com/episodes/52. I've also added links to the resources covered this week. Show Resources and Links devBetter NCrunch Al on Twitter 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 51, on the Open/Closed principle. Open/Closed Principle 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 support 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 members improve. Interested? Check it out at devBetter.com. Show Notes / Transcript My goal is to have every other tip for the next few weeks focus on one of the SOLID principles. If you're listening in order, which I recommend, you'll note that episode 49 was on Single Responsibility. Thus, here we are with episode 51, talking about the O in SOLID, the Open/Closed Principle. The name of this principle is somewhat oxymoronic. It sometimes reminds me of the classic Star Wars scene where the stormtroopers are chasing Han Solo, yelling "close the blast doors, close the blast doors!" only to find themselves blocked by the doors moments later, crying "open the blast doors, open the blast doors!" What does the principle of being both open and closed mean, really? The full principle says that software entities (no, not those entities - we mean classes, modules, functions, etc. here) should be open for extension but closed for modification. Ok, so what does each of these mean? Open for extension means that it's possible to add to the behavior of the class or method. We can make it do new or different things. Closed for modification means that the class or method itself should not be changed. Imagine that it's inside of a nuget package or its source is otherwise unavailable to modify. If we think about open for extension all by itself, it's a pretty easy one. It's saying some class or method should be open to changes in how it works. We do that all the time. We need to fix a bug or add a feature, we find where the code is that does that work, and we add a few lines to change the behavior. Often this just means adding an if statement or something similar, to account for the new behavior required. This is the typical, obvious way to add behavior to our systems, and generally there's nothing wrong with this approach. But it doesn't follow the open/closed principle, because such code is clearly not closed for modification. Now imagine that the code with the behavior you need to modify is not available to you to edit. How might you change its behavior, then? This might sound like a trick or impossible question, but we do this all the time, too. You change the behavior of classes and functions by changing their inputs. Passing in arguments or modifying data accessed by the class or method, such as configuration files or data stores, are all examples of ways in which you can modify system behavior without modifying source code. And there are some parts of your application that will benefit from being closed to modification, especially the parts that are depended on the most. By following OCP for your most fundamental classes, you'll make changes to them far more rare, which in turn will result in far fewer issues downstream due to updates to them. If you'd like to learn more about OCP, check out my courses on Pluralsight on the SOLID principles. I just produced a revised course for 2019, but my original SOLID principles of object-oriented design course is out there as well and uses different examples, so you might get benefit from seeing both of them. You'll find links to both in this episode's show notes. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring 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. This is episode 50 with some guest tips on Testing All The Things! Test All The Things This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript I'm glad to have a new guest offering some tips. Corey Weathers of Twilio is going to offer his perspective on the importance of software testing. Corey loves .NET and has worked for companies including Microsoft and the US federal government before joining Twilio as a developer evangelist. He works to inspire and equip .NET developer, underrepresented developers, and the Twitch community of developers with the tools they need to build the future of communications. Welcome, Corey! My name is Corey Weathers and I have the privilege and pleasure of being a .NET developer evangelist for a great company named Twilio. I’d like to start this week by saying a big thank you to Steve for inviting me on the Weekly Dev Tips podcast. This week I’d like to talk about something very near and dear to my heart as a developer – software testing. WHY TEST Now you may be wondering why testing. After being a developer for a number of years, I have found the following things to happen pretty consistently – someone usually has a problem and says “hey a developer can fix that”. Hopefully they’ve checked in with a software developer before making that assumption, but that’s not often the case. It’s usually problems like these that turn into use cases, user stories, or requirements. As product development happens, it can also be the case that these stories become more specific, nuanced, and refined in scope. When that happens, it’s not unusual to see more user stories created to cover the new scope that was removed from existing stories. What you end up with is one problem that a developer can fix turning into an ever-expanding list of user stories that become very complicated. Now when we start writing the code for one use case, and more show up, we continue writing more and more code to meet the ever expanding list of requirements and after this, we miss the opportunities to validate the code that we’re building. WHAT DOES TESTING DO So one of the first mantras to remember here is – TEST EARLY. Why? Because when you start early, you get to check one box that is super important – that is, you’re making sure that you’re building the right thing. This allows you to clarify your assumptions and confirm the suspicions you may have but that haven’t already been identified and figured out. Which leads me to the second mantra – TEST OFTEN. If Test Early ensures that you’re building the right thing, Test Often makes sure that you’re building the thing right. By making your code testable, you’ve added so much to your code base: maintainability, a measure of quality, and confidence in that things will work as you’ve both built and expected them to. WHERE DO I START At this point you may be wondering, ok well where do I start? And I realize a number of you may be coming from different starting points. Some of you may be at the very beginning and haven’t written a single line of code; whereas others of you may have an application deploying into a production environment that has poor test coverage. I know that it can be tough to get started. Hopefully this piece of advice should be relevant for you no matter where you’re starting from. My third and final mantra is START SIMPLE Let’s use an example here. For our conversation – let’s assume we have an application that has a user interface, and this user interfaces connects to an API that takes some data and saves it in a database. Assuming everything works as expected, you can start by writing a test for each part of this sequence. So one test can reproduce what happens when you click on the button when rendering the UI; a second test can simulate what happens when the UI calls the API; a third test can confirm that the database actually saved the data; and a final test can simulate all of the steps here by testing this one action with an API and database that looks close to what it will be in the real world. We could probably have an entire conversation as well about making sure you test setting up your application, but if you’re just getting started with testing there’s no need to start there. WHAT DO I DO WITH ALL OF THE TESTS With this suite of tests, you now have 4 tests that you can very easily expand on. You’ve started by testing the simplest path forward and can now add different modifications to this path, like what happens when my computer isn’t connected to the internet and my UI can’t talk to the API. Now here’s where we reach the inevitable – well if I’m just starting out with writing tests and something doesn’t pass as I expect it to, what do I do? Here is where I usually say – this is a good thing. Your test is starting to work. Think about it for a second. If you start writing tests and they start making you ask questions about how your test is working, then you’ll probably end up changing your test a bit so that this question focuses more on your application. This is a win because you’ll learn how to write better tests in the process. Alternatively, if you start writing tests and they make you question how your application is working, this is a win because it’s forcing you to make sure your application is meeting its intended need AND is testable as it is doing so. So write more tests, look for their results, and respond when the results don’t match what you expect. CALL TO ACTION That’s it from me this week friends. Remember TEST EARLY, TEST OFTEN, AND START SIMPLE. If you are interested in following up on testing, take a look at the Art of Unit Testing, written by Roy Osherove. He’s built an amazing body of content to help describe some of the why and how to begin testing. If you’d like to follow up with me, feel free to email me at corey@twilio.com. That’s C-O-R-E-Y@T-W-I-L-I-O.COM. That’s it from me this week. I’ll pass it back to Steve. Great stuff, Corey! Thanks for sharing with everyone. Art of Unit Testing is definitely a good book - I'll post a link in the show notes. Show Resources and Links devBetter Art of Unit Testing by Roy Osherove 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 49 on the Single Responsibility Principle. Single Responsibility This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript The Single Responsibility Principle, or SRP, is the S in the SOLID principles macronym. The short version of it is that a class should have only one reason to change. Specifically, the reason referred to here is tied to the application's requirements. Each class should only be required to change in response to a single change in the application's requirements. These requirements typically correspond to real world things. For example, let's say the application needs to display a report for quarterly sales performance. The system's requirements might be that the report be rendered in a browser, that it include all sales for a given quarter grouped by individual sales representative. Either of these requirements might change in the future. Perhaps the reports need to be emailed as PDFs. Perhaps they need to be calculated monthly instead of quarterly or rolled up by sales region. Ideally, the format of the report and the details of how it is calculated should be separate responsibilities of separate classes. Why is SRP important? Back in episode 15, Maintain Legacy Code with New Code, I explain one reason. Every time you change a class, you risk breaking classes that work with it. When a class has multiple responsibilities, it will likely need to change more often. Also, it's likely these responsibilities will be tightly coupled together by the class, making it harder to change them independently and further increasing the inherent risk of changing them. Let's say you have to fix a bug in an application. Would you rather have to work in a single class that literally only does the thing that has the bug in it, or would you prefer to work in a 2000 line long class that does 10 different things, all of which are intermixed in the class's 50 methods and properties? I know which one I prefer. Too often, developers new to SOLID will hear about SRP and misunderstand a bit what a responsibility really is. They might have a class they've carved out from the rest of the application. Something like CustomerManager. They'll happily explain how CustomerManager is only responsible for Customers in the application, and thus is following SRP. But upon reviewing the code, it's clear that CustomerManager is responsible for Customer validation, Customer persistence, and Customer formatting for various user interfaces. It's responsible for notifying Customers when they place orders and oh yeah, it also is responsible for Customers placing orders, as well as managing their orders and their payment providers and their account history. But don't worry - CustomerManager only has one responsibility: Customers! Although I said responsibilities typically map to business requirements, they don't typically map to entities like customers or orders or policies. This is because these entities will often have a lot of rich behavior that can be isolated into separate responsibilities, often with cross-cutting concerns within the application. For instance, how a customer is validated will likely be very similar to how an order is validated. The same goes for persistence and UI formatting and a host of other activities. Each of these is a responsibility, and should be isolated in its own class. Now, it might seem like breaking up big classes into small ones is going to result in a lot more code, but often just the opposite occurs. As you pull cross-cutting concerns like validation, persistence, logging, notifications, formatting, etc. into their own classes, you'll often find ways to standardize the codebase and reuse these classes. A common way to achieve this reuse is through the strategy pattern, which I discuss in episode episode 19. The Strategy pattern lets you move responsibilities out of a class by delegating to other classes, which are often defined as fields or properties on the original class. These fields or properties have their instances set by having them passed in through the constructor, in what's commonly called dependency injection. Dependency injection and the strategy design pattern go hand-in-hand, and are my favorite way to refactor to achieve SRP in classes that I find have too many responsibilities. If you'd like to learn more about SRP and SOLID, check out my newly revised course, SOLID Principles for C# Developers, on Pluralsight. It's a complete update of my original SOLID Principles of Object Oriented Design course that has been in the top 100 for Pluralsight since it was published in 2010. The new one is shorter and streamlined, though it doesn't cover some topics the original course has. The new course also uses Visual Studio 2019 and has all of its course samples on GitHub. Check both of them out and let me know what you think. Show Resources and Links devBetter SOLID Principles for C# Developers SOLID Principles of Object Oriented Design -and the DRY Principle Refactoring 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. This is episode 48 on Effective Ways to Accelerate Your Career, with guest James Hickey. Effective Ways to Accelerate Your Career This week's tip is brought to you by devBetter.com. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript This week's tip is brought to you by guest James Hickey. James is a software developer working remotely in eastern Canada. James helps software developers gain traction in their careers with his free email newsletter, "Navigating Your Software Development Career", which I link to in the show notes. He's also the author of an open source .NET Core library called Coravel, which provides advanced capabilities to web applications. James is going to share some tips on accelerating your career. Welcome to Weekly Dev Tips, James! Hi! I'm James Hickey. I'm a senior .NET developer and consultant based in eastern Canada. I'm also the author of an open source .NET Core library you might be familiar with called Coravel. One of the big realizations I had early on in my career was that doing a good job and doing what I was told to do would actually not lead to: Promotions, recognition, becoming really skilled at my craft, and opening up more opportunities. Many developers find themselves comfortable with having an easy and carefree job with minimal responsibilities. Other developers, like myself, have an inner drive, ambition, and passion to be the best that we can be. We recognize that having options means we can support our families better, have more money and resources to help our friends when in need, have the ability to create new businesses that solve important problems in our world, and know that we can inspire others to conquer obstacles in their own lives. Are you one of these developers? Here are some tips for you to accelerate a bit faster in your career! Find Gaps Here's my first tip. Early in my own career, there were times when I would solve a problem and developers who were more senior than I would ask, "How did you that?" One example was when I worked on a large database migration project. My colleagues were building various scripts that could take days to run. When I started building my own scripts, I started using regular expressions in SQL to fetch certain patterns in the data, manipulate it and then store the results. My solutions were taking mere hours to run! I became known as the guy who could migrate these large data sets very well. The senior developers would start coming to me for advice whenever they needed help in this area. Have you ever solved a problem and then been asked questions like these? "How did you do that?" "What did you do there?" "Why did you do that?" This probably indicates that you've found a knowledge or skills gap in your team. You should jump all over that topic and become the "go to" person. You might think that being known as the "regular expression guy" is not that useful. But that's not what people will think. In reality, you will be viewed as someone who can think outside the box. You will be viewed as someone who can solve tough problems. So, when promotion time comes along, guess who will be already on the minds of the decision makers? Connecting With Past Co-workers Here's tip number 2. If you've been in the field for a few years and have worked for a few different companies, then this next tip is for you. One thing I started doing is contacting past co-workers and managers on LinkedIn. First, I will ask them how they are doing. Next, I'll let them know - in a couple sentences - what I've been up to recently. And finally, I'll let them know that I am available to chat with them and help them with anything they need. This is a short and concise way to connect with them on a personal level and let them know that you are just there to help them in any way. Don't expect to be told immediately that your past co-workers have something they need help with. (Although that has happened to me, and I've landed some big opportunities this way.) The main point is to merely put it in the minds of these people that you are available. When they move on to another company and are looking to hire software developers, guess who's going to come to mind first? If you have a history of doing good work and being friendly and helpful to your co-workers, then you will be surprised where this simple tactic can lead! Teaching Have you noticed that the vast majority of the tech leaders you follow have either done public speaking, written books or recorded video tutorials? My final tip will really accelerate your career: teach other developers in public. Start speaking and presenting at user groups, meetups or even conferences. Start writing technical blog articles that address very specific issues developers are facing in their day-to-day work. You could even write a book which can skyrocket your credibility. Or, you could begin recording video tutorials that help developers learn to build software better, use their tools more effectively, and so forth. At the end of the day, simply helping people by teaching them to be better than they were yesterday will always win. Thanks! I hope you found these tips practical and useful! Thanks for letting me steal your thunder for a few minutes, Steve! No problem, Jmaes. Thanks for the great tips. Listeners, I hope you'll sign up for James' newsletter to get more career-oriented tips from James in your inbox. Show Resources and Links devBetter Find James Online 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 47, in which we'll introduce the SOLID principles. I'll spend a little time reviewing these principles in the upcoming episodes. What are the SOLID principles of object-oriented design? Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript Depending on how long you've been programming, you may have heard of the SOLID principles. These are a set of 5 principles that have been around for several decades, and about 15 years ago someone - I think it was Michael Feathers - had the idea to arrange them in such a way that they formed the macronym SOLID. Prior to that, I think the first time they were all published together was in Robert C. Martin's 2003 book, Agile Software Development: Principles, Patterns, and Practices in which their sequence spelled SOLDI - so close! This same sequence was used in the 2006 book Agile Principles, Patterns, and Practices in C#. So what are the SOLID principles? As I mentioned, SOLID is a macronym, meaning it is an acronym formed by other acronyms. In this case, these are SRP, OCP, LSP, ISP, and DIP. All those Ps at the end of each acronym stand for principle, of course. Listing each principle, we have: Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion You may already be familiar with these principles. If you're a developer who's using a strongly typed language like C# or Java, you should be extremely familiar with them. If you're not, I recommend digging into them more deeply. Applying them can make a massive difference in the quality of code you write. How do I define quality? Well, that's probably a topic I could devote an episode to, but the short version is that quality code is code that is easy to understand and easy to change to suit new requirements. It's easily and quickly tested by automated tests, which reduces the need for expensive manual testing. And it's loosely coupled to infrastructure concerns like databases or files. How do these principles help you to write quality code? They provide guidance. You need to write code that solves a problem, first and foremost. But once you have code that does that, before you call it done and check it in, you should evaluate its design and see if it makes sense to spend a few moments cleaning anything up. Back in Episode 6 - you are listening to these in sequential, not reverse, order, right? - I talked about Kent Beck's approach of Make It Work, Make It Right, Make It Fast. SOLID principles should generally be applied during the Make It Right step. Don't apply them up front, but as I discussed in Episode 10, follow Pain Driven Development. If you try to apply every principle to every part of your codebase from the start, you'll end up with extremely abstract code that could do anything but actually does nothing. Don't do that. Instead, build the code you need to solve the problem at hand, and then evaluate whether that code has any major code smells like I discussed in episode 30. One huge code smell is code that is hard to unit test, meaning it's hard to write an automated test that can just test your code, without any external infrastructure or dependencies like databases, files, or web servers. Code that is easy to unit test is generally easy to change, and code that has tests is also easier to refactor because when you're done you'll have some degree of confidence that you haven't broken anything. In upcoming episodes, I'll drill into each principle a bit more. I've published two courses on SOLID at Pluralsight where you can obviously learn a lot more and see real code as opposed to just hearing me through a podcast. The first one was published in 2010 and so the tools and look were a bit dated. The more recent one is slimmed down and uses the latest version of Visual Studio and .NET Core. There are links to both courses in the show notes - the original one also covers the Don't Repeat Yourself principle. Let me wrap this episode up with a very brief overview of each principle. The Single Responsibility Principle is generally applied to classes and suggests that classes should have only one responsibility, which can also be thought of as one reason to change. Responsibilities include things like business logic, ui logic, data access, and more. Following this principle, you'll tend to have smaller, more focused classes. The Open/Closed Principle suggests that you should be able to change the behavior of your system without changing its source code. This generally relies on some kind of parameter or plug-in capability to provide new behavior to an existing class or service. The Liskov Substitution Principle cautions against creating inheritance hierarchies in which child types are not 100% substitutable for their base types. When violated, this can result in messy code and bugs. The Interface Segregation Principle suggests that classes that use interfaces should use all or most of the interface's exposed members. This then leads to interfaces that are small, focused, and cohesive, much like SRP. Finally, the Dependency Inversion Principle recommends that low-level concerns depend on high level concerns, not the other way around. This means for example that business layer code shouldn't directly depend on data access code, but rather an abstraction should exist that the business code works with and that the data access code implements. At runtime, the data access code will be provided as an implementation of the interface the business code is written to work with, providing loose coupling and more testable code. Show Resources and Links devBetter SOLID Principles for C# on Pluralsight Refactoring Fundamentals on Pluralsight SOLID Principles of Object Oriented Design on Pluralsight (published in 2010) Agile Software Development: Principles, Patterns, and Practices on Amazon Agile Principles, Patterns, and Practices in C# on Amazon See Visualizations and Subscribe to WeeklyDevTips in YouTube Clean Code on Amazon 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 46, with guest Jamie Taylor, aka GaProgMan. On The Importance of Sleep Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript This week's tip comes to us from the UK, where fellow podcast host Jamie Taylor lives. He has a great tip that will help improve your health and productivity. Take it away, Jamie! Hello everyone, I'm Jamie "GaProgMan" Taylor, I'm the host of The .NET Core Podcast, and Steve has graciously agreed to let me share a tip with you all. My plan isn't to talk to you about .NET Core or even development, per se, but I might use them as a background for what I do want to talk about: and that's finding the time to relax and getting enough sleep. We work in a very fast paced industry, it seems like the technology space is constantly evolving. The breakneck pace of our industry can seem overwhelming to most of us, especially if you want to keep up with the latest innovations. I know that I've been guilty, in the past, of saying something like: the moment that you stop learning, you're already a day behind Which, other than being hyperbole, is a bit of a double edged sword. On the one hand, it's a great idea to keep to speed with what's going on; but on the other hand, you need down time. Now I don't care how long you can sit at your laptop, coding into the wee hours of the morning, drinking coffee, Red Bull, Mountain Dew, or whatever your incredibly sugary caffeinated drink of choice is. Eventually, you are going to need some rest and relaxation. And rest is the most important thing. Your body, whether you are aware of it or not, can go for days without food - it would be tough, but it's doable. But you cannot go for days without resting. To quote one UC Berkley article on the subject: As little as one night without sleep is enough to turn a reasonable person into "emotional Jell-O," says Matthew Walker, director of Berkeley’s Sleep and Neuroimaging Laboratory source: https://alumni.berkeley.edu/california-magazine/march-april-2008-mind-matters/your-brain-without-sleep The brain is the most important part of the body for a developer. Without it, we can't function (if you'll pardon the pun). We need the ability to deal with complex business logic, hold several layers of the application's design in our short term memory, and to be able to parse customer requirements. Without a healthy, well rested brain you can't do any of this. In the words of John Silva (host of National Geographic Channel's "Brain Games"): One of the things that happens when you're sleep-deprived is that your ability to regulate emotions goes haywire. Your brain becomes disorganised in its capacity to process information and your sensitivity to information also get scrambled. Regulating emotions is an incredibly important skill to have, and becoming disorganised is quite possibly the antithesis of the state of mind that a developer needs to be in. You need to be able to focus on the task at hand. "But I'm an extremely well motivated go-getter, Jamie. I really don't care." Eventually you are either going to crash and burn, or you're going to need the help of a team of doctors, and possibly a hospital. When you don't rest, you're not just affecting you're physical health, but you're also putting your mental health at risk. Without sleep, you'll be unable to put your thoughts in order, which means that you won't be able to communicate with others, which will lead to you becoming agitated, and that will lead to stress. And stress (or more correctly, "distress") can wreak havoc on your body. We're talking headaches, increased blood pressure, chest pain, heart problems, skin conditions, depression, and anxiety to say the least. So what can we do? Firstly, get up and walk away from your computer. Maybe not, right now. But the next time you get a chance to do so: do it. Take a walk, preferably outside; and if you really must have a coffee, walk to the next coffee shop along - the extra time in the fresh air will really help you. Spend time away from a computer of phone screen, as little as 15 minutes for every 45 will really help. Walk over to the water cooler and have a chat with someone while you get a cup of water. And if you don't have a water cooler, figure out another place to go and to be social - some companies have breakout rooms for this purpose. But what about outside of work? It's so easy to get trapped in a cycle of: Wake up Commute to work Only leave the desk to go to the bathroom or get lunch Commute home Spend all evening working on some personal projects, or staring at your phone So let's use the Japanese idea of Kaizen (which means "improvement") to break that, little by little. I've taken up running in an evening (well, it's more like jogging, because I'm so out of shape). I'll occasionally call my brother and talk with him about everything and nothing, or we'll talk about video games for hours. I attend a number of meetups which are not even remotely to technology related. By spending time away from computer screens and talking to folks, I've found that I feel more balanced, and rested. Remember: we're social beings. But the number one, most important thing, is sleep. And that can be hard to achieve when you're so used to sitting in front of a bright screen for hours. Our brains are tuned to think that bright light equals day time, so when we're surrounded by unnatural, bright lights, we tend to stay awake for longer. Which is why it's sometimes hard to sleep if you end up using a computer, tablet, or mobile phone before you go to bed. Fixing this is super easy: just don't spend all day and night sitting in front of a bright screen. Give yourself a cut off point, say 30 minutes before bed, and don't use a computer, tablet or phone during that period. But if you have to use your computer or phone during that window, know that the white light emitted by these screens contains harsh blue hues, which will make your brain think that it's day time. So just don't use them. Or, if you have to use them, look for apps similar to f.lux, or Red Moon if you're an Android user, or if you use iOS devices then you can use a combination of NightShift and True Tone. What About You Jamie? I occasionally get insomnia, and when it strikes I have a number of ways to rest even when I can't seem to sleep. The very first thing that I do is make myself a cup of chamomile tea. I've always found that it chills me out, and it can really help me to rest. This might not work for everyone, but the combination of a hot drink without caffeine before bed really helps me. You know how some people like to have a cup of hot cocoa before bed? It's the same thing. Then I try to focus on not ruminating on anything - this is the medical term for when you can't sleep because you're thinking about that bug you've been trying to recreate for 3 days. It's hard to do make these thoughts just go away, but just try to put it out of your mind. Thinking about things like this when you're meant to be sleeping isn't going to help you sleep. Trust me. The next thing that I do - and this isn't going to be to everyone's tastes, so feel free to skip over this one - is I practise mindfulness meditation. It sounds unintuitive, but focusing my attention on the breath seems to really help me to relax, which helps lead to me feeling super tired. Again, this isn't going to be to everyone's tastes. I also subscribe to a number of podcasts specifically designed to help me sleep (obviously, Weekly Dev Tips is not one of these podcasts). I used to do this with audio books, especially technical books where the reader doesn't really emphasise any particular parts of the story, but I've since found a number of podcasts which are designed to help you sleep. Sleep With Me is one of my favourite ones. I simply start an episode playing through my phone (at a low volume obviously), lay in bed and close my eyes. Some people that I've talked to about this have said that the sound white noise, or the sound of rainfall can produce a similar effect. In Summary You need to find a way to get rest which works for you. After all, you need good quality rest in order to be productive, NOT the other way around. You cannot be productive without being well rested, and no matter which way you look at it, developers need to be productive. One last thing before I go: take a look into circadian rhythm (I've probably mispronounced that completely). The tl;dr (or too long; didn't read) is that we have a certain number of states when we sleep: light sleep, deep sleep, and REM sleep. The deeper your sleeping state is when you wake up, the more groggy you'll feel when you do wake up. There are apps that you can get which will attempt to measure which sleep cycle you are in, and try to wake you while in a light sleep cycle as your alarm time approaches. This can leave you feeling less groggy, and less like you need that first cup of coffee in the morning. Now, I'd like for you all to get some good quality rest. And thank you Steve for allowing me to share this tip with everyone. Thanks, Jamie! Show Resources and Links devBetter Your Brain Without Sleep Sleep With Me podcast Circadian rhythm 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 45 on working alone with a mystery guest. Working Alone Show Notes / Transcript This week's show was recorded on 1 April 2019 with a special guest who has chosen to remain anonymous. I'm a developer with a regular day job, but at night I do freelance work in the shadows. I mostly right wrongs committed (to source control) by other developers, so the people who use their software can sleep better at night. I work alone, and have a secret identity to protect those closest to me. And because I signed a strict employee agreement with my day job and I don't want them to find out about my moonlighting activities. My tip to other developers: work alone. After years of working with other team members, I can tell you it's for the best. My team members at my day job are like my personal nemesis. There's this one guy who doesn't take the work seriously enough. He refuses to follow team conventions. Half the time it seems like he's intentionally trying to blow up our code. He should probably consider changing roles to testing. I'm constantly fighting with this joker. Then there's another dev I work with - I swear he thinks writing impossible to understand code is his ticket to job security. Most of the code he writes, even if it 'works', is like a riddle, wrapped in a mystery, inside an enigma. I think he gets a kick out of seeing if the other developers on the team can figure out his clever code. I don't have time for his games. When I'm not fighting with these two, it seems like as soon as I'm able to add a cool feature to our code, we're closing in on a ship date and the product manager puts a freeze on new features. If 'Mr. Freeze,' as we call him, weren't involved, I'm sure I could get a few more features into the product for each version. Even when I'm not having to deal with this group, I have to compete with another dev who thinks he's a gift to the team. I think he prefers to work alone, too, or at least he doesn't like to work with me. His work is always superb, which grates on me partly out of jealousy, but also because when he's out sick (he has really bad allergies), there's nobody but me to stand against the rest of the team. At night, working alone, I can do my best work. Hiding behind a bitmask, I knock out issues in client projects before they see me coming. I don't always follow the rules, but I get the job done. I may not always deliver the code teams want, but I give them the code they deserve. Ok... well thanks for that tip... uh... I'm batdev Show Resources and Links devBetter 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 44 with some guest tips on working from home that I hope you'll find useful. Working From Home Tips Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript This week we have a special guest, Andrew Lock, who like me does a lot of work with ASP.NET Core. Andrew, why don't you go ahead and introduce yourself for our listeners, and then just go right into the tips you'd like to share. Hi, my name's Andrew Lock, I'm a developer and author of the book ASP.NET Core in Action. I live in Devon in the UK but I work for a company in London. I work 100% remotely, which is becoming more and more common in the dev community, But one question I hear a lot is "how do you stay focused when you're working from home all day?" That's one of those questions where the answer is going to depend a lot on the particular person. Many people who haven't worked remotely before remember the occasional time they "worked from home" and worry about all the distractions that are around you: the TV, kids running around, all those little chores that need doing. So how can you cope with all this, and actually be productive when working from home. I thought I'd share a few things that I've found work for me. You might find some of them work for you too, but don't worry if they don't! Have a dedicated work area A really important part of working from home for me is having a dedicated work area. We have a spare bedroom with a desk and that's where I work when I'm working from home. There's two parts to this. First it's important to have a comfortable chair and a desk that's the right height for you, to avoid fatigue and injuries. So no slumping on a sofa with the laptop! Secondly, it separates my life into Work and Home. If you work in the same rooms as you relax and do other things in, it can be easy to get distracted. When I'm working, I'm in the office and it's a lot easier to get into that working mentality. This also helps when you have other people in the house, as it's easy to say "if I'm in the office, I'm at work". It's worth mentioning that some people find that even with this approach, being at home all day is still too distracting, and they like to completely separate their work time by going to a shared working area, or a coffee shop. Personally I find that far more distracting, but it might work for you. Routine As well as having a dedicated work area, I find routine to be extremely useful. Whether you're able to follow a fixed routine or not will likely depend a lot on your specific job and your living situation, as well as other commitments, but I find any structure you can add to your day helps. It's all part of getting into the "I'm at work now" mentality, and trying to shut off other distractions. Of course, just because you're following a routine and working in your office, doesn't mean that you should be head-down working the whole time. Far from it! In fact, it's very easy to lose track of time when you're working from home, and be sat still for hours. Not only is that bad for you physically, I find it's actually detrimental to my productivity in the long run. The first few weeks of working remotely, I felt so productive in the morning. I would get my head down, code for several hours, and feel like I was really going strong. By the time it got to the afternoon however, I was drained, and unable to focus for the rest of the day. Instead, I find I can stay productive for a whole day by ensuring I take a lot of small breaks. In particular, I often use the Pomodoro technique. There's lots about this approach on the internet, and there's various apps you can use to follow it, but I'll give a brief summary of how I apply it to my day. The Pomodoro technique The Pomodoro technique involves working in relatively short, timed blocks. So I set a timer for 25 minutes, and focus 100% on the task at hand. When an alarm goes off I take a 5 minute break - make a cup of tea or coffee, check my emails, anything really. When the break timer goes off, I get straight back to working again for another 25 minute block. After 5 blocks of working, I take a longer 30 minute break - get some lunch or go for a run - before settling down to another 5 blocks of work. If you haven't tried it before, I strongly suggest giving the Pomodoro technique a go. Adjust the timings to what works for you. I was sceptical at first, but I've found it helps me stay focused for a whole day, without burning out in the afternoon. In fact it's the approach I used to write my book while also working a full time job, and I don't think I would have managed that without it! IT can feel unnatural at first to break up those long coding sessions, but it really pays off in the long run. Don't beat yourself up The last thing I want to mention is the feeling that you're being unproductive when you're working from home, even if you aren't! Something I struggled with a lot initially was the feeling that everyone assumed I wasn't working hard when I was at home. So I felt like I had to go above and beyond to show that I was - by not taking breaks, or working longer than the hours I was paid for. I'm sure this is how a lot of people think when they start working remotely, but I really encourage you to fight against it. When I was working in an office, I wasn't working 100% of the time. In fact, I was way less productive in the office, so try not to beat yourself up. Take breaks. Don't overwork yourself, and try and add some structure to your day - it's far more sustainable, and you'll probably find you're more productive than you ever thought you could be. Thanks for inviting me on Steve! You're very welcome - thanks for sharing your advice with us! I've added links to the resources you mentioned to the show notes at weeklydevtips.com/044. Show Resources and Links devBetter See Visualizations and Subscribe to WeeklyDevTips in YouTube Andrew Lock blog Andrew Lock on Twitter Pomodoro Technique ASP.NET Core in Action on Amazon 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 43, with a quick story about dependency injection. A Dependency Injection Story Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript A few years and several businesses ago, my wife and I ran an online ad business, Lake Quincy Media, that served banner ads on software developer web sites like W3Schools, www.asp.net, and ASPAlliance.com. I wrote the original ad serving software for the company, and over the years as we grew we built a team and rewrote it a couple of times. We were using ASP.NET, what would now be called web forms, at the time I first really understood how to use dependency injection. I still remember exactly how it happened, and it dramatically changed how I looked at structuring my object-oriented applications from that point forward. Backing up a bit, I'd learned about and bought into practices like automated testing and continuous integration some years earlier. These practices were not as widespread as they are today, especially in the Microsoft development space, but we were using them at Lake Quincy Media to good effect on our ad server software (which also included publisher and advertiser portals, etc.). We were using a CI server called Cruise Control which included a nice system tray tool called CCTray that would pop up a notification and play a sound any time the build failed or was fixed. It worked great and problems that broke the build were quickly addressed by our small team. However, the application was architected using a traditional N-Tier architecture that was the recommended approach at that time. This meant that the ASP.NET application depended on the business logic application which in turn depended on the data access layer that called the database. Tests of the business logic required a test database, and so our tests ran SQL scripts that reset the database to a known good state before every test. Running several hundred of these tests took about 5-10 minutes on the build server as a result, which wasn't ideal. The point is, we were using automated tests, but our architecture was forcing us to rely more on integration tests rather than unit tests. This background leads to the next part of the story. I remember distinctly trying to write a test for a method that dealt with saving new banner ad media files once they were uploaded to the server. The method in question needed to save the file, perform some work on the file, and then based on some other factors, call some other methods. I was trying to write tests for this, but I was forced to write tests that actually dealt with the file system, and these were very painful. A configuration file was required to specify the upload path, this path wasn't the same between servers and developer machines. Sometimes the file would be locked and tests would fail, or someone would check in a different version of the config file with the path set wrong, and the tests would fail. It was quite brittle, and the files access really wasn't what was being tested - the conditional logic of the method was. By chance I was chatting with my friend and fellow MVP and Iraq war veteran, Jeffrey Palermo as I was struggling with this. He hopped on a screenshare with me and showed me how to change my business-level class so it wasn't working directly with the file system. Instead, he created an interface that included the required file operations like save and rename file, and moved the actual logic for working with the file system into a new class that implemented this interface. Then he created an instance of the interface in the business-level class, which was set by the constructor. However, in our test code, he showed me how to create a fake implementation of the file interface, which we could have the tests configure to return whatever kind of result we needed for the test case we were validating. This was huge! It literally blew my mind and changed how I thought about and wrote code from that day forward. Aaron B., who recently joined my tips mailing list, prompted this tip with his question, "What is one thing you wish you knew when you first started your development career?" and this is what I thought of. Thanks, Aaron, and thanks again, Jeffrey, for showing me this awesome technique for reducing painful coupling in software applications. Needless to say, armed with this technique and a desire to learn more about the related SOLID principles, my tests quickly started to emphasize unit tests wherever possible instead of intregration tests for everything. Our builds started to get faster, and we found tests were quicker and easier to write as well. This was over ten years ago now, but I wish I'd learned it much sooner in my career, and I hope sharing it here will help some of you. If you have a story you'd like to share about something you learned later in your career that you wish you'd learned sooner, go to weeklydevtips.com/043 and leave it as a comment. Thanks! Show Resources and Links devBetter See Visualizations and Subscribe to WeeklyDevTips in YouTube Clean Code on Amazon 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 42 - the answer to life, the universe, and everything - with some guest tips on learning TDD and Lisp. Learning TDD and Lisp This week we have a special guest. He is the author of the books Clean Code, The Clean Coder, and Clean Architecture, all of which I think should be required reading for professional software developers. Robert C. Martin, aka "Uncle Bob", is here to share a couple of tips for software developers. You'll find him online at @unclebobmartin on twitter and at cleancoder.com. We'll jump right into his tip after this quick word from this week's sponsor. Sponsor - devBetter Group Career Coaching for Developers Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us. Show Notes / Transcript Ok, so without further ado, please welcome Uncle Bob to WeeklyDevTips! ... Thanks so much, Bob! Structure and Interpretation of Computer Programs was actually the first computer science text book I had in college, in a class that used another Lisp variant, Scheme. I've added links to the resources you mentioned to the show notes, which you'll find in your podcast client or at weeklydevtips.com/042. Show Resources and Links devBetter See Visualizations and Subscribe to WeeklyDevTips in YouTube Uncle Bob on Twitter CleanCoder.com Clean Coders Videos Structure and Interpretation of Computer Programs on Amazon Structure and Interpretation of Computer Programs free PDF Clojure as a Dialect of Lisp Clean Code on Amazon The Clean Coder on Amazon Clean Architecture on Amazon 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 41, in which I'll talk about the difference between sprint and iteration-based software processes compared to continuous processes. If you’re enjoying these tips, please subscribe in your app. You can leave a rating and better yet, a comment in your app, too. I also accept subscriptions to @WeeklyDevTips on twitter and comments and requests for topics there or in the show comments, too. Thanks for all of your support! Sprints Versus Continuous Flow Sprint and iteration-based processes are stepping stones on the path from waterfall toward continuous flow. In this episode we'll make some comparisons to build and integration processes to demonstrate this. Sponsor - devBetter Group Career Coaching for Developers If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. devBetter is a small group of motivated developers meeting every week or two, and staying connected in the meantime via a private Slack community. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com. Show Notes / Transcript I've been a fan of continuous integration, or CI, for many years. When I was first getting started in professional software development, CI was still new and unproven. Some of my first consulting engagements had me working on teams where there was a team member who was the designated integrator. Their job was to understand how to put all the components of the application together so that the app could be deployed. This was a major ordeal every couple of months when a deployment needed to be made. In the 1990s, automated builds started to become increasingly popular. Tools like Ant, and later in .NET NAnt, were growing in popularity. Automated builds started to enable periodic scheduled integrations. Instead of having someone manually integrate and deploy the system every few months, these automated tools enabled weekly integrations, providing much more rapid feedback. Eventually, the frequency of these builds increased from weekly to daily (or more typically, nightly), and finally to the extreme of continuous integration. Continuous integration builds and tests the application every time a change is made to the application's source control. It's hard to get much better than continuous integration, but there are still a couple of nice features that can and have been added. Today, I most of my projects use continuous integration, but continuous integration by itself doesn't prevent developers from breaking the build by checking in broken stuff to the main branch. Two features that tools like Azure DevOps and GitHub support now are the ability to run builds on pull requests and the ability to restrict merging pull requests so that they require a passing build before they can be pulled in. Adding in these two features eliminates the vast majority of broken build scenarios, ensuring the main branch of the application remains in a working state at all times. So, what does this have to do with sprints? Before we had XP iterations and Scrum sprints, most software development used some kind of waterfall-like process. Iterations, such as they were, were quite long: months and sometimes years. Iterative development approaches popularized by agile software development recommended much shorter iterations, with many developer organizations shifting to 2- or 4-week iterations. Each iteration, the team would estimate the backlog, prioritize the work, plan out the iteration or sprint, commit to the plan, get work done, test it, try to deploy it, and potentially hold a retrospective about the iteration. It's not uncommon to look at iteration-based agile and compare it to a series of mini-waterfalls. The analogy from infrequent deployments to more frequent integrations is an easy one to see. So, with integrations, there's an obvious spectrum of increased benefit associated with increased frequency. There aren't many dissenting voices crying out that continuous integration is a waste of time and we should only build software once a month. The feedback benefits of CI over even daily builds is quite clear. So, if you see a certain amount of benefit when going from long-term waterfall delivery to 4-week iterative delivery, it should be obvious that this benefit will increase further if you go from 4-week to 2-week. But most teams stop there. The reason why most teams never shorten their iterations below 2-week sprints is because of the pain involved in some of the required ceremonies that are tied to the sprint. I literally saw this happen last week, when a client initially planned on 1-week sprints but dropped back to 2-week sprints because there were too many meetings to make 1-week sprints work. The issue is that the ceremonies eat into time to actually get work done. For instance, a reasonable retrospective probably takes an hour. Investing an hour every 2 weeks may seem reasonable, but what about every week, or every day? Estimating and prioritizing the backlog is a similarly painful part of most sprint plans - would it make sense to do it more often? This may sound crazy if you didn't listen to last week's episode yet, but give it some thought. Here's the thing - these ceremonies aren't strictly tied to delivering software. You could increase or decrease your sprint cadence, and still have monthly retrospectives. The same is true for prioritizing work. You can still do it every two weeks while your sprints are one week long, if you want. You can even do it literally just-in-time as things are pulled from the backlog. Imagine how quick sprint planning sessions would be if they only had to choose the next item the dev team would start working on? You could do that 10 times a day with an email exchange if the product owner made it a priority. Once you realize that really long iterations, like traditional waterfall, are not great, and shorter iterations are better, you should be able to make the jump to continuous flow pretty easily. If there are things that make this too painful, then listen to the last episode, and do those things more often. Or, realize they're not in the critical path to delivering software, and stop tying them to your software delivery cadence and schedule them on whatever cadence makes sense for your team. Show Resources and Links devBetter If It Hurts, Do It More Often See Visualizations and Subscribe to WeeklyDevTips in YouTube That’s it for this week. Next week we have a special guest as Robert "Uncle Bob" Martin will provide a couple of tips - be sure to check back for that. 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 40, in which I'll talk about the paradoxical advice, "if it hurts, do it more often." If you’re enjoying these tips, please subscribe in your app. You can leave a rating and better yet, a comment in your app, too. I also accept subscriptions to @WeeklyDevTips on twitter and comments and requests for topics there or in the show comments, too. Thanks for all of your support! If It Hurts, Do It More Often I've meant to do an episode or article on this topic for a while. It's advice I've been giving to my mentoring and corporate clients for years. Let's dive in after a quick plug for this show's sponsor, devBetter. Sponsor - devBetter Group Career Coaching for Developers If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. devBetter is a small group of motivated developers meeting every week or two, and staying connected in the meantime via a private Slack community. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com. Show Notes / Transcript I've given the advice "if it hurts, do it more often" for years, but in preparing for this episode I did some research on the phrase to see where I might have picked it up. I found a few articles, including a nice one from Martin Fowler, which I've linked from the show notes. I'll describe my own thoughts and how I usually present the concept, and then add in some of the interesting elements Fowler and others expand upon. "If it hurts, do it more often." On its face this phrase makes no sense. Putting your hand on a hot stove hurts... so, should you do that more often? Of course not. The advice applies to business and software processes, and the implied context is that whatever "it" is, it's something that you need to do as part of your process. You'll find that a list of painful-but-necessary activities involved in shipping working software includes almost every step of building software. Compiling. Integrating. Deploying. Installing. Debugging. Testing. Pretty much all of these activities are much more difficult and painful if you try and do them rarely compared to if you do them all the time. So, if you find yourself looking at your process and making decisions in order to minimize how often you perform some necessary part of your process because it's painful, I'm going to go the other way and say do it MORE OFTEN, not less. There's a scene in the Tom Clancy story Clear and Present Danger in which Jack Ryan is in a briefing with the President, who is having to deal with some scandal involving a friend of his. The President's team are advising him to distance himself from his friend, but Jack speaks up and advises just the opposite. Instead of distancing, go the other way. If the press asks if you're friends, tell them you're LIFELONG friends. Don't give them anywhere to go with it. Everyone is aghast at this advice, but of course the president takes the advice and presumably it works out well for him. I feel just like Jack Ryan when I'm giving the counterintuitive advice of doing things more frequently despite how painful they are. It's only natural to minimize pain, and the obvious approach is avoidance. But this just increases how much pain there is when the task must, eventually be done. When you force yourself to perform part of your process more frequently, the pain decreases dramatically. There are several reasons for this. The tasks becomes more familiar, you gain proficiency, you haven't forgotten what you did last time, and there's been less time to add scope and complexity between steps. All of these natural effects of putting less time between repetitions of the task result in less pain. There are also steps that your team will almost certainly take to reduce pain, like automation. If you have a painful task you do twice a year, it's almost certainly not worth automating. The effort involved in automation will only be recovered a couple of times per year. But if you are performing that same task every month, every week, or every day it very quickly starts to make sense to automate the parts of the process that you can. And once it's automated, the pain drops dramatically. A client I work with used to have very painful deployments. They would only deploy every month or two, and doing so was always a big source of pain. Many team members would come into the office at 4am on a weekday to get ready for the deployment. The goal was to complete the deployment before customers came into the office that day. There were a lot of QA and dev team heroics. Most of the time, he deployment wouldn't be 100% successful, and often 2-3 or more additional small deployments would be required to address issues that were discovered in production. In discussing this problem, my recommendation was, wait for it, to deploy more often. Nobody really was excited by this notion, least of all the team members who were getting up at 4am for these deployment days. I decided to bet on my recommendation with data. The team didn't have a fixed deployment schedule, so there was enough variability that we could capture some statistics and draw some conclusions. I had the team start tracking the number of days since the last deployment, the number of bugs found post-deployment, and whether the deployment was successful, where success meant that it didn't need rolled back and didn't have any major problems. They captured this data, along with trying to deploy a little more frequently, for a number of months. When we reviewed the data, it was clear that there was a direct correlation between failed deployments and number of days between deployments. This made sense, especially when the team reviewed the data and saw that most of the deployments that took place within very small time windows were just fixes to deployments that had just been made earlier that week. These deployments were made during regular business hours because they weren't considered high risk! With this data backing up the recommendation, the team was ready to buy into more frequent deployments. Last year, they doubled the number of deployments they made. It's February as I'm recording this show, and this year they're looking to double that number again, which will require multiple deployments per week. Martin Fowler's article on this topic notes that many of these activities have an amount of pain that increases dramatically as a function of time between repetitions. There's an exponential increase in pain as time increases, and this is why it makes sense to increases the frequency of the task. Not all activities will necessarily have this exponential increase in pain relative to time, but if you suspect part of your process does, see if you can boost its frequency. The most obvious cause of this exponential relationship is complexity. Working with large, complex things is exponentially more difficult compared to a series of small, simple things. This is why pull requests should be small and focus on one thing. It's why methods and classes should be small and focused. And it's a reason why parts of your software process should be pipelines working on small changes rather than huge, stressful ordeals that only happen once in a blue moon. Incidentally, this same concept is one of the reasons I prefer Kanban to Scrum and other sprint-based processes, but perhaps I'll cover that in another episode. Show Resources and Links devBetter Frequency Reduces Difficulty 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 39, in which I'll talk a bit about how to make code reviews a little less painful of an experience. If you’re enjoying these tips, please leave a comment or rating in your podcast app, tell a friend about the podcast, or follow us on twitter and retweet our episode announcements. There are millions of software developers in the world; help me try to reach a few more of them with these tips. Better Code Reviews I wrote an article about a year ago about Positive Reinforcement in Code Reviews. It generated a lot of feedback (on twitter if not in the article itself), so I thought I'd dedicate a Weekly Dev Tips episode to the topic. Sponsor - devBetter Group Career Coaching for Developers If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. I launched devBetter a few months ago and so far we have a small group of motivated developers meeting every week or two. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com. Show Notes / Transcript I remember my first internship in college working in a professional software development team. It was at a big company not too far from campus. The building was a three story rectangle. The second floor was basically a giant single room - you could see out the windows on all sides. In the middle were cubicles. Hundreds of cubicles. One of these became mine while I worked there. I was given a work computer, a bunch of 3-ring binders full of documentation, and once a week there was a code review that I participated in. I say I participated, but the internship didn't last very long and I spent most of my time fixing relatively simple bugs in C code, along with trying not to fall asleep while working through documentation binders. Thus, during the weekly code reviews, I mostly listened. These code reviews were conducted by the development manager. The week's updates were printed out and marked up by hand with questions and suggestions. From my perspective it was mostly a one-way conversation, though occasionally the more senior developers on the team would have a discussion about the code in question. The reviews weren't particularly insightful to me at the time, but the process itself stuck with me. I understood the intent of the reviews - to up the quality of the code - but the process reminded me more of getting an essay back from a professor marked up in red than of teamwork and collaboration. And the relative infrequency of the reviews meant that, more often than not, the printed updates being discussed were no longer current anyway. A fact that often resulted in discussions about whether it was worth making recommended changes at this point, due to the rework it would require. Over a decade later I found myself working at another company whose developers were required to conduct code reviews. This team's process was slightly different, in that each week a different senior developer took on the reviewer responsibility, and the reviews were done without any discussion or meeting. Once a week, whoever was in the reviewer role would go through the version control history and review all updates made in the last week (since the previous reviewer had done so). Any questions, suggestions, or changes were done in the form of TODO comments and emails, with management mandates that such requests be dealt with in a timely manner. It wasn't unusual, however, for deadline pressure to cause the review queue to build up, resulting in much more work to review or possibly in abandoning reviews for some period in order to get caught up. In both of these cases, there were two major problems with the code review process. First, it didn't happen fast enough. Frequently reviews were looking at code that was days or often more than a week old, which on projects under active development meant that the team had long since moved on by the time the review was taking place. Second, the reviews felt more like the code author was being graded or evaluated than like the team was working together. Fix this. This is a bad name. Come up with something better. You didn't follow the coding standard here. So, what can we do differently today? Here are some quick tips - apply the ones that you think will work best for you and your team. First, do code reviews as early as possible. The earliest way is by collaborating while you're writing the code. I'm a fan of using pair programming especially on mission-critical code, and if you've ever asked for a coworker to take a look at what you're doing to help you out, you understand the value having another team member participating can bring. Code reviews can certainly still be helpful even for code written by a pair, but the pair should catch a lot of problems so early that you may not even realize it. If collaborating while you code is too extreme for you or your organization, the next best thing is gated checkins. Many source control systems support this approach. My favorite at the moment is GitHub, who basically invented the idea and term pull request. A pull request is a conversation that happens about a change before it is made to the main source code branch. Teams I work with today use pull requests and reviews to ensure another team member looks over every PR before it's merged into the project's codebase. Usually the time from "hey can someone look at this PR for me" to someone actually reviewing it is under 10 minutes, because of notifications, Slack channels, and tight feedback loops. Of course, maybe you don't want code reviews to happen more often. Maybe you don't want someone to look at your beautiful code - and maybe call it ugly - right after you've declared it's perfect. Part of that might have to do with how your team reviews code. Code reviews are an opportunity not only to catch and fix problems but also to encourage and recognize the good stuff. Positive reinforcement works, and can help make code reviews less painful and thus more useful, as well as providing another way to get your coworkers to write what you think is better code. If a sincere accolade or positive message seems too cheesy for your tastes, consider easing up on the negativity by asking more questions and helping the author of the code arrive at a better solution themselves. Instead of saying "This code is a mess!" you might say "I'm having trouble understanding this code - could we work to make its intent more clear?" A related approach is to have a face to face or separate IM conversation with the author so you can have a more candid conversation that's not in front of the whole team (or company or world). As a rule it's better to offer praise in public but harsh criticism privately, and in any case it may be that you simply don't have all the information and a quick conversation will save you and the author a lot of trouble. Show Resources and Links devBetter Pair Programming Course 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 we’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 38, in which I'll offer some personal productivity tips. If you’re enjoying these tips, please leave a comment or rating in your podcast app, tell a friend about the podcast, or follow us on twitter and retweet our episode announcements. All these things help increase the reach of this podcast, so more people can benefit from these tips. Getting stuff done Occasionally I get asked questions like this one that came from a LinkedIn connection. He wrote, "how in the world do you accomplish so much? Would love to know the strategy." I'm flattered of course, but it's not the first time someone's claimed to be impressed by how much I get done, so I thought I'd share a bit about my approach. Sponsor - devBetter Group Career Coaching for Developers If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. I launched devBetter a few months ago and so far we have a small group of motivated developers meeting every week or two. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com. Show Notes / Transcript So, "how do I get so much done?" Let me start out by saying that I try to be pretty modest. I don't have superpowers. I'm not Bill Gates or Elon Musk, either, with billions of dollars. I don't even have online following of Scott Hanselman or Robert Martin or dozens of others. But I do alright, and I'm willing to share how that is a bit here. First, I made a realization years ago that every day I have 24 hours to utilize. No more and no less (except twice a year because of stupid daylight savings time). I used to say "I don't have time" for this or that. I'm sure I still say that sometimes, but at least in my head I try to remember that what I actually mean is "I choose not to make time" for it. It may be that you're in a position where you literally do not have control over your time, such as if you're in the military or in prison for example. But unless someone is directly controlling your freedom to choose how to spend your time, your use of time is a choice. Embrace that. Next, decide where your priorities are. What do you want out of your life? What does success look like to you. If you're a gamer, you can approach life like a strategy game. What's your strategy? Are you trying to max out income? Optimize for the best possible family? Slide through with as few commitments as possible? For me I'd say I'm following the fairly common strategy of trying to maximize my family's well-being while achieving success in my career. Within that strategy I'm focusing on entpreneurship and maximizing how many others I can help, as opposed to trying to climb as high up a corporate ladder as possible. Not having a strategy just means you're letting someone else choose your moves. Figure out what your strategy is, then figure out if the moves you're making - i.e. the way you're spending your time - is in line with what you think your strategy is. Remember, "How we spend our days is how we spend our lives." (Annie Dillard). Be sure you're spending your time wisely - it's the most precious resource you have. Ok, so that's the high level strategy side of the equation. At the tactical level, there are a few things I do that probably at least make it look like I'm being super productive. First, I minimize my commute. In the past I've had commutes of as long as an hour into work in some city where I then had the privilege of paying an obscene amount of money to park my car every day. Now, I can work from home if I choose or I have about a 10 minute country road drive to my office, which is also just a few minutes from my kids' school so it's often convenient when dropping off or picking up kids (there's no bus so driving them is one of those things my wife and I "get to" make time to do most weekdays). Not having that commute adds up. If I'm spending 10 minutes instead of 60 minutes twice a day driving, that's 100 minutes per day of bonus productivity. Think about that for a few minutes. Now, if we get self-driving cars maybe that commute time can be used productively (or if you're lucky enough to have decent public transportation). But until then I optimize for minimal time wasted on commuting. Another thing I do is minimize time spent on TV. I watch some, but pretty much only with family members as we enjoy time together, or occasionally when working out. I'm not perfect on this front, and recently I've been spending more time than I used to on video games which can suck up at least as much time as binging Netflix, but the idea is to be mindful of how much time you're spending on this and make sure you're OK with it. If you decide it's more time than you'd like to have invested in that, figure out a way to adjust. Also, if you're spending a ton of money on cable, consider dropping that cost in favor of nothing or a much cheaper Netflix or Amazon Prime subscription, which typically costs as much per year as cable with lots of channels does per month. This saves you time and money. Here's a simple, crazy idea. Typing speed. I produce a fair bit of content, between blog posts, podcasts (I script them ahead of time), writing actual code, emails with folks, social media, etc. I'm a pretty fast touch typist. I doubt that I'd set any records, but just last week at a client multiple students in my workshop were impressed by my typing speed (and asked me to slow down, which of course I did). If you want to get more done and you work at a computer keyboard all day then for the love of sanity learn to type faster! It's a skill that is relatively easy to learn and will pay off in no time. Is it the only thing that matters? Is writing software just monkey work where the bottleneck is typing? Of course not. But it 100% definitely helps and I've never once thought to myself "Boy, it sure is a useless skill to be able to type quickly. I wish I'd spent those hours learning to type watching TV instead." Something else I do that maybe you all don't is google stuff constantly. I was streaming last week and someone new hopped into the chat and was like "Oh, I thought this was someone who knew what they're doing but you keep googling basic stuff." I was slightly offended, and that's part of what you get when you watch someone streaming live as opposed to a pre-recorded course like on Pluralsight is you see how they actually work. When I'm actually working, I'm looking stuff up. All. The. Time. I'm googling stuff with my own name in the search to see my own things I've done before. I search for stuff in the ASP.NET Core docs all the time that I wrote myself but which I don't keep rattling around in my head forever. Remember there are two kinds of knowledge: things you know and things you know how to find. Knowing stuff is great. Knowing how to find stuff quickly is great, too. Of course the second one is only helpful if you use that skill, so however long you currently wait before breaking down and searching for a solution, think about reducing that and start searching sooner if you want to get more done, faster. I could go on but I need to wrap this up so we'll end with one last one which is that you need to ship. "Shipping is a feature." and "Perfect is the enemy of good." It looks like I'm productive because I'm constantly producing things. They're not perfect. They usually need work. But they're good enough to get out into the world where others can benefit from them and/or provide feedback that I can use to iterate. Don't feel like you can't start something because you don't have all the details figured out yet. Just get started. And don't wait to publish your 10 page article on your blog because it's not perfect yet. Publish the first 2 pages and call it Part 1. Hopefully at least some of that is useful to you. I'm not a fitness guru who gets up at 5, works out, never eats anything unhealthy, and only works 2 hours a day. I have 4 kids, including 4-year-old twins, and I choose to spend a lot of my time doing things with or for them. That means I need to make my remaining time count, and these are some of the ways I do that today. I'm constantly learning and trying to find ways to be more effective, though, so if you have a tip you'd like to share please leave a comment on the show at weeklydevtips.com. Show Resources and Links devBetter Take a free 1 minute typing test (Steve scored 81 WPM with 97% accuracy as an example) Recording of Steve Walking and Typing at Different Speeds for science! 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 now. Thank you for subscribing to Weekly Dev Tips, and we’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 37, in which I'll talk a bit about how I debug problems I find in my code. If you’re enjoying these tips, please leave a comment or rating in your podcast app, tell a friend about the podcast, or follow us on twitter and retweet our episode announcements. All these things help increase the reach of this podcast, so more people can benefit from these tips. Debugging Tip This week's tip is by request via twitter from Bernard FitzGerald (@bernimfitz) who wrote "How about an episode devoted to effective debugging? I think that would be interesting to hear your methodology of tracking down a bug." Well, Bernard, this bug's for you. Sorry, lame beer commercial joke. On that note, here's a commercial... Sponsor - devBetter Group Career Coaching for Developers If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. I launched devBetter a few months ago and so far we have a small group of motivated developers meeting every week or two. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com. Show Notes / Transcript Let's talk a bit about debugging. Let me start off with a couple of personal observations. First, I think debuggers are amazing. Having the ability to magically stop time in the middle of your application anywhere you want and see exactly what the state of everything is there is like a super power. It far outstrips using console output and checking a log file or terminal window for logged output like "got here" and "got here 2". Those were dark days. And second, despite how amazing they are, I almost never use the debugger. One tip I give all the time to students in my workshops is that they learn to use ctrl-F5 instead of F5 to launch their applications because it's so much faster. In my experience, 90% or more of the time you're not actually debugging when you launch your application, and in a recent experiment I ran it took about a second to launch an ASP.NET Core app without the debugger and about 10 seconds to do so with it (running on my somewhat old laptop). Those seconds add up, especially when you remember that after a few seconds you're likely to get distracted and go look at your phone or open a browser and start checking email or twitter or something. Not using the debugger helps keep you in the zone and productive. So why not use the debugger to, like, actually debug problems? I do sometimes. But more often I'll write tests. If it's my own application, I probably already have a bunch of tests. If there's some weird behavior going on and no existing test is catching it, I'll try to write a new one that fails because of the bug I'm looking for. Going through this exercise forces me to analyze what the program is doing, what classes are collaborating and how, and in general to have a better understanding of what's going on. If I can't easily write a test to isolate the issue I'm having, then I'll use the debugger. I might even debug from a test, since that's often an easy way to jump right to a particular place in my code that I know is being called with known inputs. From there I'll look at the values of all the relevant variables and arguments and usually that will identify where something isn't set the way I'd thought or assumed it was. Another approach I take is to use some kind of diagnostic tool within the app framework I'm using to provide me with as much data as possible about how the system is working. That might be using a tool like ELMAH for older ASP.NET apps, or an MVC route debugger middleware that shows me every route and how it's configured. I have some middleware for ASP.NET Core on GitHub that will format and render all of the services the application has registered. Things like this can often help provide additional context and information that can eventually help find the source of a problem. Tests aren't the only thing that helps avoid the need for a debugger. Using custom exceptions like I described in episode 7 helps make it obvious what went wrong so you don't need to debug in order to figure out that NullReferenceException. Writing short, simple methods with low complexity, perhaps with the help of Guard Clauses that I described in episode 4 is helpful, too. I actually revisited both of these topics in the previous episode, too. When your code is kept simple and small, problems are generally easily detected. If you're writing 1000 line long methods that require multiple levels of nested regions in them to be comprehensible, I can see how you might need the debugger to sort out what the heck is going on when something doesn't work. What are some other things I'm doing while troubleshooting? I'm not wasting hours focused on finding the problem mano a mano. I'm harnessing the power of a billion people on the Internet to help me. I can record another entire episode just on how to minimize how much time you waste blocked by some problem, and I've written an article on my ardalis.com site called Working Through Roadblocks - A Guide for New Programmers that goes into this as well. Show Resources and Links devBetter ELMAH ASP.NET MVC Route Debugger List all ASP.NET Core Services Working Through Roadblocks - A Guide for New Programmers 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 now. Thank you for subscribing to Weekly Dev Tips, and we’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 36, in which we'll discuss a question I recently received about guard clauses and exceptions. If you’re enjoying these tips, please leave a comment or rating in your podcast app, tell a friend about the podcast, or follow us on twitter and retweet our episode announcements so we can increase our audience. I really appreciate it. Exceptions and Guard Clauses This week's tip is on the topic guard clauses and exceptions. Specifically, whether and when it's appropriate to throw an exception in response to certain kinds of inputs. Sponsor - devBetter Group Career Coaching for Developers If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. I launched devBetter a few months ago and so far we have a small group of motivated developers meeting every week or two. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com. Show Notes / Transcript As a bit of background, I described Guard Clauses in Episode 4. If you're listening to these shows in most-recent-first order, I suggest you configure your podcast app to let you listen in order and then start back with episode 1. You'll thank me later. In any case, a guard clause is a check you make at the start of a function or method that throws an exception if some input is not valid. For instance, you could have a function that is supposed to send an email to an email address that's provided as a string argument. If the string is null, it might throw an ArgumentNullException or something similar before attempting to create and send the email. If you like the guard clause pattern, I have a nuget package you can use to easily add and extend them in a consistent fashion in your applications - look for the link in the show notes. Listener Jeremy C. writes: i discovered your podcast recently, and am going through it. I love the Guard class shortcut for happy path. What i noticed, is that this behavior relies exclusively on throwing exceptions rather than what I learned (20 years ago) in school that exceptions are for the unexpected, and if you can reliably prevent throwing an exception, like checking for a null and handling it, you should to avoid the execution cost of exception handling. Is my information just out-dated? :) Perhaps I'm too old of a coder and too many old habits are stuck. It's true that exceptions should not be used for control flow in your applications. That means if it's a normal condition for a function to get a null as an argument, perhaps because that situation means "create a new thing" instead of "do something with this thing", then you wouldn't want to write code that depended on an exception being thrown for its behavior. For example, you wouldn't want to have a try block that tried to work with the object, and then a catch block that caught the NullReferenceException when it was null and created a new instance there. There's plenty of reference material you can find about why this is considered a bad practice. In my opinion there are two main reasons. One is performance - exceptions are far more expensive than if statements so you shouldn't use them where an if statement is more appopriate. This is the main one, and because of it, writing code that leverages try-catch statements for something more than error handling is unexpected. Developers will be surprised to see this approach, which violates the Principle of Least Astonishment. You want readers of your code to be able to immediately understand what it's doing, and surprising them by doing things in odd ways is contrary to that goal. Coming back to guard clauses, the idea is that you're setting up an expectation that under all normal conditions in your application you expect that these arguments will follow certain constraints. If they don't, the program's simply not going to work the way it should. In this case, an exception is the appropriate response and is more elegant than any other solution like returning a boolean value or magic number or null and the caller having to know to check for that result. Thanks Jeremy for the great question! After I answered, he summed it up like this: So the Guard Clause is for the situation of, "I told you the expected inputs, and while I'll protect myself from bad data, I'm not going to make a huge mess of if statements to protect myself, I'll pass the mess back to the code giving me crap." Pretty much. Show Resources and Links devBetter Guard Clauses Principle of Least Astonishment

Why Immutability is Desirable This week's tip is on the topic of immutability, and why it's often considered a good thing for your data structures. I'll share my thoughts on the topic in a moment, but first a quick note from this week's sponsor. Sponsor - devBetter Group Career Coaching for Developers If you're not advancing as quickly in your career as you'd like, you may find value in joining a semi-formal career and technical coaching program like devBetter.com. I launched devBetter a few months ago and so far we have a small group of motivated developers meeting every week or two. I answer questions, review code, suggest areas in which to improve, and occasionally assign homework. Interested? Learn more at devBetter.com. Show Notes / Transcript Let's talk about immutability. This topic is on my mind because I just wrote an article about getting language support for immutability and, more broadly, DDD value objects, in C#. Value objects area DDD pattern, and one of their defining characteristics is that they're immutable. I keep using that word, so I should probably define it. An immutable data structure (an object in C#) is one that, once created, cannot have its state modified. I mention wanting language support for this feature in C# - that's not to imply that you can't create immutable objects today. It's just a lot of manual work, and easy to get wrong or screw up in the future because nothing enforces immutability at the class level. Typically in C# to create an immutable object you create a class with properties that lack setters, and then you assign values to these properties in the class constructor. Short of some reflection trickery, instances of this type cannot have their properties modified once they've been instantiated. Why might we want this? The biggest advantage I get from immutability in objects is knowledge that instances of these types are always in a valid state. That means any method using such types doesn't have to waste effort trying to verify they're in a valid state. Here's a common example. Imagine your system needs to work with date ranges that include a start and end date. You might have many methods that take in two DateTime types, and in these methods you always expect the end date to be later than the start date. So, being a good programmer, you write a guard clause to ensure start date precedes end date. This logic ends up scattered all over the place, and maybe sometimes you forget or don't bother with it, so not it's not even enforced consistently, allowing bugs to creep in. What if instead you created an immutable DateRange class, passed the start and end dates into its constructor, and ensured they were valid there? If not, you'd throw an appropriate exception. Now, any method that was accepting a start and end date can just take in a DateRange instead, shortening these methods' parameter lists. And they can remove all of their validation on start date and end date because that's now done in the DateRange class. Why can you trust that it was done? Because of immutability. If it was valid when it was created, it must still be valid now since it couldn't be changed in the meantime. Your validation logic only has to be performed in one place, and immutability gives you guarantees that it will be applied so you don't have to defensively code for it everywhere. Another advantage immutability offers is thread safety. You don't have to worry about race conditions or synchronization issues between different threads when they work with immutable objects. Why not? Simply because the objects can't change. Operating on immutable objects may produce new instances of objects, but this typically doesn't pose an issue for multi-threaded applications. The issue is more commonly something like an instance that two threads are referencing, and each thread tells the instance to increment a counter at the same time. The end result may be unexpected due to how the calculation may be completed. This is typically overcome through the use of locks, but you can pass around immutable objects between threads all you want and never have to worry about this issue. Have you ever passed an object to a method, and then found yourself surprised when the method modified the object? I generally dislike this kind of thing, and C# even has a new keyword in that will ensure this doesn't happen. I'll link to more on the in keyword in the show notes, but it has some restrictions and hasn't seen widespread adoption, yet. Another way to ensure that the state of an instance you pass to a method isn't modified within that method is to use an immutable object. This makes it much easier to reason about and debug your code, and can have performance benefits since objects that won't be modified can always be passed by reference, without copying them to the stack. Immutable types are much easier to test than other types, and for this as well as the above reasons using them appropriately can lead to better, more maintainable code. Eliminate the primitive obsession code smell, better encapsulate concepts that tie together several values, and force validation (and other business rules) to live with these values instead of in the types that use them. You should find over time that your domain model becomes much cleaner as a result. Show Resources and Links devBetter 5 Benefits of Immutable Objects Guard Clauses The C# in parameter modifier Refactoring and Code Smells

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 34, in which we'll talk about lazy loading in ASP.NET and ASP.NET Core apps, and why it's evil. If you’re enjoying these tips, please leave a comment or rating in your podcast app, tell a friend about the podcast, or follow us on twitter and retweet our episode announcements so we can increase our audience. I really appreciate it. Avoid Lazy Loading in ASP.NET (Core) Apps This week's tip is on the topic of lazy loading using Entity Framework or EF Core in ASP.NET and ASP.NET Core apps. Spoiler alert: don't do it. Keep listening to hear why. Sponsor - devBetter Group Career Coaching for Developers Last week I announced my new developer career coaching program, devBetter. If you're not advancing as quickly in your career as you'd like, and you could use someone in your corner pushing you to succeed and opening up doors to new opportunities, consider joining a handful of like-minded developers at devbetter.com. Show Notes / Transcript Lazy loading is a feature that EF6 has had for a long time and EF Core only recently added with version 2.1. The way it works is, entities are fetched without their related entities, and these related entities are loaded "just in time" as code references them. This seems to follow the best practice of deferred execution, but unfortunately the downsides far outweigh the benefits the vast majority of the time in this case. I recommend disabling lazy loading in all ASP.NET and ASP.NET Core apps. Let's look at why. On any given web request, the goal should be to return a response to the client as quickly as possible. The fewer out-of-process calls the request needs to make before it can return a response, the faster it will be, all things being equal. If a round-trip to the database takes 20ms and processing the request requires 10 database calls, then assuming they can't be made in parallel the minimum time for this is 200ms. If the same data could be fetched in a single round-trip to the database, it would cut page load time by 180ms, not counting the time to execute the queries themselves which might also be faster if done in one batch. When you use lazy loading, your code will make more calls to the database than if you had used eager loading. It's also deceptively easy to write code that will result in lazy loading being done within some kind of loop, resulting in dozens or hundreds of database calls. This can be difficult to detect in development and even in testing, but in production where usually there are more users and larger sets of data in use, the problem can have huge performance implications. I have a GitHub repo that demonstrates lazy loading using ASP.NET MVC 5 and EF 6 and also ASP.NET Core with EF Core. I encourage you to download it and run it yourself. It demonstrates the problem using a conference web site as its sample data. There are conference sessions. Each session has one or more speakers presenting it. Each session can have one or more tags. For sample data I have 2 sessions with 2 speakers and 3 tags total. Displaying the page shows each session and its speakers, tags, and description, all done with some simple razor code in the view. The initial query just pulls in the sessions - the speakers and tags are lazy loaded. How many queries do you think this page makes to the database? Let's think about how many it should make. Assuming the site's just loaded and has no cache in place, it should be able to load the data for this page using a single query. At worst a couple of queries. This kind of data is also highly cacheable, so after the first load the page should render with 0 queries. For this reason I like to say "caching hides many sins" because even if you do use lazy loading and have way too many queries, if you add caching it'll be the rare user who has to suffer for it. Coming back to the sample, with 2 sessions, 2 speakers, and 3 tags, the page makes 22 database queries to render the page using lazy loading. It should be clear that this number is going to grow rapidly as the number of sessions, speakers, and tags increases. Most conferences have more than 2 sessions, after all, but during development maybe only a couple are used and only one user is hitting the page, so the performance impact might not be felt until the worst possible time: the day of the conference. At which point it may be too late to fix and redeploy the code. Lazy loading is a tool that makes sense in certain situations. It's especially effective when the application and the database are colocated and there's just one user. If you're writing bookkeeping software that runs locally and communicates with a local database, it might make sense to use lazy loading as the user navigates around the system rather than trying to eager load all of the data. But in the context of processing a single web request, when every extra trip to the database slows the page down further, and where it can be easy to inadvertently add dozens or more requests, you should avoid it. Show Resources and Links devBetter Avoid Lazy Loading Entities in ASP.NET Apps Lazy Loading GitHub Sample How to Disable Lazy Loading in EF That’s it for this week. Thank you for subscribing to Weekly Dev Tips, and we’ll see you next week with another great developer tip.

Use the right object lifetime This week we talk about object lifetimes, why they matter, and how to choose the right one. We'll focus a little bit on Entity Framework since it's very popular and also very frequently misconfigured. Sponsor - devBetter Group Career Coaching for Developers This week I'm announcing my new developer career coaching program, devBetter. If you're not advancing as quickly in your career as you'd like, and you could use someone in your corner pushing you to succeed and opening up doors to new opportunities, check it out at devbetter.com. Show Notes / Transcript If you're not using dependency injection or following the dependency inversion principle in your code, you probably don't care much about object lifetimes. You can probably just instantiate new instances anywhere you need them and then let them be destroyed when they go out of scope. In this case, you probably have no use for an IoC or DI container. However, your code is probably also very tightly coupled, making it more difficult to test and reconfigure in the future. If it's working for you, keep at it, but if you're feeling pain from the coupling, I encourage you to check out my SOLID principles and Refactoring courses on Pluralsight to learn a different way to compose things. If you are using DI and containers, like most developers using ASP.NET Core where it's built-in, or even ASP.NET MVC, you've probably encountered the concept of object lifetimes before. There's some variety in the nomenclature for some of the options, but using the terminology of ASP.NET Core's container, there are three main kinds of object lifetimes: transient, scoped, and singleton. Let me cover these briefly and apologies if you're already well-versed in this topic. Transient scope refers to objects that are created any time they're requested. If you request an instance of a type from the container, and that type's scope is transient, you're getting a brand new instance. If you ask for a type and that type has a constructor parameter that's configured to be transient, that constructor parameter is going to be a brand new instance, every time. Scoped lifetime refers to objects that, once created, live on for the duration of a given HTTP request. If you ask the container for an instance multiple times within an HTTP request, you'll get the same instance every time. Regardless of where the request to the DI container comes from within the web request, the same object instance is returned from the DI container. The first call to get an instance of the type will get a new instance; every subsequent request for that type will get this same instance. Singleton scope is simple - there's only one instance. The first time an instance is requested, it's created, or you can create it during startup and add it to the container then. After that, the same instance is used everywhere. So, which one should you use? Well, naturally, it depends. Since we don't have a lot of time, let's just look at a couple of scenarios that involve Entity Framework or EF Core, which I'll refer to collectively as EF. EF should be set up with a scoped lifetime, so that within a given web request, exactly one instance of an EF DbContext is used. In ASP.NET Core when configuring EF Core, the helper methods take care of this for you, so you never have to make a decision about what lifetime to use. In EF 6, you had to figure it out yourself. And either way, if you're using the repository pattern, you have to make the right choice for your repository instances, too. It's important that the right choice is used for EF DbContexts, specifically because they track the entities they work with. As such, you can't have an entity that is tracked by multiple DbContext instances - that will cause an exception. You also typically don't want to share entity instances between requests - that can cause bugs when two requests are making changes to an entity they both think they have exclusive access to. So let's say you configure your repository instances to be transient. That means if you have two different classes within a request, like a controller and a service, that both need the same kind of repository, they'll each get a different, newly created instance. And assuming nothing else needs a DbContext, the first instance of the repository will get a new DbContext, and the second instance of the repository will reuse the same DbContext. There's probably no need to have two separate repository instances in this case, but there shouldn't be any bugs. Now let's say you configure your repository instances to behave as singletons. Consider the same scenario in which a given web request needs the repository first in a controller and later in a service. The very first request to the web server will result in a newly created repository instance (which will be reused) and a newly created dbcontext that's then passed to the controller. Then in that same request, when the service is created, it is passed this same repository instance, which still has the same DbContext associated with it. The request completes just fine. Now a subsequent request comes in. It will once again use the same repository instance, which still has a reference to the same DbContext. But that instance was scoped to a web request that has completed, so it's not going to work for this request. Or consider another scenario, in which two requests are occurring at the same time. Both will share the repository, and its dbcontext, so any entities created and tracked will be shared between the two requests. If one request makes a partial update, and the other request calls SaveChanges, the update will occur immediately, perhaps resulting in an error due to database constraints. This same thing can happen if you configure your dbcontext to be a singleton. So, in the case of EF DbContexts and Repositories, the key takeaway is that their lifetimes should match, and their lifetimes in web applications should be Scoped. For other kinds of services, especially other ORMs like NHibernate, it's important you understand exactly how these types should be configured when it comes to their object lifetimes for web scenarios. Show Resources and Links devBetter Dependency Injection Dependency Inversion Principle SOLID principles Refactoring

Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis. This is episode 32, in which we'll talk a little about money, salaries, and workplace taboos on sharing details about such things. If you’re enjoying these tips, please leave a comment or rating in your podcast app, tell a friend about the podcast, or follow us on twitter and retweet our episode announcements so we can increase our audience. I really appreciate it. How much do you make? This week we talk about money. Specifically, how do you feel about discussing your salary with your coworkers and peers? Why do you feel the way you do? Sponsor - Ardalis Services Does your development team need a force multiplier to level up their quality? Contact Ardalis Services to see how we can help. Show Notes / Transcript I suspect this episode will be both interesting and perhaps somewhat uncomfortable for many listeners. A lot of people have an innate aversion to discussing salary numbers, money, etc. Let's start by examining this, and then move on to look at ways you can maximize what you get in exchange for the value you provide to your employer or customer. Let's talk salary. I'll start, though since I've been self-employed for a while now, I'm going to cheat a bit and provide a quick story from early on in m career. When I got my first job in the late 90s, when the dot-com bubble was still expanding, I took an offer with a salary of $37,000. The consulting company I was working for was expanding rapidly. I was hired in August; another batch of new hires started in January. In speaking with them, I learned that they had been given offers of$42,000! I was understandably annoyed by this. Here I was, with six months' more experience and already providing value at a billable client and I was making 88% of what these new hires were making on day one. Let's stop here for a moment. What are you thinking as I relate this story? Did I break some unwritten rules by discussing salary with these new associates of mine? Was it my fault that I was annoyed by this perceived inequality? Maybe you're thinking, "Sure, you just demonstrated why it's a bad idea to talk salary with your coworkers, Steve. All it does is create bad blood and drama." If this is where you're coming from, I'm warning you now that I simply don't understand this position. I'll try to empathize, but at the end of the day I just don't get it, as will become clear in just a moment. If, after hearing the rest of the story, you want to help me understand why you still think keeping salary a secret is better for you, please leave me a note in the comments. So, why did I want to discuss salary with my coworkers? The answer is simple: I wanted data. I wanted intel. I wanted to be able to make informed decisions about my career. I had aggregate data at my fingertips in the form of annual surveys conducted by my school's career placement office, but I wanted to know what someone in the exact same position at the exact same company was making, and I was able to easily acquire this information by simply striking up a friendly conversation. Now, given this situation, what would you do? Regardless of whether you would ever actively inquire about salary, let's say your new team member volunteers their salary to you over lunch before you're able to stop them. The cat's out of the bag. You have the information. They're making a significant amount more than you, despite having less experience and having been hired into the same role. I imagine the following options are available: Do nothing. Forget about it. It's none of your business. Hold onto the information. Maybe consider it when you next get a pay raise or promotion, and use it to consider whether to ask for more. Start sending out resumes to other companies who might pay the same or more than what your company is now paying. If you get an offer, maybe your company will match it to keep you. Go to your manager and demand an increase. I'm probably leaving out some other options - feel free to add them in the show comments. Back to my story. After learning I was making $5k/year less than the batch of new hires, I went to my manager. I explained, respectfully, that I didn't think it was equitable for me to be making significantly less than the folks they'd just hired. My manager very quickly agreed to immediately adjust my salary to match, but asked me not to advertise that he was doing so to my coworkers. I agreed. In hindsight, perhaps I shouldn't have been so quick to agree to this, but at the time it seemed a small price to pay to get the immediate pay increase, and in any case it was just a verbal request, not a legal document I was asked to sign. So, who won and who lost in this story, if there were in fact any winners or losers? I'm happy with the outcome, since it meant I was able to keep up with the rapidly rising salaries of the time without having to change companies. I really liked where I worked and wasn't contemplating looking elsewhere. If I'd been ambivalent or hostile toward my current employer, I'd likely have taken a different approach. Did the new hires lose anything by sharing information with me? Not that I can tell. Some companies try to enact gag order policies that may go so far as to threaten employees with termination if they share compensation details, but most of these clauses are unenforceable in my experience. I am not a lawyer so do your own research before acting on this opinion, though. In any case, I wasn't asked how I knew what I knew, so no individual was called out as a result my acting on the information I acquired. That leaves my employer. They "lost" in that they now had to pay one more of their employees the same rate they were paying others in the same position. Their profit margin shrunk slightly. But they also won in that they retained a valuable employee who was almost always billing, even while the market grew even tighter for software developers. I stayed there for another 4 years because they continued to grow my compensation and I continued to enjoy working there. If after a year or two I'd found myself underpaid by 20% or more there, I'd very likely have jumped to another position, costing them a highly billable consultant which is how they earned all their revenue. Could this have gone badly? Perhaps. It's easy to say in hindsight that it was a good move, but what if instead of bumping my pay my manager had fired me for breaking the company's rules about discussing compensation (we didn't have any, but say we did). This was a risk, but I had risk tolerance and I felt the risk likelihood was small. I hadn't yet really expanded my lifestyle and expenses from that of a college student, Iso my expenses were small relative to my income, and I didn't yet have children. The market was also great, and I'm sure if I'd been let go I'd have gotten another offer within a few weeks. Like today in 2018, everybody seemed to be hiring. Would I have made the same choices if unemployment were high, layoffs were going on everywhere, and I didn't know how I'd make ends meet if I lost my job? Maybe not. But I'd still want as much accurate intel as I could get so that I could make the best decision for me given whatever the circumstances. Let's wrap up by considering who stands to gain from keeping salary details secret. For many listeners I suspect you can't imagine working somewhere that had transparent compensation details, but as a former Army officer I can tell you it's not a big deal. Everybody in the military, and in government service, knows exactly how much everybody else is making. You can check out the pay scale any time you want. It's not an issue. So, it shouldn't be assumed that secret compensation is somehow the only way to do things. It should by now be obvious that the ones who stand to gain the most from keeping salaries secret from one another are the company's owners. By paying different amounts for potentially the same work, they're able to increase profit margins. Pay differences can be warranted, and whether they are or not, they can seed discontent and hurt morale. Or they can empower employees to ask for what they think they're worth, as in my case, which can end up costing the company more in payroll. If companies pay different amounts to different individuals, and this is transparent, they need a way to justify this decision. This can require more communication. Just as it gives the employee more information and freedom to make decisions, it limits the company's freedom to negotiate from a position of having more information than the other party. In negotiations and economics in general, when one party has a better information than another, they can use this to their advantage and get themselves a better deal. By sharing information, employees aren't gaining an unfair advantage, they're merely eliminating an unfair advantage their employer previously held. Show Resources and Links What Color is Your Parachute (book) Great tips on job hunting and career - I read an earlier edition many years ago 2018 US Military Pay Scale

Breaking Bad Coding Habits This week guest Joe Zack talks about how to apply the power of habit to break bad coding habits. Joe is a software developer based in Central Florida. He is a host of the Coding Blocks podcast and is particularly excited about Search Engines and the JAMStack these days. Sponsor - Ardalis Services Does your development team need a force multiplier to level up their quality? Contact Ardalis Services to see how we can help. Show Notes / Transcript Hello my name is Joe Zack, and I’m a long time developer and podcaster over at Coding Blocks. I’m also a huge sucker for the Business-y PopSci Self-Help kind of books that you see on Top Seller lists. I like to take the lessons from those books and try apply them to my programming. One book I particularly enjoyed was "The Power of Habit" by Charles Duhigg, check the show notes for a link. This book describes the building of habits as the process of taking explicit procedural actions, and turning them into implicit declarative actions. And hey, that sounds kinda like programming to me! We programmers figure out precisely what operations need to occur to fulfill our requirements, and we write programs to automate those operations so that we can deal things at a higher level of abstraction. That enables us to combine and compose these programs to solve even bigger problems without getting tripped up on tiny little details. "The Power of Habit" book promises that building good habits is much like building a SOLID API. You spend the time up front building good habits, and then you get a multiple of that time back with reduced maintenance costs over time. But what if your API isn’t so SOLID? What if you’ve developed some bad habits that you would like to change? Well then, you’re in luck - because the book spends a lot of time looking at how habits can be changed and I’m here to share some of that with you. An example of a bad programming habit that I have is only considering the "happy path” operations that need to happen to meet a requirement. I tend to focus too much on how to make something work, and not enough on how to handle problems that might arise in the real-world. In writing about changing habits, author Charles Duhigg encourages me to determine the cue, routine, reward, and craving in this bad habit. If I can determine those 4 aspects of the habit, then I can figure out how best to change it. In this example, I can look back and see that my undesirable behavior most often occurs when I’m estimating tickets, so that is my “cue”. The “routine” is my act of imagining the work that needs to happen to fulfill the requirements of the ticket and then estimating how long that will take. My “reward” is that I can get back to programming, which is an activity that I enjoy a lot more than estimating. In fact, the consequences for my bad estimates are typically deferred until I actually start working on those tickets. The final aspect of a habit is the “craving”. This is the anticipation of the reward. Knowing that I can get back to “real work” once I complete my estimates provides an incentive for working quickly, rather than accurately. According to the book, the trick to changing habits is to recognize the cue, craving and reward - and to replace the routine. In my example, a good tactic would be to replace my current imaginative process with a more disciplined approach. Perhaps adding together a separate estimate for the happy path and one for dealing with exceptions would encourage me to look at the bigger picture and would lead to a more accurate result. I’m going to give this a shot, and see how it goes. In the meantime I hope that you take a moment to consider how healthy your programming habits are. If there are any habits that you are unhappy with, then remember that you can change them by recognizing the cue, craving and reward - and changing the routine that you perform in response to those stimuli. Keep doing the right thing, and eventually you’ll codify that habit into your mental muscle memory so that the good behaviors flow without you having to think explicitly about it and you can operate efficiently at a higher level of abstraction. Thanks for having me on the show Steve! Show Resources and Links The Power of Habit: Why We Do What We Do in Life and Business On Audible Power of Habit Summary

I've talked quite a bit about code smells over the course of my career. My Refactoring Fundamentals and Azure Refactoring courses on Pluralsight both discuss the topic, with the former going into great depth and covering literally dozens of code smells. The course is over 8 hours long, but it not only demonstrates tons of code smells but also shows how to refactor to improve your code in response to them. It's important to note that code smells represent things in your code that are potentially bad. They should catch your attention, and you should think about whether, in context, the smell in question is acceptable or not. Sometimes, it's perfectly fine, or it's not worth the effort to refactor to a different design. If you've never heard of the term code smell, I encourage you to look into it. There are some links in the show notes for this episode. One benefit of learning about code smells mirrors a benefit of learning about design patterns, which is that these named smells allow you to identify and communicate concepts quickly with other developers. For example, if you're discussing some code and mention it seems to have 'primitive obsession', that term refers to a specific code smell which is well-documented and which has certain known refactoring approaches. By using this term, you convey a lot of information in just two words that otherwise might have required a great deal more explanation. It can be useful as well to learn about different categories of code smells. These categories include things like Bloaters, Obfuscators, and Couplers, as well as smells specific to kinds of code, like testing smells. These categories help as you're learning about code smells because they let you see a variety of smells that all have similar impacts on the code. Bloaters tend to result in code becoming larger than necessary. Couplers introduce unnecessary coupling into the application. Obfuscators make it more difficult to quickly understand how some part of your application works. And test smells make tests more difficult to write and maintain, or less reliable when run. Some code smells you can identify with static code analysis tools, like NDepend. For instance, you can easily write a query in NDepend to return all methods over a certain number of lines of code. These kinds of tools can help you identify potential problem areas in your code so you can better direct your refactoring efforts. I may dive into some different code smells, and how to correct them, in future tips. In the meantime, if you want to get up to speed the best resource I can recommend is my Refactoring Fundamentals course, on Pluralsight. Show Resources and Links Refactoring Fundamentals Azure Developer: Refactoring Code Code Smells Refactoring Book (classic 1999) Refactoring Book (2nd Ed.) (Available 31 Dec 2018)

Shared Kernel as a Package Code shared between applications within an organization is typically referred to as a shared kernel in domain-driven design. This week's tip discusses this approach and how best to do the sharing. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript If you've written more than one application, or worked for a company that has more than one, you've probably shared code between the applications. There are a variety of approaches to this, one of the most awful being the One Solution To Rule Them All approach, in which every bit of code ever written is added to a single code repository and a single solution file. One or more projects in this solution become the shared projects used by many different applications. The benefit of this approach is that developers can easily view and even debug all of the code possibly used by anything. Changes that might break dependent projects are often discovered quickly. However, if a single project requires an update to shared code, it's not easy to have one project depend on a different version of the shared library than another. Even if you use more than one solution, if you're sharing code between multiple solutions at the file system level, you're probably in this boat. In Domain-Driven Design, the Shared Kernel is code that more than one bounded context depends on. The contract between the shared kernel code and its dependents is that the shared kernel code doesn't change unless all downstream dependencies agree with the change. Often it's one team maintaining the shared kernel and its dependent projects, in which case this is pretty easy, but in larger organizations there may be an approval process involving several teams. When updates do occur, they should be decoupled from dependencies such that they can pull in the update when they're ready. This enables updating the shared kernel code without having to test and update every downstream dependency immediately. In .NET, one way to gain the ability to have dependent projects pull in the latest updates to the shared kernel whenever they're ready is to use a Nuget package. Any time an update is made to the shared kernel, its package should be updated and its version updated. For example, you might initially have Acme.SharedKernel version 1.0.0, which two projects reference. Project A needs additional functionality, and it's agreed to place it in the shared kernel. A new package is published, with version 1.0.1. Project A updates its version of the package to require 1.0.1 and is able to be deployed. Project B continues to depend on version 1.0.0 and can continue with development and/or remain deployed using this version. Project B can choose when and how often to update which version of the shared kernel package it uses. If you follow this approach, there are a few things that you may find helpful. First, use continuous integration for your shared kernel library. When you make updates to it, the automated build should compile it, run tests (yes, it should have tests), update its version number, and publish it. This ensures you have a consistent process, which is important especially when we're talking about deploying versioned packages. Next, you'll want to have a way to share the package between your developers and build machines. One nice thing about Nuget is that any file share can serve as a Nuget server, so at a minimum you can simply drop versioned nupkg files into a particular file share. Alternately, you can use an actual Nuget server, such as one built into Jetbrains TeamCity or VSTS/Azure DevOps. You can use a cloud-based solution like myget, if you prefer. In any case, you simply need a way to distibute your shared, versioned packages. With these fairly small pieces in place, you should find that you're able to decoupled your shared kernel package from its dependents such that you can make updates to it as required and pull in those updates only as needed by each dependency. You should also find that, being a separate solution with a separate automated build, it's less likely that developers will make cavalier changes to the shared kernel, so it should become more stable by default and should only be updated when truly needed by its downstream dependencies. And of course, you should do whatever you can to minimize the things your shared kernel code depends on, since it's going to be depended on by most of your applications. Keep it lightweight and don't depend on anything from it that you can avoid. Show Resources and Links Domain-Driven Design

Applying Pain Driven Development to Patterns This week we talk about specific ways you can apply my strategy of Pain Driven Development to the use of design patterns. This is an excerpt from my Design Pattern Mastery presentation that goes into more detail on design patterns. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript I talked about Pain Driven Development, or PDD, in episode 10 - check out that episode first if you're not familiar with the practice. I've recently been focusing a bit on some design patterns. An easy trap to fall into with design patterns is trying to apply them too frequently or too soon. PDD suggests waiting to experience pain while trying to work with the application's current design before you attempt to refactor to improve its design by applying a design pattern. In this tip, I'll walk through a few common steps where applying a specific pattern may be helpful. To begin, let's assume we have a very simple web application. Let's say it's using MVC, and there's a controller that needs to be used to return some data fetched from a database. It could be an API endpoint or a view-based page - the UI format isn't important in this case. The absolute simplest thing you can do in this situation is hard code your data access code into your controller. So, assuming you're using ASP.NET Core and Entity Framework Core, you could instantiate an DbContext in the controller and use that to fetch the data. This works and meets the immediate requirement, so you ship this version. A little bit later, your application has grown more complex. You have some filters that also use data, along with other services. You start to notice occasional bugs from EF and realize that you've introduced a bug. By instantiating a new DbContext in each controller, but occasionally passing around entities between parts of the application, EF gets in a state where entities are tracked by one instance but you're trying to operate on them with another instance of DbContext. You need to use a single EF Core DbContext per web request, which is to say it should have a "Scoped" lifetime. Fortunately, ASP.NET Core makes it very easy to achieve this by configuring your DbContext inside of ConfigureServices. In fact, if you don't read the docs, you probably don't even know what lifetime EF Core is using, because it's hidden within an extension method. In any case, once you configure DbContext in ConfigureServices, you need a way to get it into your Controller(s). To do this requires the Strategy pattern, covered in episode 19. If you're familiar with dependency injection, you've used the Strategy pattern. Add a constructor to your Controller, pass in the DbContext, and set a private local field with the value passed into the constructor. Do this anywhere you're otherwise newing up the DbContext. Remind yourself 'new is glue'. You just fixed an issue with too tight of coupling to the instantiation process by using the service collection built into ASP.NET Core, an IOC container, essentially a factory on steroids. Your EF Core lifetime bug is now fixed, so you ship the code. Some more time passes, the application has grown, and now there are a bunch of controllers and other places that all have DbContext injected into them. You've noticed some duplication in how code works with the DbContext. You've also found that it's tough to unit test your classes that have a real DbContext injected, except by configuring EF Core to use its In Memory data store. This works, but you'd prefer it if your unit tests truly had no dependencies so you could just test behavior, not low-level data access libraries. You decide that you can solve both of these problems by introducing the Repository pattern, which is just a fancy name for an abstraction used to encapsulate the low level details of your data access. You create a few such interfaces, implement them with DbContext, and make sure your Controllers and other classes that were directly using DbContext now have an interface injected instead. Along the way you fix a couple of bugs you discovered that had grown due to duplicate code that had evolved differently, but which should have remained consistent. When you're done, the only types that know about DbContext directly are your concrete Repository implementations. Your application is growing more popular now, and some of the pages are really hammering the database. Their data doesn't change very often, so you decide to add some caching. Initially you start putting the caching logic directly in your data access code in your repository implementations that use EF Core, but you quickly find that there is a lot of duplication and your once-simple repositories are now growing cluttered with a lot of caching logic. What's more changing the details of what is cached how is requiring you to touch and re-touch the repository types again and again. Your current approach is obviously violating both the Single Responsibility and Open-Closed principles, two of the SOLID principles. You recognize that you can apply the Decorator (or Proxy) pattern by moving the caching logic into a CachedRepository type, which you can choose when and where to use on a per-entity basis simply by adjusting the type mapping in your application's ConfigureServices method. With this in place, you're able to quickly apply caching where appropriate, and ship a better performing version of your application. Over time, as you built out your repositories, you kept basic methods for creating, reading, updating, and deleting entities in one place. Maybe you implemented a generic repository, or used a base class. You were careful not to expose IQueryable interfaces from your Repositories, so their query details didn't leak throughout your application. However, to support many different kinds of queries, with different filters and including different amounts of data from related types, you found that you needed to add many additional methods and overloads. In addition to a simple List method on your Order repository, you needed ListByCustomer, ListByProduct, ListByCompany, not to mention ListWithOrderDetails and other variations. Some of your repositories were growing quite large, and included quite a bit of complex query logic, which wasn't always easy to reuse even between methods in the same repository. To address this pain, you applied the Specification pattern, which treats each unique query as its own type. Using this approach, you were able to create specifications like OrdersByCustomer, OrdersByProduct, and OrdersByCompany which included the appropriate OrderDetails if desired, or included an option to specify whether to include it. Your Repository implementations dropped down to just simple CRUD methods, with the List method now taking in a Specification as a parameter. Hopefully this helps you see how you can recognize a certain kind of pain, and respond to that pain by refactoring to use a specific design pattern. If you keep your code clean and simple, it's fairly easy to do this kind of refactoring as you need it, so there's no need to try and use every pattern you know speculatively as you begin a project. Show Resources and Links Design Pattern Library Refactoring Fundamentals Pain Driven Development SOLID Principles

How Do You Even Know This Crap? This week we have a special guest offering a dev tip - please welcome Scott Hanselman who blogs at Hanselman.com and has a great long-running podcast, Hanselminutes. Scott's going to share with us some tips on how you can leverage your experience to know when a problem you're facing should already have a solution somewhere. Here's Scott. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript You can view Scott's article on this topic called How Do You Even Know This Crap on his site. Show Resources and Links How Do You Even Know This Crap Scott's Blog Hanselminutes Podcast

Layering Patterns on Repositories This week we're sticking to the patterns and repositories theme. I started down the design patterns path with Episode 17 so start at least from there if you want to listen to the sequence more-or-less in order. In this episode, we'll look at some combinations with other patterns that make using the Repository pattern even more attractive. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Last week I mentioned how the Repository pattern works well with the Strategy pattern, so that you can use dependency injection with it. This is the first of many ways in which you can combine Repository with other patterns, and is probably the most powerful of them all (though probably taken for granted by many). I described the strategy pattern in episode 19. Let's look at two other patterns now that we can combine with Repository. First, let's talk about a common pain point with repositories: custom queries. I talked about the need to encapsulate query logic so it doesn't leak out of your repository in episode 18. However, I saved a powerful technique for doing so until this tip. (Sorry, there's only so much I can put into each of these and keep them short.) If you follow my earlier advice and you don't leak query logic outside of your repositories, it's likely your repository implementations have a bunch of custom query methods. Maybe you have standard GetById and List methods, but then you also have ListByState, ListByModel, ListByOwner, etc. Maybe you have methods that correlate directly to business use cases or even UI concerns, like ListPremiumCustomers or ListForSearchScreen. The point is, you may find yourself with the code smell of too many one-off custom query methods on your repositories. This is pretty common, and the worse it gets the more cumbsersome it becomes to work with the repositories. The solution to this problem is to introduce another pattern. The Specification pattern is designed to encapsulate a query within an object. I mentioned it briefly in episode 24. It's especially useful when you're using an ORM tool like EF or EF Core because not only can you encapsulate filter expressions, but you can also specify which properties to eager load. Thus, you can create a specification for a shopping basket type that might be called BasketWithItemsByCustomerId or something similar. A typical specification I use will include the filter expression (to be used with a Where LINQ expression) and will let me specify which properties and subproperties I want the query to return with it. What are the benefits of using this pattern? First, you eliminate duplication of query logic if you were previously letting client code create queries on the fly. Second, you establish a library of known queries that your development team can review, reuse, and discuss. These should be organized so they're extremely discoverable so there's minimal need to try and reinvent the wheel when someone needs a particular query that already exists. They also help clean up your repositories, eliminating most of the scenarios where you would need non-generic repository methods, and thus dramatically reducing how many repository implementations you need to write and maintain. Your repository code will better follow the Single Responsibility Principle and the Open/Closed Principle, and you won't need a bunch of custom IWhateverRepository interfaces. Finally, you can easily unit test your specifications' filter logic to ensure it's correct and provide examples for the team. Another useful pattern you can use with repository is the proxy or decorator pattern to add caching. I call this the CachedRepository pattern and I've written a number of articles about it. I mention both patterns because they're functionally the same, but differ based on intent. A proxy controls access to something. A decorator adds behavior to something. A CachedRepository controls access to the real, underlying repository, exposing it only when the result isn't in the cache. In this way, it's a proxy. But it also is responsible for adding caching behavior to any repository. In this way, it's a decorator. Either way, it's an extremely useful pattern. Most applications make a lot of queries to their database for results that don't change frequently. A lot of applications use a database to define some or all of their navigation, or the contents of common dropdownlists on forms. These and other common results are great candidates for caching, but often this behavior isn't added because of the work and complexity involved. Adding caching to a method in a data access repository isn't ideal, since it couples two unrelated concerns and breaks the single responsibility principle. It's also not very reusable. A better approach is to create a generic CachedRepository that can be used for any type that would benefit from caching. Determining whether or not to use this caching functionality can be controlled centrally for the application wherever its services are configured. Circling back around to the specification pattern, you can combine it with the CachedRepository to help with key generation. Every cache entry needs to have a unique key, and you need to take care when constructing keys that you take into account any variables or parameters that were used for a particular query. Your specification objects know exactly which parameters they require, and can easily expose a cache key property that can be used by your CachedRepository. You can also add a property to toggle whether certain specifications should be cached at all, if that's helpful. If you'd like to see what this looks like in a simple sample application, check out the eShopOnWeb sample on GitHub. I have a link in the show notes. There's also a free 110-page eBook that goes along with the sample that I encourage you to check out. I developed both the book and the sample for Microsoft as a free resource and they're both up-to-date with .NET Core 2.1 as of July 2018. Do you think your team or application could be improved by better use of design patterns? I offer remote and onsite workshops guaranteed to improve your coding skills and application code quality. Contact me at ardalis.com and let's see how I can help. Show Resources and Links Repository Pattern SOLID Principles Specification Pattern Building a CachedRepository in ASP.NET Core Introducing the CachedRepository Pattern Building a CachedRepository via Strategy Pattern

What good is a repository? This week I'm following up on last week's tip about the Repository pattern. A listener pointed out to me that I never directly answered the question posed in the last episode of "Do I need a repository?" I'll be sure to do so here. Sponsor - DevIQ Thanks to DevIQ for sponsoring this episode! Check out their list of available courses and how-to videos. Show Notes / Transcript Last episode I addressed a fairly common online argument against the use of repositories. I suggest you listen to that episode and then jump back into this one, but hey, you do what you want. I addressed the usual arguments against using a repository by using a particular article as an example, but I want to be clear that that article was by no means the direct cause of my response. In fact, I hadn't even seen that particular article until I sat down to record the episode and it happened to be pretty high up in my search results and made a good example of the kinds of arguments folks like to throw out when arguing against the pattern. So, now that we've heard and perhaps refuted some of the arguments against using the repository pattern, let's talk about why you might use it. What good is a Repository in your application? The Repository pattern is simply an abstraction of your persistence strategy for your application. In fact, the repository pattern is most frequently used along with the strategy design pattern as a way to pull low level knowledge of persistence details out of your application's other classes. I've heard the repository pattern also described as an example of the facade design pattern, since it hides away much of the detail of this or that persistence technology and exposes a much simpler interface for getting and storing entities. I can get behind that definition, too. You can think of the repository pattern as essentially a particular use case of the facade pattern in which the complex underlying implementation is related to persistence. There's one more pattern we can consider in relation to the repository, though, and that's the adapter. The main difference between a facade and an adapter is in the intent. A facade's intent is to simplify, while an adapter's intent is to allow multiple implementations to be accessed through a common interface. A repository typically does both of these things, providing a simple interface that hides unneeded complexity and allows multiple implementations, like relational, non-relational, in-memory, or even file- or API-based approaches. So, the repository pattern is all about providing an intention-revealing name to a facade or adapter that can be used as a strategy to reduce coupling in your application. Let's drill into these other patterns a little more. The strategy pattern lets you change how a class does something without having to change the class itself. If you're familiar with dependency injection, you already know this pattern. It works by passing in as a parameter a particular implementation to be used, allowing this implementation to vary without the class that uses it having to change. It's one of the most powerful design patterns for writing loosely-coupled code that follows the SOLID principles. It's very challenging to write unit-testable code in strongly typed languages without using this pattern. The facade pattern is helpful when you want to make a complex API easier to use. This might be because the complexity is unnecessary, or because there are certain "right ways" to do things in your particular application and you want to make it easier for your team to follow the right path and avoid the wrong ones. Creating a facade to expose simple persistence operations like creating, updating, and deleting records, as well as some mechanism for fetching and querying, is a pretty common technique and can allow teams to focus on business logic moreso than data access logic in many cases. That said, keep in mind that the facade can hide useful features and sometimes necessary complexity that client software should otherwise be able to access. Care must be taken in how the facade is designed to ensure it doesn't cripple the use of the libraries it wraps. The adapter pattern is helpful for testing, since it allows tests to easily substitute in implementations that behave however the particular test requires. Using adapters can also allow an application to work more flexibly with different actual providers, plugging in the appropriate one as necessary. You can see that the Repository pattern is really a particular implementation of one or more other, more generic patterns. Next week I'll talk a little bit more about the pattern, and how it can be further extended by layering additional patterns on top of it. Let's wrap up this episode by answering an important question. Do I need a repository? No, you don't need a repository. However, if any of the benefits I've described in the last two episodes sounds like something you might want in your application, you might consider it. If you want unit testability, an abstraction over data access will save you a lot of pain. If you want flexible, modular code, the same is true. If you want low-level access to all the features of your data access technology everywhere you use it, then you might not want an abstraction over it. If your application isn't set up to make use of dependency injection, it may not be worthwhile, since newing up repositories everywhere you need them will still tightly couple you to implementation details. Do you think your team or application could be improved by better use of design patterns? I offer remote and onsite workshops guaranteed to improve your coding skills and application code quality. Contact me at ardalis.com and let's see how I can help. Show Resources and Links Repository Pattern SOLID Principles New is Glue (why you don't want to new up repositories everywhere - seel also Ep 5)