Always Assume That You’re The Problem

If you are as much of a fan of the book “The Pragmatic Programmer” as I am, then you might remember the phase:

“Select” Isn’t Broken

You can find this nugget, along with others, on pragmatic press’ site. In the book though they go in further detail to lay out a story where a programmer was convinced that he had found a bug in the “select” Solaris API call. Obviously after wasted time, hilariousness, and much chicanery, the programmer was forced to analyze the problem and discovered that, alas, it was in his own code.

If this sounds familiar to you, then shame on you, but you may be sitting there saying “Pssssshhhhhaaaaaa, I always assume that my code is the problem. And then I fix that junk and release some killer builds.” And if you are saying that, then why are you speaking like that? But seriously, I applaud you for being so humble. It is good to look at your own work with a cautious eye, and sometimes it can keep you from getting seriously embarrassed.

As good as you may be about assuming that your code is always broken, are you just as good at assuming that it is your understanding that is broken? Are you just as good at looking at your own beliefs with a cautious eye? That may sound like a bizarre question, but think about it for a second. How many times have you come across a concept that looks extremely foreign to you and you say “Bah, there is no value in that. I don’t need it.” Then you find yourself 3 months down the road employing that same concept or tool and wondering how you ever lived without it. Sound familiar?

Let me just lay out a list of items, and you tell me how they are all related:

• Dependency Injection
• Immutability
• Closures
• Lambdas (and Anonymous Functions)
• GIT
• Continuous Integration
• ORMs
• Javascript
• Mocking
• Charlie The Unicorn (Shuuuuuuuuuuun)

Any ideas? Well, there are probably at least a few things in that list that you violently revolted against, or at least actively ignored, only to discover later on that they made your life better. So what was the problem? Well, we generally think we know better than everyone else… at least that is my theory.

So What Are You Trying To Get At?

Well, I am trying to say that there aren’t a billion developers out there singing the glories of GIT solely because it is the cool thing to do. Sure, about half of them probably are (or maybe three-quarters), but the rest really see value in the tool. In fact, I have seen two converts over to Git in just the past week or so, and one of them, Chris Allport, made me even more impressed with it. I thought I saw value, but I wasn’t even fully there yet!

So, next time you see a huge number of developers selecting a tool, technology, or concept; do some serious research into it. Go find someone who loves the tool and ask them to sell you on it. You might find that you’re just being a grumpy old geezer who doesn’t want to change his/her ways. Sure those crazy kids won’t get off your lawn, but maybe you could at least listen to their drunken hippy talk for a few minutes. They just might have something to tell you.

Now I know that I’m going to probably catch a lot of flack from people who will say that I am encouraging you to just go along with the crowd, and to a certain extent I am. Guilty. But it is survival of the fittest out there, and we need to at least ask the community why they find value in the tools that we just don’t get. You may be pleasantly surprised. (Or you may find a corporate backed tool with a great marketing campaign)