You were tracing a strange result in the pricing service and found the line. A rounding step that happens before a discount is applied, not after. It looks wrong. It was written three years ago by the principal engineer, the person everyone on the team goes to with hard questions. Your first thought is that you must be missing something.
You might be. That is fine. It is also possible that you are right, and that nobody has looked closely at that line since it was merged. Experienced people write bugs too. They just write them in places others are reluctant to question.
The way through is not to be more certain. It is to be more specific.
Before you raise it, make the case concrete. Write a small test that shows the input, the result, and the result you expected. If you can, find a real order where the difference showed up. A reproducible example turns a feeling into something anybody can check in a minute.
Then raise it as a question with evidence, not as an accusation and not as an apology. I think I have found an issue with the discount rounding. Here is a test that shows it. Am I missing a reason it works this way? That sentence is respectful and still clear.
Send it where the work is discussed, in the ticket or the team channel, rather than as a private message that feels like a confession. Good senior engineers want to hear about this, and it helps everyone see how the question was answered.
Be ready for either outcome. If there is a reason you did not know about, you have learned something real about the system, and it is worth adding a comment or a test so the next person does not wonder too. If it is a bug, you have found it before a customer did.
Either way, notice what you did. You read code carefully, trusted what you saw enough to check it, and said so clearly. That habit matters far more than this particular line.
– Asael Shinder
Top comments (0)