Hello. Welcome here, and thanks for coming. I presume you’re here to learn something about Code Retreat. Good for you. Here’s a list of questions that I am going to pretend someone asked me:
- How did it go?
- What is your hope with writing this post?
- What is a code retreat, anyway?
- Why do you go to a code retreat?
- What did you learn?
- What surprised you?
- What will you do differently?
- OK, but what can you tell me to help me as a future code retreat attendee?
- I’m sold! When’s the next one?
- Im organizing a code retreat. Would you like to come out?
- I’m organizing a code retreat. Can you help facilitate it?
- Can I ask you a question about the code retreat?
- WTF? This post is toooooo looong!
How did it go?
Great. Thanks for asking. Unlike other years, I experienced a very low level of frustration, and there are not many things I would do differently. I had fun and I learned a lot even in the previous years, but I felt that I could have prepared better, and I was always disappointed that I did not come out with a finished program from any of the sessions. This time I made a finished program before the event.
What is your hope with writing this post?
This was my third code retreat. I want to recommend it to everyone else who wants to get better at programming. At the same time, I’ve experienced significant frustration during the previous two years, and this year, I did not. I want to share my findings with people who will go, so that they can know what to expect, and maximize the amount of learning that happens.
What is a code retreat, anyway?
A code retreat is essentially a learning opportunity. More specifically, it is a learning opportunity to get better at developing software. In my opinion, it is suitable for anyone from people who do not know how to program to people who have programmed most of their life.
It is a full-day ( 9-5 ) event that is broken into six 45-minute sessions. In each session, you pair up with another attendee, and you try to learn to develop software better together with that person. The developed software is secondary, but it provides a problem to try to solve through software. We were implementing Conway’s Game of Life. After each 45 minute session, you pair up with another attendee, get rid of the code you wrote in the previous session, and start over.
Why do you go to a code retreat?
I go to learn from my peers how I can get better at developing software. I go to make myself available to my peers to learn how to be better at software development. I go to learn how to facilitate a code retreat so I can perhaps facilitate my own when the time comes.
What did you learn?
I learned many things. The answer I offered to the gathered group at the end of the day was that I learned that the best question to ask after each coding session is “What did you learn?” A nice open-ended question that places emphasis on what the point of the day is. This is contrasted to a question like “How did that go?”, or “What did you think about not being able to use ‘if statements’?”
What surprised you?
How many PHP sessions I did. How little frustration I experienced during the day. That there were only 11 attendees at the event. I was also pleasantly surprised by the open-mindedness David Wesst displayed during our session. I guess I had some prejudice about him :).
What will you do differently?
I can answer a few different questions based on this question…
What do I regret about this code retreat? I snapped at someone during the event. I wish I hadn’t. I’m sorry.
What will I do differently at the next code retreat? I can’t think of anything. I am very happy with how I prepared and what I did at the event. I feel like I seized all the learning opportunities I could have.
What will I do differently at work based on what I learned at this code retreat? I hope to continue increasing the number of ways in which I do not limit the freedom of choice of those who interact with me at work. For example, I hope to not push Test-Driven Development onto people who do not want to do it. I also hope to give up on more of the excuses I use to not do my best work daily. I hope to find more ways in which I can change my behavior to encourage more collaboration at work.
OK, but what can you tell me to help me as a future code retreat attendee?
In one word: Prepare.
It is very hard to actually finish the implementation of the game of life in just 45 minutes. You can pretty much do it only if both of you have done it before exactly the same way including algorithm, language and testing tools. If you have even one circumstance that will make it harder, it pretty much becomes impossible, so you might as well give up on that, and think about what you actually could learn. Things that make it harder are things such as:
- You or your pair not being familiar with the programming language used, or the testing framework used, or even the editor used. Instead of trying to learn how to finish an implementation of the game of life, focus on learning/teaching about the cool features of that language.
- You or your pair not being familiar with ideas in Test-Driven Development. Instead of trying to learn how to finish an implementation of the game of life, focus on learning the mechanics of how to do TDD and what benefits of TDD the more experienced half has seen in practice.
- You or your pair is not deeply familiar with the Game of Life. Instead of trying to finish an executable implementation, focus on exploring what a finished program might look like, and explore the algorithm with which one could implement the game of life.
The purpose of the event is to learn from your peers. What you learn is open-ended, so don’t limit yourself if you see an opportunity to learn something you or your pair thinks you should learn. In each session there are multiple things you could pursue trying to learn, but if you’re paired with someone with considerable experience with something, you should probably take advantage of that. In each pairing, it might be good to learn what are some of the strengths of the person you’re paired with, so you can focus on those things. From the other side, knowing what you’re good at can help your partner for the session understand what opportunities are available to them.
Another thing to consider is that you’re learning how to be good at pair programming, not just programming. Pair programming brings in the social aspect, and because of that, social skills are also available to be learned.
So the common things available to get some hands-on experience with at a code retreat, and meet someone who has considerable experience with it, are:
- How to develop software in a pair?
- How do my skills compare to my peers in some aspect?
- How to program?
- How to program with a specific language?
- How to do unit testing?
- How to do acceptance testing?
- How to use a particular testing framework?
- Why does a particular activity exist as part of a code retreat? What is it trying to teach me?
- What does a program that implements the Game of Life do?
- What are different ways one might implement the program for the Game of Life?
- And many more…
I’m sold! When’s the next one?
You can reply to this tweet one of the organizers sent out:
Im organizing a code retreat. Would you like to come out?
Yes, I’d love to! Just leave a comment or get in touch.
I’m organizing a code retreat. Can you help facilitate it?
I’d be honoured to! Thanks! Just leave a comment or get in touch.
Can I ask you a question ( about the code retreat )?
Absolutely – whatever is on your mind. Comments are open, so ask away, or get in touch in another way.
WTF? This post is toooooo looong!
I’m sorry. You definitely won’t want to read this collection of questions and answers that did not make it into this post.
Dan Bernardic 