April 8, 2010
I’m currently experimenting with checklists in order to make sure I don’t forget or look over important actions when programming. This is my current list.
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
- following the project standards
- peer reviewed
December 14, 2009
Last week, the Swedish ALT.NET group hosted an experimental Code Sparring night at the RemoteX offices. The idea came from the experiences we’ve had with coding dojos and the problems we recognized with that particular way of evolving as a coder. Mainly we felt that there was too much idle time for the people not sitting at the computer, and things quickly became messy with complex communication behaviors disturbing the overall experience. So I suggested that we should work on programming challenges in pairs instead.
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.
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.
October 29, 2009
I just finished reading a very interesting paper by K. Anders Ericsson, Michael J. Prietula and Edward T. Cokely called Making of an Expert. Ericsson, a Swede, is “widely recognized as one of the world’s leading theoretical and experimental researchers on expertise” according to Wikipedia.
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
See you in 10 years!
June 11, 2009
I’m a programmer and perhaps even a nerd, and as such I tend to focus on learning new tools, languages, patterns and other more technical details all the time. But at the core of my job is having good general problem-solving skills and these rarely get as much focus as cool demo webcasts of products to come etc. It’s just like school where you tried to learn facts, but never really learned how to learn.
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.