Coding Is Like Cooking

Last night a group of eight python hackers were drawn into a darkened conference room on Odinsgatan “Odin’s street” in order to exchange little-known information and to take part in obscure coding rituals. To open proceedings, Andrew Dalke shared deep insights into the enigmatic “stackless” python. Later on, fuelled by strong Swedish coffee and cucumber sandwiches, we together attempted the “BankOCR” Code Kata. Everyone present contributed to further our art, and most took a turn working the somewhat arcane keyboard and IDE. By the end we had created a perfect although incomplete code chimera. Despite our considerable successes, it may need further work before any bank would consider taking on our design for their optical character recognition system.

And now I must confess to the part I have played in this pythonic plot. It is the result of scheming between Andrew Dalke, Johan Lindberg and myself. We joined together a few weeks ago to make arrangements for the creation of this chapter of the python community. By some twist of fate, I was designated “temporär ordförande”, or “acting high priest”.

Three hours of pythonic union notwithstanding, everyone present last night agreed that the experiment should be repeated. We look forward to the continuation of our assembly at the second Gothenburg Python User Group meeting sometime next month.

I’ve listened to a lot of Bob Payne’s agile toolkit podcasts and I think Bob is pretty poor at interviewing people, although he does interview some very interesting people.

Bob clearly doesn’t plan his interviews or think in advance about what questions to ask. He just seems to sit down and chat with people as if he were in a bar somewhere and happened to have a microphone on the table. He often assumes his listeners know the background of the person and what is being discussed, and doesn’t ask people to elaborate. Bob also tends to interrupt the person he interviews and presents his own opinions rather than getting them to elaborate on their views.

It’s a far cry from the other podcasts I like to listen to, where the interviewers are really professional, for example Bob McDonald on Quirks and Quarks, or Greg Galant on Venture Voice.

Anyway, as I said, Bob Payne does interview some interesting people. I listened to this podcast today, where he was talking to Dave (Smalltalk) Thomas. They rambled on at some length about different programming languages and platforms, and Dave started talking about what he called “boutique” languages, APL being a case in point. What he said about this community totally corroborated what I discovered when I met a couple of APL programmers recently. There aren’t that many of them, they mostly work for financial institutions, and they collaborate very heavily with their business users/domain experts. This article by Stephen Taylor gives a flavour of how this community works, and talks about a kind of pair programming between an APL expert and an end user. It sounds really cool, actually, and highly productive.

Bob Payne is clearly a Ruby community member, and Dave (Smalltalk) Thomas is in the Smalltalk community. I mostly count myself part of the Python community these days. Each programming language community seems to have its quirks and personalities. Of the communities I’ve hung out with to any extent, I’ve noticed that the Ruby community seems to be really friendly and welcoming to newcomers, whereas the python community can often seem very aloof and somehow intimidating. The Java community is so enormous it doesn’t seem to notice other communities exist, or have anything useful to offer, although it’s a few years now since I’ve hung out with them, and they may be moving on.

I think these “community personalities” arise partly because people move between language communities slowly and infrequently. Once you get good at a particular language it is always easier to stick to it than learn a new one. In their first book the Pragmatic Programmers advise you learn a new language every year, but I’m sure only a vanishingly small proportion of programmers manage this, and even fewer go on to get involved in more than one language community.

I am really interested to see what will happen with all this talk of Polyglot programming that (amongst others) Neal Ford has been talking about – they predict that in future your average system will be built from a number of parts written in different languages, each suited to the task in hand, running on one of the major Virtual Machines – .Net or the JVM.

If this does indeed happen, I think it should result in a major shakeup of the way programming language communities operate and interact, and I believe this will be really positive for the industry. At the moment I feel like their are pearls of wisdom hidden in each separate community, and not enough people are moving around to pick up the pearls and distribute them to the others. Dave Thomas must be one of the few who has insight into more than just one. Maybe one day more programmers will be pairing with end users just like the APL guys have been doing for years.

There’s been a thread on the Agile Sweden mailing list this week about the kind of manipulation that consultant-coaches use in the course of their work with a software development team. Several people seem to favour this definition of what manipulation is:

"One view, to paraphrase Kent Beck, is that manipulation is when you wouldn't get
the same effect if you were upfront about the intervention."

(This quote is attributed to Michael Feathers)

Someone pointed out that they recently went on a training course where during one of the exercises, the course leader was not up front about its purpose. Afterwards he felt that this manipulation had led to a new insight that he was thankful for.

This reminded me of an experience I had many years ago on a similar training course, which was long before I or anyone else had ever heard of agile. As software consultants we were supposed to be learning about the social aspects of our profession, and it was about the third day. The instructors had been interleaving lectures with little games and activities designed to illustrate what we had been learning. The exercise that sticks in my mind went like this.

We were instructed to divide into two groups, and each group was given a datasheet of information and a description of a problem to solve. We were put in separate rooms and given a suitable time limit. We were encouraged to examine the problem, the related data, and report back a suitable solution to the problem to the instructor within the time limit.

In our group we carefully read through the problem and datasheet, and using a whiteboard made connections between the various pieces of information. We quickly discovered that there were large gaps in the information we had and that it was rather difficult to solve the problem. We questioned our instructor about this but she said she had no further information for us. We used our initiative, we thought laterally and came up with what we thought was a reasonable solution. Towards the end of the allotted time we reported back to our instructor our best guess at a solution. She told us that it was wrong.

The other team had not managed to solve their problem either, and when we joined together to discuss what had happened, it turned out that both teams had actually been given the same problem to solve, but each had only half of the needed data. So the only way to successfully complete the exercise would have been for the two teams to pool their knowledge and come up with a joint solution.

I have to say that after 3 days of these kind of exercises I was pretty fed up and I wasn’t the only one. There was a general feeling of being cheated and misled and that we had been set up to fail. In most of the other exercises we had done, talking to the other team would have been considered cheating, since in several of them had been set up as competitions.

The instructor explained that what she wished us to learn from this exercise was that in real life, if your team doesn’t have enough information to be able to write the software, go and talk to the customer. This is a good thing to learn. However, it is not the insight I took away from the exercise. For a start, in real life you know who the customer is and if you don’t have enough information, you know it is not against the rules to go and ask.

In general, I think that this kind of teaching technique can work really well and be a good antidote to endless lectures. However I think it can be done badly, as in this case. If your students come away feeling angry, cheated and misled, they are not going to be very receptive to your lesson, however well intentioned.