|
|
|
|
|
|
by futhey
1442 days ago
|
|
|
> 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. |
|
|
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.