Meetup feedback

[Mark Champine]

Tim says:

>"I love the idea of the Dojo but have 2 recommendations: 1. smaller groups. I'd say no more than 4 and preferably 3 people per group. 2. Smaller problems. Although some groups finished the tic tac toe problem, I felt that it was too big. At a previous meetup we did 4clojure problems. I think those problems are appropriately sized."

Agreed. General consensus seems to be to try smaller groups with a mix of experience levels. We'd also benefit from more project idea generation up front before the meeting. 

We should also talk about what works as far as team coding too. Do we take turns at the keyboard? Break down the problem into sub-tasks and each take some?  We could even try working on "one big project" some time, with 1 integration team and multiple feature/task teams. Of course that will take even more up-front planning to pick the right project that can be cleanly decomposed.

What do others think?

[Hans Lo]

Smaller groups I agree with; our group ended up breaking into two subgroups. Tic tac toe I think was actually not a bad problem - most groups opted to do something bigger than time allotted with Om and other frameworks, but at the core it was actually a small enough problem to get all the basics done and working in the repl, at least for me.

On a related note, it seemed to me that most people wanted to get their hands wet with specific libraries. Maybe it would be worth voting on popular frameworks to work on for a session?

Team coding was a challenge, I think figuring out something that can be cleanly decomposed might be the best way. Perhaps a web application and each team works on an endpoint or utility function?

[Andy Chambers]

At work, we sometimes play "The TDD Game" which is pretty cool. It basically works like this. Developing as a pair, each person takes a turn at the keyboard either writing a test, making a test pass, or refactoring some code without changing any tests. Then it is the next person's turn.