[LRUG] The codes

[Daniel Barlow]

Brent Snook wrote:
> Hi everyone,
> 
> First off, thanks to everyone who organised last night. It was really
> valuable and a lot of fun. I was on the pirate team. Yaaaar. Rum. etc.

What he says.

I had to take off early to meet some other people that night, then I 
promptly had a work crisis the following day so this is the first chance 
I've had to set my thoughts down.  I hung this reply on Brent's just so 
that it sits somewhere in the thread, but it's not specifically in 
response to him.

A few general observations, as a Ruby newbie who tends to prefer "think 
hard about the problem" to "write something that satisfies the tests" as 
a general approach.  Heresy, yes.

1) I was suitably aghast when we decided to pass the first test by 
spitting out a hard-coded string.  I would have started by defining a 
grid structure of some kind and writing code to print that, on the 
grounds that it was plain as the nose on your face that it would be 
required for the general solution and YAGNI (or what the Extreme 
Programming guys used to call YAGNI, I haven't really kept up with 
terminology since then) clearly didn't apply.  *But* then we spent the 
first five minutes even trying to get that to pass and fixed important 
problems like "there is a space in this directory name" that would have 
taken much longer to spot if we'd gone for anything more complicated 
than the semantic equivalent of "hello world".  So, maybe it *was* a 
good thing we did it that way around.

 > Something that seemed really hard to manage was communication between
 > the peanut gallery (awesome term) and the pair. Like Taryn mentioned,
 > everyone calling things out can be really distracting when you're the
 > one under the spotlight.

2) I noticed this from the other side, so to speak.  Some kind of 
protocol seems like it would help (later suggestions about empty chairs 
and suchlike all sound like they're worth trying) but from where I was 
in the gallery I was seeing people make suggestions more or less 
audibly, not have them picked up on, and then start side discussions. 
Side discussions (e.g "what's the difference between 'do ... end' and 
curlies for block structure") were interesting and informative in their 
own right for those of us in range, but I couldn't help feeling we were 
derelict in our duty of doing whatever our duty was w.r.t. the active 
pair by not paying attention.  Some ground rules in the initial intro 
(and I think those rules could probably be more or less arbitrary as 
long as they were communicated clearly) would enhance the experience for 
those of us not sure if we were stepping on toes or even if we were 
expected to step on toes.


3) <flamebait type="unintentional">I think we were nearly 30 minutes in 
before someone decided to break out irb and type things into it 
interactively.  Maybe I'm just a crusty old Lisp programmer, but 
honestly, that's where I'd have started.  Is the scaffolding-first 
tendency in Ruby due to the influence of Rails (which seems to be 
entirely composed of scripts that generate fill-in-the-blanks 
scaffolding) or do Ruby practitioners in general not get much out of an 
interactive evaluator, or were we looking at fairly inexperienced pairs 
for our first few slots?  Maybe that's an over-beer discussion rather 
than a list discussion </flamebait>


4) Shared structure in our array of arrays, ow.  I heard about this 
afterwards (as I said, I missed the debrief) and am kicking myself for 
not having noticed at the time.


> One thing I don't understand is how the entire team is supposed to
> work together to solve the problem - do you try and act like a huge
> gestalt entity or is investigating in parallel OK?
[...]
 > If it is OK to be approaching the problem in parallel then it would be
 > great to be able to try stuff out on your own laptop and then bring
 > the learnings into the pair when it is your chance to go up. A few
 > times I found it frustrating because I could only see the code that
 > the pair had open; I wanted some way to look at the other parts of
 > what they were working on.

5) Is ... yes.  I think that if you're not going to allow independent 
discovery by the peanuts, the onus is on a member of the active pair to 
be much more vocal about what they're doing - treat it almost like a 
presentation to a small group, rather than ordinary pair programming 
that people happen to be watching.


Thought-provoking stuff anyway, and I'm sorry I couldn't stay for the 
end.  Thanks again to the make-it-happeners.

What's on next month?


-dan