Theory: Context Is the Key to Code
The biggest difference in my mind between how computer science is assessed and how computer programming works in practice is the removal of context. Code in the whiteboard interview assignment and the CS classroom is pristine, perfect, isolated from all surrounding impurities. Any interfaces in and out of this plane of pure imagination are, like the blood-brain barrier, clearly marked and even more clearly defined, never complex or unknowable. The data comes in a format specified by the question and leaves in another, similar format, or is automatically captured when the output buffer is flushed. Actual, far more complex code works in the background (if code is executed in this fenced box) to ensure that the little frustrations of programming never intercede with what is perceived to be the pure core, the “true test” of one’s technical mettle.
Why is this a problem? The problem, in my view, is that the people selected through this process are woefully ill-equipped to deal with the practical nature of code - that is to say, how the practice of software development is carried out in the real world, so to speak. If code is the key to the digital era, then context is the key to code. Unless you are dealing with only hand-built computer hardware, almost all code you will write will build on the code written by others - often this is explicit, such as when you invoke a library, but just as often this is implicit, such as when you make use of a programming language whose interpreter has been constructed by another. Modern programming, then, is about the navigation of multifarious contexts. Any web developer will know this through the concept of the tech stack, layers of technologies that synthesise with each other to provide the necessary functionality modern web applications require, but the concept is far more universal than that. Any time we make use of multiple software suites, languages, modules or even scripts in the same project, we are combining contexts.
Contexts, of course, don’t always play well with each other. The dreaded dependency errors and data format incompatibilities are very often only the most surface sign of this issue - it can just as often be seen in the design patterns invoked by different libraries, differing approaches to similar problems like managing user sessions or data storage. The “little frustrations” we suffer each time we merge these different contexts are not just little frustrations, they are demonstrations of a different type of skill set, one that is, I would argue, just as if not more important than a theoretical grasp of how to reverse a binary tree. For complex problems people have always tried to create complex solutions, all-in-one platforms and ecosystems like Tensorflow for machine learning, but they will never be sufficient. More than bodging or hacking, the modern software engineer learns how to harmonise different contexts, and turn them into reliable, useful code that performs to specification. The ability to see a practical, context-sensitive problem, diagnose the source, look up a solution (likely on StackOverflow), and then implement that solution in a reliable way is just as valuable as the ability to turn a theoretical algorithm into equally theoretical code. After all, how many of us have needed to reverse a binary tree “by hand” in our work?
I have no grand thesis, no sudden twist to share, except what I have already told you. As code grows more complex, as our problems become more difficult to visualise and solve using a single context, the need for the context-confident engineer grows by the day. I just hope that we’ll be able to find them, when the time comes.
No comments yet.