Thoughts on being an apprentice

This summer, I wrote a small data importer program. I decided to do it non-Test-Driven-Development (TDD) to check some statements I'd been making. For example, I frequently assert that, once you get into the swing of TDD, it actually speeds you up. Well, it had been a while since I did something non-TDD, so I figured I'd try it out.

What happened? Well, for one, it took me a really long time. I kept IRB open, so I could load my module and try out the import routines. The manual aspect of the testing really slowed me down.

Another insight came out of the experience: the code looked similar to code I would have written with TDD. There were several small, task-oriented methods that a large, coordinating method gluing them together. I could see there were a few things that would have been different with TDD, but the general pattern was there. Until today, I wrote it off as just an item of interest.

In his book, The Craftsman, Richard Sennett makes a very thought-provoking point when talking about Correct vs Practical: the idea of quality vs functionality. As craftsmen, we strive for quality in our code. We look to use proper practices and techniques, such as abstraction layers, single responsibility, etc. However, when the time comes, we sometimes resort to cutting corners for production of functionality. Focusing entirely on quality, we would never allow an abstraction to leak or for a unit to have more than one responsibility/reason to change. In reality, though, we sometimes allow these, knowing that we can deal with them through another technique. Sennett's example is a woodworker who, focusing on an absolute measure of quality, "will shave a mortise-and-tenon joint until the two pieces are completely rigid, needing no screws." Focusing on the measure of functionality, the carpenter will "curb worry about each detail, knowing that small defects can be corrected by hidden screws."

How does my experiment with non-TDD relate to what Sennett is saying? The answer is in the shape and form of the code I wrote that was non-TDD. Over the past few years, I've practiced with isolation/mock frameworks that help me find the appropriate abstraction layers by virtue of 'Programming by Wishful Thinking.' TDD has led me to focus on small methods that have a single responsibility, as they are much easier to test. Due to the years of rigorously applied TDD, I find that I make more unconscious decisions about when to apply these patterns. So, when I take away the 'training wheels' of TDD, my designs are better than they would be if I hadn't practiced those techniques.

I've talked to people lately about the idea of being a journeyman. How do you know when you are ready? I don't have the answer, by any stretch, but I have an idea. During the apprentice phase, a person is busy learning. They are practicing specific techniques, rigorously applying rules and procedures. Over time, having been influenced by many mentors, an apprentice starts to develop their own toolbox, the set of practices that they systematically apply. These practices form a basis for further development, a core that an apprentice can build upon.

While discussing what makes a craftsman at the software craftsmanship summit a couple weeks ago, someone mentioned having a core set of techniques/principles that a person applies in their work; I like this idea more and more. A craftsman is mindful of his work, not just the end result, but during the act of creation, as well. The principles that hold to are not static; they can and should change as they are exposed to different ideas. However, there must be a basis to build upon. This foundation is what is established during an apprentice stage.

Just my thoughts.

[Update: Mark Needham referred me to developing a Personal Practices Map. Wonderful! That's just what I'm thinking of.]


(feel free to leave a comment here or put a link to your response on your blog)

Talk with Justin Kohnen

As the last host of my first tour, Justin Kohnen deserves a special place. He spent the entire tour as the anchor for the end of the tour. When I left for Chicago initially, I basically only had the first week planned definitively, plus Justin at the very end, 3 weeks away. Over the first week, the middle of the tour filled in with some amazing experiences, but, through it all, there was Justin. :) Add the fact that he was the only non-Ruby guy, and it was a recipe for a fun and interesting weekend.

I spent Saturday and Sunday programming with him, and we did some great stuff, had some great conversations and just generally coded the weekend away!

Both of us were new to Silverlight (SL) and Windows Communication Foundation (WCF), but, after a marathon push on Saturday, we figured it all out in time to build a reasonable architecture on Sunday. While the application we worked was secret, Justin said it would be okay to talk about it like a chat server. So, let's just say that we were building a chat server: SL on the front; WCF in the middle; and, SQL Server on the back.

Special thanks to Keith Elder for taking some time on Saturday night and walking us through the initial setup of the WCF services.

Enjoy!


Interview with Justin Kohnen from Corey Haines on Vimeo.

Pair Programming on ENIAC

Jean Jennings Bartik was one of the first people to program ENIAC. Here is a fantastic interview with her on the occasion of becoming a Computer History Museum Fellow.

I feel that listening to the stories of the people who have been around is such a fundamental aspect of our profession (I suppose of any profession). One thing that I really got a lot from during my first tour was asking everyone how they got started in programming. I heard stories that spanned more years than I've been alive, and stories that are just at their beginning. Learning about people's histories, their attitudes, their way of living was one of the unexpected joys of my time on the road.

In her interview, too, Jean talks about how they pair-programmed while working on ENIAC, and how she thinks it is the best way to program. SWEET! Her comments on pairing start around 22 minutes.

[Thanks to Rachel Appel for the link to the video]

One of the greatest moments of the tour

A lot of people have asked me about the tour, things like 'what was the biggest thing I learned' or 'who cooked the best meal?' I also get questions about highlights. I wanted to share one of the absolute best 20 minutes, or so, of the tour. Jonathan Branam's family was just great, and this video really shows a great example of how lucky I've been to have people bring me into their homes and lives. While I don't have videos of all the experiences I've had, the time I've spent with everyone's families has made this one of the all-time greatest experiences of my life; I've grown, not just as a developer and craftsman, but as a person.

Enjoy, 'Jamming with Josiah and Judah'


Jamming with the Branam Kids from Corey Haines on Vimeo.

Talk with Craig Muth

While in Columbus, I had the opportunity to hang out with Craig Muth. He's built an emacs-based framework called Xiki that is pretty awesome looking. Watching him use it is like magic! And, it is all written in Ruby, which is even cooler. It is a tree-oriented, wiki-based interface for pretty much living your entire life in emacs, even though he told me isn't one of those people who say you should spend all your time there. :)

While he and I didn't really get to pair that much, we had some fantastic conversations throughout the day, and I was very happy to get the chance to spend some time with him.


Interview with Craig Muth from Corey Haines on Vimeo.

Talk with John Distad

While at Edgecase in Columbus, I got to spend a little time pairing with John Distad on refactoring a helper function that he had. It was a bit of a bear, as there was a lot of stuff going on in it. In the end, we just scrapped it and wrote it over. It was fun working with John and seeing another person's approach.

After work, John and I went out to dinner and had some great conversations about philosophy and what not. Enjoy the video:


Talk with John Distad from Corey Haines on Vimeo.

Thanks, Matt Yoho

I wanted to take a second to thank Matt Yoho for his support. Not only did he let me crash on his couch for 3 nights in a row while I was in Columbus, but he also donated to cover costs of the tour.

I met Matt this year while becoming involved in the local .net community. He's since moved to Edgecase to do Ruby/Rails. He's a great guy, very nice and thoughtful. I didn't get a chance to interview him on video, but we had quite a few great conversations over the time I was there.

So, thanks, Matt! I really appreciate it, and the community is better because of people like you.