As developers go through their first few years as professionals they fall in love with two things:

• A green field. A clean slate. A chance to do things right this time!
• Finishing. Completing your feature, shipping it to production, and moving onto some new task without the burdens of the last.

Unfortunately, software development is a process and not a destination. Often we don’t get to walk away from a codebase until we change jobs. Sometimes a challenging codebase is why we change jobs!

The old joke goes: If software engineers built bridges, we would all be dead. More likely, if software engineers built bridges they would add helipads and ever-wider lanes as soon as the first car was across. To sustainably and happily build software, you need to create and embrace a process (the simplest one appropriate) that prepares you for the eventuality of helipads and wider lanes.

Good software development is composed of endless beginnings, each of them ceaselessly preparing you for the next. I encourage you to think about this when you complete part of your project’s process. When opening a pull request, you’re handing something off for code review. When you complete a pass at wireframes for a new feature, you’re asking a developer to begin implementation or architecture design. What should you communicate to the next person responsible for this item? What role will you play in the next step?

Code Review: The Long Beginning

Submitting code for review starts a long chain of beginnings. It is easy for a developer to think of code submission as the end of their role (“works for me!”), but properly considering that moment as a beginning helps a project’s source stay maintainable and flexible.

• Does the code have tests? When a new features lands, it is often the easiest time to add tests. The author has a unique understanding of his or her solution to a problem at that point in time. Probably not in the sense of “is this the best solution”, but certainly in the sense of “what did I intend”. Capturing that understanding in tests will be harder later, and make subsequent work on that code much more difficult and likely to introduce errors.
• Is this code understandable? Does it have comments and meaningful variable names?
• Have you summarized the changes completely? Ideally commit messages should read cleanly, but even if they aren’t Torvaldsian in quality a well written summary submitted with your request can take up the slack. Proper communication about the intent of your changes ensures that knowledge is shared and that your reviewers have a well informed context.
• Have you provided the reviewers enough time to meaningfully consider these changes? This is a beginning for the code, and it shouldn’t be presumed that the changes are ready for production just because they are submitted. I call last minute pull requests “code bombs”- If only an hour or two is provided for reviewing a PR, the submitter is asking for a rubber stamp of approval. Submitters should mitigate this habit, and reviewers should have little patience with it. It creates a misplaced confidence in the code’s correctness and stability.

Code review (and by extension Github pull requests) are not the end of adding code to a project, instead they are among the more important beginnings. Exercise them as a chance for discussion, criticism, and bettering of the code submitted. Use them well, and may your fields be evergreen and bridges ever-wider.

If you’ve built an app in Ember.js, by now you will be familiar with observers. Observers watch a given path (or paths), and run a function when the value at that path changes:

1
2
3
4
5
6
7
8
9

var Cow = Ember.Object.extend({
  weatherObserver: function(){
    if (this.get('willRain'){
      this.layDown();
    } else {
      this.standUp();
    }
  }.observes('willRain')
});

Enumerables (a group of items without order) and arrays can be observed in the same manner:

1
2
3
4
5
6
7
8
9

var Herd = Ember.Object.extend({
  migrateToPasture: function(){
    if (this.get('cows.length') > 30) {
      this.migrateToLargePasture();
    } else {
      this.migrateToSmallPasture();
    }
  }.observes('cows.@each')
});

However, Ember also provides a set of observers that share details about which items in an enumerable or array changed. Say hello to addEnumerableObserver and addArrayObserver. The API documentation for these functions isn’t that great, but they are fantastic and powerful tools once you learn how they work.

For several months I’ve been working with To Be, building a platform for creating and sharing creative work online. To Be’s fields are very visual, often incorporating animated GIFs, static images, canvas-rendered images, and iframes. Check out this field to see what kind of things people are creating and look here for more fields.

When images are loaded for a To Be field, we often need to react to the loaded state and perform some action. For instance if a given field element has a stencil description, we load the image to a canvas and process that canvas as a stencil. It turns out that image load events are notoriously un-reliable. For instance Chrome will not fire an onload callback when an image is fetched from the local cache [ticket here].

Last fall, I published a small library called after_image_load to GitHub. It handled CORs headers in addition to ensuring load events are always fired. We’ve been using that library in production for almost half a year now, and today I’ve finally incorporated the lessons from using it into an even slimmer jQuery library called load_image. Check it out on GitHub, and read on for some example usage.