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.

Either my standards are too high, or I’ve never seen an excellent CI/CD pipeline. Which got me wondering: what would a truly great continuous deployment (or continuous integration) pipeline look like?

So here’s some ideas.

1. Software developers (programmers, QA, designers, ops, customer liaisons, etc.) can build your entire application (and yes, that includes microservices) in under a minute on their work computers. Offline.

   It’s OK if the first run takes a while, but the second time shouldn’t.

   Bonus points if attempting to build something with no code changes just grabs a pre-built version from a cache somewhere (when you’re online).

2. All programming work goes through at least two people. I don’t care if it’s pair programming, ensemble programming, or some kind of code review, but I do care that it’s fast. If your review process is your bottleneck, your pipeline is not continuous.

3. All unit tests run in under a minute. This includes the centralized build pipeline, but also my (and your) development machine. I should be able to run these from the editor, and get best-in-class output. This means I shouldn’t have to trawl through terminal logs to get the test results unless that’s the status quo for the language I’m using.

4. Similarly, integrated tests take only a few minutes, and can be run from anywhere (not just a CI box). The integrated tests are there to catch edge cases that can’t be tested otherwise; they’re not likely to fail during day-to-day development, and so there are only a few of them.

5. On push, CI builds everything in the exact same way that a developer would, and gets the exact same artifact, byte for byte.

6. We can trust that builds are completely reproducible, so if we try and build the same thing twice, we get it from a cache instead.

7. Building and testing is parallelised to the point that it’s basically instant on CI.

8. Any end-to-end tests are run using production-ready artifacts (built locally or by CI). Nothing is built after the build phase. If you ship Docker images, you test your Docker images, not something else.

9. Tests are trusted, so everyone knows that if the tests pass, the application is almost certainly going to work.

10. Tests are reliable, so a failure is considered a problem, and investigated accordingly. “Flaky” tests are fixed or purged with extreme prejudice.

11. On a successful verification run (i.e. all automated tests pass), artifacts are deployed to production with zero downtime (e.g. using blue-green deployment). This is a non-event and takes less than a few minutes.

12. Developers can easily grab the production artifacts deployed right now or any point in history and deploy them locally.

13. A subset of the end-to-end tests (call them “smoke tests”) are run in production shortly after deployment to validate the application.

14. Business metrics are in place to ensure that the application is working as intended (i.e. fulfilling its purpose, which can usually be correlated with making or saving money). These metrics track as close to real-time as possible.

15. A deployment failure, smoke test failure, or a decline in critical metrics immediately triggers the software to roll back (again, without downtime) and alert the developers. Alerts are always taken seriously, and the developers work hard to make sure they very rarely see the same failure twice.

16. Data is always backwards-compatible to at least a few deployed versions, so rolling forward and backward is always safe.

This isn’t everything, of course, but I think it’s the start of something decent to aim for.