It’s nice to be the expert. But as time passes and technologies advance, your area of expertise shrinks noticeably. If you never stop to see what’s outside of your programming comfort zone, you could be using obsolete techniques and spending your time programming solutions that have already been solved.
This article weighs the pros and cons of coding within your comfort zone, describes the problems it creates, and tells you how to overcome them.
Choice of technologies
It's hard to be objective when you're the one charged with choosing the best technology to apply to a particular solution. No matter what your experience, you'll probably be biased towards what you consider tried-and-true technologies.
There may be a time-to-development advantage to deploying familiar technologies, but is it the right solution for your needs? Is it compatible with existing systems? Does it supply mechanisms especially suited to your particular circumstances? Does it satisfy the business need? These questions are often overlooked when you select the comfortable favorite. Whatever time you gain in familiarity, you may lose in available functionality.
Compile a list of objective questions to use to compare possible technologies. Prioritize the list and weigh answers consistently for each test case. Language familiarity is important, but an objective review will expose potential losses you may encounter by deploying that language.
Continued education within a technology will improve your skills and level of understanding. Keeping up with version advancements seems like an obvious requirement, but you’d be surprised how many developers fail to regularly review release notes.
When determining whether or not to upgrade, you should look at the whole picture. Significant changes between versions may require substantial modifications to your code base and additional training for your team. An upgrade might slow you down in the short term but offer tremendous potential improvements for your product.
Try to be objective when deciding on an upgrade. Consider the size of your existing code base, life expectancy, and reuse potential. When you design a solution, find out if an upgrade is imminent, and include it in your development cycle.
Libraries and modules
There's an obvious advantage to using libraries and other code developed outside your shop. You save time writing, debugging, and optimizing that code. However, lack of familiarity is the number one excuse for not using them. Take a look at some of these outside sources of code before deciding they just won’t work.
For example, why would you ever write a modular piece of functionality to send e-mail when there are dozens of pre-existing solutions? Chances are it’s because you think your application is unique. You may be right, but you won’t know unless you constantly evaluate new opportunities.
If it takes you half an hour to evaluate potential third-party source code, and you evaluate four different bodies of work, those two hours are worth it if you find a solution that saves the two days you'd spend writing the code yourself. Even if you don’t find a solution that works, you may gain new insight into how to address your own programming efforts, or find a piece of code that solves next week's big problem.
Tools and utilities
You can get too comfortable with existing tools. You may have been using “Code Champion 2000” as your IDE for years and know to avoid clicking the buttons that are buggy, or you've conformed to its syntax, but “Code Master 2005” may be a better product and worth the effort to learn it. Tools and utilities are directly proportional to your productivity. It may be easier just to use the old product, but dismissing new tools because they don’t feel familiar is a poor excuse. If there is a potential benefit to adopting a new tool, your loyalty to an inferior product is misplaced. The transition may be painful, but your solution will benefit.
It's obvious that staying within your comfort zone can dull your skills and keep you from doing your best work. While it’s good to be master of your domain, if you don’t recognize that your skills must grow along with technology, you’ll soon find yourself obsolete. Stay sharp: Constantly question and expand your area of expertise and learn to take comfort in change.
Got your head in the sand?
Have you refused to work with new technologies because the learning curve was too steep? What justifications have I missed? Drop us an e-mail or join the discussion below.