This weekend I had the opportunity to visit my favorite work event of the year: a socrates unconference. This is a quick brain dump of the things I learned in sessions, hallway discussions or over a drink. My goal is not to give a full overview of the topics covered during the sessions, but rather showcase what a typical day at a Socrates unconference could look like in case you are on the fence about attending one in the future.
Socrates unconferences use the open space format, this means that there is no predefined schedule. People just show up & share their own ideas for sessions in the morning. After some self-organization we end up with the schedule for the day. The next day this pattern repeats. It’s amazing to see how sessions and discussions during the first day often result in totally fresh session proposals the second day.
Day 0: meeting up
The unconference started on Thursday evening. We got to check into the hotel & met up in the bar for some drinks. Although not officially “started”, I already had enlightening discussions on:
- Consulting & coaching experiences. E.g: “Is it worth paying a consultant 1000$ for a day of consulting, even if he’s just there to repeat the same exact message the employees have been giving management for years?”. Or: “When you are coaching a team on scrum practices, it might help to deliberately break eye contact as a scrum master during stand ups so team members learn to talk to the team instead of the scrum master”. You don’t learn this stuff from a book.
- During dinner my table discussed how people learn & how coaches can leverage this. We discussed the Dreyfus model of skill acquisition, deliberate practice & Shu-Ha-Ri.
- At night we had an interesting discussion on philosophy: Husserl, Effective Altriusm, …
I was down with migraine for the first part of the day, but I managed to follow sessions in the afternoon. In that short timespan however, I was exposed to a ton of new ideas:
Lift pass kata
A hands-on session on the lift pass kata where all attendees got to wrap tests around & refactor a typical REST api.
Personal take-aways: Docker refresher, practice on writing tests against a real http endpoint & refactoring legacy code tips & tricks.
Wardley maps kata
Another hands-on kata session, but on a completely different topic: Wardley maps. Wardley maps are awesome. They are about building an intuitive and shareable understanding of your context to provide the situational awareness necessary for building a sound strategy. I read up on them but had never attempted to draw one myself. The session facilitators gradually eased us into creating our own map for a fictional business.
- First, we were asked to think about the value chain. What capabilities are needed to satisfy our user needs? How are they related?
- Next, they introduced the vertical axis: how visible is this capability to the end user?
- Third, we got to think about the horizontal axis that represents the stages of evolution of a capability.
I thought I understood maps on a rational level, but drawing one myself really made it click. Recommended exercise to run for your own business!
Talk like Sandi Metz
Perhaps my favorite session of the day. We got together to watch one of Sandi Metz’ amazing talks. Do yourself a favor & go watch her stuff if you haven’t already. I’ll wait.
The point of this session wasn’t the talk’s content however. Instead we were observing what makes her talks so effective & fun to watch. Everyone took notes & we had a small group chat in the end sharing our observations. Some of the ones that stuck with me I will be copy-catting in future public speaking engagements:
- She uses body language effectively. Not all over the place, but it adds to her story.
- Her talks are very visual. She uses code diffs, arrows pointing to the relevant lines & color highlights to walk you through refactorings effectively.
- She regularly shares personal experiences & stories. She also shares when she did something “frowned upon” or considered “bad practice”. This makes her instantly relatable & sincere.
- She stimulates audience participation by asking several questions.
- She often repeats her overview slides so you know “where we are” in the talk.
Evening activity: code smell quiz
In the evening, Matthew & Pedro hosted a code smell quiz. For more information, Matthew has written up a previous run on his blog. This is a great exercise to do with your own team!
In this session we learned about connascence (i.e. a taxonomy for different kinds of coupling) through a fun kata. You can find a first draft of the kata description on Aki’s github.
Behavioral code analysis
In this session several people shared their experiences with codescene & behavioral code analysis techniques, i.e. techniques you can use to mine your git logs for interesting insights like “If X leaves the team tomorrow, which parts of the code present the biggest knowledge loss risks?” or “what parts of the code present a relevant risk to feature delivery?”. More info on Adam Tornhill’s blog.
Mob code review
During this session all attendees reviewed a piece of code together. It was really interesting to see how other people do reviews: Where do they start to look? What do they focus on? Do they list pure observations or make interpretations? Do they provide possible solutions? Do they provide links to further reading?
Personal take-aways: try to keep it as objective as possible. Instead of “this feels dirty”, try to describe in terms of naming issues, SOLID violations, connascence, code smells, etc.
Refactor some messy java mob session
In this session we grabbed a random piece of Java code and refactored it in group. Again, it was really interesting to see how others tackle these kinds of problems.
In this session we were presented a design problem. Instead of only thinking about solutions, we were instead encouraged to think about what kinds of heuristics we use when solving problems. A lot of problem solving happens based on “intuition”. This session was an attempt to elucidate these implicit heuristics we use all the time. Most heated design disagreements are caused by people using different (implicit) heuristics. Once made explicit, you can constructively discuss the competing heuristics and even re-use them in new contexts. Some example heuristics we came up with:
- Consider if it is easier to throw away irrelevant information than to reconstruct missing information.
- Consider the reversibility of options when making a decision.
- Consider picking the option that delays the choice.
- If given a binary choice, consider if there are other options not presented.
This led to some really interesting discussions & a whole new set of heuristics I will be using in any future problem solving. More information on Rebecca Wirfs-Brock’s blog.
Impromptu Lightning talks
Lightning talks are my favorite part of the unconference. For 7 minutes, the floor is open to anyone that wants to share something. Topics range from a 7-minute introduction to system thinking, sharing an insight you had while working on some code during the day, to a a visual representation of the Dunning-Kruger effect. Or maybe even showing off your react app that simulates cellular automata or sharing a very personal story that managed to silence an entire room of people.
On the side
During the entire event there were a lot of other activities: attendees brought great aeropress coffee, we had an optional whisky & chocolate tasting, people played board games (playing Azul with people that do programming & maths for a living is hard!), we listened to live folk music. There might even have been some folk dancing 🙂
As always, I had an amazing time & hope to have helped in creating a welcoming environment for all the new faces. I have never encountered a group of people that are this passionate about what they do & want to share their insights, that are this considerate of other people.
To put it in the words of Jessica Kerr: I have found my camerata.