An example of kindness in tech: the case of “shitty code”

Source: Dev.to

Introduction

Disclaimer: this article reflects my personal opinion and is not intended as an absolute truth.

During my short career I have repeatedly heard developers mutter “what a shitty code” while reviewing someone’s work. Even Robert C. Martin refers to “bad code” as a metric in Clean Code. While the frustration is understandable, the expression adds no constructive value: it offers no explanation, no willingness to help a colleague improve, and it is purely judgmental. Moreover, it can create tension within the team. How would a teammate react if you label the code they just wrote as “shitty”?

Why the Term Is Problematic

• Lack of constructive feedback – The phrase provides no guidance on how to improve the code.
• Potential for conflict – Even in teams that strive to be egoless, such language can be perceived as an attack.
• Ego and psychological safety – From a managerial perspective, the term can be poisonous. Unless one is completely detached from ego, the remark can damage interpersonal relationships and erode trust.

Context Matters

The perception of what constitutes “good” or “bad” code changes over time. A codebase considered solid in the 2000s may be viewed as outdated twenty years later. In fast‑moving environments—such as startups focused on validating a business model—speed often outweighs elegance. Teams may deliberately incur technical debt to deliver an MVP quickly. In those contexts, “quick and dirty” solutions are a pragmatic choice rather than a sign of incompetence.

Impact on Psychological Safety

Research consistently shows that psychological safety is the top predictor of high‑performing teams. Using harsh labels can:

1. Prevent the creation of a psychologically safe environment.
2. Reduce the likelihood of receiving candid feedback.

Both effects hinder a team’s ability to reach its full potential and productivity.

Recommendations

1. Replace the phrase

• Use neutral terms such as “suboptimal code” or “code that could be improved.”
• Explain why the code needs improvement and suggest concrete steps.

2. Address the issue directly

• If the term makes the team uncomfortable, hold a 1:1 conversation to discuss its impact.
• Encourage a culture where feedback focuses on the code, not the person.

3. Foster constructive dialogue

• Emphasize that criticism should be specific, actionable, and respectful.
• Avoid complex solutions; a simple, neutral language shift often suffices.

Conclusion

The expression “shitty code” is harmful because it offers no constructive guidance and can undermine psychological safety. By adopting neutral terminology like “suboptimal code” and focusing on clear, actionable feedback, teams can maintain a respectful atmosphere while still improving code quality. Stay neutral, stay constructive, and prioritize a safe environment for open discussion.