3 ms·

As a manager you need to help set up a culture where showing unfinished work is ok. On my current team I will often make a quick prototype and ask our TL "Can y

As a manager you need to help set up a culture where showing unfinished work is ok. On my current team I will often make a quick prototype and ask our TL "Can you take a look to see if this is a completely off base approach? This code is not done yet but before I put more time in it I want to validate it's direction." My TL says that this behavior wastes his time and I should only show him fully finished work. He'll often say there's no tests or linting errors instead of looking at the approach. Same thing happens with design docs. If I'm even editing for spelling he'll refuse to look at it. "Ping me when you are finished editing". It's a complete waste of my time to completely finalize something, have him take a look at it for 2 seconds, and then say it's the wrong direction. And yes, we have tried to specify tickets more but he wants more general stories to allow the engineer to identify and approach. He just wants us all to identify his approach without him telling us.

ergocoder 5y ago
That TL is crappy. For my team, I even encourage them to publish PR before doing any test. They can start writing tests, but please publish PR before.
- mgkimsal 5y ago
  Interesting. I encourage people to publish early/often. However, depending on the problem, I would rather see some tests early on which would be defining the approach being developed. It's not necessarily a black/white issue for me, but there are cases where having some tests (or even just some written docs with the thinking outlined) is preferable.
  - ergocoder 5y ago
    I understand that there might be some cases that prefer a test. However, when communicating a guideline like this, it is better to make it simple. Otherwise, then it would be equivalent to no guideline. A guideline like this isn't meant to cover 100% of the cases anyway. If there are exceptions, I simply tell them to add some tests.

ergocoder 5y ago

That TL is crappy. For my team, I even encourage them to publish PR before doing any test. They can start writing tests, but please publish PR before.

mgkimsal 5y ago
Interesting. I encourage people to publish early/often. However, depending on the problem, I would rather see some tests early on which would be defining the approach being developed. It's not necessarily a black/white issue for me, but there are cases where having some tests (or even just some written docs with the thinking outlined) is preferable.
- ergocoder 5y ago
  I understand that there might be some cases that prefer a test. However, when communicating a guideline like this, it is better to make it simple. Otherwise, then it would be equivalent to no guideline. A guideline like this isn't meant to cover 100% of the cases anyway. If there are exceptions, I simply tell them to add some tests.