Managing your own skepticism is a major part of being a software developer. It’s important to be skeptical sometimes. It’s always tempting to spend all your time playing with new tools, frameworks, and technologies. But that’s not what you’re getting paid for, and you can only spend some much of your own time learning. On the other hand, being too skeptical can lead you to be inefficient and behind the times.
I’ve had a history of being very skeptical about technologies that I’ve later come to embrace. While this has inevitably lead to being made fun of by a coworker who’s been there to observe this trend, I’m confident that thinking critically about each new thing before accepting has been a good thing, and I’m sure that I’ve avoided countless wrong paths that I can’t even remember. To catalog my mistakes: I scoffed at XML, I constantly questioned unit testing, and I dismissed Ruby. I’m still skeptical about Ruby on Rails though.
I’ve also had a few successes. Though I’m certainly no visionary, I picked up on Hibernate, Spring, Maven 2, and EasyMock without going through a long period of doubt.
So, how do you know when to give a technology a try? Don’t say ‘experience’: experience is just a proxy term because you haven’t consciously figured out what your techniques are. Do you follow certain people you consider experts? I was certainly more willing to try Ruby after reading essays by Steve Yegge, but I’m still not looking to use Emacs. Do you prefer to take it slow, and wait for the bandwagon to get big enough before even looking at it? Are there times when you can’t skip ahead, because you first need to do things the hard way, to feel the pain that some new tool fixes?