The Way We Code
[Essay]
My first API reference was the thick white booklet of a TI-83 owner’s manual. It ran about 500 pages in length, the key pages spanning about the last fifth of the book. These were the chapters that covered the constructs of the dialect of BASIC installed on the TI-83. A good chunk of this covered fundamental constructs like “if” and “for”, and beyond that there were only a few standard functions for doing simple I/O and math. All the pieces of knowledge you needed were in that book, and the rest was up to you.
As a professional programmer now, I sometimes find myself longing for the bygone days. Being a software developer today means living in a sea of choices — choices of client-side JavaScript libraries, server-side frameworks, databases, caches, search indexers — all of which demand attention and consideration before new code can be written. The landscape is massive and ever shifting, with old libraries and systems fading away and new ones springing up every year.
Not so long ago, all you needed to know to be a solid web developer could be captured in four ASCII characters, which were, depending on your target audience, “LAMP”, “Java”, or “.NET”. Today, each of these letters is a marketplace filled with different libraries, products, and services, many of which are open-source. That’s not to mention the new types of user interfaces and systems (e.g, mobile, tablet, cloud) used widely today that didn’t even exist a few years back. In the old days, the choices were both bad and limited. Today, the options are much better, but also overwhelming in number and diversity.
There are so many choices of software components today that, inevitably, many choices are made with limited knowledge, based largely on personal bias. Yet each decision carries with it the risk of countless developer-hours of wasted work and the threat of future embarassment. Bad choices will draw the ridicule of colleagues down the road who will have the benefit of hindsight. Assuming a good choice is made, there is still the obstacle of learning how to use the chosen tools: reading the docs, searching for usage examples, and learning new high-level principles and concepts if the library is conceptually heavyweight or complex.
An important corollary of the trend of increasing diversity and choice is that code is becoming more connected. Quality products that target modern platforms in web browsers, on mobile devices, and in the cloud cannot be produced without leveraging multiple open-source libraries. Companies that best understand which libraries to use, how to use them, and how to combine them will be able to innovate and execute much more nimbly and consistently than those that don’t. And companies that invest in making internal code better documented, better maintained, and more easily readable will also reap the benefits seen in the best open-source communities. They will be able to build more robust, better tested, higher quality systems that actually withstand the test of time.
It is a brave new world, and the Cambrian explosion in software libraries has more fundamental consequences than incrementally improving programmer productivity. It gets at the very heart of what it means to be a programmer. It means much less of the job is designing algorithms, architecting basic systems, and writing code from scratch, and much more is interfacing with other teams, being aware of the ecosystem of existing tools and components, and understanding how to combine these into insanely great products. Some have lamented that all the code written today is “glue code,” recalling days when real programmers wrote entire systems more or less from scratch. But this is a simplistic and cynical way of looking at progress. Modern developers are not unimaginative code monkeys, dumbly cobbling together systems from pre-fab parts, but a new generation of pioneers standing on the shoulders of the giants who came before them. We are seeing farther and doing more.
The way we code has changed and continues to change at a rapid pace. Looking at the bazaar of new libraries and systems and the burgeoning ecosystems that accompany them, I don’t think there has ever been a more exciting time to be a programmer. Larger and larger challenges loom ahead of us to solve — challenges that warrant massive systems that deal with unprecedented quantities of data, intelligent systems that encompass more and more capabilities of the human brain, and physical products that lead to unknown places and experiences. As the software world rises to these challenges and gets increasingly more interconnected and complex, the big question facing us will be how we’ll manage the complexity of a growing universe and make sense of it all.
