Respect and Code Reviews [duplicate]

Question

How do you respect your boss when he asks you to write the code in his fashion for no objective reason other than he likes it that way?

I submitted my code for review and passed all lint checks and presubmits.

I got throttled by a code blocking code review. I got no accolades on my success with the app.

His first review had a few decent comments, some inconsequential bad advice, a serious mistake, and the comment: "I would appreciated it if you would rewrite the code as [example]". Rewrite was no small task.

I explained the objective problems with that example, addressed the bad advice, explained the problem with his serious mistake, and finally, explained why I written the code in the way I had, and, on top of that, I also rewrote it, just to try and appease him.

I ended up taking over an hour to rewrite it. I further provide an explanation of the pros and cons of solving that problem different ways, as I'd analyzed it. Being the author of the code, I'd already analyzed it and made assessments on how to solve that problem.

After that, I had to work on another task that I was to complete that day. I stayed until 8 to do that.

He'd pushed back my productivity on that to refashion the code in a style that he prefers with no objective reason given. I worked 11 hours that day, after a follow up of a 10 hour day prior.

Manager complained about the rewrite I'd done. How do you handle that? If I rewrite it his way, which is objectively worse, and if he cannot provide any objective reasons for why, I won't respect him. I sense he is playing power games, testing me, and trying to find reasons to fire me. As childish as this sounds, I sense that he is disrespecting me on purpose to create an issue.

What I want is to keep my job there and maintain workplace respect.

Answer 1

I think you're taking this way too personally.

I used to get pretty annoyed with a "thumbs down" of my PR (Pull Request / Peer review). but it's not meant to be that way. It just means the code is not yet ready to merge.

How do you respect your boss when he asks you to write the code in his fashion

Your boss has been tasked to provide a solution - s/he has chosen to use you as the designated coder. Your boss - effectively your client - wants it done a certain way. If you feel strongly otherwise, get another job, or make your complaints beforehand.

I also rewrote it, just to try and appease him

Your attitude is at fault. What if you were a chef in a diner and had to cook eggs the way the stupid customer asked for, rather than your way?

I stayed until 8 to do that.... I worked 11 hours that day, after a follow up of a 10 hour day prior.

Yeah, that's a mistake. Don't do that. If you're asked to rework something do it on their time (unless you were previously given contrary instruction and you did it "your way").

I probably won't get many thanks for this, but I think you're wrong, Garrett. You come across as immature. Get over yourself, grow up. You're being paid by the company to do a job required by the company - not what you think is required. (40 years experience as a developer tells me this. And I've been where you are more than once).

---

Also Garrett, do me one favour. Bookmark this page somewhere and reread it in 5 years. Give an update if you still feel the same way.

Answer 2

In development, the hierarchy of needs is:

1. It works correctly
2. It is readable/maintainable
3. Performance

An objective problem is either 1 or 3. Performance (3) only trumps readability and maintainability (2) when combined with (1), ie when you have a functional performance requirement that you aren’t meeting. While 2 is subjective, your boss is the eye that beholds. Which means if your boss thinks the style is wrong, the style is wrong. Really, anytime someone does a code review and has a problem with either the style or understanding what you are doing, take it as a given that they are right. They may be wrong on style, but by definition they are right about understanding.

That said, there is a cost to doing the rework, and you should make your boss aware of it. You should be doing a normal days work, and rework due to comments from a code review is part of that, not an emergency or something you should take on to fix outside of normal hours. If there is a task that will be pushed back to the next day, tell your boss about that, don’t try to paper over the issue with overtime (paid or unpaid). It may or may not change the priority given thee task, but at least then the right person is making the call.

Answer 3

Making changes due to a code review doesn’t reduce your productivity. It’s part of the job. You made one mistake though: You stayed late that day. Assuming that your boss requested these changes for no good reason, you should have shown him that there is a price to pay: A delay in other work. Instead you decided to pay the price yourself. Don’t do that again.

Answer 4

You have two problems:

1. You get emotionally attached to your code.
2. Feedback comes late.

Let me explain:

1. The code that you write isn't your code and it certainly makes no sense to think of it this way. You can get reassigned – even to a better position – faster than you might think, and the code you wrote will be perfectly fine. If you think about it: Any and every company code that you see and modify was "someone else's code" at some point.

2. Pull Requests are part of the GitHub flow. While it is the best work flow for many organizations and certainly the one your company chose, it does have some serious drawbacks. Feedback will always come when you think you're done and it will be mostly negative. Change requests (GitHub) and tasks (Bitbucket) are just lists of things that are not good enough in the reviewed code yet. There's no built-in way to high-five someone, though. So you'll have to emotionally detach yourself from the torrent of negative feedback that is inherent in this process.

Now, there are other development processes, like trunk-based development, where you commit to trunk – under the assumption that you will continuously refactor your code anyway. Or pair programming, where two developers program together. I hope you can see that these provide feedback earlier, but argueably require more resources and/or trust and that is why your company didn't choose those. In any case, your company is highly unlikely to change its ways upon request by a single junior.

You can always ask your boss to provide you with adequate learning materials and/or introduction to the domain of your software in the hopes of understanding his reasons for why the code looks as it does. Or ask him, or someone else more familiar with the code base, about feedback way before even thinking about opening a pull request.

In the end though, your manager is responsible for your work output anyway, so if he wants to make you objectively more unproductive, that is none of your concern. You get paid by the hour, remember? Overtime is a different topic and you'll find a lot of advice regarding this issue on The Workplace.

As a very last resort, you can always vote with your feet and walk to a different company. But do expect the GitHub workflow and its drawbacks again.