Sunday, July 7, 2013

Code Craftsmanship Saturdays (aka Crazy Coding Saturdaze)

Stuff craftsmen like:
  • Autonomy"I came to learn a little {Scala | Ruby | CoffeeScript | whatever}"
  • Mastery"Sweet! How'd you do that?"  "I'll show you."
  • Purpose: "I came to code and to learn.
  • Oh, and ... good food: "Breakfast is ready."
Stuff craftsmen don't need:


So what is this Code Craftsman Saturdays thing? 

Every month, on the 2nd Saturday, software developers of every stripe and every level get together for a day of pairing, test driving, food, and fun.  There are no presentations, no vendors, and no recruiters. Just other software craftsman (and craftswomen) learning from each other.  Registration information is used to count how many people (not who) attended.  

Did I mention?  There's no cost to participants and both breakfast and lunch are included (no Pizza or box lunches).

Often, we use a format Corey Haines and Patrick Wilson-Welsh
 created called a Code Retreat.  Other times we'll do what JB Rainsberger calls a Legacy Code retreat where the focus is how to safely rescue really bad code.  Occasionally we'll do something completely different, like a Randori Kata

What all of these have in common is that there will be pair programming, Test Driven Development** will be used, and learning will occur (usually amidst all the fun).  The only thing you won't know in advance is exactly where the learning will come from.


So please use the "register" link for the month you want on the "Upcoming Schedule" tab and join us for some intentional practice.

Why was Code Craftsman Saturdays invented

Three reasons:
One: No one else did it.  Two: Someone should be doing it.  Three: It's so much fun!

OK, a fourth reason: There are plenty of presentation-format meet-ups already.  I wanted to do something different.  Athletes and musicians practice their craft regularly and software development should be every bit as personally rewarding as music or sports.  My goal is to make Intentional practice just plain fun.


** One thing you need to know: As Jeff Patton points out, TDD isn't really about testing, that's just one of the outcomes.