Dear new developer,

There will come a time when you are looking at a system and trying to understand the choices behind it. You may be looking at a particular class, a subsystem, or a more fundamental choice, like the language or the system architecture.

And you’ll wonder what the hell the initial implementer was thinking. You’ll wonder why this system is still in production. You’ll wonder why someone didn’t fix this.

You will be tempted to trash talk this piece of work to your colleagues.

Don’t do this.

Why?

It’s not helpful. Now, it’s perfectly acceptable to point out issues and ask questions about why choices were made. It’s a good idea to suggest improvements, whether those be code changes, removal or replacement of portions of the system or something else. But complaining about the existing system doesn’t do any of that. It’s just complaining.

It displays a lack of empathy. Chance are you don’t know the constraints and pressures that the original implementer and past maintainers faced. Making judgements based on code without knowing the constraints is like hiring someone based on the color of their shirt–you just don’t have all the information needed.

Trust me, in the future you’ll face constraints, like lack of knowledge, time or labor or money, that will cause you to make choices that are suboptimal. At least once in my career I’ve come across a boneheaded piece of code. Cursing under my breath, I wondered “who wrote this crap?”. As I pulled up the commit log, my face fell as I realized that I had. Doh!

(What should you do if the code or system doesn’t work at all? In that case, the questions about constraints and understanding how a failed system was built are even more important. But again, complaining doesn’t help anyone at all.)

In short, when you are working in a codebase and trash talk it, you are the critic, not the man in the arena.

Sincerely,

Dan