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.