The Dojo (was: Twitter + SVN hook script == instant history?)

[Robert Stackhouse]

Yes, in my talks with other people who have run dojos and from the reading I've done, I think only one person in the room should be typing at any one point in time. Everyone else should be thinking about how they are going to continue on with the solution once it is there turn to jump in.

The real value in the Dojo comes from getting to observe how other people write code, and also in the next meeting of the Dojo or after it is over receiving feedback on how you are coding.  The point is to get people to think about what they are doing.

The Dojo also offers the 20 year veteran coder the opportunity to learn from the month old newb. In the Dojo, there are no masters, only students.

The Dojo  will teach people how to do what we do in the most natural way possible, by imitation.  The Dojo offers the learner the opportunity to analyze how other people solve problems and how others code those solutions into implementations. It also offers the imitated the opportunity to give pointers to the imitator.

Learning by doing is just blundering through in the absence of reflection.

On Thu, Aug 20, 2009 at 9:07 AM, Mike Abney <mi...@mikeabney.com> wrote:

I like the idea for project. It makes it easy to catch up if you
weren't in the room. I am less sure of the value in the context of the
CodeDojo. Or maybe I am just not on the same page with how the Dojo
would work. So in the version you've got below, you would have an SCM
repository, and only one pair working at a time. The value of the
Twitter stream there would be that the pair would commit each time
they ping-ponged or each time a pair member switched out for someone
new. To be a valuable way to follow the Dojo, the commit message would
then need to contain something along the lines of a play-by-play of
what had happened. That sounds like a lot to remember/write....
Perhaps something like that could be done by someone else as the pair
was working. Then, when the time came to commit, the "reporter" could
somehow update their local copy, commit that change to a second repo
with their record of what happened, and *that* gets posted to Twitter.
The only problem there is the 140 character limit. Perhaps posting to
a "liveblog" would work better? A link could be provided that would
take the "follower" to the specific changeset/version.


Mike Abney

http://practicallyagile.com
http://improvingpodcasts.com
http://agilebcs.org

On Aug 20, 2009, at 4:00 AM, rstackhouse wrote:

>
> I am always thinking about how the folks at home can follow along if
> they can't make it to a meeting whether that by by web-cam, video,
> blog, Twitter or carrier pigeon.
>
> I've tinkered with SVN hook scripts in the past. I've also toyed with
> updating Twitter using Ruby (you can go to http://twitter.com/TAMUUWeb
> and play spot the script if you want ;) ).
>
> So I started thinking about combining the two.  What if after every
> pair got done with their turn at the wheel, they saved the state of
> their work to SVN (I'd be willing to go the git or bzr route too I've
> just never done hook scripts with either of those). What if after that
> SVN commit, a script on the SVN server took the commit message and
> flung it out to Twitter? Result, instant CodeDojo timeline.  We could
> even cache the stuff for posterity's sake on a webpage, since tweets
> disappear into the ether after 3 months.
>
> What do y'all think? Stroke of genius or gonzo 3 in the morning idea?
> >

--
Robert Stackhouse

http://robertstackhouse.com
http://robertstackhouse.com/friendfeed
http://agilebcs.org
http://bcsbloggers.org
http://uweb.tamu.edu

[Mike Abney]

The other mechanism we discussed—the last one I recall being discussed—was to have more than one pair going at a time, but have each pair come up and discuss what they did an discovered. Thus the learning still happens—referencing your other message—and folks get to actually see more than one implementation of the solution—possibly in multiple languages and programming models.

I think that both mechanisms have value and that we may want to experiment as we get going. That said, I'm with you that the mechanism you describe is probably the best one while we are getting folks used to the idea of a dojo in the first place.

Mike Abney

http://practicallyagile.com

http://agilebcs.org

[Robert Stackhouse]

Mike, I totally agree with you. I think it would be best to stick with one station and one language per dojo (we can switch off languages between weeks) until we start building in size. 

I'm open to anything. I think that at the beginning of each dojo subsequent to the first, we need to have a retrospective about the one before to discuss what worked and what didn't. This is a format a lot of the other dojo's have embraced, and I think it is a capital idea.

-Robert