Conway’s Game of Life in Code Retreat
Last weekend I went to the Code Retreat Event in Singapore. The event promotes on TDD and pair programming. In the event, we work on something called Conway’s Game of Life. It is a no player game, the game just evolves by itself from it’s initial state, and it has 4 rules, and so on… It’s easier to just show it:
Above is the Conway’s game of life coded with a special initial state that is able to reproduce “glider spaceships” on and on. If you wonder what’s a spaceship, this is a single spaceship:
The interesting thing about Conway’s game of life is the fact that it can produce interesting patterns based on just simple rules:
1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
2. Any live cell with two or three live neighbours lives on to the next generation.
3. Any live cell with more than three live neighbours dies, as if by overcrowding.
4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Given only 45 mins each session to code the game of life, and we’re supposed to throw away the code after every session. It’s quite impossible to finish the code (for most of the people), however the emphasis is not to complete it, but to learn from your partner through pair programming and practice TDD. Anyway I feel a need to improve on my Ruby basics, so I finish it anyway after the event, here’s my version running in the terminal in Ruby:
A link to github for my messy (but at least working) source code:
Some thoughts on pair programming and TDD experience
I’m very new to web programming and having only 2 months experience working on Ruby on Rails, I can handle simple bug fixes without problem on a day job. In the event, whoever got to pair up with me became the more experienced guy eventually, so I get to see how they write code (of course I couldn’t learn much in a short time, but I get to see their coding habits, and get some direct feedback).
Importance of the basics of a language
While working with the experienced partner, I noticed that I’m missing something very important, which is the basics! I realize that most of them seldom refer to the documentation. For me, I must have google for something within 10 minutes. It will increase the productivity in a long run by knowing the basics well. Example, the Array class, I did not know that there’s a count() method, so I’m using ‘each’ to for counting; another example, command for generating a migration script, I have to refer to Rails Guide every single time, so I’m making it a point to remember the basics well.
Ping-pong Pair Programming
Besides, we get to practice ping-pong pair programming with TDD, where one of us writes the test, and the another writes the implementation. I realize that I learn pretty fast this way (I’m not sure if the other person learn something by teaching me thou), because I’m guided directly by an experienced programmer.
Another thing that I realize while doing ping-pong programming is that I can visualize a problem properly from the top level on what I want to build and what to expect from the outcome. I’m the one who is writing the implementation, so while looking at the other person writing the test, I can visualize the problem better and eventually, the implementation became clearer and easier. This is an interesting fact that I didn’t thought of. From now onwards, even I’m not practicing TDD, I tend to write down what I want to achieve and the expected outcome before I jump right into writing code.
In one of the session, we took a challenge to practice strict Test Driven Development, which is to write implementation just enough to pass a single test at a time. This is to prevent us from writing too much code that is either not needed, or not covered by the test. The experienced developer who paired with me often ask me to STOP! and hit F8 (to run the test) while I write too much than the coverage of the test. I got a taste of how it feels like, but I’m not sure how I could do this in my daily work.
Practicing In My Daily Work?
Is pair programming worth a try in our daily job? It certainly has it’s social aspect, where someone can be your live debugger and talk to you, and get you talking to a colleague that you normally don’t talk to. Learning from an experienced guy 1 on 1, will definitely speed up the learning process.
We might be able to cover our colleague’s back if they went for a vacation and there’s an emergency too. However, are 2 people working on the same thing going to decrease productivity instead? I’m not sure since I’ve never tried that yet…
Is TDD worth a try? I’m sure that TDD has many benefits, firstly, it will report any failures on any previously working code when we add in new features. Besides that, it makes us produce quality code from thinking thoroughly about how we should structure our code while writing the test. I watched the Unit Testing video from Misko Hevery, and he emphasizes that the key for doing TDD is to learn how to write clean & testable code. So while we practice TDD correctly, we will eventually be able to write clean and quality code. It will force us to think about the coupling of the code and write code that is easier to test.
This is some of the thoughts I have on pair programming and TDD for now after having a day of experience on an event, but I still new to all these and some of my understanding might be wrong… will blog about my new understanding as soon as I got them into my head. 🙂
TDD is definitely one of the thing I will look into soon.
That’s it for now, good night! 🙂