The Codist

When I started my programming career as a professional back in 1981, virtually everyone involved in making computers do things was a programmer. Now everywhere I go there are more specialized roles than I can keep track of. Whether you think that is good or bad one thing seems inevitable — the general purpose programmer is becoming obsolete.

Two major changes over the years make me wonder if the next generation of programmers will be one trick wonders.

Division Of Labor

In bigger IT organizations the division of labor in building applications keeps dividing faster than a hydra hit with an ax. When I started at General Dynamics we had programmers, a manager and often not much else. Once I started Data Tailor in 1985 three of us built Trapeze and we all functioned as programmers, designed the features and the UI together. Persuasion was fairly much the same, with the primary author and the 4 of us working together although Aldus provided some real QA and a product manager. For Deltagraph our team consisted of a product manager, 4 and eventually 5 programmers and a couple QA people. Again we designed the UI, corroborated on features and did all the programming.

I didn't even hear the term architect until I started doing web for a little consulting firm in 1998; we mostly did our web programming in WebObjects at the start and during the next 4 years I often functioned as architect, analyst (figuring out with the customer what was needed), project manager, programmer and UI designer. We had an artist who rarely did design, and a DBA who mostly did system stuff. Otherwise each team generally worked the same way on projects. Sometimes the customer paid for a separate project manager but that was still rare. We did have people who specialized in hardware and systems, but programmers generally did everything software or UI related. The cool thing was being able to understand how everything could work together and gain experience in doing all aspects of creating software.

As the dotcom era collapsed and I worked at a few other places I started to see and be forced into more specialized roles. Suddenly architects were more about high level stuff. Web designers did UI. Project managers made decisions. Coders wrote code. I remember an interview where the group I met with had an architect who never wrote code but created architectures, lead programmers who designed classes but never wrote code and programmers who filled in the classes. No one was allowed to overlap at all and they were proud of how organized they were. I couldn't run out of that interview fast enough. Yet it was a harbinger of what was to come.

As an architect at a financial services company I made sure I still got to program. I was the first person to use Ajax (soon after it was named). I still got to build actual applications in addition to functioning as an architect.

My foray into working at a healthcare company showed me that my era of doing it all was coming to an end. Here they had project managers who only coordinated, business analysts who only talked with customers, another group that only wrote process documents, architects who created architectures, project leads who dictated how software would be written, UI designers who provided all UI designs, database designers who controlled databases and others who managed database infrastructure. Oh and a few programmers who purely wrote code. It sure sounded organized. Yet what it really was was inefficient. Whereas earlier everyone involved in a project knew everything now we had eternal coordination meetings, incredibly detailed documents that took months to produce, and very little was actually accomplished. When I left there was one project I had estimated at two weeks worth of coding where we had had six months of weekly in-person and phone meetings and for which the requirements document was nearly 120 pages which had occupied a single analyst the entire half a year to produce. I'm pretty sure the project could have been written a dozen times over during this time.

Narrower and Narrower Programmer Skills

The other specialization irritation I see is where programmers are hired based on a continuously narrowing set of skills. Whereas in the early days you were hired as a programmer, based on experience in programming, today it's more likely that you know version X of programming technology Y. People want a square programmer who fits in a square hole and has done nothing but be a square. We want an iOS+Android programmer, we are looking for someone with Java on WebSphere, you need 8 years of .NET, or you must be a Spring guru.

Sure, programming today is far more complex than it ever was and it's tough to be good at a broad set of technologies since there are so many. But the underlying issue is that you rarely get the chance to do something different than what you have been doing. You are typecast today based on your last couple of jobs. Even within a single organization the opportunity to master multiple technologies, must less disciplines, is a thing of the past. Can I be a programmer and UI designer? Sorry. Can I talk with the customer but still write the implementation? Nope. Can I architect a solution and deliver it? Are you nuts?

Sure that's what people want today but for me I find it sad. Today I work as an iOS programmer but designing the UX architecture, the UI, deciding on features, working on the back end and working with customers or upper management is no longer part of my job, and that makes me sad sometimes.

Of all the projects I have done in the second half of my career the most fun I ever had was a huge project back in 2000 which was done by exactly two people. We met with the customer, educated them on what was possible and understood their business, I built the whole UI and the other guy built the database and together we wrote virtually all the code. We also managed the systems during development and provided a continuous running version for the customer to work with. The project was our first in Java and had both an external web application for the external customer and internal workflow for the internal team with full auditing and management features.

It was a great success and saved the customer millions of dollars per year and ultimately was automated (which sadly cost the entire internal team 120 jobs). We did most of the work in six months before the customer's IT decided to get involved (they then took six months to implement the login page!). It was fun, rewarding, successful and cost almost nothing compared to the financial benefit. That was the last time I ever got to do everything like that.

I guess nothing can ever be the same but what I find sad is that in specialization you wind up with easy obsolescence (I know one thing, if it goes out of style I'm toast) or cement technology (we know this one thing and damned if we will ever change). The more things you have experience in as a programmer the easy it is to learn something new, and the more likely you are to be willing to try something new (but still be able to separate new gold from new turds). The more organizations specialize the less efficient they become and the more coordination they require. Despite a desire to be "Agile" the less agile they become as a ponderous division of labor makes it difficult to move quickly. The more people have invested in protecting their narrow piece of the pie the less likely the pie will ever be baked.

No, I'm not some old guy yearning for the days where all I needed to know was K&R C, 3 binders of Inside Macintosh and a 68K assembly manual. But I do wonder if the modern silvers of programming knowledge will lead to less willingness to try something new, create something better or just get'r'done.