I’ve written a few times about people saying ‘this code sucks’. Most of the time the sucky code in question was written by somebody else – another employee or a different vendor.
On occasion it was written by the very person who is talking to me about it, usually 6 months or more in the past. That is always a fascinating conversation, but that is not what this blog is about. This blog is about the other situation – This Bad Code Was Written By Somebody Else And It Is Bad, Bad Code.
As a manager, I just believe now that every developer (yes, I’m talking about you team leads and architects) is always going to say that. Even people I trust.
Is that fair? Probably not.
Is it prejudicial? Yes.
Has anyone ever proven me wrong? Sometimes, but rarely.
Does it mean that the code is good? No, it doesn’t.
But here’s the thing. I’ve worked with tons of developers, some great, some good, some mediocre, but they’re all pretty clever at some level. The cleverness manifests itself in all sorts of ways. Many of even the mediocre ones work hard and deliver working solutions to clients and bosses.
And of course clients and bosses appreciate things that work.
So if you think most code is junk you’re probably seeing artifacts of something besides talent. What do you think it may be an artifcat of? Here’s a great question: If we work with this client with this sloppy code base, what do we need to look out for?
Code can be a great artifact for thinking about that question.
Chances are, in the middle of the sloppy mess, as you call it, are some bits of brilliance or cleverness. Finding them will give you some indication of both the motivations of the original developer and of the business realities this code faces in the real world.
Telling me one good or interesting thing about the code would prove that you had read the code. Telling me two good or interesting things about the code would tell me that you probably have a good grasp on it.
Providing me, as a development manager, solid context for understanding that you have read and understood the code allows you to judge the code and allows me as a manager more leeway to listen to you and understand your criticisms.
Here is my list of phrases and statements that cause me to judge people when I hear them without any further explanation:
*The code is fragile.
*This is spaghetti code.
*This was not designed properly.
*The code sucks.
*The code is over-engineered.
*The code is under-engineered.
*I make a change and it has unintended side effects.
The last one especially is a huge doozy to me. Unintended side effects? You’re really just saying “I didn’t read the code. And I don’t understand it.” In the worst case, you’re saying, “I don’t know how to do my job very well.”
When unjustified, all of those statements are smokescreens, avoidance, and hand waving. Even if you have a point, you aren’t proving it.
How do you prove that you read the code? Well, pointing out a thing or two that is good can be helpful, but there are other ways, too.
Here are two that can be helpful if you’re specific about it – Technical Debt and Code Smell.
If they’re used generically they have the same problem (they’re handing waving or avoidance or griping for the sake of griping), if they’re used specifically they can be meaningful.
Before you start to talk about the ‘bad code’ you can use these types of statements to be much more specific.
Originally published here.