Thoughts on CodeRetreat

Last weekend I‌ attended a Code retreat as part of global day of code retreat. I‌ love code retreat. I’ve been attending since 2010. I’ve organized and even facilitated some. But I‌ was rather disappointed in this one. I‌ wanted to write down the issues I‌ saw, not as a criticism of code retreat, but in the hopes of bringing back the original feel of the event and to hopefully grow more of them. As such, I‌’m using each issue to better understand what I dislike and propose a change that will improve the experience.

What it is

CodeRetreat is a full day of practice. It focuses on TDD‌ and design and you do the same problem over and over again in 40 minute bursts. Often there are small variations to help explore new areas of learning. There is often a small retrospective in between each session.

Issues:

Pairing

To be clear, I am a HUGE fan of pair programming. However, there is a skill to pair programming and many at a code retreat have never practiced it before. Having the 1st session default to the style where the driver (person at the keyboard) is typing and thinking tends to lead to a session where the navigator (the person not at the keyboard) is watching. It makes it hard to rotate, and discourages tring new languages.

Solution: I would have the 1st session be strong style pairing. The difference is that the person at the keyboard “is not thinking”. This makes it easy to work in a new language (you just type for the other person). It maximizes communication and helps people to connect. After the 1st session. I‌ would introduce the traditional style of pairing and open it up as to which they prefer.

Retros

Retros are a good way to learn from experience, but there are two issues with the current style. The first is we don’t really have a shared experience, so listening to each other talk full of misunderstandings. This is amplified by the deletion of code (more about that later). So that it was hard to get value out of the retros and they felt more like stand up status meetings.

Solution: I‌ would advise a two phased retro. 1st the teams spend 5-10 minutes retroing their experience by themselves, then they choose the best insight and do a group share of a single insight. I would also include in this group share the language and number of tests written.

Example group share: “We worked in java & wrote 9 tests. We were surprised by how hard it was to work around passing back booleans until we changed to passing in the if/else blocks to the method.”

Deleting Code

Code retreat has a rule that you delete your code at the end of a session. This is a rule that gets violated all the time, but has a good intention. It’s designed to make it safe to experiment. I believe in that safety. But I‌ also believe in the ability to review and learn from the code you wrote. Deleting it prevents reviewing and sharing.

Solution: First, wait until after the retro to delete the code. Second, make the deleting optional to the group, but allow anyone in the group to have the option to delete the code. In other words, unless it is unanimous to not delete the code, the code gets deleted.

Mobbing

I’m surprised there isn’t at least one session of mobbing and a option for mobbing on most sessions. Although, I‌ wouldn’t recommend it for the first session as it cheats people of a chance to struggle.

Solution, I would offer mobbing as a option.

TDD

Test driven development is still very new for many people. I’m surprised by the number of pairs that don’t write any test even though it is stated as a constraint. I think you need sessions just to build this skill. Probably many sessions. In the retros it was common to hear they hadn’t written test.

Solution: Slow down on the addition of constraints. Talk about the testing cycle. Ask about the tests. Give people paper so they can write the test down before code. I would even make a place to post the paper to share.

Constraints

Constraints can be a great way to explore new areas of design. But too many remove all usefulness. This is used a lot in Code Retreat so I’m going to address them individually. But by the 4 session we were doing game of life with: no talking, no primitives across a border, and no if statements. We had not mastered any of these and most people didn’t actually follow the restrictions. It also massively discorages using a new language as it’s an advanced design session.

Suggestion: make constraints optional, give a variety of choices. Encourage not using them if you are doing this session in a new language. The new language is the constraint.

Constraint - Primitives: This is open to a lot of misinterpretation. It’s designed to address coding smell of primitive obsession. Which means you shouldn’t pass around numbers and strings, but objects that have a meaning. Like Money instead of a double, or Name instead of a string. However, there is an interesting issue of constructors: is the code “new Money(100)”‌ allowed? and there is a easy misinterpretation that the specific language definition of primitive is in play. This could just be an autoboxing exercises in java. Use Boolean instead of boolean, Integer instead of int.

Suggestion: have examples and a slide of the constraint.

Constraint - Muted Ping pong Pair Programming. This constraint removes communication in pair programming. It’s rather masochistic. I don’t understand why you would do this other than to show some of the pain, which can help learning, but contributes to the general issue of making the day less fun. Since these are usually saturdays, this should be the opposite of what you are striving for.

“The most important part of practice is making sure you want to show up for practice tomorrow”

Solution: remove this constraint entirely. At a minimum add it a possible minimum constraint

New languages

One of the things I‌ loved most about code retreat was trying new languages. This time that was hard to do because of the amount of other constraints that where in play.

Fun

I also noticed that we ended with less people than we started with. This is amplified by the fact that my partner and I‌ were the only 2 people that didn’t work for the company that hosted the code retreat and I live in a very programmer heavy area. Given the number of programmers in the bay area, there should be multiple code retreats and all of them should be overflowing.
I have had sooooo much fun at code retreats. Practice should be fun. I‌ feel that some of that has gotten lost in translation.

Solution: Bring back the focus on fun. Make it a stated objective.

The Problem with Hackathons

Today I went to TestBowl 2019 - Software Testing Competition.
I had some reservations going into it, but it was in my neighborhood and only 3 hours so I thought "why not".

It was disappointing, but the thing is, I've been to 40-50 practice events for programming. I've hosted quite a few of them myself. So why was this different?

This blog is an exploration into that question...

The Event

The event had about 20 to 30 people. I believe all of them were at the conference anyways (meaning I was the only local). The had dinner and did some questions, that were stated to be ice breakers but didn't include things like actually talking to other people. There was some interesting trivia questions though.
After that we broke into teams of 2 and where given a Test Target (a government website) and a Bug Tracking system (from the company that sponsored the event). This was a contest, so the points went to the most bugs submitted (this is an simplification, but basically true).

We used a mindmap to log as we went and only entered the results into the tracking system in the last 15 minutes.

We tested for around 90 minutes. Then it was over and I went home.

What was wrong

Testing

One very possible reason I didn't enjoy this very much is that it was just exploratory testing. While I admire exploratory testing, it doesn't bring me the joy that programming does. While I do not believe this to be the reason, I think it's important to acknowledge this bias in me as it could color my impressions.

Conversely, I do think it is this bias that is allowing me to see the issues in this event more clearly. It was lacking the "spoonful of sugar" making the distasteful parts more salient.

Contest considered Harmful

The single most harmful thing about this event to me was that it was a contest. The reason I enjoy, attend and participate in hands-on practice sessions is the learning. That's always where the value and focus is. The contest changes that focus and obscures the focus.

For example, there was the option to work alone. I think some of the other teams or even most of the other teams worked separately. This is much worse for learning, but it is understandable that people would prioritise that when "the goal" is number of bugs in 2 hours.

Let's imagine working alone. It's rather hard to see what you would learn if you don't have anyone to learn from. But even with just 2 people there is less chances to learn tricks you can use later. Also, there weren't constraints which are usually helpful when learning. Forcing you to work in a new way and discover new techniques.

Alternative Motivations  

It's obvious that some of the motivation for the hosts was to get people to try out their software. This isn't inherently bad, learning new tools is often useful. However, because contest was drawing attention away from learning we used the tool but without really learning it. I didn't come away with ways the tool could help me to test. This is something that could be addressed better if the focus was solely on learning.

No Retrospective

So another downside of the contest is there isn't much sharing between teams. There was sharing of the score, but this didn't pass along learning just increased focus on the scoring and task. The competitive aspect tends to prevent sharing and reflection . The goal being "to win" instead of 'to learn" also means that when it the work is over you are tempted to leave because it feels like the event is over. You don't stick around to learn because that wasn't the point.

No Space for Stretching

"Hard in training, easy in combat"

Another element that was missing was the space to try new things. Humans tend to either be in a state of practicing or preforming. Part of fitting into the time limit was prioritizing for getting everything done in the time limit. This left little space for actual practice.

In conclusion...

The reason I enjoyed the other practice sessions is the hands on learning. I hadn't realized the amount of effort that was put into making sure this was happening.