On Monday, I asked you to review your meeting formats.

Now I want you to look back. Which of those meetings were productive? Which encouraged healthy collaboration, and which had a bunch of people staring into space (or worse, doing other work at the same time)?

Of the unproductive meetings, what was the format like? Did they stick to a specific style, or meander about? Was there someone keeping the discussion on track, or was facilitation left to whoever had the most clout or influence? Was there a clear goal for the meeting?

I can guess the answers to most of these questions. In my experience, unproductive meetings tend not to have any kind of defined format, no agenda, or no facilitation. I find that simply naming the meeting more specifically can help a lot with this. If it’s a 1-to-1 discussion, with the goal of bringing issues to light, we can name it as such: “Alice and Bob discuss potential issues”. If the goal is to make a decision on our new home page after we’ve already gathered a lot of information through discussion, let’s call it “Make a decision on the new home page”.

And if it’s to come up with ideas, debate them, and then make a decision, call it that: “come up with ideas for improving user engagement, then debate them, then make a decision”. When your meeting name is too long and repeatedly uses the name “and”, we can refactor, breaking it into pieces.

A lot of software development boils down to naming things well, recognising smells, and refactoring mercilessly. I encourage you to do the same thing with your conversations.

Again, I’m really interested to know your thoughts and reflections on this topic. Please let me know in the comments or on Twitter.

Happy Monday, those of you who are reading this as it’s published.

I have a challenge for you this week (or any week), inspired by the Agile Conversations Slack group. If you work in software development, you most likely have a bunch of “meetings” throughout the week. Now, I really dislike the term “meeting”, because I find it very general.

In the interest of improving your skills, I invite you to get better at naming things by being more specific about the meeting in question. Try breaking down the meetings by format. For example, you might encounter:

• “status updates”, where a bunch of people deliver information to get in sync;
• “catch-ups”, where 2–3 people talk about what’s on their mind;
• “brainstorming”, where a bunch of people come together to come up with ideas;
• “debates”, where several people argue the relative merits of opposing ideas;
• “decisions”, where people come together to decide a path forward;
• “lectures”, where one person presents something to an audience, possibly with time for Q&A; or
• “ask me anything”, where one person fields questions from an audience.

Names are made up by me. There are many more formats, I’m sure, but this’ll get you started.

Take a look at your calendar for the week, and see if you can tell from the event title and description what kind of meeting you expect. Does it have a format? Does it encompass multiple formats at once? Is it going to be a free-for-all?

When the event comes around, make some notes: see if the format aligns with what you expected, and if the meeting sticks to its format, changes throughout, or devolves into whatever goes. Figure out who’s leading the meeting, and if they made their agenda clear beforehand. Look around to see if people are engaged or if their attention wanders. And finally, make a judgement on whether it was a productive use of your time (and everyone else’s).

In order to improve, we begin by gathering data.

I’d love to hear how this experiment goes. Please let me know in the comments or on Twitter.

Sometimes, when attempting to write, or design, or create something new, you’ll get “blocked”. You know where you want to be, but you don’t know the next words to write to get yourself moving.

The trick, as I’ve found it, is to not write (or design, or create) the next thing.

Writing often goes from top to bottom, left to right. But it doesn’t have to be that way. You can start in the middle.

So start in the middle, and write the thing that’s first and foremost in your mind. It doesn’t matter that it doesn’t make sense without some kind of prelude, or that your story hasn’t arrived there yet. Write it anyway. Write paragraph 12, or chapter 6, or slide 19.

And then, write the bit before that. You can write upwards. It’s OK. We have computers now. No one’s stopping you.

And you know, it works with software too. Design and implement the bit that’s calling you. The rest will come later. There is no defined order. You can take it apart and reassemble it later.

And the best bit? You’ll find you didn’t need nearly as much prelude, or scaffolding, or story, as you initially thought. By starting in the middle, you’ll help your reader get to the middle a lot faster.

It’s been almost exactly nine years since I attended my first unconference: SoCraTes, in Germany. At the time, it was around 60 people, gathered in the ever-fascinating SeminarZentrum Rückersbach, nestled in a forest, on a hill, about 50km away from any kind of civilisation. A bunch of people, trapped, with very little to do except talk about computers.

SoCraTes is special, even for an unconference. It attracts an incredible mix of makers, educators, connectors, hackers, facilitators, and philosophers. People who work for large companies and small ones. People who create for themselves, and people who help others do their best work. People who care.

It’s also long, for an unconference. Two days of serious discussion and ensemble programming. Three nights of discourse and hatching ideas. A hotel with good food and tasty beer. Always-perfect weather.

The nights are where the magic happens.

Every time I visit an unconference, like SoCraTes (or SoCraTes UK, or SoCraTes Canaries, or one of the many offshoots across Europe), I come back emotional. I come back inspired, wanting to create better software, do more important work, strive for solutions to problems that have never been quite solved.

I come back knowing I have life-long friends as a result of the three days we spent together.

It’s been two years since I’ve participated in any unconference. I miss the joy, and the education, and the late-night revelry. But most of all, I miss the nights. I miss the discussions that go on late, building and building on top of each other to reach new ideas and new levels of expressiveness, fueled by the various topics brought up in the daytime. I miss pairing with someone at 2am because we had an idea and we couldn’t wait to implement it.

It doesn’t even matter if the idea didn’t work out. We learned something that we could never have learned any other way. Usually about ourselves.

Terry Pratchett often wrote about “inspiration” as particles flying through the air until they impact someone’s brain. Maybe he’s right, but they’re not totally random: we can attract them. Unconferences are a magnet for inspiration, and that, I miss most of all.

SoCraTes turns 10 years old this weekend, and like most other gatherings this year, it will be virtual. I won’t be attending. I hope it’s wonderful, and that the participants get a lot of joy out of it, but it’s not for me. I don’t miss the talks, I miss the community, the meeting of minds. I can’t get that feeling over a video link, even with a super-fast Internet connection.

Best of luck, SoCraTes. I’ll be missing you.

You might have heard that test-driven development, or “TDD”, is as simple as three easy steps. So without further ado, I present them here.

1. Write a failing test.
2. Delete that test. It was nonsense.
3. Write a much smaller test with just an assertion and a couple of extra lines.
4. Run the test and observe that the failure message is completely useless.
5. Rewrite the assertion for good failure messages.
6. Run the test again. Rejoice in your helpful failure message.
7. Try to make it pass by implementing a new function in your test code.
8. Realise that in order to make it pass, you have to basically duplicate the test setup, because you’re using stubs and mocks.
9. Decide that this way lies madness. Rewrite the test a second time, without using mocks.
10. Recognise that by not using mocks, you can’t inject an in-memory database, and so the test is going to be gargantuan and slow. You have to return a value that states the intent, and have some other thing actually do the database interaction.
11. Make lunch.
12. Eat lunch.
13. Spend some time sketching out what it means to have a value that says “insert this thing into a table”.
14. Come up with representations of state changes like InsertThisThing.
15. Recognise that that’s a bad name, and instead investigate your domain language.
16. Create structures to represent modifications to your application state in the language of your domain.
17. Realise you have no word for whatever this “thing” is, and go ask someone.
18. Have a long and fruitful discussion with your customer about what it really means when someone does this thing.
19. Agree on terminology, and write it down.
20. Add that terminology to your code.
21. Write that assertion.
22. Make it pass.
23. Move the logic out of the test code.
24. Tidy things up, move them around, generally let your brain relax as you clean things up.
25. Make some tea. It’s been a long day.

You might already be familiar with a different set of steps. They look something like this:

1. Write a failing test.
2. Make the test pass.
3. Refactor your code.

Also known as “red, green, refactor”.

While these steps definitely capture the method of TDD, they can make it sound easy. They explain the mechanics, but not the purpose. We use these steps to tease out misunderstandings, contradictions, and hidden complexity in our software and our (often informal) requirements. When they flow, and we can simply write the test, and make it pass, that’s a wonderful feeling.

But it’s when they don’t work that we’ve learned something useful about our software.