See you there!

Some science seems to suggest that a lot of good ideas, maybe even most of them, come from collaboration and is a network of thoughts rather than a single person unexpectedly getting an idea while taking a bath. In a tightly knit group, your teammates are the extension of your mind, imagination and memory. Or as Steven Johnson said, “chance favors the connected mind”.

If this is true, let’s think about it in the context of software development. What’s the most important thing to get good ideas about in our profession?

Here are a few suggestions:

• Reducing bugs
• Writing better code
• Increase collaboration
• Improve communications
• Increase usability

If you’re like me, you believe that all of the above are results of the way the team works, i.e. the process. It would then seem like a team that is capable of spawning really good ideas about the process and ways to improve it is very valuable.

If you somehow stimulate the intellectual and free discussions of progress in your team, then you’re practically bound to get many improvement suggestions that any one individual couldn’t have figured out on their own. If the teams learns how to, in a safe environment, discuss, argue, challenge and intellectually defend ideas, beautiful things happen.

To me, a well run daily stand-up seems like a good option to achieve this.

Upplägg:
- vi träffas och köper kaffe + frukostmacka
- vi skriver ner tänkbara samtalsämnen för morgonen
- vi röstar på vilka ämnen som är intressantast och betar av dem i turordning utifrån popularitet. Under tiden finns möjlighet att fylla i den mindmap som ligger framme och som sedan kommer att fotas och läggas upp på våran blogg för att vi ska kunna gå tillbaka senare och se vad som diskuterades
- det hela avslutas när folk tycker att det är dags att gå till jobbet

Alla är välkomna, det här är ett generellt lean-forum. Har du bakgrund inom akademiska världen, bilbranschen, vården eller mjukvaruindustrin spelar ingen roll, det är bara att dyka upp.

Om det finns nog med intresse för det här flyttar vi gärna in till ett mer centralt beläget café i Stockholm, men som det är nu så jobbar vi tre som drar i det hela i Sundbybergsområdet, därför var det smidigast så. Klaga gärna, vi är flexibla med både tid och plats!

Om ni vill läsa mer om Lean Coffee-konceptet kan ni kolla upp ursprunget: Seattle Lean Coffee.

I’m done when the code is:

• covered by automatic tests that express domain logic to as large an extent as possible
• tested in the following browsers: IE6, IE7, IE8, Firefox, Chrome, Safari
• commented
• following the project standards
• peer reviewed

This is a modern version of it, written in 1964.

I swear to fulfill, to the best of my ability and judgment, this covenant:

I will respect the hard-won scientific gains of those physicians in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow.

I will apply, for the benefit of the sick, all measures [that] are required, avoiding those twin traps of overtreatment and therapeutic nihilism.

I will remember that there is art to medicine as well as science, and that warmth, sympathy, and understanding may outweigh the surgeon’s knife or the chemist’s drug.

I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a patient’s recovery.

I will respect the privacy of my patients, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of life and death. If it is given me to save a life, all thanks. But it may also be within my power to take a life; this awesome responsibility must be faced with great humbleness and awareness of my own frailty. Above all, I must not play at God.

I will remember that I do not treat a fever chart, a cancerous growth, but a sick human being, whose illness may affect the person’s family and economic stability. My responsibility includes these related problems, if I am to care adequately for the sick.

I will prevent disease whenever I can, for prevention is preferable to cure.

I will remember that I remain a member of society, with special obligations to all my fellow human beings, those sound of mind and body as well as the infirm.

If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act so as to preserve the finest traditions of my calling and may I long experience the joy of healing those who seek my help.

Sparring in martial arts

There are many metaphors for software development taken from the world of hurting other people, and this is no different. I have some limited martial arts experience, mainly MMA, and I’ve always found that the most rewarding part of practice was the sparring.

A sparring session usually consists of people pairing up to try out their skills in a slightly more realistic environment that is still safe. The sparring may be very broad, i.e. everything is allowed, or sometimes only a subset of techniques can be utilized or you have to accomplish a specific goal (such as a rear naked choke).

A boxing class, for example, might start off with warm-ups and then move on to technical drills, such as a improving hand-eye coordination, like the guy to the left, or specific striking combination for 30 minutes. After that, you could finish with 30 minutes of sparring. The sparring is usually done in pairs, and you go at it for a round and then change your sparring partner. The goal is of course to improve and during the rounds you learn from each other, help each other and get to apply fine-grained knowledge in a complex and fluid situation.

How well does it translate to our profession?

Very well if you ask me. We can say that learning the programming basics through reading books, attending courses, practicing katas etc. is like drilling, and our day jobs are like a real fight in front of an audience. So code sparring should be something in between that is safe (e.g. you wont harm any important production code) and less competitive/dangerous.

I know that Micah Martin has a different definition of what code sparring is, but that was a sort of competition instead of what I feel sparring really is. I’m not saying that it’s a bad thing, but I’d call his version “light contact coding” or something.

Anyway, to emulate real programming work more than a dojo did for us, roughly 10 people gathered at a big table and paired up. In order to keep things fluent, fun and to learn to know each other better, we rotated every 20 minutes. Due to the fact that people might feel uneasy about the prospect of handing over their sacred computer to others, the ones who brought laptops stayed put, and the others switched seats by moving one step to the left. The assignment we chose to work on was the KataYahtzee, driving the implementation out using test-driven development.

This was a very pleasant experience, far more enjoyable to me compared to a coding dojo, and the rest of the attendees seemed to agree. Before we knew it, the time was 10pm and we had to go home.

The people who rotated always had fresh and clever ideas from the other pairing stations they had been at (just like consultants, eh?) which merged together with the existing code to evolve into something new. And constantly being part of a pair meant that everybody seemed to be focused and utilizing the time efficiently from start to finish. Also, unlike a dojo, any group size should work for this kind of exercise.

The constant change of pairs also meant you had to be able to quickly communicate the whats and the hows of the code to your new partner, which sharpens your verbal skills as well.

The biggest problem that I could see was the strict division between the laptop owners and the more consultant-like people who changed code base every 20 minutes. Some people were not content with sitting in the same seat all night, so there’s room for improvement. Make sure to read Morten Nielsens summary of the sparring as well.

Why don’t you try a code sparring night in your office or with your local user group? If you do, tell me how it went and any suggestions you have for making this better.

EDIT: I am in no way claiming that I invented this kind of practice. I know that CodeRetreats are very similar and other kinds of pairing roulettes existed before I suggested Code Sparring.

I’ve always known that my main problem was initializing too many projects only to become stressed out by everything, unmotivated and abandoning most of them halfway through, which in turn led to a sense of failure and broken promises, either to myself or to others. Therefore the Work In Process (WIP) limitations of a kanban board seemed like a very good idea, and I quickly set one up for free at Zen. After adding some WIP limitations to the Working column, I got started and the results came instantly: I’ve been finishing up some old projects that I’ve had in the back of my mind for years. All of a sudden I know that when I start a project, I will finish it. Even if it becomes stale or boring, I have to push through before I can move on to something that seems like more fun. Just knowing that is a great motivator for actually finishing stuff, thereby delivering some kind of value.

My kanban board is very simple: I have a backlog, a Working column, a Complete column and an archive (where items I’ve finished long ago go). It seems almost too simple compared to what large teams use, but hey – there’s no team in I (and vice versa). The Working column has a WIP limit of 2 items, of which one can be computer related (e.g. reading the RSpec Book) and one can be related to something else (e.g. painting the walls). I noticed that if I allow myself to do two or more computer related tasks at once, I jump back and forth depending on the mood. That in turn leads to the pace feeling a bit slow, which lowers the motivation to work on stuff even more, which makes the pace even slower and so on…

My personal kanban board (click to see large version)

I’ve actually completed many more items than are in the Complete column above. I’ve just moved them into the “Archive” column. Just so you know.

Since I only have three columns, the visualization part of the kanban isn’t as prominent as when you’re working on a bigger team. Neither the backlog nor the Complete column can be bottlenecks, all I have to analyze from this perspective is the Working column, and it’s always full. I tried having more columns in the beginning, just to be able to identify bottlenecks, but it always felt contrived.

So the steps for you to get started with a personal kanban are very few:

1. Create a board with columns and determine the initial Work In Process limits (you can change them later, it’s an open process).
2. Create tasks/stories and put them in the backlog.
3. Start pulling from the backlog.
4. Analyze what goes well and what doesn’t, and start reaping the benefits of actually getting things done. It sure feels good pulling items into that column.

Once those darn walls are painted, my fiancee and I will put up a common kanban board for both of us in that room (the guest room/office). I’ll report on that in a future blog post.

The paper sums up what seems to be the general idea in contemporary psychology of what it takes to become an expert in any field: deliberate practice for an extended period of time (10.000 hours or 10 years at a minimum), constantly throwing yourself at new challenges, having experts/teachers/supervisors around you etc. It also states that “across a wide range of experts, including athletes, novelists and musicians, very few appear to be able to engage in more than four to five hours of high concentration and deliberate practice at a time”. Finally I don’t have to feel guilty about not being able to perform complicated programming tasks after 2 o’clock anymore! What a relief.

The authors also give a nice tip of how to improve your skills on your journey to becoming an expert, by trying to replicate masters in the field and then compare your result to theirs, analyzing the differences and drawing conclusions upon that:

“Say you have someone in your company who is a masterly communicator, and you learn that he is going to give a talk to a unit that will be laying off workers. Sit down and write your own speech, and then compare his actual speech with what you wrote. Observe the reactions to his talk and imagine what the reactions would be to yours. Each time you can generate by yourself decisions, interactions, or speeches that match those of people who excel, you move one step closer to reaching the level of an expert performer.”

This apparently translates to any job. It’s truly inspiring, and I believe a good way for programmers to start is by looking at the expert programmers around the world. Read their books, understand how they think, and mimic it until you know it by heart, then analyze it. Memorizing a code kata seems like a good way to add to your 10.000 hours of deliberate practice

Here are two katas to help you get started right now:
Robert Martin’s Bowling Game Kata
Robert Martin’s Prime Factors Kata

See you in 10 years!

Thanks to Petter Wigle for recording, editing and putting it up on Viddler.

Edit: I’ve been told I’m looking back at the slides projection way too much during this presentation. I agree. It’s because someone changed the settings on the laptop just before my presentation, so that I couldn’t see what slide I was on on it’s screen.

I guess I’ve been thinking about this for a long time, but reading the excellent book Pragmatic Thinking & Learning: Refactor Your Wetware by Andy Hunt made me understand it at a much deeper level. Thinking and understanding aren’t the same as you’ll see.

The conclusion I reached was something that I’ve been iterating in my mind over and over during the last year: you need to learn how to communicate with yourself. Communicating with others is more visible and a highly sought after skill because it shows that you’re not a introvert geek, but being able to communicate with yourself is something that I think we all should strive for as well.

What really snapped my head into place was a bug I had been trying to solve for a few days. Yes a few days, that’s how long I was stuck on this little sucker. Just before going home on the second day, I started thinking about self communication and opened up a text editor and described the problem to myself as detailed as I could. Then I read through it and huzzah, the bug was solved within minutes. It was super simple, but I had spent the two days being stuck in a mental rut that I couldn’t escape as long as I only tried to code myself out of the problem.

The secret is the action of putting what you think about into concrete, actual words. This process switches your brain into another mode, makes you think about it a little differently and activates reflection on this subject in your mind which can go on unnoticed for weeks in your subconscious. You may believe that just thinking about the problem is enough, since you feel that you already know all you need to know. But that is a mistake. Expressing the problems differently is key to developing a holistic understanding, to start seeing patterns, to connect to the knowledge you have about the subject through different mental paths. The way I see it there are many clues in society that point to the benefit of this, such as the catholic confessions, prayer, psychotherapy, rubber ducking, letter writing, keeping a diary and so on.

So the next step for you, dear nerd, is to fire up a text editor or open a notebook and describe any problem you haven’t been able to solve for a while to yourself. It may be related to coding, work or even your personal life. Then you can throw it away, you’ve probably already benefitted from it. Do this over and over, perhaps through a simple exercise called morning pages, and you’ll start understanding the mechanics that are you and your mind and what you need to do to continually improve yourself.

It has done wonders for me anyway.