Getting out of your comfort zone

Software development in the government sector has gotten quite a bit of press in the past few months, from the botched rollout of Healthcare.gov to the revelation that the appointment booking system for the US Department of Veterans Affairs hasn't been updated since 1985. These stories have reminded me of my own experience as a government programmer, and why it pushed me to always work hard to improve my thought process as a developer.

I used to work in an office that maintained government systems written in the early 1990s. When a new project to build a modern replacement for some of these systems began, it was met with huge resistance from some of the developers who maintained the legacy code. At first, I wasn't sure why there was so much backlash. It began to make sense the longer I worked on the project: Some of these developers had been working on a single system for 15 or more years. After all the time they had invested, they were skeptical about trying anything new.

It scared me to think how easily that might happen to my career. I could settle in with one job, learning the ins-and-outs of a single system. As the system aged, I would become more valuable, and my role would eventually focus only on maintenance. I'd spend the rest of my days on the same mundane tasks, running out the clock on my retirement. And one day, my system might simply not be needed anymore, and I'd find myself having to start all over again, decades behind the competition.

That didn't seem very appealing to me; what I love about being a programmer is learning new ways to solve new problems, not maintaining a status quo. As programmers, it's easy to take a single technology and focus all of our energy into it, ignoring everything outside. While that can make you a sought-after expert in that particular field, you lose out on the benefits of exploring other technologies. After seeing how this singular focus can stifle your curiosity, I've made an effort to avoid putting all my eggs into one basket by regularly forcing myself out of my career comfort zone.

Learn new technologies

Do you work primarily in PHP? Try working through a short Rails or ASP.NET tutorial. It might be frustrating trying to wrap your head around how a different language or framework is structured, but it might also be fun. At the very least, it's a good idea to see how other languages are implemented - "if all you have is a hammer, everything looks like a nail."

Don't fear the legacy code

While I gave an extreme example of legacy code maintenance above, I don't believe all legacy code should be eliminated as soon as possible. There are thousands of reliable, well-built legacy systems in production today, and they represent a great learning opportunity for programmers who only have experience with modern tools. If your company has any legacy code that's related to your current job, take a peek (if you're authorized)! You'll be surprised at how much you can learn about your company's business rules, and you might even find that a problem you're currently working through was solved years ago.

Know your enemy

It's easy to get religious about programming languages, frameworks, and operating systems. If you've ever ever found yourself declaring hatred or disdain for a piece of technology (see Jeff Atwood's classic article on douchebaggery), maybe you should try it for yourself just once. Worst case: your hatred will be verified. Best case: you might actually learn something from the competition. But don't let your preconceptions get in the way of your curiosity.

Don't try to do everything

It's easy to get overwhelmed with all the new platforms, tools, and libraries that seem to be released every day. It's also easy to feel behind when you see hundreds of developers discussing something you've never heard of before. When you read about a product that sounds helpful or interesting, make a note to check back on it in a few weeks or months (or years). If the community is still actively supporting it, then you should investigate further. But if development seems to have stalled, you might want to skip it or find out why it fizzled.

Always be learning

Most of us do have a natural curiosity that led us to a programming career. It's fun for us to feed a few lines of code into a computer and have it do exactly what we want. But as we get more successful and busier, that curiosity can fall by the wayside. It's important to regularly challenge yourself with new ideas to keep yourself sharp and focused, and to remember why you chose your career in the first place.