I’d spent the better part of the year working on a single project. For confidentiality’s sake, let’s call it Project X. It was going well. The client was happy, beta testers loved it, and our team had done a great job. I was pleased with our progress for the most part.
But I felt a bit frustrated by the quality of code I’d recently written. There was some technical debt and test coverage was a bit lacking. Nothing insurmountable, but it bugged me. The issues weren’t serious but I spent the next two weeks prefacing every meeting with, “The code quality isn’t great, but I’ll fix it.”
I forgot about it until my next performance review. I was stunned when the reviewer said, “So, it sounds like there are some serious problems with Project X.” The app looked great, performed well, and had accomplished all of its goals. Where was this coming from?
It slowly dawned on me: it was my fault. I’d been so outspoken with my temporary concerns, it was all people remembered. For those outside the project it was the only information they had. I’d changed how the app was perceived.
Like most developers, I used to believe that the work is all that matters. But that review served as an excellent reminder: perception matters, too. It doesn’t matter how successful a project is if you’re projecting the image of a codebase with serious issues.
I learned my lesson.
The next time you feel like complaining about something small, take a moment — and remember that those complaints might be the only thing people remember.