I’ve recently been pondering what it means to be a software developer, and the ways in which it is changing.

I have been programming professionally for almost 20 years now, and I come from a generation of programmers that grew up with computers that were more like toasters than network appliances. Programming was, by nature of the hardware and the culture, a solitary undertaking. We sat at our desks and poked and prodded these little glowing boxes trying to get them to jump thru hoops for us. By and large we were self-reliant; if we needed the computer to do something for us, we had to write the code ourselves. Thus, the “Not Invented Here” phenomenon.

Then a remarkable thing happened. These boxes all started talking to each other in the form of the Internet, and we came to take advantage of their interconnectedness. This brought about a revolution in the kinds of software that we created and eventually the value in what a computer could do was supplanted by the value in what it could talk to. I won’t belabor this point; I think it’s obvious, just unplug your network connection and see how much of the software you rely on still works.

We are experiencing a similar paradigm shift in our roles as software developers. Nowadays, much of the code required to solve a problem has already been written and is freely available. Our responsibility is not to rewrite this code, but to harness its power by gluing it together in the right fashion. This requires working with the people that are responsible for these bits of software to suggest improvements, bug fixes and, yes, on occasion actually write some code for them.

The purists out there will argue that this has long been the responsibility of a “good engineer”. But that is only partially true. It wasn’t until recently that the toolkits and libraries we depend on have opened up to let us look at the source code and creative process that goes into them. It’s only with the advent of sites like SourceForge.net, Mozilla.org, or CPAN that we can count on having access to the developers responsible for the tools on which we depend. Prior to this, the effort required to get changes made to proprietary software was simply too great and the reward too small. It would take months, or even years, for a bug fix to become available, by which time it was usually too late to be useful.

None of this is particularly new or insightful. These are simply observations at a time when the gestalt surrounding “open development” is achieving a critical mass. The act of programming is changing such that the ability to contribute to the development of someone else’s code, regardless of direct benefit to yourself or your team, is not only valued, it is expected, and even demanded.

Thus, developers and companies alike will need to adapt. This will be particularly difficult for those that excelled at being isolationist or selfish. For, inevitably, they will find themselves left behind rewriting the code of a movement that has long since moved on.

[Image based on art from René Magritte]