As a programmer I have learned to embrace change, but this was not always the case. I can remember when I was once told a long time ago that I was resistant to change. At the time I felt that change was bad, it was expensive and there was in my mind no reason do so. But now I see the flip side of the coin, without change there can not be betterment.
For me changing from a Perl developer to a Java developer was a good thing. Changing from a pure development role to an architect role was also a good thing. I have found that if you want to change it can be extremely rewarding and even fun. For me I enjoy learning and employing new tools that increase my productivity and the quality of my applications, but with others I often see resistance to these changes.
Now that I am a father I see something in my son that wasn't obvious to me when I was his age. I see that he wants to learn. He wants to play with the computer, learn how to count, and he learns things because to him it is all a big game. Learning for him is fun.
To me it seems that there is some force in him that makes him want to explore and learn, and this isn't unique to just my son, all children seem to exhibit this behaviour. This makes me wonder what it is that makes us adults begin to resist change at some point in our lives, and we no longer see the fun in it.
I am not a psychiatrist, so I dare not try to explain this phenomena, but there is a reason why I am bringing this up (bear with me). I have been thinking about the tools that I have begun to employ in the work environment, and wanted to start blogging about them. All of them were resisted by at least some of our developers, but over time they began to see the benefits and now that the change had taken hold it is no longer difficult.
Some of the tools that I now live by are JUnit, Jira, Crucible, Fisheye, Subversion, and others. Some of these are free and some are not. When I blog about them I expect to see some resistance, especially for the commercial tools. In light of the expected resistance I will try to spell out how they made things better for both the developer who needs to use them and the manager who needs to understand the value proposition.