In his latest book “My Job Went to India”, Chad Fowler talks about monkey traps. If you don’t know them: it’s a simple yet effective way used in South India to catch those darn monkeys that usually steal your food on the street or wherever you stand with something eatable with your hand. In short, they dig a deep whole that’s narrow on the top and gets wider to the bottom. They put some rice in there, and a monkey, food-loving as he is, would put his hand through the whole, grab as much rice as he can (making a big fist in the process), and would try to pull back his hand. To nobody’s surprise the fist is too big to fit through the whole. But the monkeys care more about the food in their hand then their life, so they’d rather die trying to get the food out of the whole than let go of it.
A nice metaphor compared to how things sometimes work with people’s opinions in software development/engineering. Well, it might be applicable to other areas of professions as well.
That made me think about my personal monkey traps (as it was supposed to, thanks Chad ;). I used to have some big ones, I’m with Chad on the Linux one. Has been a huge monkey trap for me. Since now I’m using Mac OS X, that changed, but probably not in the way it was supposed to. But now I don’t want to put Linux (or open source software in general) on everyone’s desktop anymore. Learned a valuable lesson here from my parents which, in the long term, would rather stick to Windows, and it was good. I also changed my mind about exclusively using open source software myself, and I started paying for stuff again. Even the my view on commercial IDEs has changed. When you finally see that there’s a reason way you could pay for software, though not for that ridiculously overpriced JBuilder, things change. Even if it’s for the benefit of improved productivity.
Another one used to be vi. It’s still one of my weapons of choice, and I still like to make jokes about Emacs, but who doesn’t? But since I delved into Java programming I got way more comfortable using a good IDE which can do stuff that vi (or Vim for that matter) can’t or takes hours and intimate knowledge to get it working. Somewhere along the way I lost the way to fiddle with all that stuff, and with Mac OS X I learned to love again, that is, the usefulness of a nice and clean UI. Well, it still helps, if there are lots of keyboard shortcuts to use. Only people who aren’t slackers use the mouse for everything.
But that’s just the one side of the story. I also used to think (well, who didn’t, because nobody told them in college or university) that a programmer just programs, and he does whatever he’s told to. To some extend I actually did think that. I didn’t stick up to that as a dogma, but it’s one of these misconceptions you can stumble over easily. Of course you do more than that as a developer, or at least you should, because otherwise you’re not offering enough value for your company to hold on to you. Some people get through that way, but it’s questionable, if that will work out or even satisfy you in the end. But I’m kind of stepping on the point of Chad’s whole book here.
I’m still thinking about my technological monkey traps. I’m not saying I don’t have any, that would be too good to be true. Everybody has some, be it CORBA, an object-oriented database, J2EE, the term enterprise application, .NET, unit tests, model-driven development, you name it. Maybe a key to avoid monkey traps in a technological manner is widen your own portfolio constantly. Learning new languages, playing with new frameworks, testing new tools to include in your toolbox, maybe these things can help to avoid common monkey traps. The more technologies you’re familiar with, the easier it is to have an objective and differentiated look at things. None of that “Ruby on Rails is crap, because someone told me so” crap. Or “Eclipse sucks, because it’s a product of IBM”, or even “Java is not proprietary, and Sun will love us all forever” (all statements might or might not reflect opinions heard or said by your humble author, ). Stuff like that, you get the idea. I for my part am a little resistant towards .NET, so I’ll probably opt for giving at least C# a try. Mono to the rescue. It’s been on my radar for a while, but maybe it’s time to see, where Java got its recent language update ideas from.
It’s also a way to get a perspective for always wanting to do things perfect. On the way to strive to write perfect code, have a perfect design, perfect team, perfect management, you name it, you tend to forget that it’s your own fist that holds you back. The perfectionist will be trapped by her own desire to be perfect. Embrace the The Good Enough Approach, and you can open your fist now, and let go of the rice.
Chad puts it right when he recommends that you give that technology that you hated since forever (or only since recently) a try. If you’re a J2EE evangelist, try doing something in .NET. Always hated unit testing? Write a test for your next class or bug fix. Having preconceptions about Ruby? Play with it. After all, either you’ll know why you hated it in the first place, or best of all, you have something to put into your toolbox. If you put into that really dark corner, or right into the bottom drawer of your favourite tools doesn’t matter. The important point is that you have the possibility to classify the tool as what it is: Another tool to do things in a more or less appropriate way for the task at hand. At least the monkey doesn’t (or didn’t) have that luxury. Although evolution should kick in someday, they’re still doing the same mistake over and over again. Something to think about.
Technorati Tags:
development, badpractices, monkey traps, software development