I know that dynamic languages like Ruby and Python give you things that you can't get  with languages like C#, and as a SOLID advocate those things seem important, but... why do I go cross-eyed when I read Python and Ruby examples?  

The quote right there is from the first comment on the article.

The article is actually decent and well-written. It's just the flaw is that it's advocating dynamic languages. I get how "monkey patching" is great for testing. But having to read and understand a large project in Python would make me go cross-eyed too. Dynamic languages are anything but well-defined.

Dynamic for test: YES
Dynamic for real world projects: NO

Testable Java
It's often hard to retrofit unit tests in code that wasn't designed to be testable. In this paper, Michael Feathers describes a simple rule that you can use during development to assess the testability of your Java code.

Michael Feathers wrote a FANTASTIC rule to remember when writing code to make it easy to test. His example case is Java but the rules can easily be adapted to C#. I need to train myself to remember this.

I should also get around to reading the his book that I bought.

Agile Development community, we use the term “technical debt” to refer to this problem.  When you don’t keep your code clean, you incur debt, and as in other areas of life debt reduces your options – it can become crippling over time...

Michael Feathers compares technical debt to credit card debt. I think it's very apt.

Maybe I should try to read his _Working Effectively with Legacy Code_ book another shot. I felt it was too beginner for me. I should just read it. You can always get something new from rereading the basics.

This is a good intro to BDD. I need to fully decide if I prefer BDD to TDD. Or something along those lines anyways. I have no real testing strategy locked into my brain yet so I'm still reading as much as I can. I still feel out in the weeds when it comes to how to write tests.

First Step: Admit You’re Not As Smart As You Think You Are

And here's a good response to the previous article. I'm glad there are people that can write my thoughts better than I could. Now, I get to code.

A test that needs to be updated every time the product changes is not really a test at all. Think about it.

This article does give many things to think about. Though, it may seem like a laundry list of excuses to many.

This is a very gonzo video of debugging with VS2010. I can't wait for this and WinDBG to die.