5 Observations at Code Retreats
5 Observations at Code Retreats
Whether you're a fresh-faced Python dev right out of college, or a senior Java developer, code retreats are a great place to learn and grow.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Recently, I facilitated another code retreat. As in previous retreats, the participants who experienced their first code retreat showed pretty similar behavior. It occurred to me that nearly every code retreat first-timer shows the exact same behavior. This article is about how people will act, why they will come, and what they most likely will learn during their first code retreat.
It's important to note that the following observations are just that: observations. A code retreat is a safe environment in which trying new ways of doing things is not only welcomed but the essence of the whole experience. Doing things differently will cause problems and errors, which is just the way it is. There is no "right" way at all.
Observation #1: Java Developers Will "Think Java"
The very first thing most people do when they decide to code in Java is to create a bunch of classes and maybe empty methods. None of the rules state that there has to be a game board class or a cell class, the rules are only about living and dead neighbor cells. Nevertheless, "Java thinking" forces developers to create several classes before even thinking about the domain logic. Developers with a more functional-programming background tend to write functions that implement the domain logic. With this approach, I saw teams that implemented all rules including a 100% test coverage in just 15 minutes.
Observation #2: Developers Try to Multi-Task
The task of implementing Game of Life seems pretty easy, considering the relatively simple domain logic. However, especially young participants of code retreats have trouble with doing too much at once. Often, at least three things are done at the same time: implementing new logic, fixing some bug, and refactoring. That may work, but it makes things so much more complicated. Not multitasking and concentrating on one problem, for example, by using the Mikado method, seems like a hard thing to do.
Observation #3: No Theoretical Examination of the Problem
It's very rare to see a team starting by drawing something on actual paper. Maybe the problems provided by Game of Life are so easy that they are absolutely clear right from the start, but I doubt that. Only after a while, some developers say things like, "Let me draw that for you" or "What I mean is this situation," and begin to scribble. Experimenting with different constellations will make the implications of the rules of the game much easier to understand. Also, drawing something is a great communication tool.
Observation #4: Begin With Special Cases
"What's with the border?" is a question often heard right in the first round of a code retreat. Seemingly, developers love to focus on hard problems, so they begin with what is usually a special situation in the Game of Life: the border. Of course, it's important to decide/ask how cells should behave when they are at the frontier of the game board. But is this the most important thing to think about when no single rule has been implemented yet?
Observation #5: Code Retreats Are "For the Young and For the Old"
After having facilitated quite a few code retreats, I credit the Game of Life with the great potential to fascinate junior developers as well as seasoned software craftsmen. I saw experienced lead developers and architects struggle with the same problems as their younger co-workers. Of course, the old-timer had way more options and possibilities because of the many projects they worked in. But the special situation of having a new, unseen problem at hand seems to be special for everyone. Every code retreat-facilitator thinking that the participants may be too experienced for this event should just try it and see what happens. Bets are that everyone involved will have a great time and learn something.
These observations show: code retreats are a great opportunity to learn from each other and practice the craft of software development. Go ahead and facilitate one with your friends and colleagues!
Some behavior patterns seem to emerge in nearly every code retreat: Java developers will heavily rely on language-specific concepts, participants, in general, will try to multitask (and fail), no one is trying to think about the problem by drawing something, special cases will be focused on way too early, and code retreats are the right event for young junior developers, as well as for experienced old-timers.
Published at DZone with permission of Steven Schwenke . See the original article here.
Opinions expressed by DZone contributors are their own.