4

This question already has an answer here:

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.

marked as duplicate by Kent A., gnat, mag, Arthur Havlicek, yoozer8 Oct 21 at 10:59

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 62
    When you say "rewrite was no small task" if it took an hour to do, yes, it was a small task. – DaveG Oct 20 at 23:16
  • 1
    Could you clarify whether you have worked with code review process before, and how that went? This mainly reads as someone who has not experienced code review before, and is reacting to a first (and maybe quite standard, we cannot tell from your description) review in a new organisation. It is hard to assess objectively how egregious your boss' behaviour is without seeing the code and review, although you should definitely not share it anywhere outside your company. – Neil Slater Oct 21 at 7:26
  • 8
    Why didn't you go home on time and finish the work the following day? Do you get paid for working overtime? – Aaron F Oct 21 at 8:53
  • 1
    "write the code in his fashion for no objective reason" - there probably is one very important reason that you are missing. Ideally, all the code for a project is written in the same "style" - this greatly simplifies maintenance in the future. This is a pretty common requirement of any effective software team, and one of the most important things to check for in a code review. – dan.m was user2321368 Oct 21 at 14:28
  • Maybe it's relative, but if it ended up costing OP an hour of their own time and there was no real benefit, then that can definitely feel like no small task. Personally I would have responded with an estimate for the rewrite and suggested if he was happy, I would pick it up the following day (or push other priorities to the next day if this was more urgent). Let the boss make the call whether it's worth wasting time rewriting code which already works, but don't sacrifice your own time to do so. – delinear Oct 21 at 14:49
72

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.

  • 2
    The chef's job is to satisfy the customer with what the customer wants. Your faulty comparison is a testatment to your inability to understand the difference between subjective and objective differences. – Garrett Oct 20 at 22:39
  • 34
    @Garrett - no, it isn't. However, your inability to understand that differences in a codebase have a cost irrespective of their nature or reason is an impediment to your ability to work on multi-person projects. – Chris Stratton Oct 20 at 23:23
  • 3
    Pretty good advice here, although I also think the boss sounds like a bad reviewer. Yes, the person getting his/her code reviewed shouldn't take things so seriously usually, but reviewers tend to fall into the trap of requesting too many changes (only one or two of which may truly be important) or arguing over subjective/stylistic elements. – Chan-Ho Suh Oct 21 at 3:34
  • 7
    @Garrett A chef might know that the best way to cook a steak is medium rare with a nice crust. But if the customer orders a leathery well done steak the chef better damn well make him a leathery well done steak – TheEvilMetal Oct 21 at 8:08
  • 3
    This answer would be better without the chef analogy. It's distracting from the main point, and everyone's getting hung up on what a chef does/doesn't/should/shouldn't do. OP is clearly unable to take criticism - the question is a rant looking for validation - and has already made their mind up that they're right. – Aaron F Oct 21 at 9:02
12

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.

  • 1
    First do it, then do it right, then do it better – aloisdg says Reinstate Monica Oct 21 at 8:54
  • According to OP, the variant by his superior contained a serious mistake. This is in my opinion point 1) - correctness w.r.t. to your list, rather than style. The question at hand is - if your superior asks for code that does not work correctly and they are made aware of this - do you still deliver? if you do, how do you do it without damaging your reputation if somehow bad practices in your codebase become known? Also how to approach the superior properly to make them aware of these problems in a non-offensive fashion? – Mär Oct 21 at 8:55
  • 3
    The "hierarchy of needs" will depend on the type of project. Different projects will have different needs. – Gregory Currie Oct 21 at 9:57
7

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.

  • If it was me, the price would come due on Friday when I leave at 12, or possibly in December when I's burn the time balance for a longer holiday. – Haem Oct 21 at 9:59
5

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.

  • Missing positive comments in review process - like comments to an answer in Stack Exchange; if nobody comments, then your answer is pretty well written. – RedSonja Oct 21 at 11:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.