Completely Mental

It just so happens, that one of my favourite pastimes is following the proceedings of a little sport called football. For esoteric reasons, I happen to support a British team called Queens Park Rangers. Just recently I came across a forum post with a link to
this 1988 documentary on the team’s mental training at the time. In it, viewers are introduced to how a sports psychologist works with the team during six weeks. Players learn to focus on matters they wish to be good at, and to visualize themselves doing them.
They also get to do team sessions where they discuss problematic areas during the past season, and where they get the chance to express their feelings about situations on the football pitch. The impact of this mental training is deemed a success, with several of the players improving their focus areas. From the manager’s viewpoint, the team also started to communicate on a whole different level than what was ever imaginable before the training.

Fascinating, isn’t it: an activity based on strength, stamina, genes, hard training and ball juggling talent can be improved by psychology! Oh, and that’s why I came to think that the act of mental training is greatly underappreciated in the world of software development, and is frankly something that I don’t think many teams or companies are doing. Sure, the Agile retrospective is something along the lines of what I’d like to see, but it encompasses so many areas not related to how we feel or communicate with each other.

I don’t have a Ph.D. in Psychology, but I reckon that just by applying some commonsense we can immediately identify some things:
1. When we visualize ourselves doing hard things, or talk about things we fear, we inadvertantly improve in these areas. With continued mental training we unlearn unwanted habits while discovering how not to fear our most dreaded scenarios. I argue that visualizing writing clean code actually makes you write cleaner code, or maybe more indirectly, sets your mind in a state more open to learning things you need to know to write cleaner code!
2. When we get the chance to express our feelings about softer topics such as why you are hesitant to refactor legacy code, or why you fret about pair programming, or what you really think about the new process being pushed upon you from above, we immediately feel better about them. As a group, we bond together instead of building mental silos. Opportunities for adaptation arises instead of slipping through our fingers!
3. In reference to my previous review of The Two Second Advantage, when doing this kind of training, you are in effect building mental models of your particular focus area. These mental models include knowing how other members of your team will react in certain situations.

Maybe my argumentation is a bit abstract, so let’s just think about a few things I’ve noticed “out there”: People realize pair coding, peer code reviews, TDD, etc, are indeed very useful practices, but for one reason or another they repeatedly ignore following them. Or what about people sitting at their desks/cubicles/work stations deciphering a cryptic email from someone from another department across the hall for 30 minutes, instead of walking over to that person and resolving the confusion. Most of the time this has to do with fear; fear of not knowing how to do something, fear of not knowing what something will be like, or fear that something would be too much work or too boring! Venting such fears opens up for peer understanding and relief which in turn might push a team to try some of the practices out. The team and its members will grow, as a unit as well as individually.

As for how you can accomplish this in practice, well, unfortunately I don’t have much experience on the matter. But I suggest introducing the topics of mental training in the company, and encourage people to get together and talk about them as often as they want; on Lean Coffes before work, or during team meetings, or on extended or separate retrospectives, or preferably over a beer or two after work!

As always, experiment, evaluate, improve.

Foo Café

Foo Café seemed like an interesting enough project to warrant leaving work early to attend the ‘Grand Opening’ on Aug 27. In short, the project’s aim is to be like ‘a conference, that happens everyday’ according to the project founder, Michael Tiberg. I’m intrigued. Leanly, Tiberg spoke about the project just enough so that the audience could estimate what it had to offer. It’s supposed to support various user groups and associations in the Malmö area (southern Sweden) to create an independent meeting place for IT-folk.

As far as I could gather the project is quite mature, involves a huge crowd of people, and has been running along sneakily for some time. I definitely hope it succeeds in what it tries to do, and it will certainly fill a void in our region. Another running developer event, Java Forum, had been idle in Malmö for more than a year before only somewhat coming to life again this year. Avega’s Elevate seminars are usually much appreciated, but are intended for smaller crowds and they aren’t happening every day. Surely there should be room for these kinds of larger events in a region filled with IT professionals?

The event also featured the ever so lively developer ‘celeb’ Dan North. He gave a short talk on his views that Coding Dojos foster ‘deliberate practice’, when you should in fact strive for ‘deliberate learning’. The point being roughly that you need to learn about what you don’t yet know, to be able to learn properly in our dynamic business. His point is valid.

There was beer at the end, but unfortunately I was second order ignorant of that fact when I chose to drive a car to the venue…dang it, next time :)