Orlando Coding Dojo 2011.07.30

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.

And Now A Quote from Iago


"Iago"“When are we ever gonna get our hands on that stupid lamp!” This weekend was a great long weekend to sort more leftover baggage from 2010. Feels like I’ve dropped an easy 2 tons this weekend.

The whole “lamp” analogy is just about letting go of what I can’t reach, and honestly don’t want to. The idea right now is to just focus on “reach” – as in what I can reach, not “rich” which always seems to be much too expensive for me. Not in the sense of money, but mental currency.

Just this weekend I’ve had a very educational experience working on things that are within reach, and not the things that are so rich. Looking forward to rest of the week now.  Besides, I’m seeing that the rich stuff isn’t all it’s cracked up to be and ends up being very high maintenance, like that “stupid lamp”.

Happy Monday!

A little Christmas, a little early

Yesterday, my Software Craftsmanship calendar arrived from the folks @ NimblePros.  Now you can have a daily reminder about YAGNI, DRY, DI, or simple things like waste reminders.

Here’s mine, positioned next to the grease board so hopefully when we’re brainstorming we can keep some of these simple principles involved in what we’re doing.

Ever wonder when Edsger W. Dijkstra was born?  Me, neither him but he and other notable contributors to our craft are mentioned each months.

Order your own, or one for a c0-worker that needs a reminder for what month it is, or should be.