Global Day of Coderetreat

This past Saturday was the Global Day of Coderetreat (GDCR). Thousands of developers around the globe participated in an all day event to practice and refine their coding skills. Big Nerd Ranch, with the help of sponsors Mandrill and Pardot, graciously hosted the local Atlanta version of the event. 

The organizers of Rails Girls ATL invited all of the participants from last weekend to attend the retreat this weekend. Based on my current skill level, I wasn’t sure if I should attend. Some friends on twitter insisted that the retreat was for everyone so I decided to attend. I also convinced Scott to attend with me, thinking that it would be easy for him and that he might learn some things about Test-Driven Development. Looking back, I’m still not 100% sure if I would have recommended to myself that I attend the retreat. More on that later. Regardless, I'm glad that I was able to attend. 

Based on the information from the GDCR website, I wasn’t quite sure what to expect. I knew that my computer already had Ruby installed for programming and the rspec gem installed for testing. Scott unfortunately didn’t have his environment set up for everything needed and we wish we would have prepared a little better. I would recommend to any future participants to set up whatever language they are comfortable in and also some sort of testing environment ahead of time. Otherwise, part of your coding time will be spent just setting up your development environment. 

After a brief introduction from the sponsors, we were given the instructions for the day. Our time would be broken up into six 45 minute sessions of coding. Each session would have the same general goal in mind but some sessions would have additional constraints. 

The main objective of our coding was to write a program that runs Conway’s Game of Life. Below is a video of Conway discussing the Game of Life. 

In the game there is a board of “cells” or spaces that can be living or not living. The rules that determine what spaces are living or not living are as follows: 

1) Any live cell with fewer than two live neighbors dies, as if caused by under-population.

2) Any live cell with two or three live neighbors lives on to the next generation.

3) Any live cell with more than three live neighbors dies, as if by overcrowding.

4) Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction. 

The game begins with an initial set of living cells and as the game proceeds, the cells are born and die according to the rules. We were instructed to attempt to write a program that plays the game of life. The intention was that the game would be so hard to program that no one would actually finish in 45 minutes. Any code written would have to be deleted at the end of each session. As participants, we were instructed that the main goal was not to finish the task but to ensure that we were writing the best possible code. According to the organizer, the best code is testable, DRY, had good naming and only uses what is absolutely necessary. 

With all of the rules explained, we were instructed to find a person to pair program with and begin. Honestly, it was pretty abrupt. I paired with Lance and we started by trying to decide which language to program and which computer and development environment to use. We ended up using Ruby and my computer. It was easier for him to use my setup than it was going to be for me to use his. As soon as the session started, I immediately began to feel the disparity between our ability levels. I could feel that my programming and actions (like just switching between software) were probably agonizingly slow for Lance. Luckily he was extremely nice about everything and we started making a little progress. Early on we decided that we would use the “sparse” method. Instead of programming in a 2-dimensional array for the board, we just “seeded” the board with an array of living spaces. Of course we started by writing a test that failed. Then we wrote the code to make the test pass. I’m not sure if we managed to accomplish much else in our session but if we did I’m not sure I could remember; the day was filled with a lot of coding. The time for the first session seemed to expire quickly. After the session, we deleted all of our code and met to discuss some interesting things we had learned. 

For the next session I paired up with Loren. He was my coach at Rails Girls so I felt like he would be fully aware of my capabilities. I didn’t think it would seem like I was holding him back. Also, I feel like he took the session as a teaching opportunity and we worked together on the problem. The additional constraint for this session was to “ping pong” back and forth with your partner. One person would write a test and then the other person would write code to make that test pass plus another test. I had already done this a little bit in the first session so I didn’t feel too constrained by this rule. 

This time, we did try to print a 2D array of the board. Later I found out that the sparse method was the way to go but it didn’t matter too much. We worked through testing and then coding different size arrays. I felt like it was a good exercise for me to reason through some things with Loren’s help. I’m not sure how much he got from the session but I really appreciated it. 

The third session I was paired up with another programmer that was (at least from my perspective) a newbie like me. This is where things got pretty rough. The additional constraint for this session was that each method could only have 4 lines of code. I’m not sure we ever really encountered this problem. It sort of felt like the blind leading the blind. I wasn’t totally sure about the correct way to do things (like proper syntax) and I didn’t want to spend too much time (like all 45 minutes) looking up the correct way. It didn’t seem like he knew either. We really sort of floundered around in the code for all 45 minutes and by the end, I was totally ready for lunch. When I was in the position of having to teach another person, my weak spots became extremely and painfully clear. I suppose in that regard, this session was helpful. At the same time it was very humbling and I felt pretty terrible that I couldn’t help him. I’m not sure if that session was what the coderetreat organizers had in mind when they designed the day. 

After lunch, I paired with Pamela, another person I knew from Rails Girls. We had decided that the sparse method was the way to go and we got started right away. The constraint for this session was that we could not use nouns to name our classes and methods, they had to be action verbs (like gives_life_to_cells instead of living_cells). She did most of the driving but I was totally ok with that. We were able to get a lot done. We managed to make it to some of the rules of the game (the farthest I had progressed all day). We started to try to determine a cell’s neighbors. We learned about the .product method but we got a little stuck on figuring out how to write the range of x - 1 (left neighbor) to x + 1 (right neighbor) and the same range for top and bottom. We made it to that point but then time was up. 

The fifth session of the day was another bad one. The constraint was like the “ping pong” one from earlier but this time we couldn’t talk to each other to explain what we wanted. This constraint was crippling for me. My partner didn’t have any testing environments set up and didn’t really know about testing or Ruby. We used my setup but again I was responsible for teaching the correct syntax. But this time we weren’t allowed to talk about our goals. Even when we did try to break the rules and talk about them, I’m not sure we were on the same page. It was rough and I felt totally responsible for not being a good teacher. I was ready for that session to be over pretty quickly. At this point I was pretty exhausted and frustrated. Luckily the day wasn’t over. 

For the last session I felt like I really needed to pair with someone I knew and was comfortable with. Andy from Rails Girls had been very helpful (in person and on twitter) and I knew he was pretty awesome at testing and Ruby. I made sure he wasn’t saving the last session for anyone and asked him to pair with me. The last session had the most constraints: no conditionals (like if statements), no primitives, no more than 4 lines of code per method, and maybe some other ones that I can’t remember. We used my setup with Ruby and rspec. We got started by writing tests for a Space class and a Universe class. We made a Space be able to “know” its neighbors and then we started implementing the rules in the Universe. Andy knew lots of Ruby tricks that I didn’t know about including: the Set class, the Struct class, the Range class, the map and select methods for an array, and the should =~ equality for testing. 

Working with Andy on this project made it very clear to me that he is a smart guy and a great developer. He already had in his brain very clear concepts about how the program should work and ways to implement things. He was able to convey those ideas to me and spend extra time explaining them to me when it took me a little longer to understand. He was so great that we even finished writing the game in the 45 minutes! I know this is crazy. Even the organizer couldn’t believe that we finished it. I did contribute code to the program but most of the credit definitely goes to Andy. 

Even though we were supposed to delete the code after the session, I did not. I saved it for you all to see. We seeded the world with a “blinker” creature that we knew would live forever. We ran the program in the console and there was our blinker, blinking away. It was such an exciting moment. We even called over Stafford, the organizer, to show him how proud we were. 

I feel like the code we came up with is a good example of what we were supposed to be practicing at the coderetreat. Keep in mind that this was written in 45 minutes. I’m sure Andy could make it better with more time but from my perspective it looks pretty great. I’m just really excited that I was able to help, even just a little bit, to get to this working code. It’s exciting to see something like that work and I know that if I keep working at learning to code, I will be able to think and build like Andy one day. It makes me want to keep working hard and I think that’s part of the purpose of GDCR. 

Working with Andy at the end of the day really saved it for me. If I had another bad session where I didn’t do a good job of teaching, I’m not sure my outlook on the day would have been as good as it turned out to be. I might have been very disheartened by the day. In that regard, I’m not sure I would have recommended it for myself or other people who are still pretty new to programming. Being a beginning programmer is a pretty fragile state. If I weren’t so stubborn, a bad coderetreat could have sidelined my programming for a little while. Luckily, working with Andy at the end of the day really inspired me to keep trying.