In all of my years of being a developer, it’s only been in the past few years that I have really had to sit back and think about the philosophical side of what I do. Prior to that, there was always dealing with crushing deadlines, unreasonable specs, the thrill of a working implementation, and all of the assorted parts of a developer’s life. However, as I have moved into more of a teaching role than a coding role, I am spending a fair bit of my time making sure that I can communicate to my students the very important why questions that surround our industry. One of the most important of these questions is the general concept ‘What Is Programming?’
Historically, humans have used language to solve a problem. Pictograms on the walls of caves would depict the hunting of food. This was a language. As speaking and writing evolved, language became a way to communicate a solution to a problem to another human. What berries to eat, the best way to skin a freshly slain bison, how many shells you would take in exchange for a blanket, where to hide your treasures…these are all tasks that one might go to another for a solution. If that solution could not be communicated, it was fruitless. Knowledge could be shared, if only there was a way to codify it. Hence, language. When we think of programming, we think of syntax and math and logic usually. However, programming is an expression.
Programming is a way of expressing one’s own interpretation of the best solution to a problem. It is a way to be eloquent, or terse, depending on the nature of the problem. And the language would express, most importantly, a repeatable solution. If I give you directions from your front door to the nearest ice cream store, the result of following those instructions would be repeatable. The same is true for a computer program. If I give it my starting balance in my checking account and a list of all the transactions, it will always be able to analyze the numbers and tell me how much money I don’t have, as well as telling me that I shouldn’t have gone to the ice cream store. And this outcome will be repeatable.
Many times, the reason or motivation behind creating a program to do a task and provide a solution is to convert an analog process to a digital one. A perfect case is an organization that I helped recently had an attendance process where staff at a remote event would have a paper sign up form that attendees would fill out. That form was then photographed with a smartphone, emailed to the head office where a local staff member would have to bring up the photo from e-mail and physically transcribe the information into a spreadsheet. That spreadsheet was then saved as a CSV and imported into another tool. I’m tired just from writing that out, much less having to do that process several hundred times every year.
By getting a tool built for them that would allow staff members to digitally input the data and have it post to an API backend which would record the data and allow reporting to be done in real-time, this organization was able to save hundreds of hours of work each year. Literal months of their staff members’ lives was now returned to the organization simply by transforming an analog process into a fully-digital one. Programming is about progress, bringing tasks that have been done manually for long periods of time into the modern era by digitizing the workflow. Thanks to the ‘repeatable solution’ philosophy I discussed above, programming is enabled to provide real-world solutions.
One of the maxims which I often preach to students is that everything in programming comes down to the acronym LSD. Not the hallucinogenic, but instead LSD stands for Logic, Syntax, and Data. If you think about it, every bugfix is tracking down which one of these three things has failed in the execution of the program. Sometimes, that bugfix is one that stops the program and generates a stacktrace. However other times, it is an unintended behaviour that you have to trace the logic of to understand how to change it to a better set of steps. Programming is breaking a solution down into steps so small and finite that even a computer can do them. Of course, because computers are dumb we have to be very precise in the way we present the solution to our problem. That process of deconstructing the problem is a core aspect of programming.
Quite often, one of the best ways to approach a problem in programming is to start at the solution and work backwards. The process of figuring out what each prior step would be in order to get to the solution you envision is a critical piece of planning out a feature. Sometimes this can even go back to the analog and be done with pencil and paper, or whiteboarded, for the purposes of visualizing what the structure of the code will be. It will also generate a set of pseudocoded descriptions which can even be converted into TDD or BDD specifications that can help to guide the development for the developers.
Each of those technologies will have its own API and idiosyncrasies that will have to be implemented. The developer, by trade, is skilled in not only being able to understand the logical flow of information and execution which defines the solution they are building, but implicitly they are skilled in synthesizing these disparate technologies and skill sets into a single, unified effort to build a multi-tiered architecture which can accomplish their programmatic goals. The closest analogy is the role of a chef, whose knowledge of food, chemistry, knife techniques, cookware, presentation and seasonings can combine to produce a meal you may never forget, the developer synthesizes all of their knowledge into the code they write.
It cannot be stressed enough that programming is enjoyable. As a developer, there is an opportunity to create something new out of apparently nothing. A blank editor window is not an obstacle, it is a challenge. A developer’s ability to identify an analog problem that can be resolved through the application of technology, deconstruct the solution into a repeatable path of steps, synthesize their knowledge of languages, frameworks, hardware, and networks, and ultimately strive to deliver an effective, expressive and eloquent solution to the problem is a tremendous thrill. There is a gratification, a deep personal reward in seeing the fruit of your labor appear on the screen, fully-formed and ready to be used.
When you see others using it, it validates every effort, every difficulty you had in creating it. In the words of Nikola Tesla:
“I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success… Such emotions make a man forget food, sleep, friends, love, everything.”
Tesla had it right. Knowing that others are using your app and finding it useful is one of the greatest feelings there is. Being able to understand, quantify, codify, and verbalize the process of getting to that solution means that we go into every challenge with an even greater insight into why we do what we do.