Last year: August | September | October | November | December
These events are more fun than I've had not in a boat or in bed (from a serious waterski enthusiast and regular attendee).
November 2014 - Well that was fun! While we didn't reach our goal of 200 cities across the globe all doing code retreats, we did hit 141; still impressive and loads of fun. This year also included an app that showed where events were happening and what each was up to, including the constraint being imposed on the current session; nice!
But as always, the most fun was who showed up. This year we had a very special group of attendees; in with all our usual awesome folks, Jackson Area Career Center, HS juniors and seniors, arrived in style, in a yellow school bus. The T-shirts, laptop lid stickers, and 6 head-down sessions resulted in a lot of fun and learning for all.
Thanks are due to Pillar Technology for a great venue (as usual) but also for two fantastically prepared meals cooked on the premises. Traci Shaw and Jacki and the whole crew had everyone quite happily noshing throughout the day. Thanks also to Nate Foreman my co-facilitator for his expert insights and keeping me on task.
One last thing: The reason for all the global and country sponsorship business was to raise funds for a good cause: teaching kids to code. At last report, $14,500 was raised for CoderDojo from sponsorships.
October 2014 - In place of the planned "deep dive" into mobile development, we did what can best be described as a shallow dive, exploring on our own the special requirements that come with designing and building mobile applications. Along the way we discover pros and cons of the packages we tried out, but emerged with a few working if simple apps, on devices, not just in similators.
September 2014 - We immersed ourselves in GIT with the able tutelage of Magnus Stahre. A near record number of attendees went through total immersion.
August 2014 - What a great crowd: we had students, researchers, interns, and polyglot pros; a little of everything. The result was some great insights as we tackled one challenge after another. As always, we did pair programming, a wide array of katas (2 sessions in the morning and three in the afternoon), and each delivered insights that were shared with all attendees.
Terry: Following a silent session (where no talking is allowed: your code and the tests you write must express your intent) Terry reported "I realized a test that I wrote was asking too much from my pair. The adjustment that we ended up making resulted in simpler and clearer code." Terry's pair confirmed that while the code Terry wrote initially was singularly elegant, it's full implications were baffling. Terry concluded "Clever code can be problematic."
The lesson here is most easily appreciated when deciphering code written long ago or by someone who is not available to explain it. The same insight was offered by Carlos M the prior month, again, following a silent session.
July 2014 - We practiced test-driven katas, pairing, and iterations morning and afternoon, and did we ever eat.
The morning began with a pancake breakfast, complete with blueberries, bacon (of course), sausage, coffee, and fresh orange juice, all prepared on-site by the participants. Many thanks to our grill-masters Terry and Paco and to all who made the morning special.
Since we had about half-and-half alumni and new faces, our first kata was Conway's Game of Life. The first two katas were free of constraints. Later in the day we introduced a silent kata (intended to teach the practice of choosing expressive names for tests, classes, methods, and variables) and Jeff Bay's Object Calisthenics (to demonstrate what happens when forced to factor out methods, write short/simple methods, avoid using primitives, etc.).
As often happens, the learning came mostly from the participants during the retrospectives that follow each session:
- Jeff: "Because we were test driving the code the Object Calisthenics didn't present that much of a challenge."
- Following a round of software trivia that included the question "Who is Grace Hopper and what is she known for?" Henry was able to top the answers I offered from Wikipedia: Hopper often used a stretch of wire measuring one "light-foot" (330 mm) to illustrate how far light travels in one nanosecond. Henry recounted the tale from a first-person-personal perspective; he was there when she was presented with the wire length in answer to her questions on the limits to the speed of computing.
- Besides being a kick-ass developer and practitioner of TDD, Angel makes a totally over-the-top Strawberry Cheesecake Trifle that is not be trifled with. Magnificent! Thank you Angel.
- Not nearly on the same plane with Angel's contribution we also enjoyed a New York style cheesecake with blueberry topping. One of our rules is that you won't get the conventional-for-programmer-gatherings Pizza at our workshops.
June 2014 - This was not our usual test-driven kata, pairing, and iterations type of activity; it was a "deep dive" exploration into using mocks, fakes, spies, and stubs (aka test doubles). We will be alternating deep-dive and kata-based workshops as we go forward to keep things fresh.
Guest facilitator Magnus Stahre led us in an exploration of how to use mocks, fakes, spies and stubs to improve our testing. Beginning with Java and doing things sans a mocking framework, we covered the basics.
After lunch we were into exploring frameworks and spent a lot more hands-on time with Magnus' excellent guidance.
Thanks are due Dave Braley for the excellent suggestion that spawned this workshop.
May 2014 - No event: Not enough people signed up. Guess I didn't promote it properly.
April 2014 - Lots of alums and and equal number of first timers explored apiary.io and literate-jasmine.
This was not our usual test-driven kata, pairing, and iterations type of activity; it was a deep dive exploration into these two open source tools. We will be alternating deep-dive and kata-based workshops as we go forward to keep things fresh.
Participants began with the sample exercise provided by apiary.io which is targeted at producing REST API documentation (an API "Blueprint"). But here's the magic, when combined with for-fee services (or your own setup of dredd, also open source, the "documentation can yield contract tests of the REST API described in th blueprint.
One of the take-aways was tha despite Apiary's use of the term "mock" to describe their service, what is provided is instead a static fake as it only feeds back the first canned response given in the blueprint. A apiary forum entry shows how to force a response other than the first canned response, e.g. a defined error response, but it falls short of being a mocker service.
In the afternoon the option of further exploring apiary.io or instead diving into literate-jasmine was offered. Some teams went each way and comparisons came out during the retrospectives.
One observation offered was advice related to the format of the day: when an event is going to be a deep-dive, send advanced information to those who have registered in time to allow everyone to play with the focus area and come better prepared with questions and specific areas of interest.
Thank you! Will do.
March 2014 - We had an excellent turnout, a good breakfast(*), and the focus was a return to refactoring. As in September we used Cyber-Dojo and discovered a very useful feature on Emily Bache's Refactoring Katas on Github. Way down at the bottom of each kata's explanation is a set of links (one for each of several languages) that create a new Cyber-Dojo for that kata. This was a huge help. Thank you Emily once again.
Many deep conversations came about, some inspired by watching Jim Weirich do a masterful Roman Numerals kata, others by how issues encountered in real-life are well represented in the Gilded Rose kata.
Knowing where to start on a large legacy code base got us talking about the "heat map" technique. This is not related to UX eye-tracking but instead focussed on seeing where the largest number of source repo check-ins is occurring. The highest activity being focused on a single module is often for one (or both) of two reasons: Either the module that's getting the most attention is the center of the universe and fails to uphold the Single Responsibility Principle, or reported bugs too frequently require changes in that module's code. Both conditions are code smells that make the module a candidate for refactoring.
Steven Coffman worked out a chain of shell commands that does a great job floating the culprits to the top:* In March 2014 we did our first "Build Your Own Breakfast" to start the day off right. In the spirit of true craftspeople attendees built what we needed: scratch blueberry pancakes, belgian waffles, fruit salad, and of course, fresh brewed coffee. I'm told it was a hit so we'll continue the experiment.
git log --since='last month' --pretty=format: --name-only | sort | uniq -c | sort -rg | head -10
You can replace the 'last month' with '1 week ago', 'yesterday', '1 year ago', '3 months ago', '1/20/2009'. Or you can omit the --since='last month' to have no time limit.
February 2014 - Since we were roughly half returning attendees and half new faces, we started off with the traditional-for-code-retreat Conway's Game of Life problem. By the second hour a recurring observation surfaced: biting off more than the pair can accomplish in a short period. This is a commonly seen occurrence when pairs are new to Test Driven Development, and in day-to-day industry. Taking a page from last year, we used Taking Baby Steps technique to explore how to get to green more quickly.
February also brought the return of one of our favorite couples: Magnus and Angel. Magnus showed recent work he's done to exploit Pythonista on the iPad, and while he was at it, he couldn't resist the temptation to extend the editor.
MA: : "It was a stressful challenge, but incredibly educational. I'll definitely return."January 2014 - Not even snowmagedon (aka the Polar Vortex) can keep die-hard software craftspeople from gathering to practice their craft. Practicing software professionals with major research labs, publishers, startups, and both university students and professors all braved the elements to learn from each other on 1/11.
January brought with it a first, we did a Randori fish-bowl for the first session. Here's what we did:
Three chairs are setup at a small table with a shared laptop connected to the overhead projector. After an initial pair volunteered to start us off, the remainder of the attendees setup chairs positioned so they could watch both the overhead screen and the current pair.
What made it a "fish-bowl" Randori was the 3rd chair, initially empty. The rule is that there must always be a pair working, and that they were to do ping-pong pairing. The audience gets to cheer the pair on, offer suggestions, or heckle, as they chose. But the risk to a heckler is that too much heckling could result in a current pair member stepping away and putting the heckler on the spot by inviting them to step up, which they are obliged to do. The other way to refresh the makeup of the current pair is that any audience member can occupy the vacant third chair, obligating one of the pair to give up his/her seat.
We ran this configuration for a 45 minute sprint on the prime factors kata. At the end I pointed out that even with a group of a half-a-dozen mostly seasoned developers they had failed to complete the kata, and asked why they thought this was. One observation offered provided the best insight: it's really really hard to allow the code to tell you what it needs when working on a problem if you think you know how to solve it. Specifically, participants couldn't agree on at what point to stop doing the simplest thing that met the test and dive headlong into writing the regression they knew was required for the ultimate solution.
In hind site, I'll add a new rule next time: the audience can only address the active pair, i.e. no side conversations. Side conversations introduce way to much chatter and detract from the focus on the pair and what they are doing. The group came up with an alternate approach for rotating the pair: time-box how long the pair remained in place. We may give that a shot in the future.
December 2013 - This month we participated in a Global Day of Code Retreat, and got a pleasant surprise : Adi Bolboaca reached out from their code retreat in Bucharest and our two groups got to compare notes. What a great way to appreciate being part of a global event.
In the morning we kicked off with an awesome video showing how powerful four simple rules can be and then set to exploring how to test-drive the problem. We did a silent session (with no comments) to promote clear and expressive tests and coding.
Later in the day we practiced Adi's Taking Baby Steps technique and augmented it with random Nerf dart attacks. The last session of the day folks who had not tried the kata before gave the Gilded Rose a shot (a refactoring kata) mostly in Java, but it's also available in other languages from this same starting point.
All-in-all, not a bad way to spend the day while it snows outside.
Anonymous attendee: "I've been hanging around long enough that I am getting the hang of this. Productivity is way up! "
November 2013 - No event in November in deference to SCNA 2013
October 2013 - A lot of experimenting went on today. Although we stuck mainly to the basics (pairing every hour and driving code from tests) we also tried out various remote pair programing approaches and tools. What we got was a list of practices that improve chances of a having high quality remote pairing experience:
- Actually try out your choices software, hardware, and configuration in a local environment beforehand. Software tools we tried ranged from Google hangouts and Skype on the low end, to TeamViewer and ScreenHero (beta) on the high end.
- Bandwidth is major factor in choosing a method of sharing: full-screen refreshes will be problematic if bandwidth is limited.
- Your local hardware makes a difference: Google video hangout for instance was unusable on an underpowered laptop.
- Always have a plan B: e.g. exchange alternative contact information (e.g. cell phone numbers) beforehand. If either party's internet goes down hard, an out-of-band communication channel will minimize flailing while a pair partner tries to figure out where you went.
We also solved a problem experienced in August: people wanting to investigate a different language spent time trying to get a new environment setup on their laptop. Cyber-Dojo to the rescue. All three problems, in five languages each, were ported to Cyber-Dojo and we had zero setup issues as a result.
CL: "Thanks for sending the feedback. I am so glad that several U-M folks took advantage of the day and that it was a positive experience. Thanks to you for spearheading these events. It is a great thing you are doing!"
TW: "Again, thanks for the exciting and informative Coding Craftsman Saturday!"
August 2013 - Our first workshop was a Corey Haines-style Classic Code Retreat We did 5 iterations of Conway's Game of Life, using TDD all the way. New pairs were formed roughly every hour so everyone got exposure to different approaches and different languages/IDEs. Parts of this were new to some folks so learning happened at many levels.
DE: " Just wanted to say thank you very much for hosting the code retreat this weekend! It was the first I have attended, and I learned a ton. I'm well on my way to being a full TDD/BDD convert."
AM: " Thanks so much for putting the event together last weekend. I had a great time and definitely plan on attending in the future. I don't know many (career) software developers, but I will certainly be getting the word out to my friends on campus. I'm looking forward to attending during the upcoming year. Thanks so much for organizing these."
Please check-out the Upcoming Schedule tab to see what's next.