I read a few really great articles this week that completely changed my perspective on both the amount of time and effort I spend on practicing my craft as well as the methods I go about developing software from day to day.
The first article I read was Being the Averagest by one of my heroes; Steve Yegge. This is a great article that will be sure to make even the most talented developer a little uncomfortable. Steve's article shows us that programmers grow more complacient over time because there is no way to quantitatively measure how good of a programmer you are. This leads to a false sense of awesomeness and keeps us from reaching our full potential.
Steve says that humans tend to practice what they are already comfortable with instead of pushing the boundaries to actually make significant progress
I think I should reiterate a distinction I made earlier: programmers usually are learning new things on the job, but their self-directed study is typically just reinforcing what they're already comfortable with. C++ programmers learn more C++, Java programmers learn more Java, Perl programmers learn more Perl. Linux users ignore Windows and vice-versa. UI developers don't learn tools or systems programming, and vice-versa. People stay in their comfort zones. This isn't just true of programmers, of course. As a guitarist, I constantly have to fight the urge to practice the way all bad guitarists do worldwide; namely, to play the songs you already know from beginning to end, hoping that next time through you won't make the same mistakes. With that style, all you're doing is practicing your mistakes. The right way to practice a piece is a lot harder and far less instantly gratifying, but it's the only way to move up to the next level as a guitarist. (That took me a decade to figure out as well, even though people all around me had been trying to tell me. It took an embarrassing lesson with David Russell, a grandmaster guitarist, before I finally paid attention.) People pushing within their comfort zone may feel like they're learning more, but it's really just more of the same. And it's highly unlikely to push them past the Blub Threshold and into a higher stack-rank bucket, or into a different job category or job level.
So, the key here is to practice better. We have to get out of our comfort zones and work on things that will drastically improve our understanding of programming/math/science/etc.
How do you practice better? Simple, by reading and writing. I think that technical books are a fantastic resource and much more important that people give them credit for. Sure you can find almost any type of tutorial online that will help you on your current project, but what if you want a much deeper understanding of the source material? Stuffing your brain full of different language features that you normally wouldn't encounter is a great way to learn things that you normally wouldn't.
Next, and most importantly, we need to actually write code and lots of it. Reading in our profession just isn't enough, we need to reinforce that knowledge by actually doing something. It is only though doing that we actually begin to understand what is really going on.
Now that we know what needs to be done, how do we put it into practice? I think working towards a certification is a step in the right direction. Certifications are tricky because you are never quite sure how much value the actual piece of paper will give to your career. Most people think that their time could be better spent doing something else. However, in this case, it's not about the piece of paper at all, it's about the journey. At the end of the day, when you get a technical certification, you have completed all of the necessary steps that says this person has an in-depth understanding of X.
Another great way to improve our existing skillset is to practice a new development methodology. One promising article I came across is Uncle Bob's Three Rules of Test Driven Design. I have been looking for a way to improve the quality and consistency of my unit tests both at work and on personal projects and I think this is a great way to get started. Now, do I think TDD will magically make every software project a success? Of course not. However, when trying to improve a specific skillset, it can be useful to practice a new methodology and make your own decisions when to use it and when it can be ignored.
We need to constantly be looking for ways to practice and improve our technical skills, especially in such a fast moving industry. Hopefully this article got you thinking about what you can do to practice better. Remember, this isn't an overnight thing, it's more of a ten year thing.