This is episode 44 with some guest tips on working from home that I hope you'll find useful.
Weekly Dev Tips offers a variety of technical and career tips for software developers. Each tip is quick and to the point, describing a problem and one or more ways to solve that problem. I don't expect every tip to be useful to every developer, but I hope you'll find enough of them valuable to make listening worth your time.
Hosted by experienced software architect, trainer, and entrepreneur Steve Smith, also known online as @ardalis. If you find these useful, you may also want to get a free software development tip delivered to your inbox every Wednesday from ardalis.com/tips.
This is episode 44 with some guest tips on working from home that I hope you'll find useful.
This is episode 43, with a quick story about dependency injection.
This is episode 42 - the answer to life, the universe, and everything - with some guest tips on learning TDD and Lisp.
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.
"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.
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.
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.
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.
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.
This week's tip is on the topic of immutability, and why it's often considered a good thing for your data structures.
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.
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.
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?
This week guest Joe Zack talks about how to apply the power of habit to break bad coding habits.
Code Smells, or bad smells in code, are discussed in the book, Refactoring. Martin Fowler and Kent Beck discuss them and how they can be used to identify potential places to refactor in your code.
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.
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.
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.
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.
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.
This week we'll answer this extremely common question about the Repository pattern, and when you should think about using it.
The previous tip talked about domain events that fire before persistence. This week we'll look at another kind of domain event that should typically only fire after persistence.
Domain Events are a DDD design pattern that in my experience can really improve the design of complex applications. In this episode I describe specifically how you would benefit from raising and handling these events prior to persisting the state of your entities.
This week I'm taking a break from design patterns to talk about a useful skill to prevent you and your team having to reinvent the wheel when it comes to troubleshooting problems or working through new tools or frameworks.
Working at too low of an abstraction level is a common source of duplication and technical debt. A very common culprit in this area is authorization.
The Strategy design pattern is one of the most fundamental and commonly-used patterns in modern object-oriented design. Take some time to make sure you're proficient with it.
The Repository design pattern is one of the most popular patterns in .NET development today. However, depending on its specific implementation, its benefits to the system's design may vary. One thing to watch out for is query logic leaking out of the repository implementation.
Design Patterns offer well-known, proven approaches to common problems or situations in software application development. Having a broad knowledge of the existence of patterns, and at least a few you're proficient in, can dramatically improve your productivity.
It's difficult to differentiate yourself if you don't have a single area of expertise. Either you'll have difficulty landing work or you'll be forced to compete with a host of other non-specialists on rate. By becoming a T-shaped developer, you can market yourself as an expert in a particular area and stand out from the crowd!
Many developers work in legacy codebases, which are notoriously difficult to test and maintain in many cases. One way you can address these issues is by trying to maximize the use of new, better designed constructs in the code you add to the system.
Enumerations are a very primitive type that are frequently overused. In many scenarios, actual objects are a better choice.
It's highly unlikely that you're a software developer who works in a vacuum. Here are a few tips for showing your gratitude to the people, companies, products, and tools that help you to be successful.
Primitive Obsession describes code in which the design relies too heavily on primitive types, rather than solution-specific abstractions. It often results in more verbose code with more duplication of logic, since logic cannot be embedded with the primitive types used.
Encapsulation is a key aspect of object-oriented programming and software engineering. Unfortunately, many systems fail to properly encapsulate collection properties, resulting in reduced quality.
Many of you have probably heard of various "DD" approaches to writing software. There's TDD, or Test Driven Development. There's BDD, for Behavior Driven Development. In this tip, I want to introduce you to another one, PDD: Pain Driven Development.
One classification of objects in many applications is the Data Transfer Object, or DTO. Here are some more tips that may help you avoid problems when using these objects.
One classification of objects in many applications is the Data Transfer Object, or DTO. Here are some tips that may help you avoid problems when using these objects.
Low level built-in exception types offer little context and are much harder to diagnose than custom exceptions that can use the language of the model or application.
Don't fall into the premature optimization trap. Follow this sequence when developing new features.
Be wary of the 'new' keyword in your code, and recognize the decision you're making by using it.
Your methods should fail fast, if doing so can short-circuit their execution. Guard clauses are a programming technique that enables this behavior, resulting in smaller, simpler functions.
If you can do it without getting left behind, listen or watch educational content at a higher speed.
As a developer, you should be using source control. You should probably be using distributed source control. And you should check in, probably more often than you think.
What is this podcast about, who is it for, and how can you participate in it?