Storytime: Don't Send Me Shit
It was the first time I was looking over the system and within a minute I had already found a handful of critical bugs and was getting frustrated. “Why would you even send me this to review?!” I was fuming to myself.
“This is shit work. Don’t send me shit or I will just send it back.” I started typing in an email to the developer who had sent it over. “I don’t mind taking a look and digging deep to find issues that aren’t apparent, but at least check your work before you send me something to review.” I said in the message.
But before I sent it out I caught myself. This was my fault.
We didn’t have a good process for debugging on this project, this was a good developer whom I had worked with a lot over the years. This was was clearly a process issue.
Rather than hammering on a developer who was probably doing the best as he could, I decided to pull back and reset the process. The project was small, but it still needed a thorough QA process.
Instead of sending out an angry email, this time I sent out an email to the PM on the project and asked her to implement a more complete QA process for the project and I opened up the resources she needed to get the work done.
A week or two later, I received another email asking for a review. There were still issues, but they were hard to find and not what I would expect to see a developer catch. I was happy to go through and find every issue I could from that version of the system.
PROTIP: It’s easy to blame a developer for not checking their code, but at the end of the day it’s your fault if the proper processes aren’t in place to support your developers. They work at your bidding, so do what you need to do to make them successful.
Last updated