Activity and community are very strong parts in development, most notably the Omaha Code Retreat (Code Retreat is a yearly meeting across the globe where developers find time to have fun and learn to be better developers.) held their meeting this November with the problem of solving Conway’s Game of Life. A rather complicated problem to solve though with the goal of completing it in a short time frame. Each session was given 45 minutes to solve the problem using TDD(Test Driven Development). The methodology/technique for development mentioned in another blog post How success in the tech world is not done alone, Why is TDD involved? would provide more information about TDD.
In order to increase our ability as developers, sometimes sitting down with a problem, reassessing it over and over until the answer appears more apparent is likely the way to improve. The most uncomfortable feeling when writing code that you create only to delete it after each session just to start from scratch is knowing that we had to identify our ability to access the problem accurately. Though this is necessary form of practice, to ingrain the correct steps of TDD like second nature, be able to solve problems heuristically and write code more elegantly. With test driven development, there are some key points to remember:
| Step one | Create test case and make it fail. |
|---|---|
| Step two | Write code to make the test pass. |
| Step three | Refactor the code. |
| Step four | Repeat the process. |
A fairly simple process, though the challenge in TDD is truly knowing the specifications. This came in many perspectives as some people had algorithms formed, some wanted to create an initial test and implement TDD until a pattern emerge. Also, I would say some found that many of the approaches taken were not limited on the resources though the time constraint was really too short. Though that was part of the purpose.
As the day continued the teams were switched or grew in size, at the end of the day a mob session was done, where everyone participated in solving the problem. Another noticeable challenge during the last session was that as we dug deeper into the problem we noticed more and more issues were starting to creep up, though some were able to fix themselves. Seemingly when attempting to write code that in some ways completes tests as the process is done, we were able to notice these issues a lot earlier then simply writing the code and testing for results at the end.
This was fun filled day with witty remarks, brutes of tiny frustrations of wanting to see where the problem was leading to. What was great about this year’s Code Retreat, we were left dealing with the problem that we had to get it right the first time or at least with that ideology in mind, we were forced to think faster and more holistically
