As a developer manager (of sorts), I often find myself digging into code I don’t understand in applications when I’m trying to help out, or more likely when I’m dog-fooding our development processes.
So it’s not surprising that in my first months at Avvo as VP of Engineering I would encounter some code that shocked and horrified me. The reaction can be normal for any experienced developer, and trashing legacy code is a time honored past-time in IRC and now in slack channels. Those developers who were around when the code was written will often chime in. Lord knows most of my own old code would horrify me now.
Especially the OO C++ class hierarchies I created.
But as a manager I made a terrible mistake. I took to slack in our developer channel and asked the big “WTF is this stuff” question. Now the code I was looking at served a purpose and the anti pattern I was looking at was rather stark, but there had been a pattern, and it was intentionally done this way.
I immediately realized my error but there were some developers in the channel who got to see me “open mouth, insert foot” in real time. I quickly set about trying to edit away my comments and ask some actually useful questions instead of code shaming whichever author had written the code. Talk about awkward.
The next day at least one or two developers mentioned that code shaming is an anti-pattern, but a forgivable one.
However, as a manager, it’s never ok. It doesn’t matter if the authors have long since left the company. There’s almost always a good reason code gets written the way it does. It’s almost never because no one cared or because the developers were unskilled, if anything it’s usually due to poor engineering management.
After all, I don’t want my developers writing perfect code, or adhering to idealistic best practices. I want them doing the minimum necessary good code and the maximum possible business value.
There’s good stuff and bad stuff everywhere and when a manager starts code shaming it can increase everyone’s anxiety.
I’m still learning, but I thought I’d share this mistake, and add it to my short list of management principles:
Shaming people isn’t an effective tool for improving performance, and shaming code doesn’t help your team write better code, it just lets them know you’re an elitist punk.
Be kind and generous and helpful to your teams, don’t code-shame.