socrates_be_logo

During today’s SoCraTes BE Open Space evening, Michel Grootjans ‘reminded’ us to write testimonials for the SoCraTes conference. So I will overdeliver by posting the blog post that has been wasting away in my drafts folder for ages now… Feel free to use anything here as promotional material, Erik! ;)

For the second year now, the Software Craftsmanship and Testing community in Belgium organized a SoCraTes Open Space. The what in where whatnow? Allow me to present you with some context…

The Software Craftsmanship and Testing community is a group of people who have found value in software craftsmanship, as laid out in a manifesto, a couple of books and a whole load of blog posts and other forms of knowledge. Because a community of professionals is important to a craftsperson, we seek each other out and learn from each other. In Belgium, this community is organized by the Meetup group, which is open for everyone to join or organize events, as long as they’re reasonably tech-agnostic. There are more specific Meetup groups available for technologies and programming languages.

An Open Space (also known as unconference, but I won’t use that term since my spelling checker doesn’t know that word and I can’t reliably type it) is a form of conference where the schedule is not fixed in advance. There are some rules and ideas behind an open space, which I’ll explain in a bit. The important part is this: everyone who goes to an event without knowing the schedule, is actually saying ‘I place enough trust the community that I think this event will be more valuable to me than whatever else I can do on my own.’

Isn’t that neat? Yes. It’s super neat.

SoCraTes conferences are organized all over Europe. I’ve only been to the Belgian one so far, I would love to connect with the broader community but I have a whole lifetime left for that.

This blogpost will follow the timeline of what happened at SoCraTesBE for me. Keep in mind that an open space is a hugely subjective experience, and no two people will have followed the same path through the conference.

If you spot any omissions or mistakes, please let me know! Especially if I got people’s names wrong, there were so many new faces and so little time to get to know everyone.

Some facts

the_view

The second SoCraTes BE conference was organized from the evening of Thursday September 15 to the morning of Sunday September 18 2016. The venue was Floreal Le Panoramique Hotel in Tournai, which has a lovely view over the Tournai valley and is located annoyingly close to a church with a really loud church bell.

The conference was organized by Erik Talboom, Koen Metsu and Gien Verschatse. They did an amazing job preparing what needed to be prepared and fixing all the little annoyances that invariably crop up. This year, the annoyances clustered mostly around the taxis and the food, which is, all in all, not the biggest hurdle to an enjoyable conference.

There were about 30 participants.

Thursday evening

We started out with a few getting-to-know-each-other questions, to be answered one-on-one with a random other person you didn’t know very well:

Why did you come here?
What is your biggest dream (professionally) you have yet to achieve?
What was your biggest failure?

For me, those were:

I went last year and it was eye-opening, I want to keep the passion burning and keep learning
My first thought was about getting my team to a higher level, such that we can get to the meaty design discussions faster, instead of struggling over lessons that were already learned a billion times over by other programmers before us. After thinking that a bit through I realized that it is quite silly to limit my ‘biggest dreams’ to my current team, but let’s start from there and build on top of that..
A student job in programming that I was really unhappy about (which might have been conflated with my overall emotional state at the time) and left in an unfinished state. It got me thinking a lot about my responsibilities as software engineer.

Next were group discussions about software craftsmanship topics. These caught me a bit by surprise as they were quite broad and even visionary topics about the state of the SoCraTes movement in plus/delta format, such as ‘What is the effect of the SoCraTes movement?’ or ‘How can we demonstrate to businesses the value of software craftsmanship?’

discussion_effect

That concluded the more coordinated part of the evening. Left to our own means, we got Belgian beer at the bar and discussed some of the questions. I was part of a discussion about diversity. The conference was overwhelmingly white male populated - so how do we improve that? We didn’t quite get to conclusions in that discussion.

I also listened in on some talk about the business value of software craftsmanship. Some loosely paraphrased words of Sandro Mancuso: “Deploying an application once is easy. If you want to reliably do it multiple times per day, steadily adding the things your customer needs most, that’s hard. That’s where craftsmanship comes in. That is added value. Not the TDD or the pair programming or the scrum meetings. But being able to react to changing customer needs.”

Friday

Introduction: what is an open space?

Erik Talboom gave an introduction to open spaces. We want everyone to feel welcomed, and not explaining the rules would be a surefire way to make new people feel they don’t belong here. That makes the introduction a very important part of the conference.

I also think the code of conduct was stated at this moment, though it might also have been introduced Thursday evening. It’s vitally important that everyone feels safe at a conference and in the broader community. The code of conduct is an great tool that provides boundaries to what we consider acceptable behavior in an effort to provide this safety. If you’re wondering, I haven’t heard of any incidents during the conference.

So. Why would we do an open space?

We don’t want to prepare a big schedule up front, because talks are always different from the proposals. Hey, that sounds familiar…
We want equivalence, we believe we can learn from everyone so why would the organizers make a selection of who can take the stage?

Okay, cool, but what exactly is an open space?

Others have explained this before me, but I’ll also give it a try. There are a few ideas to this. First, and most important: the law of two feet: “you have two feet, use them”. Which means get up and go somewhere else if you’re not learning or contributing to the current session. It’s okay to change your mind or notice this isn’t what you thought it would have been or even to get coffee. You are in charge of your own learning. Session hosts will not feel offended.

Next, “It starts when it starts, it ends when it ends”. The idea is that there’s no real pressure to keep to any timing, as people will stay as long as they find value in the session. If the session is interesting, feel free to continue for a while. If the session is over before the full timeslot is filled, feel free to stop the session. There are some boundaries to this idea because someone else might want to host a session in your room, or because there’s a meal schedule to keep. Still, it’s more important to keep the learning happening than to keep to an arbitrary time schedule.

Another principle is that “whatever happens is the only thing that could have happened”. This means that you should be open to anything that happens during sessions, even if it drifts away from the original topic. If you feel the need to talk more about the original topic, try to steer the conversation in that direction, but you can’t force people by waving the (remember, pretty arbitrary) schedule at them. This principle also means that if you feel like your session failed for whatever reason, that’s still okay - it’s the only thing that could have happened and people will learn something from that.

The last explicitely stated idea is that “whoever shows up are the right people”. Don’t be discouraged if only one other person shows up. Don’t expect or assume certain people to come to your session, as it’s their right to use the law of two feet. If you want someone to join your session (for example, an expert on a certain topic), then you can, you know… just ask them to come.

The whole thing is organized via a market place, which is simply a time table of places and times where people add sessions one at a time. Hosting a session doesn’t mean you have to be an expert on a topic, you can have a question. Hosting a session doesn’t mean you have to be there the entire time, but at least be there to start it up or others might be rather confused.

Team Autonomy

The first session I went to was labeled ‘team autonomy’ and hosted by Ian Johnson. He is struggling with a reorganization in their company where the teams were suddenly ‘made autonomous’ without any guidance.

It’s hard to find concrete advice without fully knowing the situation. Most suggestions were to make sure you agree with your team what you want to build by coaching, sharing a product-owner-like role, taking time to create a vision, … Until the team figures out what to build, they can focus on quality, fix those bugs, track the correct metrics that show you are improving.

Other people shared that, basically, the path to autonomy is different for each team and it will always be messy along the way.

Winds of Change Kata

Next session was a try-out of a ‘winds of change’ coding kata excellently hosted by Egga Hartung. It was a coding kata we solved in mobs, grouped around language: Java, Ruby and C#. Since there was only one other Java dev (Aki Salmi) in the room, we paired, but a pair is just a degenerate case of a mob, right?

We did a Caesarian cipher kata with the big catch that the requirements are introduced along the way, by Egga picking a representative of each mob and pressing for some new changes. The requirements started at ‘implement ROT13’ and then ‘oh also skip special characters’ and ‘it should also work for lowercase input’. The next requirement was ‘make it configurable by injecting a shuffled alphabet to use as dictionary lookup’, and the one after that was ‘wait, scratch that, we don’t need it, just use a number to shift the alphabet, so we can for example do ROT7’…

No-one really struggled with that change because everyone was using TDD and git, so that allowed us to fall back quickly to a stable version and have enough flexibility to go in another direction. I can however imagine that you learn a lot from this kata if you didn’t see that coming. Changing requirements are a reality and we need to write our software in a way that supports this.

Aki and me did some property-based testing. One of the interesting properties of ROT13 is that encoding twice returns the same string, so you can write tests that check these properties on random inputs. Interestingly there are many String transformation that exhibit this property, so it seemed not enough to test drive the entire behavior, but the property tests provided a surprising amount of guidance. We came back to property based testing during the evening, and I’m planning to expand on the things I learned in another blog post. Stay tuned!

Code Review Patterns

Erik Talboom wanted to find out in what ways we do code reviews, and if we can create a pattern language out of it and maybe automate parts of it. It seemed very interesting, but the discussion mostly revolved about code quality, which was not exactly what I wanted to hear about as I discuss about those things pretty much every day already.

Fortran

Applying the law of two feet, I ended up with Gien Verschatse trying to find out what Fortran is all about. There wasn’t a lot of knowledge available though, so she and another person ended up going through some tutorials.

I had some Fortran at university, a long time ago. We used it to study computer architecture, to be able write blazingly fast algorithms that for example utilize CPU caches optimally and don’t cause pipeline bubbles. It’s a useful language for this as it’s a higher level language than C, but still really close to the metal. However, I think its real life usage is eclipsed by Python (for scientific programming) or maybe even Go or other new generation languages for high performance system programming, so I wouldn’t recommend it to anyone these days.

Unless, you know, time is ticking on the doomsday device and all you have is an IBM 704 and a whole stack of punchcards to defeat the megavillain. It could happen. Better be prepared.

Smalltalk

I hosted a session to find out why the smart people keep talking about Smalltalk. Seriously. They do. What’s up with that? Turns out they have very good reasons to do it. Smalltalk is amazing. I’ll never be able to stop talking about it. Only thing left to fill the stereotype is to become a smart person.

We started with a talk from Avdi Grimm, embedded below.

The basic idea of Smalltalk is simple and elegant: everything is about messages and objects. And I mean everything. Changing state, inspection, iteration, if-then structures, evaluating lambda’s, the type system and even the whole programming environment. This is combined with an extreme amount of reflection, where you can inspect and change any object, or for example fix your code the moment an exception happens.

You can download the Pharo smalltalk environment and follow the Professor Stef tutorial. Don’t worry, the professor is a pretty chill person to listen to.

Thanks to Mathias Verraes for going through the tutorial with me!

Teal Organizations

This session was hosted by Sandro Mancuso. He presented the way he leads Codurance.

‘Teal organisation’ is a term from the book ‘Reinventing Organizations’ by Laloux and Wilber. The book draws a parallel between human evolution and organizational structure, the movement from chaos (prehistoric) to organization (farming, medieval top-down power structures) to reward structures (humanities, bonuses) to personal growth (humanities) to egoless organizations.

After explaining some of the ideas and values, Sandro went into some of the practices at Codurance. Remember that practices are context sensitive, so it’s more important to understand the principles than to blindly adapt what someone else is doing. With this obligatory warning in the back of our mind, let’s see a few thing of what they do at Codurance…

Pretty much no support roles like HR, accounting, … There is one full-time person helping them with that, in a company of about 25 people. All other employees are developers (who are either ‘craftsmen’ or ‘apprentices’ on their way to become craftsmen). The reasoning is that HR, accounting, etc become departments that are not the core business, so they don’t have much power in the organization, and they will subconsciously start grabbing power by adding rules, regulations and processes. The flip side of that decision, however, is that these things still need to be done. It’s a shared responsibility of everyone. Everyone is allowed to and encouraged to work on sales, hiring, …
Far-going self-management. No managers, flat structure. Empowerment. Shared responsibility. However, to be able to make correct decisions, you need all information. In traditional organizations, making decisions often happens inefficiently because everyone only has part of the puzzle, and doesn’t want to reveal all information. The only logical conclusion for Codurance: openness in everything, including open financials and open salaries. To be completely honest, Sandro mentions he was scared shitless of that step, but he still went through with it. In his words: “even if half the company would have left because of this, it was necessary”. No-one resigned, by the way.
There are no meetings where lots of people are invited for discussion. Instead, let those that are truly passionate prepare and propose an idea. If needed they do a meeting where they decide yes/no with some feedback, but no more than that. Longer discussions happen on Slack.
Continuous self-improvement. There are no fixed time allotments for this, people are trusted to use their time responsibly. Apparently Sandro’s employee Matthew was at Socrates without Sandro even knowing he was planning to come. Matthew cleared this with his client and just went, Codurance pays, there’s no approval needed.
No vision or mission statements. “Where do I see the company in 5 years? I have no fucking idea.” If Sandro proposes a vision or a strategy, there would be no equality, because it would be his vision. This is somewhat counterbalanced because there are shared values, from which a company culture arises.
Don’t strive for consensus in decision making, people care about different things. This is to prevent stalemates where people are forced to ask about their opinion on things they are not passionate about. I personally notice this on my own project, where we took a really long time to make the decision to switch IDE’s (we’re happy IntelliJ users now). This happened just because people where forced to think about it and take a position, and you end up roughly 50/50. By striving for consensus in every decision, you get analysis paralysis and nothing moves - the death of agility.
Empowerment as a value on its own is pointless and can even be dangerous. You also need to develop the proper skills in empowered people. Otherwise, various psychological biases (for example, the Dunning-Kruger effect) will lead to suboptimal decision making.

You can find some ideas in the blog posts from Codurance on Open Financials and Initiative Circles, their way to make change happen without resorting to consensus.

Hacking Authority

This session was hosted by Matthew Butt of Codurance.

Matthew did some reading on authority and wanted to explore how we could recognize or exploit authority structures around us. As introduction, he presented us with some background from Max Weber’s essay The Three Types of Legitimate Rule. Weber defines three types of authority: traditional, legal and charismatic. Another classification is given by French & Raven: positional (corresponds to legal), coercive (stick), reward (carrot), expert (training or expertise) and referent (corresponds to charismatic, defined by relationships).

He noted that the concept of authority is closely related to hierarchies. Some ideas about hierarchy were dropped: subordination, promotion, the Peter principle (people get promoted to their level of incompetence), oligarchy (power is concentrated in a few people), narcissism.

Another important concept that Matthew noted was the difference between the informal and the explicit hierarchy. Even without an explicit hierarchy, there can still be authority. Even during a SoCraTes session, people will entrust the person holding the whiteboard marker with authority.

Having explained and written down these ideas, Matthew then told us that “we all knew as much as he did now”, so we went to group discussion. What can we do with these things?

I had two big takeaways from the discussion. The first was that the key to exploiting authority seems to be to find and use the implicit hierarchy (for example, who has the better connections or who is perceived as having the better expertise) to get past the explicit hierarchy.

The second one is to prepare the flow of information along the hierarchy (valid for both implicit and explicit hierarchies), by talking to the right people. People get (subconsciously) angry or confused when they’re surprised by new information, so if you are in a highly hierarchical context, change might happen easier if you prepare the correct people for new requests/issues.

Dinner - a small controlled experiment

Not exactly a session, but I happened to sit near Mathias Verraes and the conversation ended up on his blog post about small controlled experiments. We were talking about this because Thomas Coopman and Michel Grootjans are trying out this idea at work.

I had read the blog post before but the whole thing didn’t exactly click with me, and now I think I understand why. When Mathias talks about experiments, it’s not to be interpreted as scientific experiments, which would imply repeatability, strict definition of falsifiable hypotheses, measurements, … This is not possible in our line of work, because we don’t repeat the same work - that’s exactly what we’re paid not to do. Don’t bother with the whole science thing. You can’t measure software productivity anyway.

No, the blog post is simply about attempted improvements that can be reversed. Try out this, try out that, evaluate by feeling or maybe involve some locally valid metrics if applicable (‘how much faster does this make our tests?’) but don’t lose track of the context (‘10% faster but it takes twice as long to write one’).

We came to the conclusion that the word ‘experiment’ might not be the best one for this approach, but we didn’t spend a lot of time trying to find a better one. If anyone has a suggestion, I’m sure Mathias is listening.

The more abstract lesson here is that I was fooled by linguistics, giving a word some meaning that wasn’t there. As humans we make these mistakes all the time, and as long as we keep communicating we’ll fix this without thinking twice. However, as developers such miscommunications can cost us a lot when they become solidified in code. Pick your words carefully when introducing new concepts. Study Domain Driven Design. Expand your vocabulary.

Lighting talks

After dinner we had lightning talks. A lightning talk is simply a presentation that takes at most 7 minutes - after 7 minutes you have to leave the stage, no excuses, for the next presenter. This tries to achieve a few things. First, the audience is less likely to lose their attention. Second, no-one is hoarding the stage, which would be in conflict with the idea of equality and learning from everyone. Third, it gives freedom to presenters, because even if no-one understands what you’re saying and your talk completely fails, it only lasts for 7 minutes anyway. Fourth, creativity comes from constraints, not freedom. 7 minutes is a pretty harsh constraint, and as a result you see presenters using everything except the standard bulleted PowerPoint presentation.

The talks we had were

A presentation of (WikiData)[https://www.wikidata.org/], which is an awesome data collection initiative. The data is free to use and they have a pretty nice programming API and query/discovery toolbox. Pokemon and kitties are included.
A talk about opinions, with the basic idea as follows: ‘Ever notice how you sometimes don’t like other people’s opinions? Maybe you can flip that situation and conclude that your opinion doesn’t matter to other people, but only to you. So don’t force it upon others. However, it still matters to you, so don’t ignore it either. Teach people respectfully.’
Mathias talking about his small uncontrolled experiments thing because that kinda was related to the opinions talk and we were talking about it at the table
A talk about antipatterns in software engineering, titled YDD (for YOLO Driven Development). Funny and sometimes painfully relatable.
Thomas talking about keeping track of state in Elm (a functional language) by using the Erlang principles of spawn/message/receive, which seems to me basically a lightweight actor system
Michel doing an intro to sketchnoting. This keeps being magic, he’s so good at it.

Such a diversity of topics in about 45 minutes. How does your favorite conference compare to that?

Bar - whisky and properties

After that it was whisky tasting! Sven Cipido brought six whisky’s for us to taste (note, this was for an extra fee, of course). Rather nice.

As mentioned before, we also did some further exploration of property based testing. That’s what SoCraTes is also about: meeting awesome people and then exploring the unexplored dark caves of software design. If you can do it with whisky, even better.

Saturday

Marketplace

Same idea as the previous day.

Object Calisthenics

Alastair Smith hosted an object calisthenics session which attracted quite a lot of people. Object calisthenics is a kata where you focus on keeping your objects small and lean through some pretty extreme design rules. We used the bank account kata for this, but you could apply these rules as constraints in most katas.

The calisthenics:

one level of indentation per method
don’t use ELSE keyword
wrap all primitives and Strings
no generic collections
one dot per line
don’t abbreviate
keep all entities small
no classes with more than two instance variables
don’t expose internal state in order to make decisions outside of an object

You can read more about these rules on http://williamdurand.fr/2013/06/03/object-calisthenics/.

These constraints indeed lead to very well encapsulated and modifiable code. We applied the last rule maybe a little too strictly, and we didn’t even create accessors to test our code. This led to our tests not having any assertions, only ‘expected exception’ or ‘no exception’. Still, we managed to drive behavior of the code with those tests, which I found very interesting.

Axen Rose communication model

After that session I sat at the back of the room, listening to Erik Talboom talking about the Axen Rose communication model. I had already read the blog posts so I wasn’t very engaged there, even though Erik is a master at explaining things through storytelling.

One law to rule them all: you have 2 feet, use them.

Sifu code generation

I went to the Sifu session by Aki. Sifu is a code generation tool which generates all the things: frontend, backend, endpoints, swagger, dockerfiles, database schemas, …

What I found most interesting is that it tries to think about regenerating the code. Most tools will just generate the code and if you need to change one thing, you’re out of luck and either have to start over or make the changes manually. It’s an eternal problem with scaffolding tools.

Sifu, on the other hand, generates the code in its own git branch and then tries to merge the generated code with the master branch. This means that even if you have already changed previously generated code (for example, to add business rules) you can git merge the newly generated code. That’s a pretty elegant solution!

We toyed around a bit with the tool, and it seems pretty powerful. However, the further you go with the tool itself, the deeper you will find yourself in their own declarative language for the whole model. It’s a super expressive DSL but it’s not testable code.

In its current state, the tool is super impressive for prototyping or throwaway code which needs a bit more longevity or a bit broader model than what a scaffolding tool gives you.

Open marketplace for trainings

Next, Clément Bouillier showcased a project he is doing, which is called Hack Your Training. Basically it’s about trainings being organized by the community instead of by corporations, in order to keep down the price. The website allows you to measure interest in a training in a certain place and ping trainers with this information

The tool, and the whole idea, is still in a very early phase, but to me this makes sense.

There is another nice aspect to the whole project. Instead of storing all the data themselves or setting up elaborated communication schemes with trainers, they leverage existing web platforms such as Google Forms and Twitter. It’s the Lean Startup approach, taken to the extreme. I love it.

Apprenticeship at Codurance

Sandro Mancuso again talking about how awesome Codurance is. Once again, he puts a big emphasis on the fact that he talks about practices, which implies very context sensitive ideas that might not make sense in other companies or personally.

Some history of the company is in order. Codurance was founded by Sandro Mancuso and Mashooq Badar, who are close friends and think very alike about software craftsmanship. They realized pretty soon that they needed to train new employees to think likeminded. So that’s where the apprenticeship idea comes from. As first apprentices they had two very different people, one was a CS graduate and another a marketing person who had followed an introductory programming training and wanted to switch careers. It took three years to graduate the marketing person to craftsman, which is a huge investment for a company.

So they did what they do best and started experimenting. First of all, Sandro and Mash were trying to mentor them but didn’t have enough time available to actually invest in their students. So the second approach they tried was to teaching the apprentices by taking them along for everything that is part of a project and pairing with them. Turns out that, on it’s own, is also not a good idea, as the apprentices will not learn to think by themselves. They need time and space to make their own mistakes and learn from that.

So, another experiment. The apprentices got pet projects which the mentors suggested them, mostly internal tools that would be helpful to Codurance but that were safe to make mistakes on. That also wasn’t ideal, because they weren’t passionate about the tools they were creating, it was just a job. Learning works better when the student is passionate about what they are doing, so it’s better to let the apprentice pick what they are working on. The goal here is learning, not the creation of useful tools, although that can be a beneficial side effect.

They identified another mistake: assigning a mentor to the new employee. It’s possible that unforeseen circumstances take away too much time from the mentor, or maybe there’s just no ‘click’ between the apprentice and the mentor. To fix this, they let the apprentice search for a mentor, talking to various people in the company. Every craftsperson should be available for mentorship, it is part of their job. The apprentice seeking out the mentor has the added benefit that it gives some ownership and self-steering to the career of the apprentice from day one. It’s the job/responsibility of the apprentice to learn and graduate, they shouldn’t be passively undergoing this.

It used to be that graduation from apprentice to craftsperson starts with the apprentice’s mentor being convinced of apprentice being ready. Then the mentor would talk to the other craftspeople in the company, and these will start to work together with the apprentice, or ask for demonstrations of certain skills. The apprentice convinces the other craftspeople of their skills, by pairing or lightning talks or whatever way they find appropriate. If everyone is convinced this person is skilled enough to start working on their own and to represent the company, the apprentice graduates to craftsperson. This graduation process should not be seen as a test they want the apprentices to fail. After all, as long as a person is an apprentice the company keeps investing without much return, so from a pure revenue viewpoint it doesn’t make a lot of sense to keep apprentices from graduating. It’s just all in the spirit of feedback and personal growth, to be able to present a decent expertise to clients.

Keep in mind that all of this should be seen as a very loose system, not as a strict process to be followed.

But then an apprentice came along who really missed some structure, a somewhat standardized way of knowing what was important to learn and what wasn’t. So Sandro told her: “There is no real structure, go create one!” which she started working on.

They defined different skills a craftsperson should have, and identified different levels of required skill acquisition per skill, somewhat according to the Dreyfus model. This means a craftsperson should be an expert in for example TDD, but it’s enough to have a basic understanding of DDD that you can expand on when needed. They put all of this in a Trello board so everyone can see and adapt this.

codurance_apprenticeship_criteria

Part of the skills will be really technical skills like TDD, others will be people skills like coaching and mentoring, but there are also cards for ‘agile methods and history’ and ‘software craftsmanship history’. Cards like these create both a general framework for talking about such things but are also useful to share company values you want to have in your employees.

Based on the skill guidelines board, they make a board per apprentice to track where they are for each of the skills. A really cool idea is that, because this is a Trello board, you can apply WIP limits: only focus on teaching one skill at a time.

codurance_apprenticeship_specific

It’s important to remember that this is still more of a guideline than a strict process, even the craftsmen aren’t expert at every thing and you have to keep learning continuously. Sandro remarked that “holding someone back from graduation because they miss one criterium is stupid”, people are different and the company has grown big enough that they can start relying on complementing skillsets instead of ‘square-shaped people’, people who know everything in-depth. Still, you cannot have extremes like people not being able to TDD or not able to talk to the business.

Because the apprenticeship period is an investment for the company, they are currently experimenting with raising the bar for entry. Currently you need to show up with some IT-related experience before starting at Codurance. It’s a business decision, because during the apprenticeship period the apprentices are paid, so shortening that period results in less investment needed.

A few more practical things they do with the apprentices. Apprentices are required to write a few blog posts on the main Codurance blog, because writing and communicating clearly is an important skill to have. Apprentices will have to organize community events and facilitate meetings. The best way to learn to organize a group of people is by actually organizing a group of people.

Apprentices will need to be fluent at the computer. They need to learn how to type and learn shortcuts. A minimum barrier for pairing with craftspeople is that they can solve the roman numeral kata without touching the mouse. Pairing with someone who can’t do this is super annoying, because there is a lot of friction between thoughts and execution.

Speed reading is also taught. Somewhat cruelly, they give apprentice three books on Thursday with the assignment of wanting to discuss what these books are about on Monday. This means that you’ll be forced to skim the contents without spending a lot of time. It’s an important skill to them because there is a shitload of books to read. Their suggested reading list is on Github.

To conclude, the practices Sandro explains are in sharp contrast to some of the bigger consulting firms who take 100 people on board, send them through training after training, and then mark them as ready. For Sandro, training is about ‘individuals and interactions’, not ‘processes and tools’, so at Codurance they try to keep training as humane as possible.

Journeyman Tour

Tjen Wellens wants to go on a journeyman tour, so he hosted a session on the topic.

Journeyman tours have their roots in medieval professions, organized in guilds. A person starting in the profession would first stay a while with a single master, observing and learning from them. This is the apprenticeship stage. After some time, when both the master and the apprentice thinks the time is right, the apprentice leaves the master, to travel around to other masters and work with them for a while. This is the journeyman stage, and the journey between the masters is the journeyman tour.

A journeyman would not get paid, but the master would provide food and lodging for the journeymen passing by.

In more modern times and applied to software craftsmanship, it would mean spending some time at multiple companies and with multiple more experienced people, creating software together.

However, the session fell short because no-one knows of any possibilities. In Belgium, and I presume in most of Europe, it would be somewhat tricky to organize. Both employers and employees are protected by contract laws to prevent unreported employment, to sustain minimum wages, etc. A journeyman tour would have to fall within these laws. While I think it’s possible, I also think it’s a hard thing to manage for some companies, who might not be fully sold on the idea of taking on someone for only a little while, to teach them but not expect a lot of immediate return on investment.

Clean architecture in Kotlin

The honor of the last session comes to Kris Hofmans who showed us his implementation of the Clean Architecture in Kotlin. I wanted to see this because it was the first talk on Kotlin usage in production I heard about, but I ended up learning more about the clean architecture than about Kotlin. Still, time well spent, as I hadn’t heard about the clean architecture before.

Retrospective

No software craftsmanship meeting without feedback, of course. And even from this I learned. One of the retro formats used was something I haven’t seen before. I don’t know the name so if anyone can tell me, please do! It works as follows: all participants stands in two concentric circles, looking at each other, such that everyone from the inner circle is matched with someone from the outer circle. Then one circle gets 3 minutes to talk to their outer circle buddies about a certain question. The talkers all talk at the same time. The listeners can not respond, but are allowed to encourage the talker to keep going by sending general agreeing or I’m-still-listening cues. After the time is up, you move one of the circles so everyone ends up with another pair, and then the other circle gets a question.

I like how this forces everyone to think about a topic and articulate their response, while not wasting a lot of time. Note that it does get very chaotic and loud, so it seems only useful for setting the stage or concluding the retrospective. I’ll try out something similar at the next big group retrospective I’m facilitating.

Lightning talks and PowerPoint karaoke

The day ended with lightning talks and PowerPoint karaoke. I don’t remember all of the lightning talks, but I gave two myself. The first was about the nature of the fold operation in functional languages, which I’ll expand upon in a future blog post. The second was about systems thinking, with mainly served to show the tool Nicky Case made: Simulating the world (with Emoji). Required reading and experimenting for everyone, in my opinion!

PowerPoint karaoke is a simple idea: put someone in front of the audience where they have to present a slide show they have never seen before. It’s an improvisation exercise, which has some value: it gets you used to speaking in public and it destroys ego, as there’s quite the possibility you will fail at entertaining the audience. With the correct group it leads to hilarious results. And it was actually pretty great, but as they say… You had to be there.

Conclusion

For me, it was my second SoCraTes conference, and it’s incredible how soon I felt at home. For me, conferences like these are important, because I believe that to be or to become a software craftsperson, one has to connect to the broader community. And a SoCraTes conference is one of the best ways to do that. I wanted to share the experience with some of my colleagues, but due to circumstances this didn’t happen. I hope to do be able to do so next year!

My ticket to SoCraTes was paid for by Cegeka, my employer. If you would like to work for an employer that invests in its developers and the general software community, Cegeka is always looking for passionate developers, analysts and coaches.

Notes from SoCraTes Belgium 2016