Software Developers build things. Not physical things that people can admire from afar but rather invisible instructions that travel along wires as pulses of electrons. These instructional bursts can move data around from one place to another, add subtract multiply and divide numbers, and even draw complicated objects on the screen. A computer is like a piano; by itself it just sits there. It takes someone with enough persistence to sit and learn the thing to make it do something.
Persistence is a rare quality but one that is sorely needed when programming a computer. After all, programmers must painstakingly assemble instruction after instruction. Never was this more true than in the old days when programmers had to think in terms of ones and zeros. 10010101 could mean store a number, for example, while 10111010 might mean add two numbers. Programming this way was the only way to get things done and it drove many to the point of insanity. It is the equivalent of building a house by molding your own nails and milling your own two by fours. In other words, it took a lot of grunt work to get anything useful done.
Programmers understood this and in time became determined to make programming more time efficient by introducing what they like to call abstractions. Abstractions increase productivity by abstracting away the details of how something works. For example, compilers were introduced that would take high level languages like the C programming language and compile it into ones and zeros that the CPU understood. Now you could program with nails and two by fours already cut which was a fantastic performance boost.
Taking the idea of abstractions further, libraries were developed. A library consists of many routines—commonly called functions—that a programmer can call to get something done. Want to draw a circle on the screen or do a FFT; chances are some other programmer already created a library to do that and all you really have to do is call it with the right parameters. Forget about ones and zeros, programming became a task of calling a bunch of libraries.
Today there are hundreds of programming languages in addition to C and many more libraries that do everything from request a web page to move a robot some determined distance forward. Programming these days has become a game of how well you know a given set of libraries—typically called frameworks—and what programming languages you know to call those libraries. It’s a world of abstraction upon abstraction designed to make life better.
Before you get the idea that programming today is easy because there are all these cushy libraries to call and high level languages to do your every bidding, think again. Although things are generally easier, the shear amount of frameworks available makes it very hard to know what is going on under the hood. Most of the time you don’t care and frankly don‘t have to. However, every so often you will undoubtedly encounter a library that is not doing what you would expect. A kind of bad behaving library if you will. This is were the trouble usually starts.
During these times, the questions come flooding into your mind. What is causing the issue? Are you calling it correctly? Does it just not work? Should you try to use something else? A road block has presented itself in the otherwise smooth journey of programming bliss and you must get around it and continue on the journey. Spend any time next to a group of developers deeply concentrated in coding work, and it will become painfully clear that navigating road blocks happen on a daily basis. The clues come in the form of expressions like: “That doesn’t make any sense” or “What were they thinking” to more colorful expressions of the four letter kind.
Call it what you want but road blocks are a fact of life and developers have a similar set of terms for there solutions. Some issues will often have a well know solution called a “workaround”. A workaround is like an official response from the library creator in effect saying we screwed up and this is how you get around the issue. If the problem is less known it becomes the task of the developer to creatively implement a way around the problem in what may, depending on the degree of elegance, be referred to as a “kludge”—a kind of less elegant quick and dirty solution. Regardless of how the issue is solved, in the end the developer must make a choice. Economics have a term for this called opportunity cost. By choosing one thing you forgo the potential benefit of choosing the other.
What makes this so fascinating is after lots of workarounds or kludges you could look back at the web of decisions made and wonder if you made the most optimal path. The shear amount of paths through the web of choices is what I call the developer decision space. Two programmers may achieve the same result through different paths but one will be more efficient. The new game becomes navigate through all the pitfalls and landmines with the most optimal path possible.
To get a feel for how this plays out, I have a recent example. For work, I have been tasked with trying to get some of my code to run on the new Microsoft framework called Azure. Azure is a cloud platform that allows you to host your code on Microsoft servers rather than buying your own.
Everything was going smoothly until I hit an issue with uploading my app to the cloud. Staying as light as possible on the technical jargon, I had some loose .NET assemblies in a folder under the root application that were not getting included into the Azure package.
My first attempt to resolve the issue fell into the kludge category. I had found out about a way to create the Azure package unencrypted that would allow me to manually put my assemblies there. This turned out to not work as I received an error when uploading it to the Azure cloud—I contributed this to some check sum they must have in the Azure package. With this part of the decision space blocked, I focused my attention on other ideas. I decided to included the assemblies into the ASP.NET project which solved the issue but caused a new problem—my included assemblies were Silverlight ones and ASP.NET was trying to load them on startup. That forced me to try a different idea of copying the assemblies into the Azure local storage on startup which ultimately worked.
I shared this experience not to show that I am some technical genius who solved a problem but rather to illustrate the complex interplays of the decision space because an interesting thing happened when I uploaded my final solution to the Azure cloud. I got an error; an eerily familiar error about an invalid package similar to the error I received when uploading my first attempt with the unencrypted package. It turns out the reason for the error is a bug in Azure where you have to delete your entire Azure project and re-add it rather that upgrading it. After I did that my final solution worked but I couldn’t shake the feeling that I had missed the most optimal path.
The pestering feeling was the result of discovering new information that I didn’t posses at the time of my first failed attempt. It wasn’t until I was down other paths, trying new things, that this new information came to light which had the potential to open up other paths that I had previously closed.
In my case, I wondered if the error I got on the unencrypted package, my first attempt, was related to the bug in Azure that I discovered later and not a checksum thing after all. If that was the case my first attempt, which was a couple of branches higher in the decision space, was most optimal.
This is what makes programming more of an art than a dull mindless practice most chalk it up to be. It requires the ability to make seemingly unconnected insights and connect them. It is like solving some kind of big puzzle with limited information. As you start to solve the puzzle you learn more and that new information has the potential to unlock a number of issues you thought were previously hopeless.
I am convinced the great programmers have a heightened ability to see these connections. Not only a couple of layers above, like mere mortals, but through most of the decision space. This is even more remarkable when you consider that each decision has an opportunity cost and keeping track of all those decisions that effect other decisions is hard if not close to impossible. But the better these can be tracked mentally the greater the potential breakthrough insight; like Niels Bohr unlocking the secrets of the atom that others failed to see.
Unfortunately, there are only so many Niels Bohrs in the world. However, I believe more developers should put greater effort into understanding the developer decision space. Too often developers make their way through the space by making a decision then immediately relieving their tired brains of the circumstances and implications that justified that decision and move on to the next one. Continuing this pattern a couple more times and it becomes blatantly clear that they have no hope of applying new insights to old decisions and breakthroughs will never happen. Instead what commonly happens is they find themselves wondering in strange roads and thinking to themselves: How did I get here?
I don’t know if this is from pure laziness or simple unawareness. Software development experience tends to help some because after a couple of times traveling strange roads one starts to remember how they got there so they can find their way out. But experience alone doesn’t mean the skill will automatically develop since some experienced developers don’t seem to possess it. If it is unawareness, consider yourself informed. If it is laziness, then you probably haven’t made if this far in the article anyways.
Subscribe