Write Software for People, Not Computers

Throughout a normal day, I end up reading a lot of information about current issues in technology, and today is no different. There was a debate raging about whether or not high-level math was required for programmers that was sparked by this article by Sarah Mei Programming is not math. While it is an interesting topic, and, surprisingly, I mostly agree with Sarah on this issue, that is not the most important portion of her post. The important part is instead a quote from Structure and Interpretation of Computer Programs from MIT Press, and is as follows:

programs must be written for people to read, and only incidentally for machines to execute. Structure and Interpretation of Computer Programs, MIT Press

The interesting thing to take away from this quote from a book designed to teach introductory Computer Science to college students is that this concept never seems to sink in to many software developers. It fails to sink in to entire groups of developers, so much so that there are actual contests to see who can write the most obfuscated code.

Fortunately for developers, style guides and best practices for various languages have arisen. If you are a front end web developer, one of the important style guides that includes best practices is Idiomatic JavaScript which will hopefully guide JavaScript developers new and old to write better, more consistent, and supportable code for their websites.

All code in any code-base should look like a single person typed it, no matter how many people contributed. Idiomatic JavaScript

An important concept to grasp, then is that all code in your project should look like it should have a single author and be easily readable by humans. A perfect correlation to the desired end result of skilled software development efforts should be as easy to read as your standard novel which has a single author. Interestingly enough, it seems that Sarah Mei was making this argument all along in that:

For actual developer jobs, by contrast, the two main skills you need these days are programming and communication. Sarah Mei

In the end it seems that if all of us anti-social developers work more on our communication skills and ability to work well with others instead of throwing up more roadblocks that make software development a walled garden, we may actually have the power to make things a bit better for everyone.

Related Posts

Jun 12, 2014
One minute

Code Style Guides - Consistency is King

There have been countless flame wars online about the details of the guidelines that appear in various Code Style Guides. Some of the most famous are the tabs versus spaces arguments, whether or not to put curly brackets {} each on their own line, whether you should even use the curly brackets {} for one line actions in if statements.

I am here to say that the only thing that matters in the style of your source code, other than syntactically correct code, is consistency. When a codebase has internal consistency, developers new to it are more easily able to pick up the meaning of the source code contained within instead of having to first understand why the different styles in different sections matter, or not.

Jun 11, 2014
2 minutes

Defensive Development Failure

In the past, I have argued that devensive development is a useful tool to ensure unexpected exceptions are not introduced into a piece of software as well as ensuring that the error conditions are handled in an appropriate manner. Unfortunately, if defensive development is implemented poorly, it achieves none of its goals and can cause errors and exceptions to occur. One example that I found while reviewing some code recently is below:

Jun 2, 2014
2 minutes

Defensive Development - Fail Fast or Go Home

Defensive Development is a programming practice that is frequently misunderstood, but is nevertheless a critical practice to follow when working in many environments. I have seen articles written that argue that defensive development simply causes nonsensical null checks to be written, and as a result of seeing people writing bad code defensively, argues that no one should practice defensive development. There are other articles that, like many things in software development, argue that you should always use defensive development for everything.