On Code 
The principal activity of a software engineer is managing complexity.
I'm Learning About: Computing the Shape of Rotated Rectangles
An overview of one of the myriad of geometry problems that come up when you're building a rendering engine.
Tech Talk: Building 'Building Modular Java Applications with Gradle'
A recent presentation I gave at Rescale about the process of building my latest blog post
Building Modular Java Applications with Gradle
A primer on building a non-trivial modular Java application with Gradle
I'm Learning About: Adding Behavior to Static Websites with Cloudfront
Things I'm learning from adding behavior to this website using lambdas on cloudfront
I'm Learning About: Cloudfront
Things I'm learning from putting cloudfront in front of this website.
I'm Learning About: React Component Communication
Some things I've learned from coordinating component communication in my side projet, Yellow
What the Four Color Theorem Can Teach Us About Writing Software
A visual exploration of what The Four Color Theorem can say about software complexity.
The Rescale Blogs
A series of blogs written while I worked at Rescale.
What and Why
September 19, 2017
When software engineers look at a piece of code, the first question they ask themselves is "what is it doing?" The next question is "why is it doing it?" In fact, there is a deep connection between these two – why becomes what at the next level of abstraction. That is, what and why are mirrors of each other across an abstraction boundary. Understanding this can help engineers write more maintainable, readable software.
Responding to Sandi Metz on Duplication
November 23, 2016
Sandi Metz recently wrote an article proclaiming thatduplication is cheaper than the wrong abstraction.This article raises valuable points about the costs of speculative generalization, but it’s part of a long line of articles detailing and railing against those costs. By now it should be old hat to hear someone criticize abstraction, and yet the meme persists.
Name classNamees Like Magic: the Gathering Cards
July 18, 2016
I grew up playing Magic: the Gathering. As a kid I noticed something interesting about the card names — there were no generic names. There were no cards named "Zombie" or "Elf" or "Wizard". There were cards named "Fugitive Wizard", "Llanowar Elves", "Gravebane Zombie", and even "Storm Crow" but no "Crow". Modern card names are even more specific and evocative; witness "Crow of Dark Tidings" and "Flameheart Werewolf". Why?
The Problem with Data Modeling (as commonly practiced)
March 31, 2016
Every mature MVC application has that one model that’s grown out of control. The table has 20 columns; there are user preferences stored in it alongside system information; it sends email notifications and writes other models to the database. The model encompasses so much application logic that any new feature is likely to have to go through it. It’s the class that makes developers groan whenever they open it up.
How did we get here?
Plan for Unexpected Complexity or Be Overwhelmed by It
May 28, 2015
The world is incredibly complex, and nowhere is this more evident than the art of writing software. Software is the result of intricate interactions between social structures, business desires, and limited knowledge. The complexity of those interactions inevitably shows up in code structure. Our job as engineers is to manage this, and prepare our abstractions to handle increasing complexity over time. The most important technique in this regard is to make space for pieces of logic to take on more complexity without drowning in it – with complexity, the dose makes the poison.
Open/Closed and the Single Responsibility Principle
January 29, 2015
The SOLID principles of object-oriented design provide good guidelines for writing code that is easy to change, but for some of the principles, the motivation and value can be difficult to understand. Open/Closed is particularly vexing:software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.What does it mean to be extended but not modified? Does this principle lead inherently to deep, convoluted class hierarchies?
Leveraging Static Typing to Manage Object State
December 12, 2014
There has been a lot of talk in the software engineering world about the pains associated with OOP and specifically mutable state. Side-effect free Functional Programming is often touted as a solution. While there are some salient points on mutability, the real issues arise from naive use of implicitly mutable objects. If done properly, mutable state can be a useful tool for reasoning about code, and can guide future developers naturally and seamlessly towards correct code changes.