Reflections of CodeRetreat 14.05

This weekend, I attended CodeRetreat 14.05.  This is the 4th code retreat that I have attended.  The pattern continued that despite attending these events multiple times, I have still walked away with some valuable lessons learned.  

Here's a few of my key take-aways from this code retreat:

Rust - the language

I had the opportunity to hack around in the rust programming language.  Despite not making tons of progress with the game of life kata during this session, I was still able to experience hacking around with another fun languages.  I enjoyed seeing Rust’s approach to mutability. In Rust, every field is non-mutable unless you expressly make it such.  That seems like a good practice, because it forces you to think about which data you are okay with being mutated.  No surprises with your data changing from underneath you, and that’s a feels like a good thing.

Rust - my skills

I’ve been programming almost exclusively in Go for the past few months.  In one pairing session we began to write some unit tests in Ruby and I mixed up the syntax for GinkGo and RSpec.. a lot!  This was a friendly reminder that it’s important to practice and stay fresh in all of the languages you care about.  Many times when I am writing ruby specs I have plenty of examples laying around in the code base. When it’s a blank slate there is nothing created yet. You are left with only your your memory and the internet for googling examples. Once I got a few rspec tests written it was clear sailing, but there was a humbling moment or two getting the first test wired up.

I also had the opportunity to do this kata in C# with NUnit.  This technology set used to be my wheelhouse, and I was pleased to see that it didn’t take me much time to get back into the saddle.  My fingers even remembered most of the ReSharper shortcuts I know and love. Another neat thing is that I got to try out VIM-VS. I could leverage all of the shortcuts and keyboard navigation goodness that I have learned in VIM, while doing it inside of VisualStudio. This was a new and fun way to experience writing C# code again, but with some added editing niceties I've been practicing. This setup wasn't flawless, and I think this setup would take some tweaking in order for it to be really effective.

Golang

Last time I attended this event, I felt like my skills on Go were not strong enough that I could effectively lead a pairing session with someone who has never programmed in go, so I didn't even push the issue. I spent most of the day in Ruby that day. This time, I was determined to solve the kata in golang this session, even if I was the only Gopher there. Luckily, I wasn't. I had the pleasure of pairing with another Gopher at this code retreat and was lucky enough to be able to introduce them into using GinkGo. I'm glad to see a few others in this area using Golang.

Primitive Obsession

Like many people in this industry, there has been more than once in my career where I have over engineered a problem.  By practicing TDD so much over the past few years, I think that forcing myself to write tests first has eliminated many of the pitfalls of doing a bunch of design work first.  The problem with doing this is I think I stepped out of the “over engineering” category and into the “primitive obsession” category.  Having the challenge of doing Conways Game of Life without the use of any native datatypes exposed was a good way for me to let design for your objects to occur naturally.  I found it also drastically increased the readability of my code.  I plan on keeping a more watchful eye when using primitives to represent anything in the domain.

Remote pair programming

Where I work, we do a decent bit of pair programming.  We also gear ourselves up the right tools to do this job effectively.  We use tmux, google hangouts, and vim daily even when we're not pairing. It’s pretty typically that when pairing remotely that both developers will SSH into one of the pairing sessions.  I learned about a tools call wemux.  This seems to take some of the initial setup work out of the equation and make it easier for attaching to eachother’s tmux session without having to SSH into a shared computer.  

Learning and Teaching

Events like these are always a good experience for me.  Even when I feel like I'm ahead of the curve on some of the exercises like red/green/refactor, frequent check ins, and ping pong pairing, Jim Hurne is still an excellent facilitator and mixes up the exercises enough that can stretch my skills.   When I was in college I got a job as as tutor.  I was recently reminded how much fun it can be to teach.  I was also reminded how much you can learn by teaching.  Being able to justify what you are doing and and why you are doing it keeps your mind right.  I've been impressed how many college students and hobby programmers have been attending the code retreats recently.  It's good to see such a wiliness to learn and grow from an early age in your software development career.  It's fun and exciting to showing a disbeliever how to really write the tests first, or seeing someones mind blown when you show them a new trick, shortcut, or tool.