Lost in Thought

Computers are stupid. They take massive lists of instructions and mindlessly process them one by one. That’s purely mechanical, the result of billions of nearly invisible gates flip-flopping in a sea of electrons. A consequence set in motion by these sets of instructions.

Software -- when it is written well -- can be quite intelligent. It can remember things for you, help you organize them, control devices and even assist you in interacting with other people. Where does this intelligence come from?

The act of ‘programming’ a computer is the rather long and often painful process of assembling larger and larger lists of instructions. To get intelligence embedded into these lists it must come from the programmer. Some of these ‘smarts’ are just derived from long understood ways to combine the instructions. Some of them come from the programmer’s intuitive sense of how the world works. Some of them come from the knowledge passed onto the programmer other people who are familiar with the problems.

Thus, the source of any intelligence in the software is the thinking done by a programmer on the vast amount of knowledge acquired in relation to the solution. Programming -- often shorted to ‘coding’ is thinking, and the by-product of this thought is code.

Some code requires deep intensive thought. The programmer needs to visualize the interactions of the data in their mind, in order to linearize it down into reliable instructions. They need to explore all of the dark corners that get implied by the computer’s behavior.

With experience, most code is pretty light thinking, the mental equivalent of ‘jogging’ for the mind. It’s just smaller collections of conditionals and loops that solve very specific sub-problems. When the number of these types of pieces explodes, the heavy thinking shifts towards ways of reining in their organization and consistency. Solutions to the micro-problems in coding are most often black and white, they have definitive answers. While solutions to the larger organizational and context issues tend to revolve around difficult trade-offs, where no answer is completely satisfactory.

One of the main consequences of programming just being thoughts is that muddled or distracted thinking directly determines the quality of the code produced. If someone is rushing through a sub-problem, their answer may be fragile or they may have actually solved the wrong problem. When elegance is achieved in software development -- an increasingly rare occurrence -- it is a consequence of a well-thought out approach and a consistent implementation. The programmer understood a problem so well, that they were able to express it in its most simplest terms, and their own self-discipline was so strong that they dotted all of the ‘i’s and crossed all of the ‘t’s. The details were attended to, no matter how small.

Of course loud environments, excess stress, long hours and rampant disorganization are all easy disruptors for the ability to think clearly. So is rushing through the work as quickly as possible.

For any coding veteran, they can immediately see the underlying quality of thought that has gone into the work, whether it was an interface, API or code-base. The poor quality of workmanship almost ‘glows’ if you know what you are looking for. An interface with endless out-of-place functionality tacked all over its design speaks of disorganization and coders that don’t work well together. Inconsistent primitives for an API cry out the pain of wave after wave of quick hacks to slap on poorly thought-out extensions. A tangled mess of repetitive code sings a sad song of confusion or a rush to just get it barely working. These existing examples of other people’s work not only instruct the computer, but also tell the tales of how they were constructed and how much care and effort went into that process. They reveal far more than just functionality.

Programming is thinking. Poor quality thinking results in poor quality code. Rushed thinking results in poor quality code. Distractions result in poor quality code. Bad morale results in poor quality code. Ultimately the utility of a piece of software is dependent on how intelligent it is, and that comes directly from the efforts of the people that built it. Crap quickly tossed together in a hyperactive sweatshop is, well, crap. If you really want to help people solve their problems, you have to spend a lot of time thinking very deeply about a solution that works. There is no other way.