SoCraTes UK 2024 Insights: A Unique Unconference Experience

Hello there, Sauna fans! It’s time for another conference, or should I say an unconference report by your trusted Sauna developers. My colleague Ivana and I recently attended SoCraTes UK, and as the event is pretty unusual compared to traditional developer activities, we want to share our unique, unconference insights. Let’s go!

SoCraTes is something different. It breaks away from the traditional format of developer conferences by offering a fresh perspective, where nearly everything differs from what you’d expect at a typical conference. It even classifies itself as an unconference, meaning almost everything is unlike regular developer conferences. But what is an unconference? Three key rules for differentiation:

• There is no schedule (upfront)
• There are no talks (there is talking, though)
• The amount of interaction with everyone there is through the roof

Now that we know where we are, let’s dive deeper into the unconference world!

Glowing hula hoops

Before our departure, I was browsing the Unconference GitHub wiki pages, and on the Arrivals page, I spotted a person named Corinna saying that she was also coming to London and asking if someone would join her for the ride to the event. The more the merrier, so I contacted her through Slack, and the three of us met in London and grabbed lunch together, after which we proceeded to the unconference together.

During the train and taxi rides, we had plenty of time to get to know each other and talk about geek stuff. Perfect networking and multitasking! In other words – we actually started the unconference even before we got there!

The first SoCraTes day is informal. It’s a chance to introduce yourself, meet people & chat. Still, it’s a crucial part of the game, as the unconference attendees are very diverse. They are of various ages, the youngest fresh out of school and the oldest on the verge of retirement.

Some people stood out to me because of their outspokenness. For example, Mervi, a Polish girl living in England, is quirky but very easy to talk to. After the first dinner, she performed a dance with glowing hula hoops for just a couple of us on a whim. Here is a trimmed video:

The diversity of the attendants is not a hindrance. It is rather the opposite – it brings richness and depth to the unconference because it is contrasted with a shared interest in software craft (and testing). In other words, the interest in producing high-quality code and how to do it.

Open space

On Friday morning, we attend the unconference opening session. We are (re)introduced to Open Space technology. In short, it is a set of guidelines designed to create environments that encourage collaboration. It starts with a “marketplace” where anyone willing can take a big-format Post-it and write a topic and their name on it. The topic can be something they know about or want to know about.

Then, all the people who have written a topic stand in line and, one by one, briefly explain to the crowd what the topic is about. After presenting your topic, you go to the adjacent room and paste the Post-it on the wall with a location-time grid so everyone knows where and when the topic will be discussed. This proves to be tricky for me because I don’t want to paste my topic at the same time as a topic that interests me. But time & space are constrained, so you have to make some decisions here.

If you have more topics, you move to the end of the line and, on your next turn, explain your next topic and so on. We reflect on the day’s sessions at the end of each day. This is again done in groups where each group discusses where they have been and what they have learned. Mingling among groups is encouraged in the same way as for all the other discussions.

Sessions

Confidence in Software Engineers

Confidence is a multifaceted topic that requires careful consideration. Here are two key aspects of confidence to unpack:

• Confidence in presentation: not having the ability to speak or present your ideas with confidence, although you are confident in them
• Confidence in execution: not having the ability to decide which way to go as you are not sure where you will end up
  

Be supportive and see who needs to change – the devs or their environment?

Feedback like “You have low confidence” is counter-productive and will even lower the dev’s confidence. Be supportive and see who needs to change – the devs or their environment?

Also, with gender taken into account, women usually appear less confident than men simply because men will “fake it until you make it,” having no problem saying they know something when they only heard a term once, while women will be honest about their experience. So, should women also fake it until they make it or should men stop doing that?

Another interesting perspective is that we value existing experience more than the ability to learn, supposedly because the former is easier to measure, but the latter is much more important.

Problematic XP Practices

The central theme of the session is a list of contentious (often argued about) XP practices:

• Trunk-based development
• Pairing
• Monorepos
• No estimates
• No projects

Unfortunately (for me), most of the time is spent discussing monorepos and no estimates. This depends on the crowd – that’s how Open space works. I’m most interested in the “no projects” topic. The gist is that this doesn’t mean projects should not be used at all. This means developers shouldn’t set project-related goals but instead focus on the product. The product is much more important, while the project is just one of the tools to help product delivery.

How do you do BDD?

I suggest this topic in the morning and hope to gather various experiences and distill the core practices that make good BDD workflows. This turned out to be one of the best knowledge exchanges I have ever participated in, as both Seb Rose and Nat Pryce joined in and cut through the less-relevant stuff like tooling & syntax to the core of what BDD is. I try to capture it on a paper panel and annotate it that evening:

My notes from the session are also on the unconference GitHub wiki.

Android Java Mobbing

After all these “heavy thinking” sessions, it is a bit refreshing to participate in a hands-on technical session. Anita has started building a chess game for Android in Java, and she wants help cleaning up the code.

We help her convert it to Kotlin, fix the build configuration & start on refactoring the code. The stuff left for later is replacing the current presentation library with Jetpack Compose and separating game logic from presentation logic so it can be thoroughly covered with tests.

Remote XP

In this group, we discuss how XP practices transfer to remote work. XP has traditionally been designed around the physical presence of all people required to do the work, so this is sometimes challenging when the people are outside the office.

The discussions are in-depth, so we only have time to cover 2 XP practices (informative workspace and sit-together), but I remember these suggestions for remote XP:

• The team dashboard will not be visible at all times (everyone having an extra monitor is complicated) so some alerting system can be put in place (Slack was proposed) so that everyone in the team knows when to look at the dashboard to see what has changed
• The team dashboard traditionally displays the current build status, but also any other information important to the current project
• A whole-day video call can be set up for solo work to which all solo workers connect. Although they do solo stuff, they can easily just ask anyone for help. The problem of spacial audio (you want to overhear a conversation, but not listen to it as you would in a normal call) software was proposed like Gather Town.
• I raised the problem of headsets being too hard on your ears if worn all the time. The response was that you should use the laptop’s speakers & microphone (even if it has less quality).

BDD reboot

In this session, I put together all the bits & pieces I gathered from the previous BDD session but also from the last decade of my search for a working BDD workflow. I am pleasantly surprised that we have been doing exactly what was described with one of our long-term customer projects. However, some improvements can always be tried out.

Testing UI components

A Finnish guy called Esko shows us how his team test-drives UI components. The approach is quite different than ours, and it seems over-engineered. Still, the environments (client, requirements, etc.) are different, so it’s hard to say whether our approach is better. However, we do have interesting discussions about testing in general.

Example mapping

This workshop will plug the last holes in my understanding of practical BDD. It does not go as well as I expected, but I’m still glad to have tried it. Besides, I bought books on BDD in the morning, one of which explains example mapping, so I’m confident I can pick it up from there.

Impact mapping

I suggested an impact mapping session, hoping several people were going to show us how it works in the real world. Alas, only one person from the assembled group did it five years ago. Nevertheless, they proceed to explain it to the whole group. I was surprised that more people hadn’t heard about it before, but not so many people attended the session.

Me showcasing my hobby project

A fun session happens when I offer to showcase my hobby project. It’s made using TDD, and it’s a game. Both of these things cause interest, and I get some good feedback about the game and my artwork.

Software ball

This is a very geeky ball game where participants throw a ball to each other representing execution of a program. The participants and the game facilitator try to agree on a set of instructions for each participant (a “node”) so the ball will travel according to the specifications with as few instructions as possible. I liked it very much as it’s both fun and challenging, plus it encourages physical activity in the open.

Other sessions

Sadly, I missed most of the sessions because of time and space limits on Earth. However, it was clear that the session topics were very diverse. From autism and imposter syndrome through clean code practices all the way to specific hands-on tinkering with Excel, Bash, build scripts, etc.

There were also many other discussions during meals, walks, drinks, and evening board games. We talked to each other a lot since we were all together from 8-9 in the morning until midnight or even later.

Afterglow

During the unconference retrospective, Mervi thought of the term afterglow to describe our state after the unconference due to the fond memories we created together. I’m sure I’ll be buzzing with ideas and thoughts in the days and weeks following the unconference.

However, I will also reflect on all the experiences of interactions, kindness, curiosity, inclusivity, and warmth. In other words: I’ll be enveloped by the afterglow.