Something that I've struggled with ever since I started cutting code was to know where to concentrate my efforts when I go home at night and want to learn something new. It's great to download the latest shiny bits of technology and look around to see what's cool, but what I'm really interested in is being able to learn things ahead of time so when these things are needed on my team I'll be able to step up and provide value immediately.
Since I'm on a team that practices Agile development principles, as a developer I am responsible for a vertical slice of development from the user interface down to the database. The gap between user interface and database is so huge, so what the heck do I concentrate on? I could become really proficient in jQuery or ASP.Net MVC so I can be a superstar UI coder, or I could learn NHibernate or SubSonic inside out so I can rock out with the database. But no matter how much I learn about those, they could become worthless to my project if we decide to switch them out for shinier bits.
So as I've gone through a few iterations of learning frameworks and code libraries the one thing that I've found to be true is that learning the concrete implementation of software is not going to benefit me in the long term. What is valuable is reading the code (and API) and seeing how the problems are being solved. Some call these "design patterns". But really it's looking at the problem and seeing how others have naturally melded in to solving the problem in an elegant, easy to understand way. After you've seen the problem solved a few different ways you begin to see these patterns. So when you pick up the latest shiny bits of the latest MVC framework or remoting software, you're going to immediately start looking for the patterns you've seen before and start asking questions about their specific implementation. I think this makes "just in time learning" much easier.
So in summary, I think the best way to learn software and how to solve software problems is to read a lot of code. Identify key patterns of problem solving in other people's code. Don't concentrate on their API, but concentrate on the abstract ideas that they're using to solve their problems in a robust and elegant way.
2 comments:
I think you're on the right track: How to solve the problem will always be a bigger deal than what you use to solve it.
However, picking up the latest and greatest can still serve you well. If you take Jim Holmes's idea of being a specializing generalist to heart, then knowing a little about a lot and a lot about a little can still benefit you.
Coincidentally Ayende just wrote a post that really is in the spirit of what I was trying to say in this post. It is at least complimentary.
He says it perfectly... it's innovation vs derivation. Keep your eye peeled for the things that will innovate our jobs, but only give a glance to the things that are simply repeating what has already been done.
Ayende's Post
Post a Comment