Scott Hanselman’s Best Blog Posts Of All Time
If you’re familiar with the .NET development community, then you’ve definitely heard of Scott Hanselman from Microsoft.
Scott engages a lot with the community through blog posts, podcasts, and speaking. I had the pleasure of seeing one of his talks live at a conference not too long ago and it was the most entertaining talk I’ve ever been to.
Several of Scott’s posts come to the top of my mind as being some of the best on certain topics, and many others agree — that’s probably why he has such a big following. After following Scott’s blog for quite a long time now, I’d like to take a look at a few of his most inspiring posts.
I'll admit, in my initial list I included the Interview Questions post and its sequel. Those posts are definitely some of his most popular ones since they serve as a reference both for interviewers and interviewees.
Many of Scott’s posts really moved and connected with me as a developer and as a person, and I’ve included these posts here.
They feature answers to many important questions: You can have the most .NET knowledge in the world, but if you're mean to new folks in open source, does being smart really matter? If you decline to mentor junior developers, are you really a professional in the world of programming? If you consider yourself a rockstar developer, do you believe there's nothing left to learn?
Some of these posts are technology based, but I tried to keep this list of blog posts as developer-focused as possible. The technology may eventually become stale, but the posts on life as a developer will always be relevant.
Here is a list of what I believe are Scott Hanselman's best blog posts. I use the term “best” because these are the posts that have moved me the most as a developer or included great actionable items.
“There's a tool for everything.” That is definitely true in the world of software development.
In this post, Scott highlights the tools that he personally uses and recommends others use, too. You may have already heard of some of the them, but I bet there might be a tool or two on this list that you haven't heard about before. Give all of them a try, and it may change the way you do your daily programming.
Most of these tools are Windows only, but you may be able to find a similar tool for Mac or Linux. You probably won’t need all of them, but you might find one that will become your all-time favorite tool.
While the interview posts I mentioned earlier didn’t make this list, I wanted to include this one since it involves keeping up with what’s current. As developers, we must always be learning and staying up-to-date with the latest in our industry. This post highlights a lot of those things that developers can keep an eye on.
Not only does it highlight libraries that are good to get into, such as Xamarin or .NET Core, but it also goes back to the basics of what .NET really is and what managed code is, which is a good place to start if you’re just now entering the .NET space.
You can find productivity tips and lists pretty much everywhere. In fact, I’m currently reading a book about how to be a more effective developer.
Everyone wants to be more productive at their job. If you’re looking to learn how to improve your productivity, this post by Scott (based off one of his talks) details a lot of the tips that he personally uses. Just like the blogging tips post, there are some obvious and not-so-obvious tips here.
While you’ll find similar advice from books like “The 4 Hour Workweek” or “Deep Work” about removing distractions and improving productivity including using the Pomodoro technique), what makes this post special is seeing how those techniques are being used by someone who we know has a busy day.
Perhaps one of the most sought-after pieces of advice that all developers search for is finding ways to become better. Why? This advice can be used to earn a higher salary or raise your hourly rate, but a good portion of developers are also simply lifelong learners. They are interested in building their craft and want to become better at what they do purely for the sake of learning and growing.
This post notes several actions that a developer can do to become better, or in Scott’s words, to sharpen their own saw. If you can do only a few of these, your saw will definitely be sharpened quite a bit. A few of my favorites are investing and reading technical books, attending and speaking at conferences, and having “lunch and learns” at your company.
It’s good to learn at least some code, whether you’re in QA and want a better understanding of what the dev team does, or you’re someone who wants to automate a lot of what they do in their job.
Learning to make programs that do simple things may not seem like much, but learning how to be on a team and produce quality code isn’t that easy. However, as Scott points out in this post, there are a ton of rewards for all of the hard work: you can build something that you will be proud to have been a part of, and you will meet some people who may end up being life-long friends.
Getting started in open source is becoming increasingly easier to do. With more and more companies moving their code to open source, finding an open source project to help out with is easier than ever.
Whatever type of software you’re interested in, there’s most likely an open source project you can contribute to. However, finding a project is just the tip of the iceberg: going through the code and then fixing an issue or adding a feature will be a good part of your efforts.
The scariest part, though, is submitting your work – because our code is out in the open for anyone to see and critique. Scott gives suggestions on how you can keep the kindness in your project as an open source project maintainer, such as having a “contributing” file to guide new people to your project on the procedure of things, and having an “up-for-grabs” label on issues so new people to your project have simpler things to work on to better get them up-to-speed on how the architecture works.
How many times have you been nervous to do a code review of changes you’ve made? I’ve definitely been nervous many times, and I still continue to feel that way when going over any type of code with a colleague.
The number one thing people tend to say about code reviews is to not take any criticism of your code personally. That’s really hard to do in practice. You came up with the code, you wrote it, you tested it. Then, in an instant, someone shoots it down right in front of you — your co-workers, or maybe even your boss. That’s hard not to take personally. The main part of this post is to not let any worries stop you from sharing your code – it just might be exactly what someone needs.
It’s common to think that no one reads your blog and that you’re just putting posts out there for them to end up in blog post purgatory. With this post, Scott argues that the engine of the community IS your blog.
This post serves as inspiration to keep on blogging. There is no quick reward for keeping your blog up — with it, you'll be playing the long game. Every now and then, you'll have a hit post,ut that hit won't come overnight.
John always says that every developer should have a blog. So much so that he created an email course just to help developers get started making one. A blog is easy to create, but making it one people will want to visit often can be a bit challenging.
In this post, Scott goes over a lot of tips and strategies to make your blog the best it can be. There are some obvious tips here, such as checking your spelling in your posts. There are also some tips that aren’t so obvious, such as having a license for your blog.
I believe it's fairly common that developers have imposter syndrome; I know I do, and this post makes me feel like I'm not alone. That I’m not the only one with this type of feeling. That I’m not just faking it each and every day. There was one part of this post in particular that made me feel a little bit better; he cites part of the Wikipedia article which states that “…people with true ability tended to underestimate their relative competence”. That’s definitely reassures me that I may not be as bad as I think I am.
Feeling like a phony can have its positive side, though. One benefit from this feeling, I believe, is that you won’t let your ego get in the way. You welcome code reviews instead of taking suggestions personally. You constantly seek advice on how to do things better, rather than stay set in your ways regarding how things should be done. Doing these things are the mark of someone who is a professional in their craft – not a phony.
There is Still More to Come
Scott puts priority on his blog and constantly creates new posts. Perhaps next year there will be a whole new set of best posts in this list.
In your view, what are your top favorite posts by Scott, and what have you learned from them?