I was a software programmer in the US Air Force in the late 80’s and early 90’s. Gratefully, I was a part of a “modernization effort” to pull systems from IBM mainframes into client-server applications. I was sent to Oracle database classes, object-oriented analysis and design classes, and was able to experience what worked and what didn’t work in various software projects. I don’t know if the “modernization effort” was a success for the Air Force, but it provided a great start for me.
We had this idea that all the world needed was a lot of reusable libraries so that it didn’t need to write the same code over and over gain. We applied this to user interface elements as well as business domain elements. It was a vision.
So, here we are 20 years later and much of that vision is realized. There are reusable frameworks and libraries to cover just about anything (except maybe the business domain). There are libraries you have to pay for and even more that you don’t. Any successful project today is using more than a few of these libraries, maybe without even realizing it.
What we might not have spent much time thinking about twenty years ago are the consequences that this realized vision would have on those working in the software industry. What we expected was a reduction in the amount of time that would be spent writing code. What we didn’t consider was the amount of time and brain cells that would need to be spent finding and understanding how to use all of the reusable libraries. What the realized vision has done is to change the primary function of a programmer’s job from code writing to researching/learning. We are no longer primarily coders. We are now primarily learners.
It may not be obvious to some people that learning is just as difficult and time-consuming as coding. In many ways it is more difficult, and for three primary reasons. First, the complexity of today’s distributed systems results in a great diversity of libraries to learn. Second, all of these libraries are changing all the time. Finally, there are still decisions to be made in terms of software design theory in a world without a consensus on the best approach.
Regarding diversity, the number of libraries to learn to get a typical web application to work is immense. Each library is specialized, but in order to use each of them correctly really requires a level of understanding that takes time to acquire. I’ve seen what I call “programmer grunts” who just want to know how to use something. The reality, though, is in order to be a truly useful developer you have to know more than how. You need to know why. This takes a real effort.
Regarding change, libraries today are changing faster than the time it would take to document how to use them. This is a cycle that is perpetuated by successful reuse. The more I successfully reuse, the faster I can implement change, which means that those people who are reusing my software have to be able to adopt my changes. Any software organization that thinks they can stay still in terms of the versions of software that they use for more than a year is clueless to the rapid nature of change in the software cosmos. At this time, change is not creeping anywhere. It is exploding. And it isn’t changing for the sake of change, either. It is getting remarkably better all the time. To fail to take advantage of this change is to fail to understand the reason things are changing.
Regarding software design, there are theories on the move in every area of software development, and they come in waves that are not concerned about a particular project’s schedule. A software developer has to pull from the information that is “out there” and make real decisions as to how much of that information will affect a particular software design. This is not monkey work, and the more a developer understands about the parts and pieces that are being reused, the more practical and helpful particular design decisions will be.
So, how does an old fart like me cope with the new job description our vision from twenty years ago resulted in? I have to realize that I am not a software programmer anymore. I am an Eager Learner. My job requires this now. I cannot ever depend on what I knew 5, 10, or 20 years ago. My past experience cannot define what I do for 8 hours today. It just helps me understand how I need to adjust how I work today. If I’m not ready to learn and change at all times, it may be time for me to turn in my IDE.
This is not instinctive to someone older than 40 (or 50, or 60). We would like to be experts. The reality is that the humility and eagerness to learn that we had when we were 24 is more important now than it was back then, whether we like it or not.