Today i want to share a programming technique with you. My former fellow developer Felix and i tried it and had real good experiences while using it. (Damn, its a long time we didn’t worked together and i miss it!)
We named it sushi programming. I will explain later how we came to this name, the differences to Katas and Pair Programming and where we found pros and cons. Let’s keep things short and dive into the sushi bar!
How to do it?
We have two phases in sushi programming:
- the performance and
- the discussion
Let’s dive into the performance
The base philosophy behind “Sushi Programming” is to watch, and ONLY watch, note things, which will be discussed later. So we have one developer who is writing code with his normal IDE in the normal way he does this. Lets call him the author.
The other role is the audience, at minimum one other developer. The audience is only watching the author. It is important, that the audience in no circumstance (only a nuclear war or the lunch time should disturb us ;)) talks to each other or the author. No questions like “How did you get your IDE to automagically create this whole file?” or “Why don’t you use this fancy key combination to commit your code?”. The audience just writes remarkable things down. This phase should durate between 15 and 45 minutes. With shorter phases you won’t find enough new good or bad habits, with longer the amount of things will decrease.
In the second phase, called discussion, the audience and the author walk through the notes of the audience. Here all good habits swap around the team and the bad ones get out of the author. Rule of thumb is, that all points should be formulated respectfull and without a personal judgement. So only ask “How did you did that magic trick?” or “Do you know, that you could generate the getters/setters?”. I think it is important to write about this rule, cause it will keep the drama out of the discussion. The aim of this technique is to spread the given knowledge as much as possible in the team and increase everyones work quality and speed.
Differences to other techniques
In pair programming you are allowed to talk all the time. This gives the software developers a better understanding of each other and the solution they build. With suhi programming we are aiming only at the habits of each other. Therefore the silence in the first phase is installed.
Peer reviews are either with one guy or with multiple guys. So whenever a piece of code, a software or UI design or an architecture is watched by a group of people, we can call it a peer review. The aim is slightly different from sushi programming: in peer reviews we want to improve the code at all. We should not mind who wrote the code, we just want to see, if it fits our quality standards and our understanding.
Code Katas are a great wy to learn things as a group. We sit together and work through a rigid plan of steps without thinking too deep while doing. The aim is to get a new habit into our muscle memory. For instance it is perfect to get into the Test Driven Development circle, if you never before used it. Or a new framework into your brain. This said, the aim is clearly close to sushi programming: train the new things.
Why the crazy name “Sushi Programming”?
I’m not sure where i got this information from and if it is true: i heard, if you want to become a sushi cook, you have to spend a certain time as a dish washer and as a waiter. This phase around your aimed work should give you the respect for the other activities and let you soak in the spirit of a sushi restaurant, like how to treat the food and the guests. This should beware you of doing the biggest mistakes in the everyday worklife over and over again. You’re filled with best practices before you even ram your first knive in the first fish. Soaking the spirit, for the learning developers, and spreading the spirit, for the master developers is a healthy habit in my eyes.
Pros and cons
- the flow of the author isn’t broke by discussions – a big plus to get more knowledge moving from one to another individual
- the author and the audience find more hidden treasures (a.k.a. IDE shortcuts or bad habits) in the everyday routines of the other than by Pair Programming
- the team members get a deeper understanding of the used techniques
- the team members get kwowing each other better, because they see each other finding solutions (hopefully they reflect their own too and thereby know themself better)
- the team members train discussing techniques and routines without hurting personal feelings, which will be good for the team spirit
- after a time only the knowledge of the team is spreaded, there is a “we don’t learn anthing new” if you do it too often, without developers from the outside of the team
For me it was a really useful habit to sometimes sushi program. Our team knowledge went up fast and it helped me and the others! So my recommendation is: try it yourself and have fun!
Did you liked the article or the idea? Do you feel the urge to propose a better name? Do you know, if it is part of becoming a suhsi cook to be dish washer and waiter first? Did you tried it yourself with some colleagues? What were your experiences? Than please leave a comment!
Thanks for reading and sharing!