You need to blog. Now.

Seriously. No, I know. Stop it. Stop whining. Yes, they will care what you have to say. No, it hasn’t all been said before. Yes, seriously. Do it. YOU, YES YOU!

The most common excuse for not blogging I hear (including from myself) is “It’s all been said, what can I possibly add?”

While that may be mostly true, what you’re missing is that not everyone is hearing it!  But there are still some gaping voids of content that aren’t adequately covered.

Here’s a few blog ideas I’ve been kicking around and I’ll share them with you so that you can take some of these and run with them. PLEASE GRAB ONE AND GO!  As you blog them, I will link them to you and cross ‘em off the list. I’m going to be doing some of them too, but it’s not enough. I need your help. I need differing views. I need conflicting, but useful information to further discussion and stimulate progress.

I’m even going to go so far an pull rank on you and go Catholic:  If you have even the slightest knowledge of these things you have a professional obligation to share that knowledge with as many people as you can. Yes, even if you’re wrong on parts. Yes, even if you’re not sure (just prefix with ‘not sure about this’).  I’d rather have a bunch of 80% right posts out there that we can discuss and critique and further knowledge from than 0 0% right posts out there (which is a lot of what we have right now).

  • Guiding Principles 101:  Single Responsibility Principle, Dependency Inversion Principle, Liskov Substitution Principle, Framework Ignorance Principle, (and others I’m not thinking of right now ’cause it’s late)
  • Dependency Injection 101: Talk about c’tor injection, setter injection, when it’s good, when it’s bad. Talk about the need for interfaces and how they help with this.
  • Inversion of Control 101:  Talk about how to take DI to the next level and automate a lot of it (or push the burden elsewhere).  Use StructureMap, Windsor, or roll your own super-simplistic one to show how things work and then add in one of the big frameworks.
  • Unit Testing 101:  Most people know what unit testing is, but they don’t know that there are xUnit frameworks that make it a lot easier. Pick one (NUnit, MBUnit, MSTest) and start from scratch and go through a few dirt simple scenarios
  • Mocks 101: “I just bought this iMac and now I want to know how to use Rhino Mocks” — the absolute start-from-zero low-down on why mocking and how to use Rhino Mocks (or any other framework for that matter). Many posts out there assume that you have the basic understanding of what Mocks are for and why’d you use them. The vast majority of the .NET developer community has no idea what mocks are for in the first place, let alone how you go about using them. This is a tragedy and we must correct this soon.
  • Unit Testing 201:  Test naming, test file/class/method structure, what to assert, when, and how, etc.
  • Mocks 201: Talk about when to use CreateMock vs. DynamicMock vs. Stub. When to use Expect.Call() vs. SetupResult.For… maybe you might give ‘em a glimpse at constraints


That should get you started. I’ll be cooking up some more ideas, but this should be enough to show you that there’s a WEALTH of stuff upon which to blog. Do it now!

About Chad Myers

Chad Myers is the Director of Development for Dovetail Software, in Austin, TX, where he leads a premiere software team building complex enterprise software products. Chad is a .NET software developer specializing in enterprise software designs and architectures. He has over 12 years of software development experience and a proven track record of Agile, test-driven project leadership using both Microsoft and open source tools. He is a community leader who speaks at the Austin .NET User's Group, the ADNUG Code Camp, and participates in various development communities and open source projects.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Way to call people out! ;-)

  • I think that it’s indicative of the growing short-sightedness that the dependency on blogging has brought that we presume that sharing knowledge should be done from the comfort of our armchairs.

    It has indeed all been said before – except for brand new stuff. Even though it’s all been said, it’s all far from understood.

    If the communication effort is to achieve its potential, the last mile has to be crossed on-foot, and in-person.

    Your TDD coding dojo is an example of what I’m talking about.

    Blogging is fine, but it’s saturated. Time to up the ante. What the tech world needed when there were few bloggers was more bloggers. What the tech wold needs now that you can’t swing a cat without hitting a blogger is more teachers. Correction… more teaching. Less blogging, more teaching – even if done on a blog (but better if done out in the wild).

  • @Scott

    I want what you’re asking for to be an additional call-to-arms. Established bloggers need to get outside their comfort zone and teach more. We have lots of opportunities for this, whether it’s Agile Austin’s workshops, ADNUG’s Code Camps, etc. It does seem that we are spoiled in Austin with the number of opportunities.

    Agreed that blogging is saturated, but it provides a nice first step towards leadership. It’s also a first step in community participation. You have to form an opinion to post (unless you’re a tool shill), so blogging creates a catalyst for critical analysis.

  • I’ll take you up on your challenge, Chad. I’m a very new blogger ( < 10 posts at the moment), so one of my biggest challenges is coming up with ideas for posts. I’ll try and tackle a few of the topics you listed. Even though I may not be very knowledgeable about these topics, there’s no better way to learn than to try to teach.

  • Interesting post; couldn’t agree more.

    Framework Ignorance Principal???

    Sorry if I’m making a fool of myself but never heard of this one before.

    Maybe a line or two on what it is and then maybe I can give a shot at putting in some more research and blogging about it? :)

  • @rajiv

    Yeah, I hadn’t heard a name for this concept before, so I just made that one up. It covers things like ‘Persistence Ignorance’ and ‘IoC Container Ignorance’ and things like that.

    I think these ‘ignorance’ concepts can be grouped under a single principle which I hastily dubbed ‘Framework Ignorance Principle’.