Another Journeyman Week

Recently I had the chance to accompany one of my fellow Craftsman to his work and immediately agreed to do so. While my own Code Cop Pair Programming Tour finished in 2013 I am still enthusiastic about being on tour. In the spirit of documenting my previous 13 weeks, I consider these past days to be week number 14 of my (probably never ending) Code Cop Tour ;-)

Global Day of Coderetreat 2015
To improve my facilitation skills, I ask facilitators to run trainings together with me. My friend Carlos Blé agreed to host me for a Code Retreat and I ended in Las Palmas, Gran Canaria for the Global Day of Coderetreat 2015. I recommend Gran Canaria for GDCR because the weather was much nicer than in Austria during mid-November.

For the Code Retreat itself I proposed to have a specific focus, a theme that we would use to shape the day. Carlos selected Object Orientated Design and we built the whole day around it. We started the day with a (very) short introduction - probably more a summary - of basic object oriented design principles. During the day we only used design centric constraints like No Naked Primitives or Tell Don't Ask. I was concerned that some people would like to try functional programming and indeed there was one participant working in Clojure in all sessions. But he did not complain and tried to fulfil the constraints, which was certainly a great exercise, even when using functional paradigms. We also asked participants to use Test Driven Development and pair programming, but we did not stress these topics. By making the Code Retreat more focused, we were able to exercise a single topic more in depth.

Besides from copying Carlos' every move, I learned a lot from the changed setting. I was a guest and knew nothing about how the Craftsmanship group of Gran Canaria and their Code Retreats. Further I had trouble communicating clearly and talked too fast for the Spanish participants. In return I did not get much feedback because I had not communicated well - which left me confused and made me sweat. I cannot remember feeling that exposed. The whole setting proved to be very challenging, exactly what I had been looking for.

Ruben wrote a summary of the day, which saved me from writing it myself. The slides Carlos and I used are available here.

AIDA Canaries
Because I "happened" to be around, Carlos invited me to spend a few days with his current client, AIDA, probably the largest IT company native to the island of Gran Canaria. I spend three days mob programming with Carlos, Emilio Medina and Ronny Ancorini. I used the opportunity to improve my C#, which I had not used since my session with Paul two years ago. I learned some more things about C# and ReSharper. We worked long hours and I did not see much of Gran Canaria during these days. As I had not come as a tourist, I did not mind.

Carlos published his summary of my visit already, which saved me a lot of typing again. (It seems that it pays off that my post is a month late ;-) I really loved staying some days in AIDA, everybody was nice and very inclusive. While a few employees had problems talking English, everybody seemed to appreciate my visit and the discussions I started. I enjoyed my time there. Thank you!

Spontaneous Unconference on Functional Programming
The following Friday I was lucky to meet Nicole Rauch. She had come to Vienna for her talk at the Agile Tour Vienna. She was one day early and we took the opportunity to spend the day together. While I had planned to host her, my friend Görge Albrecht, the "Code Mentor", stepped up and did the extra work of really organising the day, getting the necessary infrastructure and even paid for drinks and lunch. (Thank you Görge, I owe you.) The Software Craftsmen GmbH helped us out with their meeting room and shared their office with us for a day. The Software Craftsmen are a young company of experienced but still enthusiastic software professionals.

So a few members of the Vienna Craftsmanship group came together to discuss, share and exchange knowledge with Nicole. In the morning we collected possible topics. As Nicole is into functional programming, it was no surprise that Haskell, Monads and all kind of functional topics came up. We started discussing and reviewing one of her older presentation on Monads, which gave us plenty food for thought. In the afternoon we decided to do some coding and mob programmed an asynchronous error handling Monad in NodeJS. It was a great day and I learned a lot. Thank you Nicole for finding time for us and squeezing in a day of learning between your customer meetings, travel time and conference presentations.

Conclusion
The bottom line of this week is that our community is very inclusive. It is easy to find people who will accept you as a guest or be your guest if you just pay a little attention to their schedule. I had found Nicole's name in the list of speakers of Agile Tour Vienna, so I knew she would come. All I had to do was reach out to her early enough and we made it happen. The same was true for my visit to Carlos. I knew he would run a Code Retreat for GDCR15, so all I had to do was propose doing it together. I encourage you to look out for such kind of learning opportunities. Follow the people you meet at conferences, pay some attention to their (promotional) tweets and conference schedules and do not be afraid to reach out and ask them to spend some time together to discuss, learn, practise or just write some code together.

Journeyman Pairing Sessions

This is the third and last part of my series about my Journeyman Tour two years ago. In how to Journeyman Tour I summed up all facts and advice regarding planning such a tour. Then I described what I learned by going on a Journeyman Tour. Today I want to share more about the actual pair programming sessions. During the tour I already summarised some findings, e.g. I wrote about discussing expectations with your pairing partner up front and bringing a keyboard for all languages used in the area.

The Very First Session
When I started my tour I did not know how it would work out. I was uncertain how others would react and afraid to screw up. It helped me that the very first session took place in my usual environment. Raphael and I met in a co-working space I had been before. I knew the place and how to get there. Also we worked in Java, the language I had been using almost exclusively until my tour. By using my main language I was not bothered by the language and its tools. Third we started a new project from scratch, starting with a detailed introductory discussion. There was no old code I had to understand. And finally Raphael and I shared the same mindset. It was clear from the beginning that we would do TDD and create high quality code that he needed for his games. The only thing that was new for me during our pair programming was being on tour and pairing with a stranger. It was the perfect start. Probably I was just lucky, but I recommend starting your tour like that. Look for someone you know, working in a place you know, using a programming language you know. This might be a colleague from a previous engagement or someone from your favourite meetup community who agrees with you on most things.

Warm-up
When pairing with a stranger for the first time, I needed some time to establish a rapport. During my tour it took between a few pomodoros (two hours) up to the while day (eight hours) to get in sync with my partner and understand the domain to an extend that I was able to contribute. On the second day we usually worked much better. Due to this warm-up I recommend sessions of at least two full days with each person - assuming that you are looking for real pair programming during your tour.

Interruptions
Most of my pairing partners had blocked their calendar and made sure they were available the whole day without interruptions. Many did not even check their email all day. Some had even organised a meeting room so we could work on our own. Unfortunately not all people I visited knew how to "behave well". Working with heavy task switchers was really difficult. As the guest I did not complain about task switches, but when the interruptions became too many or too long, I went back discussing our expectations of the pairing. Few young developers had to be reminded to stay focused on the task at hand.


Tasks
In the introduction of my Code Cop Tour I explained my conditions as following: The only condition is that we will pair program. It should be a quiet time without meetings where you plan development activities on the mainline of delivery, e.g. writing code, writing tests or improve your build system. Obviously not all kinds of work, even on the mainline of delivery, were useful to me. For example researching or spiking, where we both had no clue how to continue, did not work well. And I hated spending two days of my tour looking for a single bug, tracing execution through auditing records in the database. While I believe that pair programming might be useful for debugging in general, I did not have the relevant experience to help my pair here. I recommend rejecting such work for your visit, or at least discuss the problems with your pairing partner up front.

Taking Notes
I brought a large notebook with me to record all interesting things. I wrote down the full names of my pairing partners, their expectations and any learnings during the sessions. I kept notes of each session retrospective and a kind of personal diary. I glued in business cards, Post-it notes and all stickers I collected during my tour. In the beginning I used a cheap pen, which made my hand hurt after some time. I had not practised my hand writing for almost 20 years. I fall back to my fountain-pen, which created a mess of ink now and then, but was a better writing device by far. I wrote a total of 55 pages A4, two pages per pair programming session on average. For road thoughts I used the standard voice recorder of my mobile phone. While it worked I do not recommend using it during driving, especially when going fast on the highway.

Known Or Unknown Pairing Partners
In the previous blog posts I quoted some other Journeymen and named their advice according their names. While these rules make sense for me, you may chose to ignore them. The last of these "rules" is Samir's rule: If I do not know you, I will not pair with you. What Samir meant was to meet before the session, to get to know the partner and make sure that both get something out of pairing. This is definitely a way to reduce uncertainty and avoid surprises. Checking future pairing partners helps aligning your expectations with potential learnings. On the other hand - depending on your learning goal (see Daniel's rule, you need a learning goal) - you might want to pair only with people you do not know because it gives you more coverage.

That ends my notes. If you plan to go on tour yourself and have some questions I did not discuss, do not hesitate to contact me. And when you have been on tour, I would love to talk about how it went and compare our experiences. Please get in touch with me!

What I Learned on Tour

When you think about doing your own Software Journeyman Tour I guess the most interesting questions is what you will learn. After all such a tour is mainly about learning and seeing how other people work. The time (and money) put into such a tour should be worth it.

My Expectations
To be fair I need to discuss my expectations first. In retrospect my expectations were not clear. I did not follow Daniel's rule and had not defined an explicit learning goal. (See my previous discussion on how to go on tour for details.) I had expectations that I would pair with fantastic masters of our craft, who are much superior to me, and see astounding things. That was not measurable and definitely not clear enough. There was no goal and I did not align my plans accordingly. Obviously my expectations were too high, sigh.

When starting my tour I knew TDD well and had been developing professionally since more than a decade. In contrast to that many of my pairing sessions were basic. I helped developers to create their first unit test. Maybe I should have done the tour five years earlier. Daniel even proposed that the perfect time for a Journeyman Tour might be for young developers with two to three years of experience.

A friend called me a master and remarked that masters do not go rounds any more. They do not learn like that (Smi's rule). I am no master but there seem to be diminishing returns for a learning tour if you are already advanced in some areas. Some coder friends have also expressed this concern.

Concrete Learnings
To give you an impression here is a list of all concrete learnings of the first and second week. I spent ten days pair programming with four different people in this time. While it is hard to express the real learning, here are the things I found interesting enough to write down during the sessions:

• Learned about little HTML5 games and their way of publishing and making money.
• Brushed up my IntelliJ IDEA short-cut knowledge.
• Improved my Mechanics of pair programming, how to deal with exhaustion and zoning out.
• How to handle dependencies with local and shared lock files.
• Startup developers are "poor" creatures because they support their customers, do operating, fix bugs, help less technical co-founders and have very little time for actual development.
• I coded Python for the first time - or more accurate - paired on Python code.
• oh-my-zsh with plugins is an useful shell extension.
• I relearned Vi as it had been many years since I had last used it.
• I paired on existing C# code for the first time.
• The "Rename Overloads" is a nice function of Visual Studio (or Resharper) that I had not seen in Java yet.
• When the current Pomodoro finishes, run the tests.
• I learned more about dependencies of OSGi bundles and their problems.
• Deploying OSGi bundles in an OSGi aware server is a real pain.
• It is possible to create a cash flow calculation and business plan in a pair as well.

If I multiply these items with the total of 13 weeks, I get around 80 to 100 interesting things I saw. So yes, a Journeyman Tour is a great way to see many things. I worked on many things for the very first time in my life, e.g. I had never even seen Python, C#, VBA or Typescript code or developed for Google App Engine or opened Netbeans etc. I gained lot of experience on many different things in a short time. Maybe the experiences lacked depth. For example how much learning can you expect from two days Typescript? I spent a maximum of three days in a company working with one or sometimes with two different developers. Maybe I should have worked at least a full week on one topic to get deeper insights. Daniel spent a whole week at each host and considers it the perfect length for a Journeyman visit.

Practice
The tour gave me a lot of practice in different areas, maybe I had even more practice than learning new things. I had little pair programming experience before. On my tour I pair programmed all day, each day for almost three months. That improved my pair programming skills by far. In the end of the tour I was able to get in sync with a new pairing partner quickly. Since my tour I love pair programming. I feel stupid when working alone, so I rarely do it nowadays.

Next I practised getting productive in a new project. By running Hackergarten in Vienna for more than a year I was already comfortable with that. On my tour I figured out how to ask for the right amount of context without slowing down my pair with too many questions. Today I am confident to be productive in a new project or technology within a few hours - with the help of a pairing partner who knows the area of course. This conforms to Corey Haines' observation that he learned most how to start with an unfamiliar code base immediately. While this is very helpful for my current occupation as Code Cop and Freelance Code Mentor, I do not know how much this would help you during regular development, where you stay in the project for months of even years.

Value
I understand the value of practice and like working on code katas and other practice exercises. Still my improved IntelliJ IDEA short-cut-fu feels less valuable than working in Typescript because there was nothing new in the former and everything new in the later. I know that my feeling is wrong. The mastery of IntelliJ short-cuts is important and helps even when working in other languages (as long as I stay with JetBrains products) while the basics of another static, object orientated, main-stream language are forgotten soon (unless I get into a real project, which I did not).

Some of my learnings were not interesting, e.g. creating an Excel cash flow calculation was not what I expected to do nor had ever wanted to. Working with my pair on the tasks he or she had chosen forced me to a few boring things, that I hated and would have never done on my own. It was painful but definitely broadened my horizon. Maybe these are the most valuable experiences because I would never get them otherwise. Or maybe these experiences are useless because I will never do such things and I wasted a few days of my life. I am unable to decide.

Satisfaction
My expectations partly fulfilled by learnings and practice, which both have a vague value, result in a certain feeling of satisfaction. Still many questions remain. Am I satisfied with the outcome of my tour compared to the time and money involved? What is the value of the things I learned? Could I have learned more useful things in a shorter time? And even if, would I have learned it (or done something else instead)? Maybe more interesting to you is if you would be satisfied with such a tour?

So let us look at some hard facts again. Before my tour I got in touch with 32 companies. During the 60 days of my tour 16 companies hosted me and I paired with 26 people. I further attended two conferences and 15 user group meetings in the evenings. My overall statistics shows me 40% of great pairing sessions which were awesome and where I had insights into TDD or a lot of fun. Then there were 40% of tolerable pairing sessions which were sort of OK. The remaining 20% were bad sessions, where I did not learn much or even felt like crying. It is true that you learn from everybody, even from very beginners, but e.g. handling difficult people was not on my list of learning goals.

Conclusion
Even with some of my expectations not satisfied, my Code Cop Journeyman Tour was one of the most interesting and most intense times of my life. Its overall experience was awesome. Half of the time I did great work while pairing with amazing people. I learned around a hundred new things and had a lot of practice. In comparison, had I stayed with my previous employer I would have experienced a few great days and learned a few new things during regular work. The tour made a massive difference for me and I am glad I went for it. Until today I plan for single Journeyman visits from time to time. Last year I spent three days pair programming for food. While this is less than 2% of my total work time, I am still proud of myself that I kept the spirit of the tour.

Final Recommendation
If you came here to check if it is worth to go on tour then my answer is yes. A Pair Programming Tour is a great thing to do. Even if you go for a single month, visiting only four companies for a few days each, you will see a lot of new things and work with people you never worked with before. It is the right thing to do. Now go and do it!

How to Journeyman Tour

It has been two years since I did my own Journeyman Tour. It has been a blast but I never took the time to write about some topics besides the actual things that I did back then. Recently I was reminded of the topic by Lennart's tour and friends asking me about it as well. So I need to catch up and discuss some of my findings. This article is not about the tour itself, but about things to be considered if you plan your own Journeyman Tour.

What to Expect
Back in 2013 I first analysed Corey Haines's Pair Programming Tour in 2008 to get an idea what it means to do such a tour. Then I defined my personal, particular rules of my own Code Cop Tour. My rules were supposed to reduce uncertainty and help me achieve my objectives, but they were not specific enough. (I will write about that later.) During a Journeyman Tour one objective is about learning, so you need to define your learning goal (Daniel's Rule). Maybe I did not have that, or I had the wrong one, or my other tour preparations were not aligned with my objectives. More discussion would have helped me to get a better picture what might happen during a tour. So if you plan to go on tour yourself, I recommend you discuss your plans with people who have done it before.

Plan Ahead
First you need to select the area you want to visit. I stayed local in my city. Others toured their country or continent and a few visited the whole world, e.g. working at companies both in Europe and the United States. Adding conferences as speaker or attendee is a great thing as well. Based on the decided locations and dates I created a schedule. Be aware that a Journeyman Tour, while being a great thing to do, is also exhausting, and in fact hard work. You need to plan accordingly. I had planned too many sessions in too little time. You need to plan for some free time each month as well.

Host Companies
Finding hosts is the hard part. See my list how to find hosts and sell a Journeyman Tour to management. Some hosts have specific legal requirements. You need to be prepared for some legal hassle. In Austria and Germany the legal background for unpaid work is the Volontariat, which is primarily used for education. But I am not a lawyer, please do not ask me for details.

Sign Non-disclosure Agreement
All larger companies asked me to sign NDAs. I signed them because I was not interested in their customers, products or other details. I wanted to see the way they worked, how the used technologies and the engineers working there. I even brought a generic NDA with me if a small company or startup did not have any template. I respected the agreement and did not talk about any details we had worked on ever. That is the reason that my reports of the tour are generic and lacking details. I always asked for permission to mention the company in my blog and let them review and approve my posts before publishing it.

Respect the Host Company (Security) Policies
Having worked at large corporations I understood the need for security of most host company representatives. As they had no idea what a visit of a Journeyman meant, they had concerns. My rules were never to work alone. Beside security concerns it helped me keeping focused on pair programming. Obviously I did not need any access codes, passwords or other security related information. While I brought my private laptop to take notes, I even asked for permission to plug it into electricity. Some companies do now allow private IT equipment to be operated inside their premises. While most of these issues might sound silly to you, it is of utmost importance to make potential host company representatives feel secure if they are going to allow an outsider in. Further I wanted to respect any company policy of the host while I stayed there.

Finding a Future Job
Working for some time at a company is a great way to figure out if it is a place you would like to stay. Some host companies even implied that depending on the report of my pairing partner they would offer me a job. This could lead to problematic situations. If I would not apply for a job after my visit, it would be like saying "your company sucks". A company hosting a journeyman is always a great company. I recommend rejecting any discussions regarding future jobs by saying that your visit is not about a job but about learning and sharing (Thomas' rule).

Expect No Compensation
Some people asked me if it paid off to go on tour. While it is possible to have a paid tour, all the Journeymen I know did not get any money for their work. The classic Journeyman Tour is a self-funded journey of discovery and sharing. Even when provided with food and a room to sleep, a tour is not a cheap trip. You still need to cover additional costs, e.g. public transport. During my tour one company wanted to pay me because they were afraid to be accused of unreported employment. In another company the team lead had to pay for my lunch himself because it was impossible to get the money from the company. When I was away from home, I asked the host company to pay for my hotel at least.

Journeyman Work
Daniel told me this story: During his tour in 2013, a company showed interest in hosting him. When discussing terms of his visit, it turned out that the company wanted to get professional training for free during his visit. As working together and sharing knowledge is the base idea of a Journeyman Tour, it is difficult to draw the line between regular exchange and abuse. But extensive training of the host company's stuff for free is definitely out of scope. During my tour I pair-programmed (and pair-designed and pair-tested) with developers and occasionally gave a presentation about the background of my tour. In one case I prepared a presentation of the things I had learned during my visit. I did not engage in any other internal activities like facilitating internal Coding Dojos or giving presentations on other topics, and nobody asked for it. Wherever you draw the line, you should think about it before starting your tour.

That information together with my older articles should get you started in your own Journeyman Tour! Read more about the tours of other people, e.g. Daniel Temme, Andy Waite and recently Lennart Fridén.

The 13th and Final Week

The 13th week of my Pair Programming tour started a bit uncertain. I had not been able to finish the arrangement with the company I had planned to visit. I had got positive replies from my contact there that his team was interested and that he would ask the HR department for final approval. And then there was only silence ;-) Additionally winter came to Austria and the temperature fell by ten degrees just over night. I was exhausted and thought about quitting the tour prematurely.

But then, in the beginning of the week, the first FirefoxOS DevTreff meetup in Austria took place and I met some really enthusiastic hackers who immediately agreed to host me. So I went on with my tour for another week. First I visited a development team to run some in-house training. Besides the usual Coding Dojo we wanted to try something different this time. We started refactoring some nasty piece of production code Randori-style. It was really interesting to see the whole team communicating, e.g. the architect was surprised to see certain patterns in the class we worked on. Everybody was engaged and I wanted to encourage everybody to contribute so I abandoned the Randori-dojo protocol and the session turned into Mob Programming. It was fascinating. In the end the team agreed to use this style of working for our next session as well.

Déjà vu
Then I visited Jürgen Cito in his office at the University of Technology, Vienna. I had a strong sensation of Déjà vu because many years ago, I had roamed these very same rooms in the beginning of my own studies. Jürgen told me about his master thesis about Statistical Methods in Managing Web Performance. It looked great and I am looking forward to the finished work. He had finished his research and was just wrapping things up so there was little we could work on. Instead Jürgen told me about an idea he had for some time and so we created Sinatramania. Sinatramania compares (or rather will compare) the different frameworks based on the Ruby Framework Sinatra by implementing the same simple REST API in the different programming languages and frameworks. We created a Cucumber test suite and started with the Sinatra reference implementation. It was much fun and I will definitely send him some pull requests as soon as things settle down. If you use one framework inspired by Sinatra, e.g. Flask, Laravel, Ratpack or Scalatra, then I encourage you to add your implementation to Sinatramania.

Tying up loose ends
I started my tour visiting the Vienna Ruby Community, presenting them my idea of Journeyman Tour. Back then the leaders of the group had invited me to run a Coding Dojo but it had taken almost three months to find a suitable date while I was busy on tour. Finally I came back to deliver the promised Ruby Coding Dojo. We worked on the String Calculator Kata, a perfect exercise for a first time Dojo. We had excellent discussions and I particularly liked Ben's question if three powerful Ruby functions like split, map and reduce might be too much to squeeze into a single line of code. Yes, with great power comes great responsibility ;-)


Friday I visited an old friend. His line manager had agreed to my visit but he had not bothered to ask for full, official approval up the hierarchy. So I cannot name him nor his employer. Nevertheless it was a great day. In the morning we discussed TDD and integration tests. Then we created a new Maven plugin, test first of course. I proposed to create a guiding test, which we built using the Maven Invoker Plugin. It took us half of a day to get the guiding test ready, because asserting the proper behaviour of our plugin under test was tricky. I learned a lot and Maven Invoker looked like a good alternative for the Maven Plugin Testing Tools, especially when considering the problems I had with them. Using the guiding test, further development was smooth and we would have finished the plugin on the second day. I was really sad that we only had one day to work on it.

This is the end my only friend, the end
As the title of this blog post implied, this was the last week of my tour and it ends my diary. You ask me why? You say that my tour sounds like some serious fun and I should go on forever. Actually I cannot. First I need a break. Second I ran out of companies. I wrote earlier that it took me roughly a man-month (160 hours) to find the 16 companies that hosted me and during my tour I did not have time to look for new hosts. Further I had planned my tour to last for three months and it had been exactly three months. Finally I need to go back to work and earn some money again. Although lunch was free, I spent a lot of money on commuting. Although my tour has ended, I still have many things I want to share. I will discuss what I have learned in upcoming posts, so stay tuned.

A Dozen Weeks

Gilded Rose, again
In the 12th week of my Software Craftsmanship tour I ran an in-house Coding Dojo for a team that wanted to improve their unit testing skills. After an introduction what constitutes (and what does not) a good unit test I wanted them to practice. Understanding the concept of unit tests and using the corresponding testing framework was no big deal, but applying all the principles in practice was harder than it looked. I asked them to write the Test Cases for the Gilded Rose Kata, an exercise designed by Emily Bache. Since I participated in Emily's session during this year's XP conference in Vienna, I just love this kata. Although creating test cases for a small piece of logic might seem trivial, there is so much one can learn here. I had run the same kata during one of my Dojos at Agile Testing Days before and got a lot of positive feedback. If you got curious about the kata, it is described in full detail in Emily's excellent Coding Dojo Handbook.

Quality important is. Fight for it you must ;-)
Next I visited Gregor Riegler. I had not known Gregor before my tour, but his blog Be a Better Developer had attracted my attention. I really liked its subtitle "Quality important is". When I studied his blog I noticed that he was from Austria, even Vienna. I immediately sent him an email and Gregor was interested in my tour right away. Although it looked like we would not be able to pair, he managed to get approval from his management in the end. I spent three days in the office of EBCONT enterprise technologies, in the 34th floor of the Millennium City and enjoyed the view.

Gregor called himself a Restifarian and so we rightfully worked on a REST API for his current project. The Spring Web-MVC powered REST resources would just display data from the database, and first it looked that there would be no particular logic to put into the resource controllers. But we needed links to related resources, the so called hypertext. We had great discussions how to create and add these links to the response in a DRY way without messing up the domain model which we wanted to stay independent of any technology. I liked our session very much and learned a lot both about REST and learning in general. Thank you Gregor!

November is DemoCamp Time
Since the very first Eclipse DemoCamp in Vienna, November 30th 2009, we kept up the tradition of organizing an Eclipse DemoCamp twice a year. So Friday afternoon was demo time. For the ninth time the Vienna Eclipse enthusiasts met to see all the cool technology being built by the Eclipse community. There were great presentations by Tom Schindl, Gunnar Wagenknecht and Benjamin Cabé as well as some local people. The closing presentation was Flo's famous demo remote controlling Sharky. It was a pleasant event and socialising continued till late night. You should definitely attend our next DemoCamp in June. To keep updated about it, follow us on Twitter: @edcvienna. (Please note that the Twitter handle was changed recently.)

CodeCopTour Week 11

In the eleventh week of my Software Craftsmanship tour I visited the Austrian Lotteries gaming enterprise. I paired with Felix Kammerer and Stanka Gasic from the development team only one day each. In these days I learned that I am a keyboard hugger ;-) Usually I am dominating my pair. The situation is better if there is no second keyboard because it takes more energy to take it away actively from my pair than to just start typing on my own one. Maybe I will continue my tour without an extra keyboard from now on...

Devoxx 2013
The manager of the Lotteries' development department had invited me for a longer visit, and I had planned my tour accordingly, but I had to change my plans on short notice. In a last-minute lottery the Vienna Scala User Group gave away a ticket for this year's Devoxx conference in Antwerp, Belgium. I have been to Devoxx before and it really is a great conference. I had not planned for it because I knew that I would be busy with my tour, but obviously I was supposed to go there after all. Luckily my JUG voucher was still valid after the conference had been sold out, which usually happens quite early. On my return I gave a short presentation at the Scala Vienna meetup about my impressions of Devoxx 2013. The short summary is that Devoxx is a great conference and you need to go there, at least once. I probably should write a long summary as well, as I did three years ago, but I rather continue with the findings from my current CodeCopTour. So if you want to know more about Devoxx 2013, please refer to posts other attendees have written, e.g. Bartosz Majsak, Peter Pilgrim or Steve Schols.

Conferences as part of a Journeyman Tour
This brings me to the topic of conferences. Conferences and other community related activities like Coding Dojos or Code Retreats are the perfect addition to a teaching and learning tour. For example Daniel Temme, who did a similar tour earlier this year, actually started his tour during the German SoCraTes conference and visited ALE conference in the middle of his tour. When you plan for a Journeyman tour, adding space for conferences and other technology related meet-ups is easy. Additional to learning something new, conferences provide you with opportunities to discuss your findings with other craftsmen and maybe even find new hosts for your continued tour. As you have no income commercial conferences are out of the question, unless you present something, like I did during Agile Testing Days.

CodeCopTour Week 10

For the tenth week of my Software Craftsmanship tour RISE, the Research Industrial Systems Engineering, invited me to stay for three days and I pair-programmed with Kilian Matt. Kilian had prepared some special work items for my visit and we started refactoring some old piece of legacy code. Kilian was happy because nobody would touch that code and usually he would not have time to work on it himself, but for my visit he had "made some time". We worked together well and I was productive as soon as we sat down to code. Together we made smaller steps in the refactoring than both of us would have taken on their own and we moved forward steadily. Kilian focused on using keyboard short-cuts and I learned some of IDEA's key bindings. In the end of the day we had typed 15.000 keys and clicked 1800 times, a good ratio according to Kilian. (The recording was done with Workrave, a little tool for monitoring your work to avoid Repetitive Strain Injury.) Kilian is a true Software Craftsman and I enjoyed working with him a lot. Thank you very much and special thanks for the cheese ;-)

The third day of my visit I worked with Zeljko Brdaric, who specialized in test automation and BDD. We added a small feature to his code base, and adding the test first I worked for the first time with TestNG. It did not make any difference as the annotations and assertions looked the same as in plain old JUnit. We had an interesting discussion about using present or past tense in commit messages. I liked this attention to detail.

Then I moved on to Dimoco, a company offering mobile payments worldwide. There I pair-programmed with Helmut Jelinek for two days. Helmut had arranged a meeting room for us so we would not disturb other colleagues in the open plan office. It was a very small meeting room, more like an aquarium ;-) I called it the "pair-programming cell", see its picture on the right. Helmut was responsible for Dimoco's reporting backend which collected events throughout the application and aggregated them for monitoring purposes and we added a small feature to its reporting backend. Helmut had a strict attitude about introducing zero defects and was very serious about checking, reviewing and retesting our changes. I have never met a person checking his or her code so closely. Obviously I liked that and will incorporate some elements of his work flow.

Remote Book Club
Besides pair-programming I finished reading Domain-Driven Design by Eric Evans in that week. I participated in a remote reading group, started by a former colleague Jonny Andersson, back in the days when I worked for IBM. Since January we have been meeting online each week and worked through 15 pages of the book each time. It took us 33 meetings in total to go through the 500 pages of the book and a few meetings were delayed due to public holidays or holiday time in general. We had many interesting discussions during the year which made reading the book more fun and the learning experience much richer. Jonny is preparing for the next reading group right now. It will start January 2014 and we are currently discussing which book to read. If you want to join us, stay in touch.

CodeCopTour Weeks 8 and 9

Today ends the tenth week of my Software Craftsmanship tour. I visited several companies, paired with many developers and discussed with even more people about our craft. My memories are blurry, there is just too much to keep track of. Fortunately I use a large notebook to collect thoughts and findings during my tour and it helps me to continue my diary about the recent weeks of my tour. As I need to catch up with three weeks by now, this one is going to be brief.

Week 8
I started the eighth week of my tour visiting Codeship, a Vienna based startup offering hosted Continuous Integration and Continuous Deployment solutions for many technologies and hosting platforms. Together with Codeship's development lead Clemens Helm I worked on a feature deep inside the Codeship's Ruby on Rails core. Clemens, of "Testing Tuesday" fame, created a guiding test with Cucumber and then switched to RSpec unit tests for the details. It was a great pairing experience despite that my Ruby skills have degraded considerably causing me to slow down Clemens a bit. Between pairing I joined the Codeship team playing some rounds of tabletop football and improved my skills there as well ;-)

Then I spent three days at Irian, a Java Enterprise consultancy famous for co-founding the Apache MyFaces project. I worked with Jan Zarnikov on a new application in TypeScript. TypeScript, the new open source language from Microsoft, was designed for application-scale JavaScript development and compiles to plain JavaScript. I had never heard of it (it was just created last year) and Jan was concerned if I would be able to work with it. But I had no problems and we made good progress. Jan had prepared all the details in advance and we were just banging out the first version of a touch enabled learning game, driving the whole development by tests. It was awesome! Typescript looked cool and was easy to work with, just the development environment and infrastructure (outside of Visual Studio) needs to catch up.

Dojo Week 9
The following Monday I facilitated an in-house Code Retreat for two development teams. Although there were only ten participants, the final retrospective showed many learnings, which was proof for me that the Code Retreat was useful for them. I want to point out how great this Vienna based company is. Running Code Retreats as part of developer education is awesome and I only know a few companies that do things like that.

The rest of the week I attended the Agile Testing Days 2013, an annual European conference. I had been invited by the organizers to run the Coding Dojos each afternoon of the conference. I chose three different katas for the Dojos to keep things interesting. I started with Refactoring the Tennis Kata, a kata designed by Emily Bache. The provided source code of scoring a Tennis game was awful but had a comprehensive suite of automated tests which allowed the participants to focus entirely on refactoring. All seats were taken and we had a great Dojo with good discussions in the end. The following day I helped the participants to Design Test Cases for the Gilded Rose Kata, originally made up by Terry Hughes and modified by Emily Bache. The prepared code base contained some (spaghetti-) business logic but no tests. The participants were asked to add test cases. Again we had a great Dojo with good discussions in the end. For the third Dojo I had prepared the exercise of TDD as if you meant it, as proposed by Keith Braithwaite. I considered it a difficult exercise and the participants were struggling with the concept in the beginning. After some time they made progress and even skipped the break to enjoy pair programming for additional 25 minutes. Obviously they meant it ;-)

I did not pair program with anybody during this week, but learned many new things in the conference sessions and taught a few things to the participants of the Coding Dojos. I had great discussions in the evenings with like minded people and made some new friends as well. Food was provided at the conference venue and travel cost was refunded by the conference organizers. All these facts come pretty close to the requirements for my Journeyman Tour ;-)

How to sell a Journeyman Tour to Management

I have been asked by several fellow craftsmen how to sell my Journeyman Tour to management. When preparing my tour I had to help people willing to host me to convince their bosses that my visit would be a good idea. Here are some points you might use to justify a Journeyman visit.

Corey Haines did not write anything about convincing management in his Journeyman blog back in 2008. Earlier this year I sent him an email asking for an advice. Although I believe Corey is a busy man, he answered my question. Here is what he wrote:

I'm afraid that I don't have a lot of advice on pre-selling the idea to management. I stayed away from companies that had trouble figuring out the value of having me there. Especially at the beginning, a lot of companies were a bit worried about the idea of having someone in. I just started without them. One major advice I have that is based on my experience is to just start. I didn't really plan things out too far in advance, especially at the beginning. If you just start going to some of the places that you do know, then others might start to turn their attitudes around. Make sure that you blog, do videos, etc, to get the word out of what you are doing. That way, companies will have something to focus on when they are making the decision. (Corey Haines, private mail, 29th of July 2013)

Start with companies who understand the idea.
So the first plan is not to convince management but just start with companies who understand the idea. This surely works if you travel a large enough area, as Daniel Temme's tour around Germany shows. So try to travel an area as large as possible.

Ask startups and small companies to host you.
As far as I noticed, small companies are more likely to host you. I started my tour with two startups, Blossom and letsplay.io because their founders just agreed to my visit without any questions. Especially the lean startup movement is open to the ideas of learning and continuous improvement. People running one-man businesses who are not permanently working at the customer's site seem to be more open to visits as well, e.g. Lunifera or sdguide.org.

Show that you are valuable.
As I want to stay in Vienna and the Journeyman concept is hardly known here, I have to convince some companies. Obviously there are benefits in having an outsider in your team for a few days. I start the "convincing" with describing my skills and enclose a current version of my CV that shows my experience and my willingness to teach, for example I list my talks at local user groups.

An outsider has a fresh perspective.
Even an outsider can provide valuable input. This is the main argument used by German coach Ralf Westphal who did a Journeyman tour this spring. This input might be some piece of code or just a second opinion during pair programming. As an outsider I am not affected by organisational blindness and can reflect on structures, assumptions, conventions and behaviour without adhering to company policy or any personal interests. I can share my views on coding, design, architecture, development process and anything I see during my visit. My host will benefit from my visit.

Help with Agile practices.
Related to a fresh perspective, I offer to help my hosts with Agile practices like TDD or pair programming. I will not run workshops or give polished presentations, but obviously I will practice with my pairing partner. I also offer to give a short presentation about the Journeyman concept and Software Craftsmanship in general which I have given several times since the beginning of my tour.

My friend Thomas Sundberg pointed out that managers of development teams who want to introduce pair programming or TDD into their teams should be interested in hosting Journeymen. By working closely with someone who has experience in pair programming, the developers will get a first impression of how it is done. This is especially valuable if they have absolutely no prior experience.

Knowledge is spread effectively using Pair Programming.
All the things said about outside view are even more true in the small world of a (programming) pair. As much as you hope to learn by pairing from a stranger, as much the stranger will learn from you. As the Code Cop I love unit testing and clean code. I do not know the domain I will be working in, but I know testing. My pair will know his or her domain, but maybe not how to create a good unit test, so we will work together on the domain with good tests. The same is true for clean code. One of my hosts invited me for exactly these reasons. The managers of the development department had tried to grow an atmosphere of professionalism and supported pair programming and TDD but the development culture had not changed. Of course my visit did not change it either, but at least I told the developers the same things their managers had been telling them and a few developers experienced these things while pair programming with me.

Spread the word about your tour.
As Corey said in his email, it is crucial to show what you are doing. It probably helps if you are well known like Corey or Ralf, but it is not necessary. I did not write any technical books nor do I speak regularly at conferences. I just started my tour with writing about my idea and added smaller posts on the way. People who wanted to pair with me showed my blog to their boss to explain the concept. I got invited to Germany based on the fuzz I created on Twitter. You should tell everyone about your tour in advance, present it at local user groups. You need to do some marketing. For example Ralf Westphal had his tour published in a high-circulation developer magazine and got much more offers than he had planned for.

You need a champion vouching for you.
In my experience the most important fact is the "mole" inside the company. Someone who understands the idea and wants to work with you. In the end he or she has to convince management and possibly vouch for you to be admitted. This person is a like-minded individual, someone whom you know from user groups or conferences. Especially Craftsmanship related activities like Coding Dojos, Code Retreats or Software Craftsmanship conferences are the right place to meet these people. As Daniel Temme wrote, his tour was based on people he had met during the SoCraTes 2013 conferences a week before. Saying that it is high time to say a big thank you to all the people that believed in me and convinced their managers that I would bring value to their organisations. Thank you all, you rock!

CodeCopTour Week 7

I think it would speed things up if I cover two weeks of my Pair Programming Tour in one swoop, as I did two weeks ago. I want to share some insights besides the usual diary, so I need to increase my writing throughput. On the other hand I do not like going faster because writing a blog post takes as long as it takes. Although I know people who do speed blogging, the OCD part of my personality does not like short-cuts, obviously.

Last week I was hosted by Thomas Baldauf of the Austrian Environment Agency. I did not know Thomas but had got his name from a friend. After a short email he immediately agreed to host me without any questions which surprised me a lot. Unfortunately Thomas, the lead of the development team, did not have time to work with me in person but had prepared some developers from his team for my visit. I worked with Nexhat Gashi on a small feature of their newest web application which is based on JSF technology. I did not know JSF before I started my tour, but saw it all the time when pairing with people. Probably I will be fluent with JSF until end of November ;-)

I also worked with Martin Lackner whom I knew as long time attendee of our Eclipse DemoCamps in Vienna. Martin, an Eclipse platform veteran, worked on an MDA prototype using Xtext. I had worked with the older versions 0.7 and 1.0 before and he had prepared all the nitty-gritty details in the previous week. I reviewed his DSL and probably spoilt all his fun by proposing a different, shorter syntax. We moved forward very fast. In only one day we created a technical language to define entities and aggregates, together with full editor support, code completion, validation and proper formatting. Such is the power of Xtext - I love it. If you do not know Xtext, I really encourage you to check it out. The Eclipse Xtext project has excellent documentation and many examples which provide a starting point to get your DSL up and running in no time.

Free Lunch
The only compensation I asked for pairing was food and beverages throughout the day. It worked out well - till now I have been provided with free lunch every day. All my hosts were very polite and offered me coffee or drinks and asked me for my preferences when choosing places to eat. I never asked for anything special but went for lunch where my partners went. I visited take-away noodle stores, staff canteens and fancy restaurants. Having lunch with many people, together with the various places in Vienna I have been to, was a culinary trip of its own.

The two weeks I spent away from home, I stayed in a hotel. The host company refunded me 600 Euro for my expenses per week. It was a nice hotel, expensive but comfortable. The money was sufficient because I saved on food, eating in the company canteen now and then. Staying in a hotel and working all day was acceptable for the two weeks, and I enjoyed the rich breakfast buffet including bacon and scrambled eggs. But I would not like to stay in a hotel for extended periods of time. I am not a travelling person and I never worked like that. I enjoy going home after work, where connectivity is good and wireless network is free ;-)

Can PL/SQL be Clean?
At the end of the week I spoke at the Austrian Oracle User Group. The organizer had planned an event focusing on clean development and three friends had recommended me to him independently. I agreed to give a presentation but was not sure about the topic I should talk about. For talking to an Oracle user group, the first thing that came to my mind was PL/SQL, Oracle's database language. I have seen horrible pieces of PL/SQL and the question was if it can be written in a clean way? According to Michael Feathers, the author of Working Effectively with Legacy Code, "clean code looks like it was written by someone who cares." I presented his quote as first rule of clean code. Continuing the discussion I listed several books about clean code, including Code Complete by Steve McConnell. Steve said to "write programs for people first, computers second", which I defined as second rule of clean code. Following both rules it was obvious that even PL/SQL can be written in a clean way. I got good feedback on my presentation, especially that it was very entertaining, so I encourage you to check out the slides on Slideshare.

Awesome Week 6

Journeyman Tip: Plan for some space each month
I try to keep the pairing sessions of my Journeyman tour free of any appointments. If we spend only two or three days I do not feel comfortable in coming late or leaving early, there is just not enough time. My calendar was blocked by pairing sessions entirely until my first "free" day last week. It was a busy day, and I used it to prepare a few things for our upcoming Eclipse DemoCamp in Vienna. And I had a job interview. (The position looked cool but in the end it turned out the vacancy was not for a developer but for a Unix sys-admin guru, someone who compiles his own kernel for fun now and then.) They day was too full, I had packed too much into it. So I recommend leaving one or two days without any pairing session each month, to catch up with all the things that need to be done. Corey did the same thing, splitting his journey into tours of up to four weeks, and also Daniel Temme ended his Journeyman weeks after four weeks.

Week Number Six
The remaining days of the last week I visited SIB Visions, a company focusing on the simplification of the software landscape used to support business processes. The backbone of their application stack is the JVx Enterprise Application Framework which was open source right from the start. If you need to build a typical business application to edit data in table- or master-detail-style, this is the framework you want to use. Check it out!

First I paired with René Jahn, SIB Visions' Head of R&D. He had a list of things he wanted to discuss with me. We started with the build. I complained that it was too slow, running longer than a hour, and that there were failing tests. We immediately started fixing them. Then René showed me the framework and I was impressed. The JVx code-base is following a strict standard defined by René, covering documentation, naming and much more. While I did not agree to some of his conventions I did admire the consistency in the code base. I believe that consistency is crucial for quality of a code base, some time ago I even declared it the First Law of Code Quality. Well done JVx team, I like that ;-)

Then I worked with Martin Handsteiner, CTO of SIB Visions, on a particular tricky problem. A main class of JVx' data model had grown larger than 5000 lines and needed to be split. Due to performance optimizations it worked with plain object arrays internally, following the Flyweight Design Pattern, which did not make it easier to understand. We fought the beast for two days and were able to split away a few hundred lines of code. It was hard work, but just the beginning of a longer rework Martin had estimated to take two weeks. It should never have become that large and entangled in the first place. Martin had always wished for a keyboarder/keyboardist and a "mouser" and thus stayed in the navigator role for most of the time. While it was unusual for me to be the driver for extended periods of time, it worked out well because Martin knew the concept of his model and I was moving forward relentlessly.

Just yesterday I received mail from René telling me that his build now takes nine minutes, 900% faster than last week and that all tests are green. I was delighted. For the first time one of my hosts had taken my ramblings serious and immediately fixed the issues. Awesome, that is the right spirit. Keep up the good work!

Remote Pair Programming
Even more awesomeness happened at the weekend. My friend Thomas Sundberg asked me for help with his presentation on (Remote) Pair Programming at 33rd Degree for charity in Kraków, Poland. He needed a remote pairing partner for a small demo. We frequently do remote pair programming katas since more than a year and were sure we could pull it off. During lunch break we tested connectivity and the audio equipment of the conference venue, to make sure that everybody would hear me. During the demo we did a few cycles of TDD, discussing names and refactoring the code in ping-pong style as usual. I was sitting at home, still contributing to a conference talk - it was awesome!

CodeCopTour Weeks 4 and 5

Today The day I started writing this post was the first day since more than five weeks that I did not schedule any pairing session. Somehow the day stayed blank in my calendar. Still it was a busy day. I spent more than four hours on emails, preparing stuff for our upcoming Eclipse DemoCamp and in the evening I attended an user group meeting. There was just enough time to squeeze in a blog post about the last two weeks, the fourth and fifth week of my CodeCopTour. Both weeks I visited a larger IT service provider. As I tweeted earlier this company wanted to stay anonymous for reasons I will explain later, so lets just name it Reynholm Industries. When planning my tour I had aimed for sessions of two or three days with each host but the management of Reynholm had invited me for two full weeks to visit several teams and pair with different people. I agreed and they had prepared for my visit three months in advance, at least that was what I thought.

Legal Issues
Obviously Reynholm was large enough to employ one or more legal advisers and they were afraid. I would work for Reynholm for two weeks and would not get any money. Nobody would believe that, so Reynholm might be accused of employing me without paying taxes. Austria has mandatory social insurance and its institution is lacking money and tracking down all possible cases of black market work to collect their share of the salary. In the morning after I arrived I was brought to the legal adviser and he told me that we had to cancel my visit. After preparing my visit for three months he had started his work one day before the deadline, my arrival. I was not amused and in no mood to drive back two hours with my business here unfinished. It took us half a day to work something out. In the end I signed a contract, accepting the responsibility to pay taxes for my income as necessary and I paid for the hotel and food myself. The fee of the contract was exactly the amount of money Reynholm had planned for my expenses, which was pretty accurate. I hope that in the end I will get back all the money I spent. Working on a contract and spending all income on expenses also does not sound reasonable, and I hope I will not get in trouble with the tax office.

First Code Retreat in Graz
Being in the area of Graz I used the opportunity to meet with my friend Wolfgang Kaufmann. Before I arrived I had talked to him about running a Code Retreat in Graz and he immediately agreed. He brought in some of his colleagues to help us organize and even talked his employer INFONOVA into sponsoring the coffee and lunch during the event. The local university FH Campus02 let us use one of its lecture rooms and we were ready to get started.

After morning coffee I introduced the participants to the idea of Code Retreat and we started practising TDD, pair programming and object orientation.

During the first session almost all teams used arrays of integers or boolean flags so I chose No Naked Primitives as constraint for the second session. During that session only one pair worked on the business rules and all others created only infrastructure, so I proposed to focus on the domain in the next session. Lunch was great, we had wine and beer, several main dishes, even cheese and sweets. It was luxuriant - thank you INFONOVA. (I know I already mentioned them, but the lunch was really awesome, so one extra link will not hurt. Did I mention that they are looking for all kind of developers, just check out their web site ;-)

After lunch we had a session of Ping Pong Mute, which was really fun. One participant complained that he could not go for a design he wanted to try because his pair would not understand it without long explanations. I liked the idea of measuring a design by its simplicity - by its ability to be understood without much discussion. Probably his idea did not follow the KISS principle. After another round I asked the audience what they would like to work on in their last session and Wolfgang proposed No Conditionals. Although this is one of the more difficult exercises they came up with great solutions using nested maps or state machines.

It was a very nice Code Retreat. The 15 participants were a good mixture of junior and senior developers, Scrum Masters and even one Product Owner who wanted to know what "his" developers do in their personal time ;-) People learned a lot, many of them had their first contact with TDD and pair programming in practice. Several decided to give TDD a try in their daily work. Thanks to our awesome sponsors INFONOVA and Campus02 we had everything we needed and the attending developers used the opportunity and made it a great event. Thank you all!

Second Week
In the second week I continued my journey through different teams at Reynholm and paired with different people for a day. All developers I met were friendly and open and I had a lot of interesting discussions. I already knew many people from the previous week and kept meeting known faces in the hallways and during lunch. At the end of the second week I felt like I had been with Reynholm for a long time and I even felt a bit sad I had to go away now because the people were so awesome. Thank you Alexander, Andreas, Andreas, Bernhard, Harald, Karl, Martin, Peter, Robert, Sabine, Stefan, Tom and Wolfgang. I will miss you.

CodeCopTour Week 3

I was waiting for the legal advisor of TechTalk to review the five lines I wrote about my visit at their office the week before, which caused some delay in my blogging queue, but now I am back on track and will continue with week number three of my tour. I started the week with going to the country-side of Lower Austria. While driving I reflected about my tour (and I already published my thoughts here). Markus Schinerl had invited me to stay at his house for three days. Markus runs a small company called sdguide.org which is specialized in calculating metrics like the carbon footprint for factories in the pulp and paper industry. Pulp and paper is a very competitive industry and customers like governments demand the highest environment-conserving certificates from their paper providers. Sdguide's office was located in an old house and due to old age and structural damage it was under construction and looked terrible, see the image on the right side. Some windows were broken and we worked on a raw, wooden construction resembling a table. However we had a powerful computer, two keyboards and two huge screens - no problem there ;-)

Spreadsheet Monstrosities
Markus used a gigantic spreadsheet to enter all parameters needed for such a calculation. It contained roughly 200 input parameters and 500 metrics for up to 50 product parts resulting in huge files with thousand of lines. Obviously Excel was reaching its limits and he needed something more powerful. We spent the first day discussing the domain of carbon footprint and created a small diagram defining the core elements of his calculations. Although we did not write any code it was a productive day because I helped Markus to reflect on his needs and he explained the requirement to me at the same time. We came to the shared conclusion that he needed a real database, but one that he might be able to develop himself, so we ended with Visual Basic (for Applications aka VBA) and MS Access. Although I did not fancy VBA it was the best choice for his needs and he liked the idea that he would be able to use parts of our VBA code in his spreadsheets as well.

Markus had used VBA some years ago and I had never worked with it before. It took us half of a day googling and reading StackOverflow until we got fluent and then we flew. VBA does not offer much and I missed a lot like unit testing, collection classes, closures and much more, still we made good progress. At the end of the second day, actually the very end of the day - it was 10pm, we had built full end-to-end functionality. Of course it was not finished and only calculated one simple formula of one metric for one product part without considering scenarios, different years or different customers. Still it showed the way. I had aimed for that because we needed to know if the chosen design would work. It looked good. During the third day we added more features Markus wanted to investigate, we even created an infix math parser to evaluate arbitrary formulas. It was great and I learned a lot.

Being Brutal
Back in Vienna I helped a small team of developers to improve their refactoring skills. The developers liked practice and I chose Adrian Bolboaca's Brutal Refactoring Game. I had participated in Adrian's session during XP2013 earlier this year and had liked it a lot. It is a programming challenge focusing on refactoring. The brutal part is that each code smell needs to be refactored right now, regardless how small it is. This makes an excellent exercise to train developers in spotting code smells and refactoring them. Adrian lists 17 code smells as the base of the game and I asked the team to prepare short presentations about each of them. At the beginning of the session the developers presented the material to the audience. I just love when trainees teach themselves ;-) During the sessions I collected all the smells I had flagged. Half of them was about naming, i.e. "name not from domain" and "name not revealing intent" which did not surprise me because naming is a difficult problem. Further 30% were "Primitive Obsession" and "lack of tests", common problems in most code bases. One participant was disappointed that he did not hit each of the 17 smells at some point during the game - maybe I will add some game like achievements for completionists like him.

Even for a small group it was demanding to watch out for the smallest code smell in several evolving code bases at the same time. I noticed that pairs kept hitting the same smells again and again. Besides naming, which all participants had to deal with, one pair was "obsessed with primitives" several times, whereas another team had trouble writing tests to cover their design ideas. A fast typing pair, two developers who knew their IDEs well, created a lot of code, but as soon as I found a smell they were unable to remove it by refactoring and had to delete the new code and start over. Although I was as brutal as possible and challenged the participants a lot, I got positive feedback after the exercise and all participants learned something.

The Java User Groups of Austria
For the rest of the week I went "on tour" with the Java Klassentreffen 2013. The Klassentreffen is a series of events organized by the Austrian Java training company Ciit and sponsored by Oracle. It is a mixture of sales pitches and technical presentations, covering various aspects of Java. Technically the Klassentreffen did not meet my requirements for the pair programming tour, but the organizers had invited me to speak and food was provided. Together with Martin Ahrer, the founder of the eJUG Austria, I introduced the audience to Java and Java related user groups in Austria. I started my talk with the reasons to attend user groups, then covered the core groups of Java, Eclipse, Android and Scala and finished the presentation with Open Source, Software Craftsmanship and upcoming Code Retreats. (For details and links please open the slides.) Later the leaders of several groups told me about new registrations, so I guess my presentation was a full success.

CodeCopTour Week 2

Culture Shock
My second week's journey brought me to the highest towers of Vienna (see picture on the right). After previous week's startups this felt different. Paul Rohorzka had invited me to join him for two days. I had not known Paul before but had seen his name on the manifesto. Later when I met him in person during a Code Retreat I told him about my tour and he immediately agreed to pair with me. Working for a regular company TechTalk he had to get permission for my visit which took some time to figure out but finally he managed.

In the morning Paul surprised me with a list of several things he wanted to work on. On his current assignment he worked alone and lacked potential reviewers and therefore wanted several pieces of his code discussed. He had prepared his expectations, work packages and a list of verification "milestones" for these two days. After previous' week marathon coding sessions I felt like using Pomodoros and his work packages were sized small enough to fit into Pomodoros which we kept doing both days.

On the first day we worked on improving the readability of his specs. He used SpecFlow, a BDD testing tool for .NET, which worked just fine. I am generally disappointed by .NET tooling, but I was positively surprised how nice SpecFlow worked, just like you would expect it to work. Although we did not finish the work on the specs, Paul wanted to work on something else the second day, to get as much coverage of his work as possible. We dived into test infrastructure and reworked the part for creating test data. Its core class really needed some refactoring and we spent the entire day cleaning it up and making it ready for new features Paul knew he would have to add soon.

Paul is a true craftsman. I thought that I was a structured worker, but he was much more structured than I, which was nice to witness - there is always room for improvement ;-). Although I had never worked with C# before we had a shared understanding and were productive after the first hour. I enjoyed working with him and had a great time. Thank you Paul.

In the middle of the week I moderated the September Coding Dojo of the Scala User Group Vienna. (A Coding Dojo is a meeting where a bunch of coders get together and work on a small programming challenge to improve their skills. You can find more information about Coding Dojo in Emily's excellent Coding Dojo Handbook.) It was their eight dojo and I wanted to try something more advanced than basic code katas. I chose the TDD as if you meant it exercise by Keith Braithwaite. This was a difficult exercise and it was difficult on purpose, but the participants did well, much better than I did my first time during GeeCON 2012. It was my first time facilitating and their first time working through this exercise, and all of us learned a lot.

Yak Shaving
The remainder of the week Florian Pirchner hosted me in the office of his company Lunifera. I knew Florian since several years as organized the Eclipse DemoCamp in Vienna together. Lunifera was a development shop specialized in OSGi technologies and its "office" was still located in the living room of his flat which made a comfortable place to work and we had a lot of fun. But the work - the work was terrible and we spent almost three days Yak Shaving.

When I arrived at Lunifera, Florian showed me his current pet project, a radio controlled air swimmer, a flying shark, using BeagleBone, Arduino, many cables and - of course - OSGi technology. He prepared the project for his upcoming talk at EclipseCon Europe and needed some third-party code deployed to Eclipse Virgo, an OSGi compliant server. And it just did not work. After reading the documentation several times, we started from scratch, took baby steps and reproduced the smallest examples from the documentation. Based on these working Virgo examples, we moved forward to implement the code he needed, a m2m server based on Apache ActiveMQ. Besides some integration tests, we did not write a single line of Java, but many lines of poms, manifests, Spring and other XML configurations. I hate infrastructure work. Finally we got it to work and Florian was thankful for my help on this task, I even got a new nick-name "Config-Cop" ;-)

Journeyman Tour is hard work

The post about my second week is ready since some days but I am waiting for it to be reviewed by the company I visited. In the meantime let me tell you about some other aspect of my Journeyman tour.

At the beginning of the third week I drove to the country-side to pair with an old friend. While driving, I used the time to reflect about my tour. The quiet activity of driving seemed to support reflection. At some point I stopped to take notes so I would not forget, something that Corey called Road Thoughts. Corey recorded several of them during his tour as he drove around all the time.

Preparation takes time
A Journeyman tour might be seen as a funny or exciting undertaking, which it certainly is, but most of all, it is hard work. It started with the preparations, which were time consuming. Over three months I spent considerable effort in contacting people, promoting my tour, and finally finding individuals who would host me. I regularly spent two hours on emails, usually after regular work in the evening. Because I wanted to do my tour in Vienna, and because Software Craftsmanship is not widely known there, I needed to explain the tour, my motivation and potential benefits to future hosts and their managers again and again. (I will discuss how to sell such a Pair Programming Tour to management in a later post.) I roughly spent a man-month (160 hours) on preparations and discussions to find 20 to 25 hosts who would host me for a total of three months.

I never worked that hard
Facing a new project every three days is exhausting. There is no time to get used to it and obviously I want to be productive as soon as possible. New projects with new technologies in new domains are not a problem by themselves, but the cognitive load is extreme. There are many things I learn every hour and I constantly need to do things I never did before. I assume digesting this new knowledge comes "with a cost" - I am very tired in the evenings. I work with my hosts from morning to evening, usually seven to eight hours and after work we might add a retrospective or discuss some geek issues while drinking beer. Surely I overdid my tour by attending as many user group meetings as possible to promote the idea of Pair Programming Tour.

Pairing is intense
I try to pair 100% with my host. Even when Nik had to write a technical mail regarding Dart build issues, or when Florian had to create a cash flow spreadsheet for an upcoming project, we worked together. Pair programming is more demanding than regular work. There are no distractions, no mails or Twitter, because we are working on something. We keep each other focused all the time (and sometimes skip breaks or forget to drink which is a bad thing). This work is intense all day, five days a week.

Personal Pressure
The uncertainty of a new host, paired with possible expectations they might have, make me uneasy. What is my host really expecting? Will I fail? Will I look stupid? I know that there is no failing, still the thoughts of doubt are here. I feel the need to get something done, to deliver some value. This is my personal commitment for my host. On some occasions it caused me to take short-cuts during pair development, which I had never taken before and should not have taken at all.

Sharing needs time as well
Finally I want to blog about my tour. Summarizing what happened during the week is important to reflect on the things I learned. I found many things I need to share with future Journeyman, observations about our craft and other fascinating topics. Also people keep asking me about my tour. I initially planned to write blog posts twice a week, one diary and one about some discovery I made. I am a slow writer and I am two posts behind schedule already. But I promised Corey Haines himself that I would write about my tour. He is watching me, and these posts will be written ;-)