It is a well known fact that the software industry moves at a mind-boggling pace. At times, perhaps the pace is faster than is good for the health of the industry, and (quite literally) for the health of the people working in it. New technology is constantly introduced, and major paradigm shifts are introduced at almost every major industry event. I certainly can not claim to understand all of the business industries that exist today, but I am not aware of any other trade that introduces new knowledge (often of revolutionary rather than evolutionary nature) at the same rate. I would go as far to say that rapid change defines many aspects of being a software developer.

In light of all of this, it always surprises me that software developers and their employers do not have a good plan as to how to cope with the situation. Working as both a consultant and magazine publisher, I have contact with a large number of developers, and very few of them have a well-defined and regular research and training program. Very few employers seem to have a standardized and recurring developer evaluation process. Often, developers themselves are very motivated to learn new things, but the process is generally ad-hoc and a reaction to the market. Developers may grab a magazine or a book to learn about the technology that they need for their current project. This often results in all but the most dedicated learners having to constantly catch up with the industry. And catching up is hard!

My personal opinion is that developers need to be able to get to a point where they can be pro-active about new technologies. It is a little bit like surfing: if you can manage to stay ahead of the technology wave, it will push you into a hell of a joyride, but if you are just behind the wave, you face some seriously hard uphill paddling, and the danger of getting sucked back out to sea and being run over by the next technology wave.

This is easier said than done of course! But why is it that so many people keep paddling against the flow, struggling to keep their head above water to get a short breather? I believe that it has to do with the depth of knowledge! I meet a lot of people who have a knowledge base that is the proverbial mile wide, but only an inch deep. And this makes it hard to work in a business that basically trades in the application of knowledge in minute detail. Not having a solid basis and a good understanding of core computer science topics leaves developers with hard to grasp concepts.

It is difficult to understand the .NET Garbage Collector, when you do not know how memory is allocated, how variables are managed, and what the key issues are that go along with that. Often, people understand the syntax of their (pre-.NET?) language of choice, and know how to use it to do things like create memory variables. But more often than not, the understanding only goes as far as “this is how I can temporarily store a string.” What it really means to store that string in memory and what has to happen when that string is manipulated remains unknown, even in concept. As a result, it is very difficult to understand that .NET StringBuilder objects perform better in certain scenarios than simple strings. While developers with an understanding of memory management can look at the situation and say “ah, ok” the first time they read about this, developers without this basis have to familiarize themselves with convoluted and seemingly arbitrary rules that describe when to use which object. Suddenly, one developer faces a huge learning curve (and a serious level of obscurity), while another spent a few seconds or minutes on the subject and gained a thorough understanding.

I always like to compare this to a game of baseball. If a player does not know how to get to first base (and that he in fact can safely remain there for a while), he will have a very hard time to score a run. The desired result of scoring a run is pretty clear and simple in concept, but one needs to understand a bit more about baseball to play it successfully. Sure, even if a player is not aware that first base is a safe haven, he might still score the occasional home run and become a star for a little while, but it will have required near super-human effort, and overall, he will not be very reliable, and thus not a very valuable player.

But how can one gain such a solid understanding? Read. Experiment. Attend user group meetings and conferences. Mingle with like-minded spirits. But most importantly, pay attention to mixing up the topics. You may be an ASP.NET developer who mostly uses VB, but have you ever considered reading a book about software architecture? How about peeking into a Java or Linux magazine? How about reading that article on the Intel site about how processors save power? Perhaps the “Dragon Book” (a classic of computer literature that deals with building a compiler) would be an interesting diversion between that “Understanding VB.NET” and the “.NET Web Services” books? Also, read some blogs! Often, blogs (especially from Microsoft Visual Studio Team Members or established authors and experts) provide very valuable insight and only require a few minutes to read.

I also do not consider any learning efforts wasted! Sometimes people tell me that they are “glad to not have spent much time learning all this COM stuff,” since they now program in .NET, but I beg to differ! Many of the things one had to learn for COM are very valuable in the .NET world. Perhaps you are not as likely to have to deal with IUnknown in .NET (although… who knows? Interop anyone?), but the concept of interfaces and the concept of describing objects in generic terms and finding generic ways to invoke them is even more important today.

It seems to be a conventionally accepted wisdom that developers with a computer science degree do not know much about the “real developer life.” And in fact, when one hires computer science graduates straight out of the university, those people are unlikely to have knowledge about the most up-to-date technologies currently used in our job. But that does not mean that there is no value to a computer science degree! I often see that these former students struggle quite a bit in their first projects, partially because they are in a catch-up position, and partially because academia is significantly different from the adventures one goes through in business. But a year later, when the whole team has to get used to the next paradigm shift, it is often the computer science graduates who take the learning curve with the least amount of effort, while the rest of the team has to make up for their lack of fundamentals with sheer willpower and motivation.

Of course, some people may argue that most developers do not need such a deep level of understanding anymore. Developers should focus on the business aspects. They should focus on the goals of the task ahead rather than technical details involved. I completely agree with that! However, I think we still have a very long way to go before we get there. Wanting to get to that scenario does not mean that we can already pretend to have reached it. Today, we need to know about objects. We need to know about messaging. We need to know a lot about the technical aspects of our job. And frankly, this is what makes being a developer so attractive to me. Once we get to a point where we do not have to worry about technical details anymore, business managers will rejoice, but the profession of a software developer as we know it today will have all but vanished.

So let's go play some ball! But let's do it right. Software development, just like baseball, is a team effort. Scoring RBIs is easier than scoring home runs, just as it is easier to learn how a StringBuilder solves the string handling problem you are already aware of, rather than trying to understand StringBuilders with no prior understanding of the subject. Go ahead and get to first base, and CoDe will help you get home safely.