Coding dojos

At work, we do weekly coding dojos since 2 1/2 months now - and it's great!

Every thursday at 11am we meet in front of a computer and start a 1h-timeboxed session. This session consists of 3 parts: discuss kata, code, retrospective.

Discuss kata

First, we decide which kata to start with. If we haven't finished the kata from the week before, we throw away the results and start again from scratch including finding a common interpretation of the requirements (e.g. does an account number consist of 3 or 4 lines). Throwing away the work you have already done is not painful at all. Actually, it is necessary to improve yourself. Seeing direct improvements (e.g. completing a part of the kata which was never touched the week before) is priceless!

This part should be as long as necessary but as short as possible. At the moment, we need more than 10 minutes before writing our first test. I think we can cut that into halves in the coming weeks.

Code

At the moment, we work on the Bank OCR-kata and haven't finished the first user story yet. Before this kata, we successfully finished the katas Prime Factors and Roman Numerals *proud*. We do the katas (as well as our actual real-code-pair-programming) in a flow-Randori system:
The first person to be on the keyboard creates the test-project and writes the first test. After that, we play a round of musical chairs and the next developer solves the test. When it's green, he has the chance to refactor the code using baby-steps. Having finished the refactoring, all he has to do now is to write the next test and initiate the next round of musical chairs (which doesn't necessarily needs music to play in the background).
I think doing this kind of system is perfect when you're 4-6 people. Are there more than that, you would probably more likely do the prepari system. But being 10+ developers, I would rather split the group into two halves than having one big group where not everyone can participate.

Retrospective
About 5 minutes before the deadline, we begin the retrospective and try to find out what was good or what can be better next time. Right now, we're far away from a fast TDD-circle: approximately 5 minutes lasts a red-green-refactor-mantra, which surely can be lowered to 2 minutes.

In my opinion, every company writing software should have a regular coding dojo in the calendar. It helps enormously to spread a common coding style. Everyone learns from everyone, be it new keyboard-shortcuts (- is my newest) or amazing tools like R# or Visual Studio Power Tools.

With coding dojos, it is easy to integrate new team members and guide them in learning TDD. All in all, I highly recommend that!

Pair Programming

Puh, just finished a pair programming-session with Artem. This was hard work!
We started at about 14:00 and wanted to add some unittests for a class Artem wrote. I already reviewed his code, so I knew it quite good. By the way, one result of the review was "where are the unittests?" - so I maneuvered myself in this position. Anyway, good quality-code needs some sacrifices *heroic*
I took the keyboard and Artem the mouse... No, just kidding. He was sitting beside me keeping an eye on my cursor. So we began with the first function and let Visual Studio build a test-stub and an accessor (yes, I love that!) for us. We discussed what to test for this method and I began to write code for it - easy. Not long afterwards, we found the first inconsistency which wasn't visible in the review and in the productive code either. Fixed it and continued. This went on and on, one unittest after the other. We discussed the relevant parts of the code and enhanced a few places.
But as time goes by, I noticed how unconcentrated I was and that I made more and more typos. What a luck that we almost had all unittests we longed for. So we created the rest and finished that session. It was 16:00 and I was exhausted like never before when writing some code.
I must say, that this was hard, but it was worth for it. You can't get such a tight feedback-loop when doing reviews and you can't produce code just by discussing it in a normal meeting. So, pair programming is great but exhausting!

CodeRush Xpress

Some time ago, I tried ReSharper, but wasn't totally convinced to spend > 100 Euro - so I forgot about it. As I'm doing more and more refactorings (you know, I'm on my way...), I really felt that there could be tools to help me. I read some forums and found CodeRush Xpress. Just have a look at the introductory video here and you want to work immediately with it.
I discovered that tool the day before I went on a 1-week-no-pc-holiday-trip. As I came back, I was eager to try it and it held all my demands.
I'm using + + <+ / -> (Selection increase / decrease), the camel-case navigation and on a variable (show appearance). And of course I'm using + <ö> (german layout) to call the refactorings. It's nice how you get a visual feedback for an upcoming refactoring:

There's so much so discover for me. There's also a kind-of mod-community, because the API is open (DXCore) to extend. Great tool!

Black and short

Did you see the Shortcut Poster for Visual Studio? It fits nicely on a Din A4-paper (ok, you should have sharp eyes) and it lays now in front of my monitor. For example, do you know CTRL-Tab? Browsing open documents inside VS. Or CTRL-K, CTRL-C: comment the selected lines. Veeeery helpful!

And now finally I'm cool: I use a theme for my Visual Studio. I wanted to try a black background and ended up on the VibrantInk-theme. I use it for about 3 days and I think it's great :)