After a bit of discussion the dojo group decided on the Python language – there are many others the group has used by in my experience it’s only been Python and Ruby, neither are easy to use for me.  Once the choice for language has been established the problem for this dojo was a Euler problem 7.

Ketema, the host of the dojo had setup TMUX to run the session.  Usually we have one PC that drives the coding through a projector that everyone can see.  With TMUX everyone got a session and could pilot and co-pilot their five minutes of coding on their own machines.  I’ve not seen this before, so this was one thing I took away wanting to figure out.

Once everyone got started it was about helping everyone else out that had not seen or used Python (myself included) or written a program before.  In some ways Python reminded me of my Ruby experience I had at the dojo last year.  The SMEs in the room were quick to help us understand why Python did it certain things, and how it can do things differently than Ruby.  This is where the dojo begins to add lots of value quickly.

If you’ve never written a program using a test first approach (aka TDD), this is something that will help you make sense of it all.  If you’re used to the term baby-steps and fire-engine-steps, these are baby-step coding sessions.  The group coding for roughly two hours and only put up about (excluding whitespace) 30 lines of code.  The best part about this was that almost every function and code block was discussed at length so all (I think) 11 of us understood why something had been coded the way it was – very cool!

This being my second dojo to attend, it was a another great experience and encouraged me to try a few things I haven’t done and to do the some of the things I currently do, better.

My favorite quotes came from one of Caike’s friends he had brought all the way from Brazil.  We (geeks) have heard the notion that we should keep functions/methods to ~10 lines of code.  The statement someone made enforce this tenet, but also my own idea that the third time you write (or refactor) it will be close to it best state whether it is 10 lines or not.

“When we try to keep our functions to 10 lines sometimes it causes us to write [poorer] code to achieve this.”  A few minutes later he stated this, “[In Rio] we use red, green, and blue.  Blue being the refactor step that gets us closer having better code.”  To paraphrase something else he mentioned code should be correct first, testable second, and elegant (readable/maintainable) third – in that order.

Again, just a great session of learning and sharing, stuff you can’t really get from a book and only from a community that wants to share and strive to become better developers than we were yesterday.