[nlh]

I agree with this sentiment. And in fact, I’ll take it further:

I’m not sure any “you should have” phrase is ever beneficial UNLESS it’s in the context of giving guidance about the future. And even then, it’s better to phrase it as “next time, I would suggest…”

This has been a pet peeve of mine for a long time. “You should have” phrases are often used to berate or make the recipient feel bad while acting as a vent for the sayer. By grammatical definition, they refer to events / things in the past and suggest an alternate course that didn’t happen. A theoretical construct. Good for language construction, bad for feedback.

I’d love counterexamples if anyone thinks differently, btw.

[allenu]

This reminds me of a case of a director asking a "tough question" of a dev team as a way of providing feedback. I don't think the feedback was taken the right way in this case.

I was in a meeting where a group of devs were presenting a technical solution to our director, who was overseeing the product as a whole. At one point the director asks, "Did you look into other companies doing this and potentially licensing their solution to the problem instead?" All the devs were confused because they were tasked with building a technical solution in-house. I was confused as well because it seemed like a question the director should've asked a PM or one of the dev leads, not the grunts who were tasked with writing the code. The devs presenting were flustered by the question and didn't know how to proceed. The director continued with the line of questioning and it was clear he didn't like what he saw in the presentation.

The experience left a bad taste in my mouth.

Anyway, a couple weeks later, my manager mentioned the incident and told me he asked the director about it. The director admitted that he had only asked the question to get the team thinking differently about how they were solving the problem and cut through some of the technical details they were providing him. My manager thought it was a clever tactic, but I thought it was manipulative. I also think he just lost his cool since the solutions weren't to his liking and wanted to take it out on the team a little bit. I didn't think it was a great way of building trust with the team, nor do I think it made them think differently about the problem.

[zacmps]

I think the question is fine, and a good one, but the motivation should have been made explicit, certainly no later than the end of the meeting.

[HWR_14]

It can be used in the context of explaining what changes that need to be made to someone's work for it to be acceptable. "You should have used established crypto library calls here instead of rolling your own SHA-256 implementation with probable bugs. Please fix it"

I also think it works well, better than "next time I would", for giving someone permission to do things. "You should have called me when the client asked for XYZ" sounds more forgiving and less venting than "Next time call me when the client asks you for XYZ". Or "you should have felt free to take a mental health day". It's more empowering.

[nlh]

Your first example is great -- in a correctible situation (as with code, or writing, or design), it works and is helpful. You should have used, should have written, should have drawn, etc.

But I respectfully disagree with your second example:

"You should have called me when the client asked for XYZ" is _exactly_ the kind of phrase I find unhelpful. All that does it lay blame - it says you did something wrong and in a perfect world you would have done something right. Your counterexample is the kind of feedback I'd MUCH rather hear.

"Ok, you didn't call me when the client asked for XYZ. That is fine. If it happens again, call me." It addresses the situation that happened, emphasizes that you are indeed forgiving, and gives guidance about how to handle it in the future.

[HWR_14]

I agree my second example was poor. The intention was "should have" would be used when you had an optional, not imperative, future choice. "If you thought something was wrong, you should have (implicit or explicit) felt free to call me and escalate it." And (upon reflection) I don't think it really expresses that at all.

I still feel like "If you needed a mental health day yesterday you should have taken one" can be empowering more than "If you need a mental health day in the future, take one", for the same reason that the middle example is poor. It shifts agency (and blame in the second example) to the person you are talking to. But I no longer even feel as confident in that example either, and would welcome pushback or not on the point.

Thanks for pointing it out. I'll try to be more aware of that going forward.

[nlh]

All good! I hope my respectful disagreement came across that way (and not combative). I appreciate this exchange.

[HWR_14]

It totally came across as a non-combative (and friendly/respectful) disagreement.

[fernandotakai]

>"You should have used established crypto library calls here instead of rolling your own SHA-256 implementation with probable bugs. Please fix it"

in this case, i would say something like "hey, we need ot[or should] use a cryto library here since it's battle tested, rolling your own crypto might have issues [yadda yadda yadda]".

it makes it feel like it's not a single developer decision, but a team/company wide one.

[xupybd]

The only counterexample I can think of is the present tense.

For example: You have kids, you should have life insurance.

[nlh]

Yes - you're absolutely right. I should have (ha!) specified I meant in the context of a past participle ("you should have <verbed>"), not the present suggestive (is that the right term?) -- eg "you should have <object>" or even "you should <verb>"

Man, grammar is weird. ;)

[russelg]

At my workplace, we have explicitly banned the use of "should have".

[rdtwo]

So i work with this person that is really slow. She should have accomplished a task in 2-4 weeks and it took her 6 months. We gave her 3 months to accomplish it. So at some point you do need to point out that a task should not have v taken as long as it did and ask the person why it did. Was there some sort of unknown issue that caused the task to take 4x longer than expected

[kmonsen]

(1) I don't think you can reliably say after the first suck project. Some people are a bit slow at picking up new things, but become very productive after a while.

(2) Others pick things up super quickly, but never become super productive as the first group.

And of course lots of variations of people that don't fit neatly into either group.

I am in group (2) I think, but in my experience you really want people that become strong experts after a while. They are the ones I have seen do the best over the long term.

[milesvp]

Salman Khan talks about this a little. He said one of the things they learned from the Khan Academy is that you can sort of group everyone into either "convex" or "concave" learners and they all basically get to the same level of competence by time T, and it's more a matter of do they plateau at the beginning or at the end.

He seems to be very careful about placing value judgements on which is "better", and he's also very careful to crop the graph near time T. His big push is to make sure that teachers understand that people that are categorized as "slow learners" actually often take just as long to get to the same level of proficiency as "fast learners".

[kmonsen]

Yes, agree with all that :-)

[nlh]

This is a great example - thank you. Rephrasing as a "you should have", it would read:

"You should have been able to finish this in 2-4 weeks, but it took you 6 months. What went wrong?"

That's actually useful feedback, I think. It highlights that the giver believes the recipient has abilities that exceed the demonstrated result.

[41b696ef1113]

My one quibble with this example -I sincerely hope there was feedback given the entire duration of those six months. Being told far after the fact that you are doing X thing poorly is a kick to the self-esteem.

[rdtwo]

Oh absolutely, it was pretty clear that this person wasn’t on track 4 weeks in. And after that you have to keep communicating that we were expecting more progress… what are the issues will you make the deadline etc.

[democracy]

Try to break down the tasks so that their single task doesn't take more than a day/two, see how it works out. Some people seem to operate better on short, simple tasks with visible understandable impact.

Also a 4 weeks task for a member of a larger team is something that turns them into their own development shop and it's probably not something you want to have in a team.

I also understand some will say "a senior dev should manage such a long task on their own" - well maybe they should and some might, but in the end it's not their business and they can jump the ship 2 weeks before the deadline of a 3 months task (seen that) - that's why good project/tech/team management is a skill ))

[SilasX]

More generally, I would say that any advice of the form "don't do X" is useless unless paired with "instead, in that kind of situation, for the goal(s) you were optimizing for, do Y".

[neutronicus]

Your phrase is also a good replacement for "why didn't you ..."