Shut up and write a test!

Due to the hype around ChatGPT I wanted to create this text with it. I failed. I tried several versions of different prompts, and also asked the Bing variant, but it failed to create any text I liked. It could not simulate my personal style. I should have to train a model with all my blog posts ... It seemed easier to use with the good old method of writing my texts myself.

Should I Write a Test?
Around ten years ago I stumbled upon a diagram if and when to write a test. This was a repeating question in trainings, when should you write tests? Before or after writing the code? Only when you have time? Only when you feel like it? I loved the diagram because there was only one end state. Whatever the reason or excuse would be, just shut up and write a test! It does not matter if you are tired, or if it is a little change, it should be tested. Such a rule is helpful when you want to adopt Test Driven Development, as there are plenty of excuses why to skip it.


The original diagram was created by Gemma R Cameron, a software engineer and event organiser from Manchester. She was inspired by a similar diagram about skating. Recently, when I was asked again when to test, I wanted to share the diagram and could not find its page. I thought it lost and planned to repost the diagram here. Eventually I discovered Gemma's page again, it had moved from a .me to a WordPress domain. I am glad that the original source is still available. You can find it here.

Java Version
The original version of the diagram was for Ruby, indicated by the use of Automock. What was bad with Automock? It provided some support for automated mocking of Rails application and is dead since 2016. Here I present a slightly modified version for Java, replacing Automock with PowerMock. And I do know what is wrong with PowerMock. It is a powerful mocking tool which uses a custom class loader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods and more. It is useful to bring legacy code under test, before seams can be introduced. The bytecode manipulation makes it slow compared to regular mocking. If used often, the whole test suite will run much longer than needed. Further, if code is hard to test, I change its design to make it testable by applying SOLID principles or by creating seams as outlined by Michael Feathers in his WELC book. Using PowerMock for tests does not improve the design. (I am not inherently against PowerMock, it is extremely powerful and as such dangerous. I needed something to replace Automock.)

Download and print the Java version of the Shut up and Write a Test Diagram. The fact that there are versions of this diagram for both Ruby and Java is a testament to the universality of its principle: Shut up and Write a Test! The Code Cop approves, and I am sure your future self will too.

I want you to exceed me

During my time at IBM I started coaching other teams. It was fun and I liked it. Later I went into full time training and coaching, and my motto was "Developing Quality Software Developers". I knew it was the thing I wanted to do, but I did not know why.

Gamification
I use Gamification as a strategy to improve user engagement. To increase participation in my workshops and to express my feelings about that, I created achievement cards, the Code Cop Achievement Cards. Achievements or trophies are concepts from video games, and describe meta-goals defined outside the game's parameters. Meeting the fulfilment conditions, and receiving recognition of fulfilment by the game, is referred to as unlocking the achievement. There are several cards for first time participants in my deck, for example Shortcut Fu when someone uses a rare keyboard short-cut, Regexer for comprehending a crazy regular expression or Finisher for finishing the coding exercise started during the workshop at home - which I always offer but rarely happens. I award these cards to a participant, if I feel that the person has worked hard or struggled to make it.

Appreciation
I wanted my cards to convey my honest appreciation and used NVC (Non-violent Communication) appreciation statements. For a NVC-style appreciation we share the specific actions that contributed to our well-being, the needs that have been fulfilled, and the feelings engendered by the fulfilment of those needs. The focus is to create a clear understanding of how our life was enriched.. This made me think more about my feelings and which of my needs had been satisfied at the moments when I wanted to appreciate some action. I had thought about needs before in more general, less personal way. My friend and NVC coach Aki Salmi helped me to formulate these statements using different phrases to avoid having the same text on each card again and again: For example: "I value the usage of short-cuts as effective and as sign of ongoing mastery in our craft." "I am touched to see courage in situations of uncertainty, risk and emotional exposure." "I am amazed by critical questions based on creativity and independent thought." "I am inspired by the integrity and consistency of sticking to principles in difficult situations." The process of finding the right words alone strengthened my ability to express my feelings dramatically.

Scrutiny
Some of my appreciation cards celebrate learning, including stepping out of one's comfort zone, which is required for learning. One card I of these is titled "Scrutiny", subtitled Correct me when I am wrong. It shows a Whistle icon (by Delapouite CC BY 3.0) and the appreciation is "I am proud when you correct me, showing independence and competence." It does not happen often - still sometimes in a pairing or ensemble session, my focus may slip and I make a mistake or do not call out a mistake on time. And then, sometimes, someone else does.

Growth
There is a common theme in most of my cards: growth. Now that I have seen it, it is obvious to me. Growth is one of my major needs. I want to grow - e.g. learning new languages and other stuff regularly. And I want the people I coach and work with to grow, too. My second motto - surfacing around 2013 - "Developing Quality Software Developers" expresses that clearly. I want them to grow, to learn, to improve - and I am inspired and amazed the most, when they exceed me.

Snatch the Pebble From My Hand
There is nothing more satisfying than when a pupil exceeds his or her master. This is often depicted in movies, where a student must learn a lot, for example in Kung Fu movies: In the television series Kung Fu, Caine is an orphan and is accepted into a Shaolin Monastery. Part of the Shaolin way of life is strengthening the body and the mind. For example, one of Caine's teachers asks him to "snatch the pebble from my hand":


Then, after many years of training, Caine is finally able to beat his master:


What a satisfying moment, and Caine's master smiles. This is one of my favourite TV moments ;-) Like being corrected (see Scrutiny card above), "snatch the pebble from my hand" situations make me proud of my students.

Make Me Look Like a Baby
I want to leave you with a quote from a different and maybe more controversial source of motivation than Caine, ex Navy SEAL member Jocko Willink: Don't try and be like me. Be better than me. Crush me. Make me look like a baby. That's what you do. (Even better when he says it himself.) - OK, maybe there is too much testosterone here ;-)

Tips for Remote Work

During COVID lockdown, I worked remotely. I did all my Code Cop things, e.g. pair programming, code reviews, coding workshops, just in a remote way. All these tasks involved other people and I was severely affected by my "remoteness". After one year of remote work, one of my clients ran an in-house knowledge sharing on how to do that successfully. They invited me and I thought about the advice I would give. What would be my top three tips for remote work?

1. Check-in
When working remotely, the first and foremost thing I use are check-ins. During a check-in everybody says a few words how he or she is here - as a human being. The check-in is not about your role, your expectations or current work. It is about how you feel. When we work separately, I miss your face and body language and we need to be explicit how we are. In a face to face situation I might be able to recognise if you are tired or distracted or upset. I am unable to identify the little hints when you are just a small image on my screen. Now I place more emphasis on the human and emotional side of my peers because it is missing in a remote setting. Some people always reply with "I am OK" and I am fine with that. Nobody has to share. Some people keep talking and I have to remind them what the check-in is about and stop them from taking all the space. Conversation, arguing or discussion break the check-in. And at the end of the meeting I ask everybody to check-out, which is the opposite, asking how they are leaving as human beings.

2. Be Professional
I preach being professional. After all "I help development teams with Professionalism" (as written on the second introduction slide of all of my decks). Professionalism is an attitude, it is how you do your job. This includes also your appearance. In a remote setting, your appearance is the image of your face, the sound of your voice and the background behind your head. There are several implications: Your camera is always on. You are in the centre of your camera's focus and the camera is ideally placed on top of your screen where you are looking at from time to time. On the other hand, when only half of your face is visible, or your face is distorted in some way, it is hard to see and to connect. In communication theory, as the initiator if the exchange, the sender is responsible for the message to be received. Much of your message is conveyed by your voice. For the best audio, use a headset with a microphone so your team mates have a change of hearing you. Next I recommend a professional background. Best is a uniform wall or board. In the beginning of remote work, I hung a blanket between two window handles to provide a uniform, non distracting background during my video calls. Non uniform backgrounds are distracting and make it harder to focus on the face of the person speaking. A Green Screen background helps if you have no option to work in front of a wall or door. Please choose a neutral image with soft colours. Most Green Screen backgrounds are unsuitable.

3. Strive for the same Level of Collaboration
It is harder to collaborate under remote working conditions. For example pair programming is more complicated. Now I do not accept less collaboration than before remote work. There are options and tools to overcome the barrier. Ten years ago, in 2012, I already used tools as TeamViewer or AnyDesk to control the machine of my remote pairing partner. I spent many hours working like that and it worked well. Modern tools I have used include Code With Me, which works with the JetBrains family of IDEs, Visual Studio Live Share, which you can even join with a browser, Floobits, CodeTogether and mob.sh. If you are blocked by remote work, push for some solution to keep in touch and do what you used to do. Do not accept less collaboration than in face to face situations.

We need to keep in touch
After I had put together my three tips, I was surprised. I had expected some technology or tool but all three tips are about connecting. Then it is not a surprise after all, because remote work first and foremost affects collaboration. Most advice of the other presenters was aligned with that. Here are some examples: When working closely with a team you need to keep in touch. You should speak with your team members often, probably talk daily. You should also meet outside work, e.g. remote game events like online escape room. Meeting in person is even better, e.g. visiting each other or visiting the office once in a while.

Video Conference All Day
A team lead shared his story how they had managed transition to remote work. The team used to talk a lot during the day. When remote work started, they kept a video call running. Whenever people would work, they would be in the call, unless they were in a meeting with someone. Many team members used a second device, e.g. a tablet, for this ongoing call. They felt like being in the office and whenever someone wanted to talk, she could talk to the people in the room. Using the video conference open all day, the team kept up the good vibe while fully working remotely.

I am curious about your tips to improve remote collaboration. If you have any, I invite you to comment.