Wednesday, April 1, 2009

How will you learn the next wave?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_will_you_learn_the_next_wave.htm]

New technology is constantly coming out. Some of these are small - a new tool, a special trick, or some open source library - and these can be learned easily enough. However, every few years, there's a fundamentally new wave of technologies that makes the previous wave obsolete. For example, classic ASP to ASP.Net 1.0, to ASP.Net (3.5 with Ajax, JQuery, and MVC) to Silverlight. - every few years there's a significantly more powerful UI technology.

So, the question becomes, how do you continually keep up with the next wave?

You have three main categories of options:

  • Your company trains you. This was popular during good economic times. Some companies have a training budget based on a percent of the employee's salary.
  • Your company doesn't train you, so instead you train yourself.
  • You don't keep up, and eventually become obsolete.

The last option speaks for itself - but there's a difficult balance between the first two. Every developer should be able to ask their manager "What role, if any, does the company have in assisting me to learn the next wave of technologies?" Every manager should have a ready answer.

Realistically, you need both internal motivation and external support. For example, if your company won't even pay for a $30 book on a hot new technology, then you're screwed. On the other hand, you simply can't learn a whole new technology by passively skimming blogs during your lunch hour.

Personally, I'd emphasize the concept of an upward spiral. If you want to be a decent developer, be prepared to invest:

  • Time - prepare to spend on average of at least 8-10 hours a week doing continual education. Maybe you're working 60+ hour weeks at your company, and the 10 hours is part of that. Maybe you have a "cushy" 40-hour week job and you do the 10 hours on your "free time". Sure, there are weeks (or even entire months) where life needs you to take a break. Likewise, there will be other times when an in-demand tech first comes out that you may be sprinting.
  • People - Try to get to a live-person event at least once a year, such as a user group or conference. Also, explicitly seek out peers who you can collaborate with (even doing informal code reviews with your coworkers, or discussing ideas during a lunch break).
  • Blogs - Use a blog aggregator to continually monitor the industry leader's blogs. This will give you a heads up of new techs coming down the pipeline, so you can prepare. If the tech actually has potential (as opposed to just some other buzzword), you'll see it light up on multiple people's blogs.
  • Books - Especially for a new wave, or for matured design patterns on existing techs, try to read a full book at least twice a year (I think once every other month is more ideal, but there's a balance).
  • Projects - If you have the opportunity, put in the extra work to get on a project that uses a new technology that appeals to you. Ultimately, the best way to learn a new tech is to actually use it, and unless you use it on a real project, you'll always remain a hobbyist.

Essentially, learning a new technology takes hard, pro-active, work, which many devs are already willing to do. The question becomes how to best maximize your investment on that hard work.

No comments:

Post a Comment