Recently, I’ve been experimenting with doing database migrations directly with JOOQ instead of using some tool like Liquibase or Flyway. And even though it’s just a proof-of-concept for now and the project is mostly on hold, I want to write down what I did so far. Also, I would love to hear your feedback: Pink me on Twitter or via Email.

In the previous post, I said that when you ask a waiter “Is [some dish] vegan?” you would not want to hear the answer “I don’t know”.

But what if you ask about a dish that they do not serve? Imagine asking “Are Powidltatschkerln vegan?” somewhere outside Austria. I would totally expect to hear “I don’t know” as an answer. (They are not, by the way).

So, we might need a boolean with a third “I don’t know” option, after all…

I posted the image above on Twitter with the caption “Almost vegan”—as a (bad) joke about how something cannot be “almost vegan”. Peter Kofler answered “Almost pregnant”, which made me think of… programming, of course. Types, in particular.

“We are in the middle of a global pandemic, and you still write about technology?!?” - Noone of you, dear readers, asked that (yet), but I will now answer it anyway…

Almost over night, everything was different. It is OK to worry, to be scared. But for me, now is also the time to try things. To move closer together, all across the globe, while keeping a physical distance.

Let me explain what I mean…

Last week I tried test && commit || revert - a.k.a “TCR” - for the first time. I went to Mödling (near Vienna) to spend a whole day with Peter Kofler to learn this technique.

We did three sessions: “FizzBuzz”, then a “Snakes & Ladders” game and again the “Snakes & Ladders” game. Before I’ll describe what happened there, TCS means (as defined by Kent Beck):

“When you have a lot of tests; What do you do when you want to change something, and the tests get in your way?”

I hear this question - in one form or another - every now and then. I hear it during the trainings I teach, when coaching or when I am working on some code with a team and try to convince them to write more automated tests.

It is one of the objections I often hear against doing test driven development (TDD): “When we have more tests, changing things later will become harder”.

Recently I was teaching a course about “Software Crafting” to a group of developers, all from the same company. We agreed that I would prepare three days of training (or workshops), and then we would spend two days on whatever they wanted. The original idea was to mob program on their produciton code in those last two days, so we could work on problems they have right now.

But after the three workshop days, they asked me whether we could practice more.

“We want to do a longer example and practice everything we learned so far again!”

So we did that, and it went really well. And here I want to share with you what I have learned in those two days.

But first, let’s talk about the…

Last week I was teaching TDD to two groups of programmers. And in the first group, someone asked me “Why do you always want me to write wrong code?”

I was thinking to myself: “You are wrong, I do not want you to write wrong code, I want you to write the right code!” Fortunately, I did not say that out loud. Instead I asked: “I think I don’t understand what you mean. Can you explain it to me?”

Then the whole question turned into a long discussion with the whole group. And it turned out that this is a really good question and describes a problem that I had too, when I started with TDD. And the group was able to find the answer on their own, with very little input from myself.

It turned out, I had asked them to write “wrong” code…

At the We Are Developers World Congress 2018, I gave a talk about how to deal with legacy code using the Mikado Method. So, here is the concrete example I gave in my talk.

I enter the room. I’m about to give a talk at a conference.
They gave me the biggest room of the venue.
Oh my god, I did not realize how big it is.
I hope it won’t be full.
Oh my god, I hope it won’t look empty!
I go to the audio engineer. Getting my microphone, testing my laptop.
I wait somewhere near the back. My heart starts racing.
Slowly, the room is filling. So many people.
Why did I submit my talk to this conference again?
5 minutes to go. I know that, because I am checking my watch every 20 seconds.
I ask the audio engineer the time. 4:40, then it starts.
I check if my hands are sweating. They are dry. Why are they dry?
I really don’t like to be in the same room with so many people.
40 seconds to go. I can’t remember what I wanted to talk about.
20 seconds. Do my slides even make sense? I should have re-arranged them.
0 seconds. OH MY GOD, I have to give my talk NOW.

I put on a smile. I walk up the stage.
“Good afternoon, everyone! So many came here - awesome! I hope your lunch was good. Today I will talk about…”

Two weeks ago, I gave a talk at a conference. This is roughly how I felt.