Vrftsjtryk

TL,DR: Questions under the text

I am a software developer at a R&D center. Due to my seniority, I am oftentimes asked to review time/scope critical changes to our code-base. Due to the hectic state of the project, it is not unusual that I am asked to review others' code the day or even hours before a major delivery.

I often review pull requests from a contractor, Joe. Joe gets paid for every feature he completes rather than a hourly rate. It is my impression that Joe tries to get as many features done as possible, oftentimes skimping on documentation/code quality in the process. In the past, I have had to do overtime to fix issues with Joe's code, because once it's approved and paid for, he doesn't feel and nobody makes him responsible for bug fixing. Our team has pointed out that the situation is non-ideal, but the current managerial decision is that this won't change.

I would frequently request changes in Joe's code because it doesn't meet our guidelines. Joe would usually approach me with a story about how he wouldn't get paid if his code wasn't accepted in time. For a while I would accept minor issues under the condition that Joe would fix them later, but that never happened. Eventually I stopped accepting incomplete submissions and have asked Joe to escalate the issue if he's unhappy with my verdict.

Generally, Joe's code would have the following issues, in ascending order of seriousness:

1. Lacking documentation/formatting against our guidelines


2. Lacking tests


3. Architecture incompatible with what we were trying to achieve in the future


4. Performance issues


5. Flat out not working

Since Joe's features were often promised to the client in that particular week and there wouldn't be time for Joe to fix them, eventually other people have started approaching me to accept Joe's code, from Product Owner, through Project Management, my boss, to my boss' boss.

In the discussions my project management/my superiors usually ask me to find a way to accept Joe's code anyway. I would generally let 1 and 2 through at this point, but refuse to accept anything more serious, citing my responsibility for code quality and technical debt as engineer. To put it bluntly, accepting code like this would cost us more time down the road than it is worth.

In some situations my superiors have asked to accept the code anyway, even if the issues were egregious, citing features promised to the client and the upcoming delivery. At this point I usually respond by saying:

• Anyone, including non-technical employees can overrule my decision and merge the code.


• If they are my direct superior, they can send me an email ordering me to accept it and I will oblige.

I do this not necessarily as a CYA tactic, but rather believe that people think twice about the decisions they are making if they put them in writing. To this date, no one has decided to do any of the above, even if I have gotten some scoffs as a result.

Nevertheless, some co-workers have privately told me I wouldn't make it very far with this attitude, thus I wonder:

• As an engineer, code quality is my responsibility. To what degree should I fight for it?


• Is it appropriate for me to ask my superiors to put their decisions in writing?


• If code quality is suffering due to organizational issues (the way a contractor is compensated), is it appropriate for me to be "a judge" or raise the issue with my superiors or HR?