To improve is to change; to be perfect is to change often.
Every once in a while I wonder if my programming tools, languages and platforms need to be changed. Maybe, just maybe, the software mix I use every day needs to be shaken up.
And then my mind starts spinning in circles.
As we all do, I find myself using the same languages and tools over and over again. The same programmer’s editor. The same color scheme and fonts. The same language for scripting. The same platform for web services. The same database. The same server applications.
I use them because they work. Actually, I really use them because I know them so well. They are proven, robust, easy for me to use, easy for me to deploy and easy for me to support. I have gone though the learning curves, fought with the quirks, dealt with the problems and emerged a master of these tools.
But I sometimes do wonder: Is it time for a change? Maybe I do need to learn and master a new editor, new scheme, new language, new web platform, new database, new server, new everything.
The only way that we can live, is if we grow. The only way that we can grow is if we change. The only way that we can change is if we learn.
But the question then is which new things to learn and tackle? My programmer’s editor is still modern, fast and reliable. My scripting language is still popular and works great. The web platform I use is robust and has just been updated to a whole new version. And I switched to the database I use these days only three years ago.
So maybe I don’t need to change. The languages and tools I use these days are still at or near the top of their game. A glance at the competitive space for each area shows a few promising new technologies, a few stable similarly aged technologies and a bunch of older ones, but none stand out as “the next big thing” yet.
But I don’t want to miss or be late for “next big thing” wave. And I fortunately do have the time to learn new stuff. But what to learn? What to change?
And what to change to?
Change Simply for the Sake of Change Is an Abdication of Leadership.
Is change for the sake of changing good or no good? John Luke Jr believes it is not good, a sign of bad leadership. Freek Vermeulen, Phanish Puranam, and Ranjay Gulati in the Harvard Business Review’s Change for Change’s Sake disagree, they view it as a good thing, a sign of good leadership. Both great sources of advice, and yet completely contradictory. Not helping!
Maybe, thinking more on it, I need a real arguable reason to change? A stand-out “this is amazing and much better than what I use” reason to change?
Looking back, it was arguable need that caused me to switch from stagnating Perl to growing Ruby years ago. From Apache to Nginx to get more workers and throughput on the same hardware. From ASP.Net to Ruby on Rails for platform independence and development speed. From MySQL to PostgreSQL for better write performance and large data management.
But what if I change and land up with the “wrong” platform? Marco Arment wrote about his trusty PHP when looking to make his own change:
The fear of making the “wrong” choice actually makes the familiar, mastered PHP more attractive.
Or, maybe it’s not tools, just a timing issue? Is it time for the next change? Even though there seems to be no reason to do so just yet. Do I need to shake things up a bit right now?
I honestly don’t know.
In this specific case, maybe T. Bert Lance is right (even though I do not believe this maxim):
If it ain't broke, don't fix it.
And so the thinking, spinning and search continues.
Until I find the “right” new things for me, I’ll stick with what I have. But I’ll keep looking, keep checking things out.
My next project will be a trusty Rails project on a trusty Linux platform using my trusty Nginx setup against trusty PostgreSQL. And my next script will still be in trusty Ruby. And I’ll still program it all using trusty TextMate 2 with my familiar CombinedCasts theme.