Work with Meaning

Years ago I worked for the IT department of an Austrian bank. I contributed to an application built to approve loans automatically, including some fraud detection. Surely the application made perfect sense for the bank, as it had already taken 50 person years to develop it. But my work did not feel meaningful. I believed it was due to the virtual nature of the product. (Most banking products are virtual, nothing real is produced. Further virtual products allow for the most contrived processes which is why I believe finance to be a horrible industry to work for. But that is not the point here.)

So my work had no meaning, it did make sense. It was neither important nor did it matter. It did not feel real. Of course it did make sense, but not to me. It was just a feeling, soon forgotten over the excitement of a new project. What does it mean to be meaningful, to be important, to matter? Using the definitions from dictionaries the meaning is the end, purpose, or significance of something. Being important says it is of consequence or significance. Consequence again is defined as importance or significance - I am going in circles here. I use the words meaning, importance and it matters in the same way. I am still looking for the right words to use as English is not my native language.

We can argue for hours and still not agree on a definition of meaningful work. You are paid for your work, so it matters. People spend money on the product or service you provide, so it must be important to them. Maybe you tackle real problems and create new and innovative solutions, which surely have meaning. To describe what I mean, I refer to Alf Rehn's presentation about How To Save Innovation From Itself, given during Craft Conference this year. It is the most important presentation I have seen in 2015. I will not summarise it, just watch it now. (I definitely recommend watching it. Besides talking about important topics, Alf's sarcasm is hilarious. I laughed and cried at the same time.) Kasia Mrowca shared her summary of his presentation and Linda Saukko-Rauta published her sketch notes from the same talk given in 2013.

I am still not sure of my definition of "meaning / importance / it matters", but it includes social factors and much responsibility, maybe a personal social responsibility similar to Corporate social responsibility. I will not talk about your personal responsibilities, which are your own decision, but I believe that we as software delivery professionals have a professional responsibility because our software is everywhere and heavily impacts society.

A similar opinion was expressed by Martin Fowler during his lightning talk Not Just Code Monkeys at Agile 2014 and OOP. Martin emphasised three points for us developers: Sustainable Business, Professional Software Excellence and Social Justice. While we (developers) are concerned with software excellence a lot, I have hardly seen people touching the other two areas. Even articles discussing ethics, e.g. Mike Cavaliere's Ethics for Freelance Programmers mainly talk about customer relationship and avoid the real issue of social responsibility.

Martin finished his talk with the concrete call to care actively for diversity and privacy. The recent story about VW showed another aspect: fraud. Robert Martin said that the engineers that implemented the cheating code failed in their professional duty. Even if the engineers did not know, which is unlikely, they need to take some responsibility for their actions.

So why did they do it? Maybe they were afraid to lose their job. While getting fired is not appealing, I believe it is not a real problem. The demand for our skills is huge and there are always more offers than we can take. But I agree that changing jobs may be inconvenient. Then there is thought of replaceability which might be not as important as we think. I guess that they did not care. There was a problem and the engineers found a solution. The technical challenge of cheating the test was interesting and possible. So it was done. I know developers who are more interested in the solving of problems, the technical challenge and the tools than in the implications of their work. I do not blame them. I do not know if I had acted differently.

I find the whole topic difficult. Structuring my thoughts (by writing this post) helped but I still have many questions. Obviously there are many things we need to care for, e.g. the environment, extreme poverty, waste of resources, Human Rights, cruelty to animals and much more. What should we actually care for? What can we do about it and which impact could we have as software professionals? I plan to explore these questions in a series of future articles. Let's see what comes up during these discussions.

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!