Randori Retrospective

[faithfulgeek]

Hey everyone!

I compiled a list of the most common suggestions for improving the
Randori session for March. I'm including them in this post. Does
anyone else have any thoughts on this? I'd like to get a discussion
going here, so feel free to reply!

Suggestions from last night:
- Break off into two groups (floaters?)
- Caught up on bad tests, faster pace would have helped
- scratch design session?
- If pairs aren't getting anywhere, let them up or ask for help
- Simpler projects?
- Two problems: one advanced, one medium to beginner
- Smaller pieces
- Solution ahead of time? - simpler problem?
- Practice same problem over and over - kata?


Thanks!
Joe

[dave]

your assumptions on Randori are that everyone knows TDD and rspec and
keyboard shortcuts of the MAC...
performing live in front of an audience while demonstrating your lack
of Ruby knowledge can be daunting
maybe try to outline the problem in rspec so that pairs can work on
individual methods independently then
let the pairs work in private then see as pairs if they can/have
something for their assigned method

[John Miller]

It's challenging to come up with an approach that's gonna work for
everyone, since we all have varying backgrounds with ruby. The range
in skill set is pretty broad. Large variety of working environments
(including OS and text editors).

Personally, as someone that's brand new to the language, I felt that I
was able to take away a lot from the last meeting. Really helps when
you can see how someone who already knows the language would approach
the problem. Breaking us up into small groups (< 5) could make it even
better. Small enough that one group could sit around a table and
everyone could see the screen. Maybe spread out the number of medium
\advanced users in each group so no one group would consist of all
beginners.

Thoughts?

> > Joe- Hide quoted text -
>
> - Show quoted text -

[Jim Wilson]

I enjoyed the last session but given the wide array of skill levels and
limited time in the meeting I thought I might throw out one more idea for
consideration.

As a way of combining the kata concept with the meeting, imagine starting
with the assignment of a simple project like the bowling score keeper. Then
before the meeting we can all spend a little time implementing the project
to get their hands dirty and form some real implementation questions. Then
when we get together for the meeting we can begin by taking questions from
those who had trouble and/or debate some of the different design approaches
we each came up with. Then for the last 30 minutes or so two of the more
senior Ruby developers could take to the main computer to answer some of the
question in code and maybe even put together an agreed upon sample "elegant"
solution.

This approach would allow everyone to get on the same page and to discover
other approaches from the other developers in the room. It might also
inspire a little more back channel chatter prior to the meeting with people
asking/answering questions about the approaching assignment.

Thoughts?
Jim Wilson

[Joe Fiorini]

Thanks everyone for the suggestions. There have been a number of
different ideas for the next meeting, all of them excellent. One of
our members suggested performing a Kata for the group to show proper
BDD/development in Ruby. He volunteered to do this in front of the
group, using the bowling score keeper.

The Columbus group is going to be following the Randori style at their
next meeting. They are doing it a little differently in that they have
a small group doing the coding and everyone else is just watching. If
anyone wants to work on something else, they can go to another part of
the room and do so.

I'm thinking of following in the CRB's footsteps here. Getting to see
a small group work out a simple problem might be beneficial.
Especially if most of the people coding already understand the
problem.

Any thoughts on this?

- joe