What is Programming?

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?'

Programming is Expression

In a recent study, scientists determined that we use the same part of our brain to understand, conceptualize, and implement code as we do for other languages such as French, Spanish, etc. The parts of our brains that we use in Grade 10 when we have to learn a second spoken/written language are also firing when we take on the task of being productive with Ruby, JavaScript, or any other programming language. I have a theory for why this is true.

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.

Programming is progress

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.

Programming is disassembly

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.

Programming is Synthetic

A web application, for instance, involves a number of different technologies. The presentation layer will contain languages like HTML and CSS, perhaps with the intervention of JavaScript and libraries such as jQuery, React, or Angular. There will be a business layer. This will involve a server-side language such as Ruby, Python, PHP, or Java perhaps. There will be a number of modular libraries included, perhaps a full MVC framework such as Rails or Laravel. That, in itself, will bring in concepts of Object-Oriented Programming, encapsulation, abstraction, and many other computer science principles which the developer will have some facility implementing. And there will be a data layer where the app pulls its data from. This layer could be Postgres, MySQL, Mongo, Firebase, Parse or any other of the available data sources out there.

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.

Programming is fun

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.

MkObj - VanillaJS Library for Instance-safe objects

Part of my job as an instructor at Lighthouse Labs is to teach Prototypal Inheritance in JavaScript. It’s usually left for one of the advanced lectures in the later part of the bootcamp, and also typically turns students’ heads on one end and spins them around when they first wrap their heads around the idea that all inheritance isn’t like class-based inheritance in Ruby, for instance. (pardon the pun)

However, I recently came upon a very interesting article/talk by Eric Elliott entitled ‘The Two Pillars of JavaScript‘. In it, Elliott brings up the very important point that in JavaScript, new objects created through “typical” prototypal inheritance are not instance-safe. This means that when you change the prototype of the ‘parent’ class, you are also changing the implementation of the inheriting class/object/child.

As an example, see this code:

As you can see if you run this code, what ends up happening is that our Garfield instance gets the swish() method we add to Cat, even though it wasn’t part of the original inheritance.

So, I started working on an implementation of some of the principles that Elliott covered in his talk, without having to implement something the size and weight of StampIt(his library for building instance safe objects). It wasn’t that I thought StampIt was a bad idea. In fact, it’s great. But what intrigued me was the idea of mixin-based object creation, where you could throw a few methods and properties in a mortar and pestle, grind for thirty seconds, and out pops an object.

So, I have created mkobj, a simple implementation which allows you to register callbacks and properties which you would like to use in object construction. You can see it and an example here. Please note the minified version of the code weighs in at a VERY minimal 267 bytes!

The library itself is rather simple. There are two methods:

.register(name, fn/prop)

This method will register a function or property that you would like to use as a mixin later for the construction of an object. The name must be unique, else it will overwrite a previously-saved mixin. If you pass null instead of a function or property, then it will unregister that particular named mixin. You can register as many as you would like, and they will be namespaced inside the mkobj library itself.

.construct([name1, name2, name3, …, nameN])

This will return an object with all of the properties passed in the array on it as keys, provided that they were previously registered using .register() (see above). If you didn’t .register() it, then it won’t be set on the object. All objects created by .construct() are instance-safe.

As well, you could take an object created by .construct() and make an instance-safe copy of it using Object.create();.

Have fun, play around with this. Perhaps if I get especially motivated next week before I head back to work, I will do the whole ‘module-compatibility’ thing, so that it’s RequireJS/CommonJS/Bower/Browserify/whatever-compatible. This technique would work well for Node as well. (Which is how I tested it all, anyway).

The Mind of a Developer

Some of the most common myths about developers involve social awkwardness, poor fashion sense, and a general image of their minds being a warren of circuitry and math. There are many people who will assure you that the mind of a developer is a scary place, fraught with obscure lingo, random characters such as curly braces and parentheses, and an understanding of technology that surpasses that of mere mortals. However, one of the most pervasive myths about developers is that those who have certain mental illnesses are somehow more skilled and more suitable for the profession than others.

Myths are made to be disproven, and this particular myth is no exception. Topping the list of mental illnesses that supposedly contribute to the skills of a developer are dyslexia, OCD (Obsessive-Compulsive Disorder), and ASD (Autism Spectrum Disorder). However, while each of these is an illness that affects the way that the brain processes data and does impact problem-solving, they are no gift to a developer.

Dyslexia is often characterized by difficulties with accurate word recognition, decoding, and spelling. Most people think of dyslexia as letters being flipped and reversed, or the brain jumbling the order of the letters of a word when it tries to process it. These are two variants of dyslexia, but are by no means the entirety of the condition. However, the dyslexic developer myth says that someone who has learned to overcome dyslexia and “function” is therefore able to be more focused and attentive to the small details. Theoretically, this would make them a better programmer.

However, just because you learn to function with dyslexia doesn’t mean you are cured. Your brain never stops misinterpreting words and numbers, you just learn to re-interpret the input you’re getting. Dyslexia is a life-long struggle with expressing yourself through writing clearly, interpreting the written languages around you, and embracing complex grammatical structures. Unfortunately for dyslexic developers, writing code is a form of written expression, involving complex syntax having to read and accurately interpret code written by others.

There are at least ten times as many myths about OCD as there are myths about obsessive-compulsive developers, and the vast majority of them in both categories are misconceptions. Obsession is a word that we use very casually in everyday conversation, devaluing the definition of the word. People discuss being obsessed with a show, a food, or pumpkin-spice lattes. Compulsion is something we generally only face when in school or the military. An activity or class will be compulsory.

Many people use OCD as an adjective when they intend to say that they are choosy or particular about how something is done, without understanding how distinct it is from a condition that causes you physical discomfort and anxiety when reality is not following an arbitrary pattern upon which your mind has become fixated. The myth that developers with OCD have to have things just a certain way, orderly and methodically building their code, is completely false. Even if the process of coding is the pattern with which someone with OCD has become fixated, they are still just as likely to suffer anxiety when something isn’t correct. Having OCD doesn’t make you a good coder; it makes you an anxious one.

Anyone who has seen Rain Man has a certain impression of ASD, more commonly known as autism. Autistic people, the myth says, are automatically good at math, bad at dressing themselves, and don’t know the value of money. Many would agree that this is the very definition of a developer, however they are discounting the mental chaos and dysfunction that comes from being somewhere on the autism spectrum. Recent scientific progress has spurred a reclassification of the condition as a spectrum of disorders, including Asperger’s and savantism.

The misconception focuses on how all those who suffer with autism demonstrate savantism, or abnormally proficient skill in one area or another. Many have seen a movie of the week profiling Leslie Lemke, Kim Peek, Stephen Wiltshire, or Daniel Tammet. Therefore, it is an easy (though illogical) leap to go from those cases of autism to a developer with Asperger’s being expected to code at an abnormally proficient level. As the core areas affected by autism include the ability to express yourself and the ability solve problems, this makes the process of coding particularly challenging. Even with famous savants like Lemke and Wiltshire, they are only able to reproduce things they hear or see. Coding requires you to be able to innovate and invent.

Overall, the myths surrounding these mental illnesses being a benefit to developers are more detrimental than anything else. It puts an unfair pressure on these developers to perform at an impossible standard, and only adds to their anxiety when this arbitrary excellence isn’t achieved to someone’s Hollywood-fuelled expectations. A good developer is someone who studies, practices, and devotes themselves to building their skills. That is a set of characteristics that is independent of any other condition, and ultimately common to any profession. Good developers are good because they work hard, not because they suffer from mental illness.


Recently when collaborating on a project with some students at Lighthouse Labs, I was asked to help debug a script that would save form values between page loads, so that the user wouldn’t have to re-populate the form. This piqued my interest, and so the sleeves were both literally and metaphorically rolled up so as to dive in and help with this project.

A lot of the original efforts that had been done following some of the best principles demonstrated in Addy Osmani’s wonderful basket.js script. The idea there being that it was possible to store values in localStorage and retrieve them later, though his script is more about storing scripts locally. And I looked on the jQuery plugin site, and discovered that there were already a number of plugins to do this. However, the purpose of Lighthouse is learning to code, so the mentorship began.

The result is a plugin called jQuery Elephant, which utilizes localStorage to store form values so that forms do not have to be re-populated. Why Elephant? Well, elephants never forget, of course!

There were a few concepts that needed to be communicated here in order to make the plugin successful. One of the main ones was that we had to find a way to constructively serialize the form data, no matter what kind it was. To that end, input boxes, selects, checkboxes, radio buttons, and textareas all had to be considered as possible sources of information.

Additionally, there needed to be a standard format in which to store them, and since we were dealing with JS and jQuery already, then JSON became the obvious choice. As well, this was an excellent opportunity to teach about closures and how they can keep a namespace clean from outside influence.

And, of course, there was the tutorial on how localStorage worked. Once this was put together, it was a pretty decent plugin, so I have put it up here.

First Sentence jQuery Plugin

Alright, so I freely admit that this is one of the more “niche” plugins I have ever written. A colleague of mine was working on a WordPress blog for one of the company properties, and the designer wanted to have the first sentence of a paragraph in the ‘Recent Articles’ section highlighted in a different colour.

Now, this would be all fine and dandy, because you could just set the colour of the first sentence of the post that colour, and all would be great. Except then the first sentence would ALWAYS be that colour, everywhere. In the post, in the excerpt, everywhere. The colleague had tried using the ::first-line pseudo-selector from CSS, but depending on the screen size (Responsive design FTW) and the sentence, this might mean that more than the first sentence, or significantly less than the first sentence, would be highlighted.

A better solution was needed. Armed with a full stomach from lunch, I set out to get something that would work for them. I looked at a few different solutions, before just giving up and realizing that I was going to have to use regexp. Which led to my remembering a great quote.

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

So despite my better judgement, I delivered a solution that uses regexp to grab the first “sentence” of text in an HTML element. It doesn’t strip out tags, so if you have tags in the first sentence of your HTML, it will break. But this wasn’t a use case, so I didn’t account for it. If someone was interested in taking this further, I would welcome the contribution. The logic is that all text up to the first sentence-ending punctuation (?, ., or !) is then wrapped in a tag.

I also hardcoded a class name into the plugin. It’s horrible, I know. But if you set the class ‘.firstSentence’ in your CSS to be the styling you want to use on the first sentence (naming schemes rock), it will work. If you don’t like that class, edit the plugin. Again, I would welcome the contribution. Theoretically, you could pass the class name as an argument into the plugin, which would have a default set and accept the parameter.

Demo here. Uncompressed code here. Minified code (232b!) here.