Confession: I hated revising. As an English major at a wacky liberal arts school I did a lot of writing. Most classes required at least one 12-20 page paper and I think there’s even a bound 60-pager about Chaucer sitting somewhere on the campus library shelf with my name on it.

But I wasn’t a great writer- in fact, I’ve never wanted to find out if that bound copy actually exists because I’ve looked back at some of my college writing and it makes me cringe. My ideas were sound and I even managed to get some decent grades, but I’m ashamed that I handed in some of those papers. The content is fine, the punctuation is in the right places… but it could have been better, waaaay better.

However, all I aimed for was to write a paper that was “good enough”. I was training full time and had a work-study job that I loved, so when it came to my studies I aimed for the minimal amount of effort to get the grades I was happy with. I wrote papers that were “good enough”, looked them over for grammatical errors, and handed them in. If my professors criticized my writing sometimes I’d even have the guts to say, “but it gets my point across!” (thank you Re, George and Dan for putting up with me).

But if I want to be a Software Craftsman, “good enough” definitely doesn’t cut it, and “but it works!” is not a defense for poorly written software. I remember when I first met up with Mike to go over the Rails tic-tac-toe app that I wrote in order to apply for the apprenticeship. There was a small part of me that was proud I met all the requirements and the game really was unbeatable (“but it works!”), but a bigger part of me knew that the code was a hot mess. I hadn’t written a single test (because I really didn’t know how to then), my rules-based computer AI was a massive “if/elsif” chain, and I basically stuck all the code into either the model or just one controller method. Although I was fully prepared for twenty well-deserved licks from the “crappy coder” paddle, instead Mike just gave me the feedback I needed and some recommended reading on how to make the code better.

It’s been the same with my command-line tic-tac-toe app as well, but now I’m starting to recognize where my thinking is wrong before I even type out the code. Since I still don’t have enough experience on what the right code should be I usually end up typing out some hack anyway, but now I at least have an idea of what questions I need to ask in order to make it better.

The idea of being ok with making mistakes and open to receiving feedback are something that both Software Craftsmanship and Apprenticeship Patterns discuss. I think being one of the “new guys” at 8th Light I was a little hesitant to be caught making mistakes and nervous about the feedback I’d get, but this initial apprenticeship time is the period when I’m allowed to make mistakes and also have access to really great feedback. So, I’ll code to the best of my ability, ask questions about what I can do better, and soak up any and all feedback. Thank you sir, may I have another.