It was a nice surprise when former team member Colin sent me a review. There was some existing code that basically used an ID to look up some data from a local cache. It was written in a way that implied that one result should always be returned. The ID number does not come from the user, it will (originally) come from the database if you trace the code back far enough.
Anyway, Colin had changed the code to allow for 0 results. Just like the story I told about Derek in https://strangercodingtings.home.blog/2019/02/07/derek-origins/, Colin is basically hiding an error from the user. So began an argument in the review:
timeinints:“if we have an ID, how is it possible that this doesn’t find a result”
Colin: “I don’t know, this is a question for Paul” <link to Paul’s original change>
timeinints:“this is clearly a data issue. Paul’s code works as intended.”
Colin: “My change prevents the crash. I don’t care about it finding a result, the information it retrieves from there isn’t applicable in my case.”
timeinints: “A crash signifies to the user that there is a problem. Preventing the crash hides the problem, and the user will miss potentially key information. Just because your scenario doesn’t use the extra data doesn’t mean you can change it; all the other scenarios require it.
Colin: “Just to explain this problem: The user has a task which they can Accept or Reject. This problem happens if the user Rejects it.”
timeinints: “If they Reject it, should it clear out the ID because it no longer exists then?
Colin: “On further investigation, there are other scenarios where this can occurs. It’s a bigger problem than I anticipated”.
<facepalm> I think it’s quite disheartening that I can spend less than a minute looking at an issue and can categorise a problem better than Senior Colin. Not much thought had gone into finding out the root cause of the issue. He has gone straight to the “paper over the cracks” approach. That mentality is deserving of a demotion to Junior Developer.