The Craft of Code
Software developers are a dime a dozen. Between university Computer Science departments pumping them out as fast as the debt can be run up, to boot camps, self-teaching, and the “tangential to my job” people finding themselves writing code, it is easy to see that this isn’t the most difficult of disciplines to learn. As with anything though, the difference between the merely capable, the competent, and the master can be stark.
In a simplified view, code is a language that directs the computer on what to do, how to do it, and when. As with any language, there is a certain grammar that is necessary for proper understanding. Computers are catastrophically literal beasts. They have no capacity for inference, no spark of creativity, which allows them to deviate from bad instructions, no ability to do anything other than what is explicitly and correctly communicated. This leaves the software programmer with a responsibility to translate a given abstract idea into an appropriate computer language with all inference, assumption, and idiom spelled out in explicit detail. We are all human however, and occasionally we get things wrong, or forget that assumptions aren’t allowed. When these mistakes occur, a flaw (idiomatically referred to as a “bug”) is imprinted into these instructions. As a result, the computer does not do what was intended, merely what was instructed. The challenge for the software programmer is to locate where the flaw occurred, and what was intended. They then reformulate the instructions to more correctly direct the computer.
Now consider for a moment that you are a software programmer, working on a project that has been under development for several years. Your boss, or perhaps a user has pointed out a flaw in the system. You’ve never worked on that part of the system, and in fact, the person who did no longer works for the company. You forge into the unfamiliar code, trying to decipher what is going on, not even prepared to understand what might have been intended. If you can pull yourself out of your situation, you will discover why there are so many different computer languages. The *real* consumers of these copious lines of programming code are in fact your fellow developers. No matter what programming language is used, all code is reduced to specific instructions tailored to the CPU that the computer uses. The computer has no idea what language was used, nor does it care. When a programmer wades into a file of source code, they are immediately trying to infer intent, understand functional flow, and discover the patterns that the original author(s) may have used. This is necessary in order to efficiently translate the code back into the abstract ideas that we humans tend to work with.
Now, as an aside, my above point may be slightly misleading. There are functional differences between different languages. Typically, the functional differences are balancing a few different priorities. Some have efficient translation between the language structure that the programmer uses and the low-level instruction-set that the CPU uses. Other languages allow for simplified usage of certain features. Several languages try to prioritize programmer style, to better assist a team to have a consistent and expressive programming style, and make it easier to quickly detect the patterns and intent of the original authors.
At this point, if we can reasonably establish that the primary consumer of programming source code is the programmer, not the computer, then we need to examine how that source code is authored. Is the code clear and expressive? Does it adequately describe the implicit assumptions and intent? Were you to revisit the code after a six-month absence, would you be able to understand what you meant?
Thanks to Moore’s law, computing power is more available than it has ever been. Gone are the days where a simple website requires thousands of dollars of servers installed in an expensive data center. As previously stated, all programming languages are reduced to a common set of CPU specific instructions. Therefore, the biggest difference between languages has more to do with the programmers than the computers. Even the “least efficient” language has a marginal difference in cost compared to the cost of a developer. Of course there are exceptions, but by and large, developer hours are large multiples of cost compared to current computing unit prices. Choosing which language to use has less to do with CPU efficiency, and more to do with developer efficiency.
How do you maximize developer efficiency? This is the heart of the Craft of Coding. First and foremost, whenever possible, spell out your assumptions and intents. This can be done via blocks of comments, functional specification documents, and event flowcharts. It *should* also be done by judicious selection of function and variable names, clear and consistent patterns, and if your language provides, constraining tools such as type systems, constant declarations, and object abstraction. These are all tools used to express intent. They should not be used arbitrarily, “just because someone said to” but should help to constrain the code usage in ways that help to illustrate what the author was attempting to describe.
The spark of creativity is one of the more enjoyable aspects of this profession. The ability to create and form ideas into real experiences gives me no end of satisfaction. At times, to some programmers, it can feel like the job is a thankless grind. The task appears to require nothing more than rote data entry with little if any opportunity for creative exercise. I propose that in these situations, and all others, ensure that you are crafting expressive code. This is an abundant outlet for creativity. Even in those rushed cases where a deadline is looming, and there isn’t sufficient time to do things the way you’d like, carve out the time to clearly express your goals. It will increase the likelihood of successfully reworking the code later on when the pressure isn’t quite so acute. When I return to a well-crafted piece of code months or years later, and can easily discern what is going on, and what is _supposed_ to be going on, I can’t help but get a little charge of pleasure. This is well-crafted code.