In a previous blog entry, I wrote about the importance of professional development, especially from within. I'd like to briefly underscore this with a double line written in a heavy magic marker.
One of the major goals of education at the high school level (at least it was when I was teaching) is to foster lifelong learning. I am a strong proponent of this and try to live it as best as I can.
It is also important to recognize, as you get older and more experienced, your ability to take new things and put them into a bigger picture in terms of either abstraction or concrete application. Here's an ideal example, Rick has been writing a series about using stack allocation for performance tuning. I had written a blog entry about this a couple years back which got some helpful comments.
Rick came in to ask me a few questions and in true Steve style, I sent him off with about a half dozen new questions that we raised together and a direction for finding the answers, and a spark.
The point is that most of us know more than we give ourselves credit for. If you choose to believe this then you can take advantage of it to help your colleagues learn. I don't mean necessarily shoving knowledge down their throats (guilty!), but rather finding the opportune moment to add a piece to the puzzle to help sort things out or put in a bigger perspective.
Personal perspective adds a lot to the picture as well. I came into the professional from an old school direction. As an adolescent, I (re)invented a lot of the major elements of computer science and software engineering while coding in assembly language. No, really. I wrote code that was procedural before I had been exposed to procedural programming. Later I wrote code that was object-oriented before I had seen C++ because it solved the problems I needed to solve in a terse, uniform, effective way. As a result, when I look at languages like C# or C++, I often find myself thinking of them in terms of how I would write that code in plain C or in an assembly. I do this because I naturally try to spot bottlenecks where code could be (a) made more flexible and (b) be make faster. For example, I demonstrated this to Rick again by showing a traditional C++ code pattern and then showed how it could be implemented in C and with a tiny bit of refactoring would shave a half dozen instructions off an inner loop without losing any of the flexibility. The point there is that I had a perspective that he didn't and by sharing it, I hope I just saved Rick years of work. It took me years, after all, to learn it.