My experience at Code Retreat Miami 2012

This past weekend (Dec. 8th, 2013) I had the great opportunity to experience my first Code Retreat in Miami, for the Global Day of Code Retreat, here is a post about it to help inform others about this wonderful event.  If you have a chance in the future to get to one, it is a “must do”.

The Crowd

I was very surprised there was a large group of Rails developers, and it was nice to see there were a few PHP people from the South Florida PHP Users Group (SoFloPHP) because I had posted the event on the group page.  It’s comical how the Rails folks (I do not refer to them as Ruby developers, because generally they do not know Ruby.) seem to feel their framework makes it the best tool for everything, and completely disregard every other language and framework on the planet to blindly evangelize.  I say “blindly” because Rails users seem to feel the need to push the framework on me by selling wonderful features, as if no other language/framework in the world has it.  (But I digress, that is another subject for another post.)

It was nice to see all of the programming languages represented.  There was PHP, Ruby on Rails, Java, Smalltalk, C#, and even some Python.  This made for a nice mix to view other languages, and how developers of those languages operate.

Overall everyone was friendly and it made for a great day of learning and fun.

What is Code Retreat?

Code Retreat is a single day pair-programming workshop giving a chance to practice Test Driven Development (TDD) while trying to solve a pretty challenging sample application, and follow the 4 rules of simple design.  The sample application is to build Conway’s Game of Life.  I will not try to explain the Game of Life here, so if you are curious you can click the link and learn of it on your own.

For many, the sample application is not an easy one to grasp. I found that all of my pairs kept trying to pre-define the game board size at the beginning of the process, though one of the criteria of the game is to have infinite size. (Even the moderator seemed to be stuck on the concept as well, and claimed that predefining a size was OK, because it is how he did it.  I found this disturbing, but overlooked it.)

Others found that forcing ourselves to write the tests first (TDD) was the hardest part of the event, and that is what it was all about.  The event is all about learning TDD, so it was justifiable that it was the challenging part.  I, for one, was up for the challenge and forced myself to NOT WRITE A SINGLE LINE OF CODE WITHOUT A TEST WRITTEN FIRST TO COVER IT.  Because of this I had 100% code coverage the entire day.

The day is broken down into 45 minute sessions where pairs work together and get as far as they can.  Usually the first 5 minutes are spent as each member of the pair explains how they envision the logic to work out.  Following that the initial tests are built to test the game board, then code is written to satisfy the tests.  Then more tests to populate the board, then more code to satisfy tests.  Then tests to makes sure the 4 rules of the game work, then code to carry them out.  Finally, if you got this far, tests to ensure a new turn is executed, and code to satisfy the test.

One of the parts of the interesting parts of the challenge is that prior to each 45 minutes pairing session the pairs were changed.  Which required that the pairs started over by explaining their vision.  Then at the end of each 45 minute session ALL code was deleted to ensure you start from scratch again.  This included any hand-written notes you took during previous pairings.

Of course, due to the 45 minutes restriction I don’t believe that anyone could truly get the completed application running.  But that is OK.  The purpose of the event is achieved by showing the benefits of pair-programming, using TDD (Test Driven Development), and bringing the various communities together.

Additional requirements

In addition to the rules and steps defined above, there was additional criteria placed upon the teams for each iteration.  The first round had no additional criteria, but each additional round carried a new requirement to follow.  For this event we had the following criteria set for each round respectively:

  1. Team with someone using a different programming language.
  2. 5 lines or less per method/function.
  3. No usage of mouse.  All keyboard shortcuts.
  4. No talking.

The additional requirements made it fun and forced attendees out of their comfort zone, in most cases.  It was interesting to see how, when faced with the difficulties of the additional requirements, it brought the pairs closer together to tackle the obstacle.

Possible Tweaks

While I did find the event awesome, and enabled developers from across the board to experience new things, I would love to do such an event where everyone used the same technologies.  This would enable to see how other developers in our own area of expertise have adjusted their workflow, and allow further learning.

By having a group using the same technologies it would allow juniors and seniors to learn from each other and grow the individual communities.

My Take-away

For me this was an awesome way to force myself to use TDD to develop.  Too often I get in a hurry and just skip right to the code, then come back and write tests later…maybe.  However, I found that by writing tests first during this event I actually got more coding done and ended up with less code overall.  And it also led me to do less back and forth refactoring during coding, that is normally a HUGE time waster.

I also found that pair-programming was very enjoyable, and led to time savings.  The person at the keyboard tended to get more done while the second person was free to think a bit more, rather than being occupied with the manual tasks of writing the code.

In Closing

I enjoyed the event thoroughly, and would love to do it again….today!  If you get a chance to attend one of these events in the future, I highly recommend it.

Great time at php|tek 2012

On May 21st, 2012 I set out on a journey to my once annual PHP related conference. I have limited myself to a single conference each year and generally work the expenses and time into my employment contract. Most companies are willing to sponsor employees going to a conference, as long as it will benefit them in some way and as long as you get it approved from the beginning of your employment. (Otherwise they “perceive” it as an expense and not an investment to gain an employee.)

I arrived early in the morning rather than later in the day (there were no flights in the middle) because I wanted to ensure I had time to network and socialize prior to the tutorials the following day. For past conferences I always enjoyed them and learned a bunch, but never really socialized much. I was the wall flower quiet person sitting in the front latching onto every word of the speakers, but then didn’t really talk much after.  This year I wanted to make it different.

Why the difference? A couple of years ago (due to events I will cover elsewhere) I decided to help South Florida enter the PHP community and grow into a place where companies could find PHP developers, and where PHP developers would enjoy a thriving community. So I started the South Florida PHP Users Group which has grown to around 270 members. In the process I learned to gain the most from any event or training through an added social aspect and that realization washed over into how I experienced Tek12.

Tek12 was very social…more social than I remember on previous times I attended. It seemed like everywhere I looked there was a group talking, and laughing.  And each group was very approachable or outright invited bystanders to participate.  Plus the groups constantly changed, so there were no “clicks” where the same people were always together.  Everyone seemed to flow from one group to another and contribute to each conversation.  I also felt very comfortable walking right up to others and simply asking a question. (Something I think most are intimidated to do.)  So I learned a bunch, and had a great time finding answers to questions I’ve had for some time.

I loved the achievement patch idea, and feel it helped by gently forcing everyone to talk to the sponsors and each other. It wasn’t like entering a large hall full of sponsor tables where you quickly passed a table grabbing “swag” and avoiding an uncomfortable product spiel on something of no interest. The php|tek crew did a good job of bringing sponsors who are relevant to current developer needs.  Not only did I learn from some of them, but I also found some services I can really use.  And I did manage to collect EVERY patch, plus one extra from Mashery for building a quick application using one of their APIs. (It is the white patch.)

Of course the sessions at the conference were wonderful with lots of great speakers. It took me a few days for my brain to catch up and actually digest the contents and topics I saw. I am still trying to work through some of them. The people who decided which talks get through the screening process did a great job of ensuring we had a good list of topics, and kept them relevant to current trends.

I also took advantage of the Engine Yard Jaunt sponsored by Engine Yard on Friday night after the conference.  It was a great way to see some sites in the city, and spend more time with old and new friends in the PHP community.  There was great pizza at Giordano’s, a tour of Skydeck Chicago, and then some night life events. (My wife and son were arriving at the airport to spend the weekend with me in Chicago, so I didn’t continue on to the club portion of the trip, but I am sure everyone had a great time.)

Of course no trip would be complete without a short jaunt with the family on a beautiful sunny day.  So on Saturday and Sunday we headed out and saw a lot more of the city, which will be posted on my more “family” oriented outlets.