“This code base is really growing now. And it is growing fast”.
More thoughts are bubbling up inside you as you are browsing through a massive amount of vaguely familiar looking code. You are hunting for a good place to put your new domain related abstractions. Up and down, to the left and to the right. Finally, you find the place you where looking for.
“There you go!”
A sense of relief and the sweetness of smaller victory enters your body. You relax for a bit.
‘But … wait .. hey, what is this. Oh no, not again. Crap-alert … crap-alert’ – A voice inside your head screams.
You start to quickly scan through some code you’ve never seen before. ‘Aaaaaaarrrgh!‘ After only a few minutes you can not hold it in any longer. A ‘What’s this garbage doing here’ blurts out of your mouth. Followed by a ‘This is not acceptable’ in a slightly louder voice and a much sharper tone. You suddenly feel the attention from a few colleagues around you and the tension rises a bit. You shake your head and get back to looking at the code. Feeling a bit better for letting off some steam. Your colleagues on the other hand returns one by one to what they where doing as someone just thawed them.
I have seen this happen over and over again. I have myself delivered my fair share of such remarks, shouts and outbursts. It is probably happening in a software team even as you read this. The scenario I described could indicate some sort of established trust, but that is probably not the case. It is more likely because the person complaining over the code thinks he has the right to do so. He could be a senior developer, an architect or just a general loudmouth who likes to express his opinions about anything that pops into his mind. Whatever may be the case there are better ways.
This is really about feedback. Much needed feedback might I add. So, if you are planning on giving feedback about this, I would suggest another aproach.
About feedback
Positive feedback
Positive feedback or encouragement of a desired behavior has, just like discouragement of behavior, best effect if delivered immedately after the behavior occurs.
Negative feedback
Negative feedback or feedback about behavior that you do not think is appropriate or desirable. This kind of feedback should be delivered personally, be concrete and followed by a suggestion of what you would like to see.
The 5:1-rule
Deliver positive feedback five times as often as you deliver negative feedback.
I will not go into much more detail about feedback in general but rather move on to the specifics of the subject.
The Remedy: Code Hausse
Every time you feel the urge of shouting out or making a sarcastic remark about bad code. Take all that energy you have built up inside and use it to find equally good code. Then shout out. ‘Wow, this code is fantastic. It is easy to read, to the point and really makes sense’. If you can not find code you like. Look again.
Here are three ways to save yourself from an outburst
- ‘What is this, this is just absolutely … fantastic’
- ‘Who did this, who put this piece of … gorgeous code here’
- ‘If I see code like this again … I really have to sharpen my coding skills or I’m out of work’
Additional tip: Add a bookmark in your favorite editor and learn how to get there fast. So you can whip that up when you get the attention from comments like the ones above
Encouraging behavior in a programming environment
Here are my three favourite ways of talking about and encouraging behavior.
Pair programming
Always close to my heart. This is a very natural arena for quick, relevant and useful feedback.
Code reviews
Not the kind where you hand over your newly, 2-3 weeks worth of code to an ivory tower architect. Who gives your code a glance and comes up with all kinds of improvements that has to be ‘implemented’. No, I am talking about a hands on constructive, workshop like event where 2 or more programmers sit down and improves an area of the codebase. Together.
Discussions
‘Over lunch’, ‘Cup of coffee-in hand’ or just ‘By the whiteboard’ relaxed kind of discussions where you find out what your colleagues think about design and programming.
These three approaches have one thing in common. They have a lot more leverage if there is trust present. But so does almost all kinds of interaction between people.
Remember: Behavior change starts with you … today.
Highway 74 
Wow! Great post! If I see many more of these posts from you I’ll have to stop blogging myself since it would be futile in comparison. 🙂
Quick one – Do you approve of all developers having equal access to all sections of code, or, in your view, is assigning different portions of code to different (sets of?) people a more reliable approach? I appreciate you don’t approve of individual developers having a high bus factor but surely everybody having free reign is equally as dangerous?
I like to give all developers the same starting conditions. I.e everyone can change any piece of code. If that, for some reason, wouldn’t work I’d start making changes. Up to this day, I haven’t seen anyone misuse this privilege.
Sometimes you’ll have to start with working agreements though.