I'd like to relate three anecdotes that made me feel part of a cool team.


Hopefully you have read the Pragmatic Programmer by Andy Hunt and Dave Thomas so you know what I mean by "rubberducking". If not, go put that on your list now.

So when we were at Uni, a circle of friends would meet almost every day. This was in the era when networks were new and the cable was coaxial. At one time we had three Linux PCs, cobbled together from scavenged parts (not including cases, think bare mainboards), running in different corners of the not-that-big room. We'd play around with our own MUD in LPC. Arne would make tea in Dirk's kitchen, Dirk would switch on the TV with a recording of Star Trek T.N.G., Matze would eat potato chips ... very cosy all in all.

Markus would be in the zone, hacking away. We called that "hack mode". He'd forget that his tea was getting cold, and he'd answer incoherently to any questions that we'd dare pierce through his haze.

At one point, Markus would turn around, look me directly in the eye, point an index finger at the ceiling like an old teacher requesting attention, and take a breath to start talking. Instead of saying anything he'd furrow his eyebrows for a second, then his mien would lighten up and he'd go: "Ah ok, that works! Good talk!". Then he'd turn around and hack away at the keyboard in exactly the same monotonous, concentrated manner as before.

Chips continued to be crushed, Picard continued to give orders, and the tea kept steaming from our cups.

Team Code-Cleaning

In my current team, we have a pile of code to deal with. Some of it is now old enough to go to college. Some of it spreads across half a dozen scripting languages. There have been more different people working on it over time than are currently working in the team.

We've learned some good things over the years. We've learned how to hire smart people and create an atmosphere where they can do solid work.

While the Clean Code movement has some followers, at some places people are still afraid of refactoring, because you can't immediately measure the benefit. I have this feature to finish ASAP, I can't waste time doing it right! As a lead, I'm aware that it's easier to crush the desire for excellence than to instill it as an addiction. Hence I was very satisfied when I found this comment on a review request:

I know this solution works, but I don't feel comfortable about it. It feels clumsy and fragile and is hard to explain. Anyone have a better idea how to formulate this logic?

And wouldn't you know, that same day they paired up for only half an hour, they changed it just so, and I really think that we'll all have a much easier time to understand this bit when we circle around to it in a year or ten. The same day it was checked in, passed the tests, and it ran happily ever after in production.

Silent text and sudden motion

Since the company moved, the team is now living in an eight-people office. I was acutely irritated at the thought that so many devs were supposed to sit together. And in every retrospective, someone mentions that pair programming is good and we should do it more; but for pair programming you need to talk, and four pairs in one room, talking and arguing at the same time, is going to be loud. Turns out we communicate silently much of the time, through text (Slack, if you're interested). There's a voodoo remote control feeling every day:

The room is silent. There's only the clickety-clack of a few keyboards. Stirring of tea with a spoon. An occasional sigh. The faint creaking of a chair.

As if by hypnosis, suddenly all stand up and turn towards the center of the room. The stand-up meeting begins.

We explain what we've been doing, what is bugging each of us, what needs to be put on the list lest we forget. We groan together, we laugh together.

Then we go for lunch together.

jan 2018-09-19