DEV Community: Steve Smith

2019 Year in Review

Steve Smith — Tue, 14 Jan 2020 15:43:26 +0000

Yes, it’s that time again. Time for another recap of what happened last year. If you’re reading this, and you’re not me, you probably are mostly interested in the most popular articles from last year, in case you missed something others found interesting. So, I’ll start with those. If you’re looking for other years in review, or want a checklist to help with writing your own year in review article, here are a few links:

Blogging

Last year I only added 41 posts to my blog. My high for a month was 6. The total is actually up from 37 in 2018, but it’s still less than one per week.

New Articles per Month in 2019.

In terms of traffic, Google Analytics reported that I had 769,979 page views, and that’s with missing about a week in January. In 2018 I had 708,260, so that represents about a 9% growth rate. Not amazing, but at least it grew. You can see there were a few weeks with big spikes from articles that were pretty popular.

Which brings me to articles. Google Analytics is great for identifying one’s most popular content. Often it’s not what you might think, expect, or hope for, though. For example, I mostly focus on code quality topics, domain-driven design, object-oriented principles, testing, etc. My top posts… don’t always reflect that though:

Force Nuget to Reinstall Packages Without Updating (53k impressions)
Using MediaR in ASP.NET Core Apps (30k impressions)
How to Find All Objects in SQL Server Schema (23k impressions)
Why Delete Old Git Branches (22k impressions)
SQL Server Error User Group or Role Already Exists (21k impressions)
Add Images Easily to GitHub (20k impressions)
The More You Know The More You Realize You Don’t Know (15k impressions)
Git Graph Visualizes Branches in VS Code for Free (14k impressions)
Enum Alternatives in C# (14k impressions)
How to Add Nuget Packages Using dotnet add (14k impressions)

At least my one Excel tip on How to Display a Plus Sign If the Value of a Cell is Positive is no longer in my top 10 (it’s #12 with 12k impressions).

Currently I have 1502 blog posts on this site.

Goal for 2020: One Million Page Views

Probably a stretch goal to get 33% more page views (since last year I only got about 10% growth) but goals should be exciting when achieved and hoping for another modest 10% doesn’t excite me. I’d like to publish at least 52 posts in 2020 (about 25% more than I did in 2019) and if I can push that a bit higher that should help me with the overall traffic goal. Note that most of my most popular posts weren’t even published in the last year so the real trick isn’t quantity but quality. I need to publish the right posts.

Another strategy I’m just starting is reposting on the DEV community. I’ve only just started this so it’s too early to say if it will have much of an impact on my site traffic or other metrics. If you’re there, be sure to follow me and I’ll most likely follow you back.

Weekly Dev Tips Podcast Stats

Some of you may know I have a podcast, Weekly Dev Tips (which is the same name as my emailed newsletter that goes out every Wednesday). I don’t necessarily keep up with the “weekly” in the name… In 2019 I published 23 episodes (so, not quite enough to call it biweekly…).

Podcast downloads in 2019

My podcast had 146k downloads in 2019. You can see from the chart above when I released new episodes. Here are the top shows (all time downloads):

Domain Events – Before Persistence (6,907)
Do I Need a Repository? (6,300)
What Good is a Repository? (6,039)
On Learning TDD and LISP with Uncle Bob Martin (6,021)
Layering Patterns on Repositories (5,437)
On Design Patterns (5,334)
Maintain Legacy Code with New Code (5,300)
Breaking Bad Coding Habits with Joe Zack (5,169)
How much do you make?(5,070)
How Do You Even Know This Crap? (5,059)

Seems my tips on design patterns like domain events and repositories are among the most popular. Maybe that means I should record more tips on these, but I don’t want to read too much into it. Mostly I just need to get more consistent about publishing these shows. I got busy toward the end of last year and now it’s been almost 3 months since I published a new episode. I have a few in the queue so hopefully we’ll get them going again soon (I need to finish this blog post, first…). My goal for 2020 will be to publish 52 tips, even if they’re not actually every week (since that ship has already left the harbor).

Weekly Dev Tips Mailing List

This one I don’t miss. I sent a new tip out ever Wednesday in, just like I did in 2018 and 2017. I’m currently on a 195 week streak and I hope to keep that up through 2020. Currently I have 2,917 subscribers. You can sign up here, if you’re interested.

In terms of goals, I want to make sure I have something helpful to send every week. If I can meet my blog and podcast goals, then it makes it much easier to have something ready for the email. I’d also like the list to continue to grow, of course. If I can grow it to 4,000 subscribers, which seems pretty modest, that should help with my goal of getting 33% more page views for the blog.

Social Media Stats

It can be difficult to get this information after the fact, so here are my stats for various social media things as of January 2020.

Twitter.com/ardalis: 13,135 followers. 37.7k tweets sent.
YouTube.com/ardalis: 628 subscribers. 46 videos. 14,917 views.
YouTube.com/weeklydevtips: 251 subs; 13 videos. 1,307 views.
Twitch.tv/ardalis: 777 followers; 0 subscribers; 5,201 views.
GitHub.com/ardalis: 1.6k followers; 163 repositories.
- CleanArchitecture repo: 3.6k stars; 715 forks
- 1,111 contributions in last year (everywhere)
Instagram.com/ardalis_steve: 60 posts; 171 followers.

Publications

In 2019, I published the following books and courses:

Architecting Cloud-Native .NET Apps for Azure

I also updated my architecture eBook for .NET Core 3.1.

Architecting Modern Web Applications with ASP.NET Core and Microsoft Azure

My Pluralsight Courses (2019) (View All)

Note that these are both updates of existing, more comprehensive courses. You may find value in watching the originals as well, which have additional content:

Speaking

Last year I spoke at the following 5 conferences:

Stir Trek (April 2019)
DevIntersection (June 2019)
dotnetconf (September 2019)
DogFoodCon (October 2019)
DevIntersection (November 2019)

In 2018 I traveled and spoke quite a bit more (11 events) and in 2019 I decided to slow it down a bit. For 2019 so far things are looking to be busier again, but we’ll see how things play out. So far I’ve already spoken at Codemash and I’ll be at NDC London at the end of January.

My talks and workshops have mostly focused on domain driven design, clean architecture, cloud design patterns, and ASP.NET Core.

Travel

Since I cut back on my speaking gigs I didn’t travel as much in 2019 as I have in other years. Two new places I visited were MIT with my daughter for a college visit and Hawaii with my family.

Steve at MIT

In Hawaii we stayed on Oahu and visited Pearl Harbor, hiked Diamond Head, visited the Dole plantation, and hung out at Disney’s Aulani resort. It was certainly a beautiful place to visit.

Sunset from Aulani

I also got another email from Fitbit telling me my stats for the year. My one device died and it took a while before I opted to get a new one, so there was some missed time.

For 2019:

Best day was 25,708 steps. That’s pretty low, really.
2,370,187 total steps
75 Average Sleep Score (new with new Fitbit HR device)

Work Environment and Gear

I try to keep my current list of gear and tools used up to date. In 2019 I did choose to upgrade a lot of my hardware that was getting really up there in age. I don’t think I’ll be getting any new laptops or desktops in the next year or two as a result. My desktop configuration is still this one. I’ll try to write a quick post about my Dell XPS laptop I got last month some time soon.

I did move my office at the end of last year. I’m pretty happy with how it turned out in terms of recording and streaming. I now have a green screen wall that works pretty well (I need to get a little better lighting but it’s 95% good as is). I also put in some matching sound panels. The treadmill desk still gets a lot of steps every day, though at this moment I’ve got my chair on it.

My office set up in January 2020.

(this is getting rather long – is anyone still reading?)

In terms of gear a couple other things I got this year that I’m happy with are a Stream Deck, which I talked about here, and a Tesla Model X. I’ve wanted a Tesla for a very long time and the incentives, timing, and cash flow finally aligned to let me do it. I’ve been very pleased with the car, and its over the air updates have improved it over time (unlike every other car I’ve owned that has only degraded with time). I haven’t missed gas stations, the car is super fun, and it just charges in my garage. It’s been fine for relatively short road trips (3-4 hours away), but for family vacations we’ll stick with the minivan.

Work Stuff

My wife Michelle and I run a bunch of businesses together. Too many, in fact. In 2019 we were able to wind one down, which was a good thing. Our main revenue-producing business is software training, mentoring, and consulting, and we hired our second employee in 2019. Things are going well and we’re looking to probably hire another 1-2 senior people in 2020 assuming things keep going well.

That’s It

Thanks for reading this far. Like I said, this is mostly so I can look back years later and see where things were at this point in time. Hopefully if you’re not me doing that you found some useful tidbits here. If you want to write your own year in review blog post, I wrote a checklist here that is probably longer than most people will want but you can just pick and choose what works for you.

Good luck in 2020 and beyond!

The post 2019 Year in Review appeared first on ardalis.

Year in Review Post Checklist

Steve Smith — Mon, 06 Jan 2020 19:33:00 +0000

You have a blog. It’s early January. You need something to post. Why not post a [Current Year – 1] in Review post? Something like this 2017 in Review or 2018 Year in Review or any of these developer year in review posts? Great idea! But what should you include? You don’t want to forget anything important. That’s why I’m creating this software developer blog year in review article checklist. Now you can just read this year in review meta post and pick and choose the bits that make sense for your own year in review blog post. Enjoy and please share and add anything I’ve missed in the comments.

By the way, I recommend including a bunch of pictures, ideally both photos and screenshots, in your post. It’ll add a great deal to the visual interest and people love graphs and charts so if you’re sharing stats and have charts to go with it, be sure to include them.

Note: This is kind of long but the idea is to be comprehensive. Skip anything that doesn’t apply or you don’t care to include. Don’t not post something just because you can’t include everything listed below.

Your Blog

This one should be obvious. Write about the highlights and stats for your blog. Consider covering any or all of these things:

How many posts did you publish?
How many page views / sessions did you get per month/year?
What were the top 10 posts?
Did you have any goals? Did you meet them?
Anything else you want to share. Did you hit some milestone? Most web hosts or blog platforms? This is your chance for some meta-blogging about your blogging.

Your Mailing List

If you have a mailing list… If you don’t, you should start one. Literally every other way people can find you is through a platform over which you have no control. Email is your direct link to people who want to hear from you, and building that list of subscribers takes time. The sooner you start, the better. Here you might include things like:

Number of subscribers
Number of emails sent
Most popular (in terms of engagement) email(s) sent

Your Podcast

A podcast, even if you don’t update it regularly, provides another way for you to share your ideas with the world. If you have one, consider:

Number of episodes published
Number of downloads
Number of guests (if it’s not 1 per episode)
Anything new that happened with the show. New co-host. New platform. Etc.
Recap your goals and if you met them

Don’t forget to also list any guest appearances or interviews you made on other podcasts!

Your YouTube Channel

Creating a YouTube channel takes about 5 minutes. If nothing else you can upload a video introducing yourself and what you’re into. Later on you might post helpful tips or other videos. In any case, if you have one, you might include these in your review:

Number of videos published
Channel subscribers
Most popular video(s)
Any milestones you hit, goals you had and how you did, etc.

Your Twitch Stream

Are you streaming Twitch (or another platform)? If so, you can use this opportunity to share some of your experience with that.

Total followers and/or subscribers
How many streams did you do?
How many hours did you stream?
Any favorite events, clips, anecdotes, etc. you want to share?
Any big changes? Did you start last year? Did you change anything major last year?
Were you on anyone else’s streams?

Your GitHub Contributions

GitHub has become the place to go for open source software. If you’ve contributed or if you have your own projects, share what’s happened with them over the past year.

What does your GitHub contributions graph look like for last year?
What are your most popular repositories, in terms of stars or forks or both?
How many repositories do you have, total?
How many followers do you have?
Did you have any goals? Did you meet them?
What are your plans for this year?

Your Social Media

Yes, I know GitHub and YouTube are kind of social media, too, but here I’m referring to the ones that are just about being social, like Twitter, Facebook, Instagram, LinkedIn, and whatever the kids are using these days.

Did you start a new account anywhere? How do you like it? Are you going to keep using it?
What are your current follower/fan/whatever stats?
How many posts did you make last year?
Did you have any goals and did you meet them?
What are your thoughts about how you’ll use social media in general (and whichever specific ones you’re using) this year?

Other Social Media

Other sites you might include, along with relevant stats:

Your Pluralsight (or wherever) Course(s)

Did you publish any courses last year on Pluralsight or somewhere else? If so, recap them and how they’re doing.

Courses published
Goals and stats. Downloads, viewers, sales, whatever you have.
Plans for the coming year

Your Books

Did you publish or contribute to any books? Recap here and link to them, or to the posts where you talked about them already.

Books published
Sales/download stats, if you have any you want to share
Reviews (count, stars, etc)
Links to buy/download/review
Status of any in-progress books

Your Public Speaking

You can break this up into separate categories for user groups and conferences if you’re a prolific speaker and that helps. If you’re not speaking at events, you can obviously skip this one but it’s certainly a good thing to try.

Total events attended
Total talks given
Most popular or favorite session and why
Planned speaking engagements for this year
Anything you learned or feel like sharing about your experience as a speaker

Your Travels

Traveling is a goal for many of us, and this often dovetails nicely with speaking opportunities. But even if it was just a vacation you took somewhere, this is a good place to recap some of the new places you visited in the last year.

How many states/countries/continents did you visit?
What new (to you) places did you explore?
Share any stats like total miles flown if you want. Be prepared to defend your carbon footprint…
This is a great time to share a few photos.

Your Work Environment

Did your work area change dramatically last year in a way you want to share or remember? New office, new desk, new computer, etc? I don’t buy a new computer all that often, so when I do I often try to blog about it, and this is a good place to recap your current tools used list.

What’s your office look like?
What’s your desk setup look like?
Link to your post describing your new desk/chair/computer/monitor/whatever
Talk about how you like (or don’t) your setup and any plans you have to update/change it this year

Your Tech

If you got any new toys you’re especially excited about and think others would be interested in, that you didn’t already cover in your work environment, consider sharing here (ideally with links to your posts that already talk about these things). It’s easy for this to come off as bragging about all the things you can afford so try to focus on being helpful and sharing with the intent of helping others decide if (whatever) is something they would want to invest in.

Some examples:

Phone
Camera
Stream Deck or similar
Audio Equipment
Laptop
Desktop
Tablet
Car
Other gadgets

Your Job

Whether you’re an employee or independent or a business owner, you may want to share some things about the actual work you do.

What did you do last year?
Where did you work?
Were there any big changes? New job? Promotion?
How are things looking this year?
Any metrics you can share? Most folks keep things like compensation private (or at least not out on the Internet) but if there are any public metrics you’re proud of related to your work, share them here.

Your Life

Another year of your life is in the books. What do you want to remember about it when you read this post in 5 or 10 or 20 years? Maybe you already post updates to some social media account, but this blog post will probably be easier for you to find, later.

Any major life events? Graduations, weddings, anniversaries, births, deaths?
Personal accomplishments? Awards? New black belt in karate? Finally got your pilot license?
Favorite things you did with friends or family (even if vague) that you want to be sure you make time to do again in the future

Wrapping Up

If you have other ideas, please share them in the comments and I’ll update this post to include them and credit you. If you use this list as an inspiration for your own year in review blog post, I’d love it if you’d link to this article from your post. Feel free to add your post in the comments below or to reply to or retweet this tweet with your own post:

The Year in Review Post Checklist post

https://t.co/z7aOMfcIDU

— Steve "ardalis" Smith (@ardalis ) January 6, 2020

Thanks and (assuming you’re most likely reading this in early January) happy new year!

The post Year in Review Post Checklist appeared first on ardalis.

Be Humble and Kind

Steve Smith — Mon, 28 Oct 2019 13:05:37 +0000

This originally went out just to my Weekly Dev Tips mailing list, but I got a lot of positive comments and requests to share it, so I’m publishing it here. Sign up for Weekly Dev Tips to get a new tip in your inbox each Wednesday.

I’m not a big fan of country music (my wife is, however) but Tim McGraw’s Humble and Kind has it right. Don’t let success get to your head. You don’t know everything – be open to others’ input. You can disagree with others respectfully. Be kind when you feel the need to disagree or correct someone. Take extra care that your correction is actually helpful, especially if there’s a big power differential between you and the person you’re correcting, and especially if you’re doing it in public. Remember “ praise in public; criticize in private ” when you’re in a position of authority. It’s good advice and will serve you well.

Why am I writing this as a _dev tip _(if that’s not obvious)? Because being humble and kind is a part of being professional as much as it is a part of just being a good person, neighbor, coworker, and citizen. I’ve written and published before on the value of being thankful. See also this podcast episode. This ties right into that. It requires a measure of empathy. Empathy involves allowing yourself to consider how another person experiences the world. If you’re able to experience empathy for someone, it’s very easy to be kind to them. If you lack empathy, it’s easy for you to be a jerk. People don’t want more jerks in their lives – most of us know enough of them already.

So don’t be a jerk.

Professionally it’s obviously a good idea for you to not be a jerk to your boss. It’s probably a good idea not to be a jerk to your peers. It’s generally a good idea not to be a jerk in public, especially in public where things can be widely shared (with your boss, your customers, etc). But guess what? You really shouldn’t be a jerk in private, either. Not to your subordinates. Not to your spouse. Not to your friends. Not to your kids. Not even to strangers or when you think you can get away with it. Strive to be more humble, more kind, and more professional, when you can. And when you can’t, strive to at least take ownership of that rather than getting angry or defensive. It’s not easy, but it’s one more thing that will make you a better professional software developer. And person.

The post Be Humble and Kind appeared first on ardalis.

Configure Different Implementations for Different Controllers in ConfigureServices

Steve Smith — Wed, 09 Oct 2019 04:28:51 +0000

You may find yourself in a position where you need to have two (or more) different implementations of the same interface within your ASP.NET Core application. This may be because your application is too big to allow you to fully replace one implementation with another all at once, so you’re rolling out the updates one type at a time. Let’s say the services in question relate to persistence, and you’re using some variation of the Repository pattern for the interface. You can easily create separate implementation-specific classes that implement your Repository interface – but how do you dynamically determine which endpoints in your system will use which implementations?

Your basic ConfigureServices code for just wiring up a repository to a single implementation looks something like this:

services.AddScoped(typeof(IAsyncRepository\<\>), typeof(EfRepository\<\>));

You can see an example of this approach in the eShopOnWeb reference application.

Using Different Services in Different Controllers

The problem arises when you have multiple controllers and you want to use different services with each one. There are actually several ways you can address this problem. One approach assuming you’re using a generic repository is to vary your implementation with the type of the entity, rather than with the controller. For example, you could have one entity use an EfRepository while another uses a DapperRepository, like so:

// specify specific repo implementation types per entity services.AddScoped\<IAsyncRepository\<Customer\>, EfAsyncRepository\<Customer\>\>(); services.AddScoped\<IAsyncRepository\<Product\>, DapperProductRepository\>(x =\> new DapperProductRepository(Configuration.GetConnectionString("DefaultConnection")));

With this approach, everywhere in your application that you use a repository to fetch an entity, if that entity is a Customer then you’ll use EF Core to get it, but if it’s a Product then you’ll use Dapper to get it.

This may be sufficient or perhaps preferable to configuring the services per Controller, but of course you can do that, too.

To do so, add some variation of this code to ConfigureServices:

// specify specific repo implementation to use per controller services.AddScoped\<EfAsyncRepository\<Car\>\>(); services.AddScoped\<CarsController\>(x =\> new CarsController(x.GetRequiredService\<EfAsyncRepository\<Car\>\>()));

Now when the CarsController is accessed, it will specifically use the EF Repository (of Car) instead of whatever the default implementation might be for the generic repository.

Note: For this to work, you need to add controllers as services using services.AddMvc().AddControllersAsServices();

You can see the code and download and run the sample from its GitHub repo here.

The post Configure Different Implementations for Different Controllers in ConfigureServices appeared first on ardalis.

Attacking Technical Debt

Steve Smith — Wed, 18 Sep 2019 01:07:52 +0000

Technical Debt is a metaphor for shortcuts and hacks in software that make it more difficult to change and maintain than it could be with an optimal design. Many applications have accumulated a large amount of technical debt, and figuring out how to deal with it is a fairly common challenge for many developers, especially senior developers starting new contracts or jobs at companies that need help with their legacy code and its huge technical debt.

So, how should you approach paying down technical debt?

In some cases, you shouldn’t. It may make sense to rewrite the app. Declare “technical bankruptcy.” This should be rare, and it’s likely not a decision a developer is going to be making. Let’s assume that’s not an option (or not the decision that was made) in this scenario. Now what?

Stop the bleeding

Step one is to stop the bleeding. If you’re a doctor and you have a patient who is bleeding profusely, the first thing you need to do is stop the bleeding , not perform a bunch of other diagnostics or gather medical history or get a CT scan done. Stopping the bleeding buys you time to assess the situation and correct things without things continuing to get worse.

Going back to the debt metaphor, if you’re advising someone on how to get out of debt, and their biggest problem is they’re constantly outspending their income using credit cards, the first thing you do is cut up the credit cards.

One last metaphor for you. If you’re in a deep hole and are wondering how you’re going to get out, the first thing to do is to stop digging yourself deeper into the ground. You’re only making the future problem harder to solve.

What does this look like in terms of your software project? Technical debt increases when you add untested, difficult to test, tightly coupled code (among other things). So, step one is to stop doing that. New code will follow standards. It will be tested. It will be well-factored. Even updates to large legacy codebases can be written using new classes that can be well-designed. Maintain legacy code by adding new code, not by changing existing code.

Refactor, while adding value

Getting rid of technical debt is what refactoring is all about. There are many specific techniques you can use and code smells you can identify that contribute to technical debt. I’ve written three courses on refactoring that you may find useful when you get to this step:

One thing that’s common to all of them is the idea of when should you refactor? The approach I recommend is to refactor in the course of making necessary updates to the code – fixing bugs or adding new features. Customers and stakeholders expect development teams to make changes that they can see and appreciate. If you try to just stop delivering value and spend an extended period of time “cleaning up” the code, you’re sending a very dangerous message to stakeholders. What’s more, you’re not necessarily focusing your efforts where they matter most and will have the most immediate return on investment.

When you refactor as you add value, you’re making the code that you’re already working on better. The benefits of your refactoring efforts are felt immediately. And, typically, the areas of the code that you’re working on at any point in time are likely to be worked on again in the near future. Bugs and features tend to affect certain areas of the codebase more than others, not to be evenly distributed. If you take a broad, sweeping approach to your refactoring efforts, odds are good you’re going to be cleaning up code that you otherwise were never going to need to touch, which doesn’t add much value (it might be a complete waste of time and worse, might break something that would have been fine if you’d let it be).

Measure and Keep Quality Increasing

Once you decide to stop making things worse and start following the Boy Scout Rule and making the code at least a little bit better with each new pull request, you’re on the right track. Now’s a good time to monitor the quality of the application using whatever metrics you find valuable. Some metrics I use include:

Code Test Coverage – Keep it trending upward over time
Aggregate Complexity – Keep it trending toward zero
NDepend Technical Debt – Keep it trending down

You can also use some of the metrics available in Visual Studio, or SonarQube. But whatever metrics you pick, you want to be able to look at a trend over time of your code’s quality using some kind of metric to give you confidence that you are, in fact, moving things in the right direction.

Other things you may want to track:

Total passing tests (more is better)
Frequency of deployments (more often is better)
Cycle time for new work (faster is better)
Frequency of bug reports
Frequency of deployment rollbacks

You don’t need to track all of these things, but if you’re going to go to the trouble of making a concerted effort to clean up your code, it’s worth identifying up front how you’re going to measure your progress. What metrics are valuable to your team or your stakeholders? How can you move them in the right direction with your efforts? That’s how you’ll know if you’re on the right track.

Your turn

Have you gone through a major refactoring effort? What worked and what didn’t? Share your thoughts below. What about metrics? How did you know when you were done? Or that it was “better”? Were there certain metrics you used to guide your effort? Please share. Thanks!

The post Attacking Technical Debt appeared first on ardalis.