How to Hear Your Unhappy Code: An Interview with Cory Foy


Cory Foy uses more than a decade of experience with agile and lean development to help developers create cleaner code, and also be able to know—or "hear"—when their code is unhappy. In this interview, Cory shows why constantly learning and evolving your language skills is so important.

Noel: I love that your upcoming session is titled "When Code Cries: Listening to Code." What in the world makes code cry, and what does crying code sound like?
Cory: The talk started off from an insight while teaching a junior developer. A key insight from test-driven development is that it isn't about the tests, but about the design that the tests enable to emerge. But I found that junior developers were struggling to get that clean code to emerge from the tests. What I struggled with was why that was. The code was clearly telling them what it wanted to do....
And then it hit me. The code was talking to us, but they couldn't hear it. Not from lack of trying, but because they couldn't understand the subtlety of the language. And I imagined this piece of code trying desperately to tell us what it needed to do but not being able to. And that picture was very sad in my mind.
So crying code looks like a mess. Because we couldn't hear what it was trying to tell us it needed.
Noel: In what other ways does code talk to us? If it's not "crying," what else can our code tell us?
Cory: Like many others, my initial exposure to the idea of design patterns was from the "Gang of Four" book. But I was lucky enough to work alongside of Alan Shalloway, who has a different view of design patterns than many others I had worked with. He went back to the seminal text on patterns: Christopher Alexander's The Timeless Way of Building. Alexander refers to the idea that things can be "alive" based on how they respond to the pressure (or forces) put upon them. So the patterns are solutions to recurring problems within the context of these pressures.
In other words, design patterns aren't mere recipes that we implement, but inherent in the problem we are trying to solve, and the pressures of that solution. We don't put them in—we get out of their way so they can come out.
Ultimately, programming is about communication—which is why we call them programming languages. But part of that communication is staying out of the way of the emergent design inherent in the things we build. So, if we're listening to our code, we can tell that something isn't right—that we're doing the wrong thing. We often call this "intuition," but I think a large chunk of intuition comes from practice of hearing what the code is saying.
Noel: I also really liked where in the abstract for this session, you say that you can "help code to come alive by naturally resolving the forces that are present in the problems you are working to solve." How is this done?
Cory: As I mentioned above, Alexander talks about the idea of things being "alive"—that is, how well something resolves all of the forces and pressures at play. Let's imagine we have a collection of objects and we need to loop over them. One way would be to use a traditional for loop:
collection = [Coke, Pepsi, Dr. Pepper]
for(i = 0; i < collection.length; i++) {
print collection[i];
This code sets up a variable ("i"), initializes it to 0, and then loops while i is less than the length of the collection. During each loop, we get the item in the collection that corresponds to the current position and print it out.
Now, look at this code:
collection = [Coke, Pepsi, Dr. Pepper]
collection.each do |item|
print item
I don't have to explain what this does. For each item in the collection, we print it.
Both snippets of code work. They loop over the collection and print it out. And, in that sense, they are both good code. But if we consider the other pressures at play—communicating with other developers, seeing duplication, understanding the domain—the latter code clearly wins. It "feels" better because it resolves the pressures for us better. This is the idea of code that is alive.

About the author

Upcoming Events

Nov 05
Nov 14
Dec 05
Jun 03