DEV Community

Cover image for SoCraTes UK 2024
Marko Bjelac
Marko Bjelac

Posted on

SoCraTes UK 2024

My colleague Ivana & I went to SoCraTes UK!

This is an unconference, meaning almost all things are unlike regular developer conferences.

But what is an unconference?

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

Here we go…

Glowing hula hoops

Before we leave for England, I browse the unconference github wiki pages and in the Arrivals page I spot a person named Corinna saying she is coming to London and would someone join her for the train & taxi ride to the event. I contact her through Slack, and the 3 of us meet in London & grab lunch together, after which we proceed to the unconference by train & taxi. We get to know each other & talk about our geeky stuff but also various other things.

In other words - we start the unconference even before we get there! 👍

The first day is informal. It’s a chance for introducing yourself, meeting people & chatting.

The unconference attendees are very diverse, but everyone is at ease and open to conversation. After the first dinner, Mervi performs 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 & depth to the unconference because it is contrasted with a shared interest for software craft (and testing). In short, the interest for 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 which encourage collaboration.

It starts with a “marketplace” where anyone who wants takes a big-format post-it and writes a topic and their name on it. The topic can be something they know about or something they want to know about. Then all the people who have written a topic stand in line and one by one shortly explain to the crowd what the topic is about.

After you have explained your topic, you go to the adjacent room and you paste the post-it on the wall with a location-time grid so everyone knows where & 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 of another topic that is interesting to me. But time & space are constrained so you have to make some decision here.

Friday sessions Saturday sessions
Friday sessions Saturday sessions

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.

At the end of each day there we reflect on the day’s sessions. 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.

These reflection sessions are a great idea because I find out what has been going on in the sessions I missed, I get to talk to people I haven't had a chance to talk to yet and they relax the crowd after the wind-up of the day, just in time for dinner.

Sessions

Here are descriptions of most of the sessions I attended.

Confidence in Software Engineers

Confidence is a complex topic. We do a lot of unpacking.

  • 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 certain where you will end up

A feedback like “You have low confidence” is counter-productive and will lower the dev’s confidence even more. Be supportive & see who needs to change the most - the dev or her 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 to say 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. 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 was spent on discussing monorepos & no estimates. This depends on the crowd - that’s how Open space works.

I was most interested in the “no projects” topic. The gist is that this doesn’t mean projects should not be used at all. It means that developers shouldn’t set project-related goals, but instead should 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. I hope I can gather various experiences and distill what are the core practices which make good BDD workflows.

This turns out to be one of the best knowledge exchanges I have ever participated in, as both Seb Rose & Nat Pryce 😍 join in and cut through the less-relevant stuff like tooling & syntax to the core of what is BDD. I try to capture it on a flipchart and annotate it that evening:

My

There are also my notes from the session on the unconference github wiki.

Android Java Mobbing

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

We help her convert it to Kotlin, fix the build configuration & start on refactoring the code.

Stuff left for later is replacing the current presentation library with Jetpack Compose, and also 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 physical presence of all people required to do the work, so this is sometimes challenging when none of the people are in the office.

The discussions are in-depth so we only have time to cover 2 XP practices (informative workspace & 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
  • For solo work, a whole-day video call can be set up 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

This was a session organised by Seb Rose. It helped me put together all the bits & pieces I gathered from the previous BDD session but also from the last decade of my searching for a working BDD workflow.

BDD workflow

I am pleasantly surprised to find out my team was almost on the correct path. We will try out some improvements though.

Testing UI components

Esko showed us how his team test-drives UI components. The approach is quite different than what I've used but the environments (client, requirements, etc.) are different so it’s hard to say whether our approach is really better. However, we do have interesting discussions about testing in general.

Example mapping

This is a workshop to plug the last holes in my understanding of practical BDD. It does not go as well as I expect, but still I’m 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.

The books are available on Leanpub.

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 5 years ago. Nevertheless, they proceed to explain it to the whole group. I was surprised more people didn’t hear about it before but also at so many people attending the session.

Me showcasing my hobby project

A fun session happens when I offer to showcase my hobby project. It’s made using TDD & 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 was planned for Friday morning but ended up being moved to Saturday. This was great because I would have missed it otherwise.

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, challenging & encourages physical activity in the open.

Other sessions

Time-space constraints being what they are on Earth, I missed most of the sessions. However it was clear that the session topics were very diverse. From autism & 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 & evening board games. We were talking to each other a lot, since we were all together from 8-9 in the morning until midnight or even later.

TDD board game Playing TDD, the board game. Yes, it was very late. 😜

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.

In the days & weeks following the unconference I’m sure I’ll be buzzing with ideas & thoughts.

However, I think I will also be reflecting on the experience of the interactions I had, the kindness, curiosity, inclusivity & warmth.

I am deeply grateful to all participants. Thank you for the afterglow! ❤️

SoCraTes UK 2024 group photo

Top comments (0)