Global Day of Coderetreat - Organizing

Yesterday was the first ever Global Day of Coderetreat. Using the closing circle format, allow me to share my experience as an organizer of the Salt Lake City event.

What, if anything, did you learn today?

The first lesson I (re-)learned as an organizer is that we have an awesome community both globally and locally. There were so many people willing to help out and make this a great day for coders. Of the many tasks required to make the day happen, I could only do a portion on my own.

  • Kay Johansen did an amazing job as the facilitator. I don't know how to thank her enough for all she did.
  • Mike Clement took the lead in communicating with the facility sponsor including making last minute calls to get doors unlocked so we could set up early.
  • The STG office staff, including Crystal, Kelly, Thayne, Marth, Ron and Chick, took care of our catering needs including correcting a communication error with the restaurant.
  • All of the attendees helped clean setup and clean up the room.

The most important lesson I learned through organizing the event is empathy for managers. The lunch mix-up is actually what triggered the epiphany for me. When you delegate an important task to someone else, you have to trust them to do it well. When lunch arrived and was only enough food for 6 people instead of 30, my very first reaction was,

"I should not have trusted anyone else to take care of this.
I should have done it myself!"

Fortunately, I have been working in agile development shops for years and I was able to focus on the solution rather than the problem. My excellent team members Martha, Ron and Chick sprang into action and got additional food ordered and delivered and everyone had a great lunch. Kay ran the prelunch session long so that people didn't realize they weren't eating. I think most of the attendees were thrilled for the extra time anyway.
So, the next time a manager tries to micro manage the team or me directly, I will have a lot more empathy for that behavior. Rather than resenting their lack of trust, I will try to remember the way I felt when lunch arrived. Then I will work in a way that inspires trust, so that they don't have to feel let down or the desire to micromanage.

What, if anything, surprised you today?

I think the biggest surprise was when lunch showed up.

What, if anything, will you do differently in the future?

I'm not really sure what I will do differently. I think that communicating expectations more clearly and communicating with my team more regularly will be part of it. The locked doors and lunch mix-up could have easily been avoided if we had communicated the needs of the event more clearly.

Conclusion

This was a great experience for me. I will not shy away from participating in the organization of future events.

Comments

Post a Comment

Popular posts from this blog

TFS to SVN Conversion with History

Recently, the team I was on wanted to move our source code from Team Foundation Server to SVN for reasons that had almost nothing to do with source control directly. This would be a pretty simple operation, but we didn't want to lose access to the history when the operations team turned off the machine running TFS. We couldn't find any direct paths for moving history from TFS to SVN, so instead we chose to use git as an intermediary. Here's how we did it: Step 1 - Install the tools Install msysgit: http://code.google.com/p/msysgit/ Install git-tfs: https://github.com/git-tfs/git-tfs Step 2 - Pull TFS history to local git repository git tfs clone <tfs-project-url> "$/<tfs-project-name>/<tfs-project-folder>" <localfolder> example: git tfs clone http://tfs-001:8080/tfs/projectroot "$/Reference Architecture/ReferenceArchitecture" RefArch Step 3 - Initialize git-svn * User Lower Case - Caps will make it fail! * Change direc...
Read more

Simpler Tests: What kind of test are you writing?

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of the author. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. There are a few broad categories of tests that I keep in mind to help focus my testing: Unit Tests Also called micro tests, unit tests form the foundation of any good testing strategy. These are tests that test a single class or method in isolation from it's dependencies. Mocks and stubs help us isolate the code under test and make our tests more focused and expressive. A test that touches any external resource such as the database, the file system, a web service, etc is never a unit test. The primary purpose of unit tests is to validate that the subject under test is functionally correct for the expected inputs and outputs. Additiona...
Read more

Architecture at different levels of abstraction

Image
This week I am attending the O'Reilly Architecture Conference in NYC with my team and I had the pleasure of attending a two day training on Building Evolutionary Architectures presented by Neal Ford and Rebecca Parsons . During this session, on of the things we talked about extensively was coupling. We looked at dependency maps for different architectural styles including the big ball of mud . We saw something like the following and almost everyone agreed, "That is a bad architecture." Big Ball of Mud This reminded me of something I has seen elsewhere before, and after a quick search, I found it: Amazon and Netflix Death Star Architectures The ball of mud is considered obviously wrong by most architects, but the death star seems to be held up as an ideal by just as many and likely most of the same architects. Why is this? Are afferent coupling (inbound dependencies) and efferent coupling (outreaching dependencies) only important at a certain sc...
Read more