Cincinnati Clean Coders

I tweeted today that a team I’m working with has started a weekly patterns and techniques learning cycle to expand the team’s toolbox for creating clean, testable, and flexible code.  This came out of some reflection that I’ll dive into in another post.

This tweet sparked some interest and I’m happy to follow the rabbit hole.  So I threw up a twtpoll to find out who is interested in a similar concept, but open to all comers.  It would be entirely language and platform agnostic.  I have some initial ideas on how to make it work in a reasonable amount of time, but we’ll roll with the mood.

So let me know what you think:

Please retweet, email a link, whatever.  Just find people who would benefit (everyone) and convince them it’s a good idea. 


Do remember there is bound to be someone willing to sponsor food.  Might not even be pizza.

Programming is not a craft… but you can be a craftsman

Craftmanship was the software development phrase d’jour in 2010 (or maybe REST, it was a close race).  To start 2011 Dan North very abruptly stated that Programming is not a craft.  I happened to read this a few days before Codemash which was keynoted by Chad Fowler where he very conveniently discussed the Passionate Programmer

My take from the keynote is that we shouldn’t be so quick to fear, resent, and minimize formal mechanisms of inspection and improvement (aka Six Sigma), but instead embrace them as ways to expose and enable our passion productively.  I don’t know that many expected this from a mustachioed (ok it’s gone, but come one, did you see that thing), Ruby loving, saxophonist; it certainly was sobering.

Today David Starr responded in much the same way I did when I began reading Dan’s comments: how dare you.  But I’m not sure Dan’s headline grabbing commentary is quite as radical as some are bound to interpret. 

Dan, as I’ve understood him, is looking at the term craft and craftsmanship as it is used in trades such as plumbing, electricians, etc.  In these trades, there is a well defined ladder of training, experience and excellence with an approving body.  We don’t have this (or want it I dare say) and cannot therefore call what we do a sibling according to Dan.

Our sub-industry of coding, even with our self-declared passion, neglects those activities which would transform us from egocentric, but well meaning geeks to a “proper profession” as Dan puts it.  How many in Chad’s keynote didn’t scoff and chuckle at the 6-Sigma reference and then stare at the table in silence when we came to realize it’s a lot like our Inspect and Adapt frameworks.  Coincidentally enough, many of our favorite Agile practices such as XP, Scrum, and Kanban come about from a thorough examination of mechanisms like Six Sigma.

The qualities that embody the Software Craftsmanship (as a proper noun with a unique meaning) are fantastic, I want to reflect them.  At this moment, for better or worse, there seems to be no effort to give the movement an objective beyond personal empowerment.  Do we need one?  Probably.  Can it come from the Software Programmers Union in the form of a Master Coder License?  I certainly hope not.

In the mean time, you can be a software craftsman.  Love your code.  As David puts it “one mark of a true professional might be a willingness to balance client need with implementation elegance…”.  Just keep searching for the elegance.

The Purpose of Katas

Codemash 2011 has had a Coding Dojo dedicated to Katas.  I don’t recall that last year, but I love it.  While I was there, they were well coordinated also.  Nimble Pros seemed to be organizing things and they kept suggesting people pair up as they walked in and finally coordinated a discussion, swapping out the projector from person to person. 

In and of themselves, the Kata problem is generally not terribly difficult.  We’re talking about Harry Potter and Bowling for crying out loud.  In fact, Uncle Bob goes so far as to say that “a kata is meant to be memorized.”

But the problem is not point of a kata.  Instead, <robe>it’s the journey</robe> that we aspire towards.  Every execution of a kata should start with a goal, an objective.  That goal may be to investigate, understand and adopt another coders decision making process.  Your goal, as it seems for many this week, may be to learn a language or language feature.  Often the objective is to learn a new coding technique. 

Over the past few months, my objectives have often been related to streamlining my tooling techniques.  I’ve used katas to learn Vim and a little Emacs.  I’ve used katas to learn new ReSharper features.  The Vim learning process resulted in much better use of Visual Studio, even installing the VsVim extension which I love. 

Today I used the Greed Kata to practice the Transformation Priority Premise and I was very intruiged by the way my code evolved.  It certainly took me down a path different than that others and the one I would have otherwise have chosen.

So my suggestion to you in an attempt to make your sessions more productive… have a kata goal.

Rules of the Game: Effective Group Discussion

Meetings are hard.  They can easily suck the life out of your day, week, or *gasp* job.  Let pain be your guide. (Thanks @coreyhaines)

I recently had to work through a mountain of feedback data provided by a limited product release.  User Experience experts, random individuals, and customers known for their willingness to provide quality feedback gave us excellent information.  The question became how do we effectively process the information as a team. 

Here a redacted version of the meeting notice I sent out:

We have feedback from some users. We need to talk about it, but it’s a lot of info.

Here’s the tentative plan (tentative because someone might think of a better one).


15min · Soapbox

30min · UX Feedback

30min · Customer Feedback

15min · Next Steps


We need a really, really good note taker.  Volunteers?


Rules of the Game

  1. Each person receives 3 uninterrupted minutes for their soapbox.
  2. Interrupt someone during their soapbox and you lose a minute from yours.
  3. Maximum 5 minutes on any one feedback item.  Action item to dig in later.
  4. Fist in the air by anyone immediately halts discussion on the topic and we move to the next. Action item to dig in later.
  5. Add a sticky note to the wall if you want to discuss something relevant by off topic.
  6. Try to have read as much of the feedback as possible before the meeting.

The key to any meeting is preparation and an effective recorder.  By having a timeboxed agenda, audible timer, rules, and an awesome recorder meetings can actually be fun! 

I love the Soapbox for two reasons.  First it gets everyone talking.  Even the quiet person has three minutes (or a really long, awkward silence).  If someone finishes before their allotted time, sit quietly (you kinda have to or you lose a minute yourself!).  They will probably come up with something else right before their alarm buzzes. The second reason I love the soapbox is that you can then get down to business without people interjecting something off topic.

We didn’t make it through everything, people were cut off by the alarm, and people didn’t get to say everything during their soapbox.  It’s ok.  Do it often and people will learn to be direct, to prioritize their thoughts, and to PREPARE.


Now, back to my code.

Greatest Overeager Design Decision: Assignment

In a getting back to basics moment of mine, I started through the TDD Problems.  I found myself on the Console Interaction problem and decided to take a step back from after refactoring.  This is what I saw:

var shape = _console.AskForShape();

var rectange = GetRectange();


ReSharper was hinting at it, but it should have screamed.  Why do I need to hang on to shape?  I can imagine my mindset at the time.  I was worried about the inevitable decision I would have to make about 20 tests down the road.  That little assignment was the beginning of my overeager, premature design.

Question your code.