#poecode?

I got to enjoy my favorite kind of learning moment today: when an innocent, seemingly simple question turns into a journey, which leads to a revelation. The revelation is that code is poetry, not prose.

I was really dissatisfied with code I wrote at the end of last week for a flashcard program (the technical term is 'flashcardinator', apparently). The challenge was designed to enhance our knowledge of RSpec, Ruby's popular testing framework, as well as our understanding of test driven development (TDD). TDD's basic idea is to write a failing test for an aspect of your program before you write any code, then get the test to pass as simply as possible, then look at how you can refactor your methods into better code. That idea makes sense to me, and seems important to me, so I decided it would be a good use of my time to revisit the challenge and see if I could do it better.

In order for TDD to be effective, you have to increment your code by tiny steps , and recognizing my own tendency to want to plow ahead, I spent all morning explicitly focused on writing sensible tests, getting them to pass with the simplest code possible, and thoroughly considering my refactors.

After lunch, I approached Jeffrey (one of our instructors) with what I thought was a simple question. For every challenge that's involved printing and reading data to and from the command line, we've had a ton of trouble figuring out effective tests. There are all sorts of different poorly documented workarounds, but they're all hacks that carry a nagging feeling that if you have to resort to these measures, you're probably doing something wrong. I thought I'd figured out a structure that would allow for easier testing, but was stuck on a design choice I didn't know how to resolve.

I posed my question to Jeffrey, expecting a simple answer. That is not exactly what I got.

He looked through my code, starting from where I was stuck, and began to completely dismantle it, piece by piece. I was completely flustered, and I even broke into a sweat (granted, that's my body's response for basically any emotion). I was totally put off- I'd spent all morning believing I was doing a great job on this challenge my second time around, only to be shown that nothing was where it belonged, and my understanding of what the structure of this program should be was utterly flawed!

Eventually I recovered from the shock, and that's where the true magic began. I had the huge privilege of sitting with Jeffrey for close to an hour working to understand why certain methods should belong in certain places, what parts of different classes should and needed to be visible, how the code I had written was implicitly making hazardous assumptions, and how the concerns of my classes were totally mixed up. I know I've only been doing this for 3 weeks (and one day), but it was completely amazing to see what I thought was good code be transformed before my eyes into what is actually good code. The learning was immense.

To return to the title of this post, code is poetry, not prose. Rather than paste my incomplete code below (code and explanation to come upon completion of the challenge), I consider the following to be an analogous example. Take the idea of courage, and think of how we might express it. You could go with the following:

Courage is the ability to confront intimidating circumstances with confidence, and to have the power to act even if you're afraid or uncertain. You can be physically courageous, for instance if you're jumping off something high, or maybe confronting an aggressive animal or human. You can also be morally courageous, like when you speak up on behalf of yourself or someone else because you know it's the right thing to do. It's a desirable quality. It's closely associated with bravery.

I could go on, but you get the point.

This is another way to express the same idea:

Two roads diverged in a wood, and I-

I took the one less traveled by,

And that has made all the difference.