The Passionate Programmer

Act on It!

On a piece of paper or a whiteboard, list the dimensions on which you may or may not be generalizing your knowledge and abilities. For each dimension, write your specialty. For example, if Platform and Operating System is one of your dimensions, you might write Windows/.NET next to it. Now, to the right of your specialty, write one or more topics you should put into your “To Learn” list. Continuing with the same example, you might write Linux and Java (or even Ruby or Perl).
As soon as possible (some time this week at the latest!), find thirty minutes of time to start addressing at least one of the “To Learn” items on your list. Don’t just read about it. If possible, get some hands-on experience. If it’s web technology, then download a web server package and set it up yourself. If it’s a business topic, find one of your customers at work and ask them to go out for lunch for a chat.

Act on It!

What are your biggest career fears? Think about the last few career choices you made. They don’t have to be big decisions (after all, if you’re making fear-driven choices, your decisions likely aren’t big anyway). They could be whether you took on special assignments or whether you applied for a job change or promotion. Make a list of these choices, and, for each one, force yourself to make an honest assessment: how much was your decision driven by fear? What would you have done if fear had not been a factor? If the decision was indeed fear-driven, how can you reverse it or find a similar opportunity in which to make the less fear-driven choice?

Act on It!

Learn a new programming language. But, don’t go from Java to C# or from C to C++. Learn a new language that makes you think in a new way. If you’re a Java or C# programmer, try learning a language like Smalltalk or Ruby that doesn’t employ strong, static typing. Or, if you’ve been doing object-oriented programming for a long time, try a functional language like Haskell or Scheme. You don’t have to become an expert. Work through enough code that you truly feel the difference in the new programming environment. If it doesn’t feel strange enough, either you’ve picked the wrong language or you’re applying your old way of thinking to the new language. Go out of your way to learn the idioms of the new language. Ask old-timers to review your code and make suggestions that would make it more idiomatically correct.

Act on It!

Find a “be the worst” situation for yourself. You may not have the luxury of immediately switching teams or companies just because you want to work with better people. Instead, find a volunteer project on which you can work with other developers who will make you better via osmosis. Check for developer group meetings in your city, and attend those meetings. Developers are often looking for spare-time projects on which to practice new techniques and hone their skills.
If you don’t have an active developer community nearby, use the Internet. Pick an open source project that you admire and whose developers appear to be at that “next level” you’re looking to reach. Go through the project’s to-do list or mailing list archives, pick a feature or a major bug fix, and code away! Emulate the style of the project’s surrounding code. Turn it into a game. Make your design and code so indistinguishable from the rest of the project that even the original developers eventually won’t remember who wrote it. Then, when you’re satisfied with your work, submit it as a patch. If it’s good, it will be accepted into the project. Start over, and do it again. If you’ve made decisions that the project’s developers disagree with, either incorporate their feedback and resubmit or take note of the changes they make. On your next patch, try to get it in with less rework. Eventually, you’ll find yourself to be a trusted member of the project team. You’ll be amazed at what you can learn from a remote set of senior developers, even if you never get a chance to hear their voices.

Research current technical skill demand. Use job posting and career websites to find out which skills are in high demand and in low demand. Find the websites of some offshore outsourcing companies (or talk to employees of those companies if you work with them). Compare the skills available via these companies with the high-demand list you compiled. Make note of which skills appear to be in high demand domestically with little penetration offshore.
Do a similar comparison between leading-edge technologies and the skills available via offshore outsourcing firms. Keep your eyes on both sets of technical skills that are underserved by the offshore companies. How long does it take for them to fill the holes (if ever)? This time gap is the window during which a market imbalance exists.