What Makes Code Hard to Understand?

July 13, 2014

@garybernhardt linked to a short academic paper on code readability, called “What Makes Code Hard to Understand?”. It’s a quick read that details an experiment where researchers showed severals versions of the same program to a bunch of programmers and asked them to guess the output. Each version had the same cyclomatic complexity and lines of code, but differed only in formatting, variable naming, and use of types.

Choice quote:

The physical aspects of notation, often considered superficial, can have a profound impact on performance [of programmers to understand what code will do]

In particular, in a program that relied on order of operations, two versions were given, one in which one space was used around operators (zigzag) and another where the operators were all vertically aligned (linedup):

Programmers were more likely to respect the order of mathematical operations in the linedup version of whitespace, showing how horizontal space can emphasize the common structure between related calculations.

Also, they presented three versions of code to calculate the area of a rectangle, using free variables, tuples, and a Rectangle class:

Programmers took longer to respond to the tuples version of rectangle despite it having fewer lines than the class version. It is not uncommon in Python to use tuples for (x, y) coordinates, but the syntactic “noise” that is present in the tuples version for variable names (e.g., r1_xy_1) and calculations (e.g., width = xy_2[0] - xy_1[0]) likely gave programmers pause when verifying the code’s operation.

This was not something that was initially obvious to me as I learned programming, but I have come to realize the importance of typography in writing code. From my post on the subject over a year ago:

But, it’s not just the content - the code itself - that affects readability. How it’s presented matters and if we’re going to talk about presentation, we have to talk about typography.

The Complexity of Object-Oriented Design

July 11, 2014

I can’t say what a codebase designed to Alan Kay’s idea of “object-oriented” might look like. I can say what your average developer (including myself) actually creates using object-oriented languages, tools, and techniques. The result is a constant battle to tame complexity. I’m going to lay out one source of that complexity, because it’s baked-in to object-orientation, and I debate that it provides any utility in making programs easy to understand or change.

Dealing With Resque Failure

July 02, 2014

Over on Stitch Fix’s engineering blog, I wrote a new post on how we deal with tricky job failures. Namely, make your jobs idempotent:

Trapping Resque::TermException is really just kicking the can down the road. You might prevent some of your jobs from failing, but you’ll still get failed jobs. Granted, they will fail at a lower rate, but it’s still a rate correlated to the scale of your business.

The underlying problem is that jobs aren’t idempotent.

Check out the entire thing here.

Thinking In Types

June 30, 2014

In a previous post about Swift, I talked about how static types were increasingly seen as important in programming language design. “Static” concerns a lot of developers, especially those using languages like Ruby or JavaScript. Let’s forget about that word and just talk about types.

What do we mean by types?

Types are everywhere, they are all around us, even now in your very programs. You can see them when you look at your browser, or when you start up your editor. You can feel them when you go to work, when you go to meetups, when you buy your conference passes.

Morpheus is correct, types are at the absolute core of every program we write, “static” or not.

Resque Brain - a Better Resque Web UI

June 12, 2014

Monitoring multiple Resque instances, especially from a mobile phone browser, is a huge pain. That pain is now over. From the Stitch Fix blog

Today, we’re introducing Resque Brain, an open source application that monitors multiple resque instances. It has a mobile-friendly UI, and provides better tools for managing the failed queue. It also includes some basic monitoring and statistics tasks.

Check it out.

Understanding New Programming Languages

June 05, 2014

In reading “The Swift Programming Language” to prep for my post on how Swift informs us about programming language trends, I was surprised at how straightforward the language’s features seemed:

I found myself nodding along with each feature introduced. Tuples: check. Named Parameters: check. Default Parameters: check. Protocols: check. Functions: check.

I realized it wasn’t just because Swift has unsurprising features, but because I’m familiar enough with enough other languages that I’ve experienced or used those features before. Although I write mainly in Ruby and JavaScript at work, I have a lot of experience with Java and C, and had my head was in Scala for quite a while a few years ago.

Although the forms of Swift’s various features differ from their analogs in other languages, conceptually, they are the same: the generic type system is similar to Java’s, and the tuples are close enough to Scala’s that all I need to do is understand the syntax.

It really is true that the more languages you know, the easier it is to “pick up” new ones. This is a great reason to learn a new programming language every year.

If all you know are dynamic languages like Ruby or JavaScript1, or you are only familiar with Java or C#, you are increasingly at a disadvantage when trying to acquire new skills. Learning something like Swift (or Scala, or Elixir, or whatever) requires not just understanding the syntax of the language, but the very concepts that underpin its features (some of which can be mind-bending).


  1. 1Particularly JavaScript. It has probably the least features of any modern programming language. If you've never experienced a truly powerful and expressive language, you will be more and more behind as the industry moves on. JavaScript won't go away, but it's becoming assembly language. You don't want to be an assembly programmer.

What Swift Tells Us About Programming Language Trends

June 04, 2014

To the surprise of just about everyone, Apple announced a new programming language, Swift, at WWDC this Monday. This is a rare event for us programmers, as we don’t often get to see what the biggest technology company on the planet (who owns one of the biggest platforms on the planet) thinks about programming language design.

Swift embodies two major themes in programming language design that have come to the forefront in the last several years: functions as first-class values (a given, these days), and, more surprisingly, static typing.

Rails Does Not Define Your Application Architecture

May 27, 2014

While Rails doesn’t prevent you from creating a well-architected application, it certainly doesn’t give you everything you need. This is not so bad if your application is incredibly simple, but for anything of moderate complexity (and I would argue that any app someone is paying you to produce is going to be moderately complex), Rails leaves a lot of architectural decisions to you.

Use Bower for managing front-end assets in Rails

April 10, 2014

By yours truly, on the GrowingDevs blog, giving you some more reasons and help on using Bower instead of RubyGems for managing your front-end assets in Rails:

Use Bower for managing front-end assets in Rails

Rails 4.0.4 depends on version 2.2.x of the jquery-rails gem which in turn bundles 1.9.1 of JQuery. Does that make any sense? The latest official release of angular-ui-bootstrap-rails is 0.9.0, which is at least a version behind the current release of the Angular UI bootstrap directives. When will it be updated? chosen-rails version 1.1.0 bundles an old version of chosen-jquery that has never been officially released. What?

The state of front-end assets in RubyGems is almost comical. Please start using Bower.

Getting Angular and Rails Working Together

April 07, 2014

I’ve been doing a bit of AngularJS at work, and getting it all working with Rails, the asset pipeline, testing, and deployment was quite a challenge. It wasn’t so much difficult to do, but difficult to uncover the right information. So, I decided to compile it all in a nice tutorial and post it as a free mini-ebook, in web form, also known as a website1.

From angular-rails.com:

Once you're familiar enough with Angular to start building an app, you'll find there are a lot of unanswered questions:
  • How do I serve Angular assets via the Rails Asset Pipeline?
  • How does Angular's templating system work with Rails?
  • How do I connect Angular to my Rails controllers?
  • How do I test my Angular code within a Rails app?
  • How do I manage all these JavaScript dependencies?
  • What challenges will there be in the production environment not present in the development environment?
I was able to find answers by piecing together information from Stack Overflow and various blog posts. You shouldn't have to do that.

Check it out, start making some awesome Angular apps with Rails, and correct any mistakes you find.


  1. 1I have a longer-term goal to make this an actual e-book, but for now, I wanted to get it out and get feedback