Sushi Programming is an agile technique to get knowledge and good habits from older Software Developers to the newer guys around. Also we want to get rid of the fishy bad habits, but thats just the other side of the coin :) Learn how to do it, which rules the two phases have and where the benefits against Pair Programming are!

1. SUSHI PROGRAMMING
The healthy way to share nice habits...
0

2. SUSHI PROGRAMMING
The healthy way to share nice habits...
(...and eat the shy ones)
0

3. WHO AM I?
Software Developer and User Interface Designer
Studied
CS at and
Design-Informatics at
Certi ed ScrumMaster
Working at
Main interests
programming languages/compiler construction
3D Programming
nature/hiking, sports (Kettlebell/Basketball), guitar
Martin-Luther-Universität
Burg Giebichenstein Art College
Halle
OXID eSales AG
0

4. WHY "SUSHI" PROGRAMMING?
not sure
where i got this information from
if it is true :D
if you want to become a sushi cook, you have to
spend a certain time as a dish washer and
waiter
0

5. BENEFITS OF BEING ASSISTANT FIRST
should give you
respect for other tasks around
soak in spirit, like how to treat food/guests
you are
avoiding biggest mistakes over and over again
lled with best practices
0

6. WHATS IN FOR US?
Healthy habit in my eyes:
learning developers: soaking the spirit/knowledge
master developers: spreading the spirit/knowledge
0

7. HOW TO DO IT?
We have two phases in sushi programming:
1.the "Performance" and
2.the Discussion
0

8. THE PERFORMANCE - ROLE #I: THE AUTHOR
one Developer gets a small, usual task
writes code as usual with normal
computer,
IDE,
language and
project/product/platform
0

9. THE PERFORMANCE - ROLE #II: THE
AUDIENCE
at least one Developer
base philosophy: watch, and only watch
no talking overall!
while watching: note remarkable things
0

10. THE PERFORMANCE - DURATION
between 15 and 45 minutes
shorter: not enough new good/bad habits
longer: amount of new things per minute decreases
0

11. THE DISCUSSION
Audience and Author walk through the notes
example questions (good ones):
"How did you get your IDE to automagically create this
whole bunch of fully tested classes?"
"Do you know, that you could generate the getters/setters?"
0

12. DISCUSSING THE DISCUSSION
good habits swap around the Team
bad ones get out of the Author
Rule of thumb:
all points must be formulated respectful
without a personal valuation
will keep the drama out
Aim: spread the given knowledge as much as possible
0

13. DIFFERENCES TO SIMILAR TECHNIQUES
Pair Programming: doing and talking strictly divided into
phases
Peer Reviews: looking at the HOW and not on the WHAT
Katas: only one performs, always different tasks
0

14. PROS AND CONS
0

15. PROS
Authors ow isn't broke by discussions
get more knowledge copy/pasted
nd more hidden treasures (a.k.a. IDE shortcuts or bad habits)
than by Pair Programming
team members get deeper understanding of technologies
team members get knowing each other better (seeing each
other nding solutions)
team members train discussing without hurting each other
0

16. CONS
the "we don't learn anything new" trap
too often,
without new developers
0

17. CONCLUSION
Felix and i
had fun,
learned things
it was worth :)
Do you have a better name?
Is a dish washer and waiter job a part of becoming a Sushi chef?
Please tell me your experiences with Sushi Programming!
--> i@sebastianbauer.name
0

18. THANK YOU!
0

19. QUESTIONS?
0