This code is crap

Throughout my career, I've frequently heard developers lament that "this code is crap!" (well, they usually say ). It's usually some mid or senior level engineer looking at the existing codebase whining about how "bad" the old code is. To those situations, I say there's never a valid time to say the code is "crap."

Code represents the sum of:

• the acceptance criteria, goals, and deadlines that inspired the code to be written.
• the knowledge of the problem domain at the time it was written.
• the balance between Done & Good-enough at the time it was written. Put another way, the balance between get it out the door versus make it perfect.
• the knowledge, skill, attention, and diligence of the reviewers.
• the knowledge and skill of the author. (This is intentionally last.)

Ultimately, code reflects the team of people who specified it, wrote it, reviewed it, and tested it, as well as the priorities, deadlines, and understanding at the time it was written. Attacking code is attacking people, many of whom may still be your fellow employees.

So, don’t say “this code is crap.” Instead, say given what we know now, given the people we have to work on it, and the time we have to work on it now, we can make it better.

An anecdote

"This code is crap" said the reviewer to my face at my first ever professional code review. What a way to start a career! Now, he was right. I was new and had tons to learn. To his credit, he showed me the many ways my code could be improved. In the end, what was merged into the codebase was much better code. I learned a lot. And despite dealing with a rather harsh personality, I learned to appreciate what a code review can do for me and the team.

Still, don't ever say that to a new engineer!