[ManlyBread]

>back and forth with PR comments

In one company I was one of these people who was causing this to happen. For any bigger change the TL would leave close to a hundred comments.

The problem here was that the TL had a certain vision on how to approach the task. Vision that he wouldn't share until code has been written. Then he'd write these comments, telling us to redesign this or that or to use a certain library. We'd challenge him from time to time to which he'd respond that we talked about this in the past on some meeting ages ago and that we were supposed to "take notes". At the same time he refused to formalize the process and set up any sort of a coding standard.

We literally had to guess what he expects of us. I couldn't even ask to clarify because there was no telling what might become unacceptable to him. So the standard has become "anything that went through the review process in the past", which leads to an another pattern that you've mentioned being a "copy paster". Even this stopped being a safety net at some point. I'd set something up exactly as it was for an another project - a project that was completed merely 4 months ago - only to hear that it's all wrong and that "we don't do it like this anymore". Naturally he didn't even bother to notify us. Stuff like these kept on piling up until it became so ridiculous that I've left the company.

So my advice would be to set up clear expectations and standardize things as much as possible.

[futhey]

> The problem here was that the TL had a certain vision on how to approach the task. Vision that he wouldn't share until code has been written.

I run into this exact problem fairly often, and I have run out of strategies to "manage up" or prevent this problem from happening. Would love to hear more on this.

[ManlyBread]

It was more of a communication problem on his part, as well as picking up some really quirky bits of knowledge and insisting on using them even though it didn't make much sense.

An example can be when he made a fuss of us not using the .NET IOptions pattern. In one PR he took great offense to this, stated that he said we're supposed to use this pattern ages ago, even though nothing like this happened and said he won't accept it before it was rewritten. Then he ignored all of the comments stating that this makes no sense and is no different from just using a regular object, especially since IOptions is more about dealing with config files while we were getting these values from somewhere else. He told us to "just make it work" and that "he can't make all the thinking for us". I did manage to get it working the way he wanted but in the end I had to throw out a solution that was already working and was commonly used across plethora of other projects to accommodate for something new that made zero difference in the end.

There were tons of situations like these. He would tell me to use a tool/library that he never used, I'd come back to him half a day later with proof that this doesn't work the way he thinks it does, he would dismiss me by flat out saying that I'm wrong, I'd come back the next day saying the exact same thing and only then I'd finally get through to him. An interaction that should have took 5 minutes tops would take a day and a half because he refused to acknowledge that his vision was wrong.

A better, more positive example was when he provided a design on his own and had us implement it. It ended up with some minor adjustments and was quickly accepted, I was surprised it went that well.