[myowz]

This boss telling you that they felt the project should have been done a long time ago: I wonder who that comment benefits? Feels like no one. You get bummed, they give late feedback without a lot of constructive aspects to it.

I am trying to think of one way it was useful to tell you that, but I can’t.

Seems like you should feel justified in not being a fan of working under this person. What you do with that is hard to say. Sounds like you got to work on a cool project and got to mostly solo it. That’s pretty great for a junior.

[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 ..."

[lmeyerov]

A project being late involving a junior dev due to architectural and scoping issues is probably not because of the junior dev but the tech lead and product/project manager. The junior dev is still at risk in practice because the team is at risk and their manager can use them for the blame game.

In this scenario, I'd work through a 5-whys for figuring out why the multiple reasons why the "you're effectively on warning for being fired, and certainly not being promoted" just happened, and the reasons behind them. Ideally with someone at least a few years ahead of you who, and not at the company to avoid politics/bias issues. Maybe you need a tech lead or a senior dev mentor. Maybe project planning is broken. Maybe product expectations are broken. Maybe they don't know you're a junior dev and that means basic stuff like teaching you how to work in a team. Once you've done that, then repeat it with your team: they want to do better too, hopefully.

From there, if possible, maybe get it fixed... but it's not your job to fix team culture as someone junior, so also look at switching teams (managers) or even companies. If you believe you're being diligent and working hard, it's a net loss for yourself and better functioning teams to keep underdelivering for reasons not under your control. Other places would be happy to have you, help you be more productive, and your career + their results will be better. Leaving at 1-3mo point is not that bad on a CV (and you can drop it later) -- leaving at 6mo-24mo is the bad one.

[busterarm]

I wanted to post in this thread saying all of these above things but you put everything I was feeling into words perfectly.

I think this is the most accurate and actionable advice in the thread.

[cocoggu]

I think it is useful to let the employee know what are the accepted delays in this company, for future projects. But the boss or the manager should have said that earlier, at the beginning of the project, then the employee knows what to expect.

That's quite clumsy to say it only once the project has been released. Anyway, don't take it too personally, he/she probably just wanted to keep the pressure on you so you keep improving and never stay satisfied with your current pace. That's not very good management, but that's the way it is in most companies.

[dazeandconfuse]

I'm not sure. I'm glad he told me, otherwise I wouldn't have known I was undershooting his expectations. I did make mistakes that made the project taking longer than it had to. I guess if I want to keep working here I'll need to find a way to make fewer mistakes like that in the future.

[PragmaticPulp]

> I guess if I want to keep working here I'll need to find a way to make fewer mistakes like that in the future.

Communication is the answer.

If you think you're going to quietly go back to your laptop and solve all of these problems by being more careful, you'll probably end up disappointed.

You should take this as a learning opportunity to improve your communication skills. Communicate early and often. Ask for feedback. Ask for clarification. Ask for code review. Ask for a performance review.

Also: There is some good advice in this comment section, but there's also some absolutely terrible advice. Please ignore all of the low-effort comments insisting that you should quit or the comments suggesting that your boss's boss is malicious "gaslighting" you. This may be your first stumbling block in the workplace, but it won't be your last. If you make a habit of shutting down, quitting, or becoming resentful in these situations then you're never going to learn how to build actual healthy relationships in the workplace. Do as much as you can to learn from this, but make sure you do move on as quickly as possible. Don't let it eat you up.

[hunter-gatherer]

To piggy back on this, you will most definitely work with and for people who are malicious and gaslight you. Not saying that is the case here, but even if it is, a valuable skill is learning how to cope through it and work with those individuals. It isn't easy, but it is more sustainable than just being a victim.

[strken]

You want a strategy that works regardless. E.g. if your skip-level manager tells you a project should have been completed a while ago, and this is the first time you're hearing about it, it's better to say "let me follow up on that after the meeting and get back to you, because it's a bit different from the timeline we've set within the project" than to push the blame onto your direct manager, get defensive to your skip-level manager, apologise, or agree to spend the weekend working. Get some breathing room, put together a paper trail of emails and meeting notes, and let everyone cool down.

[nerdponx]

I've had modest success with this kind of thing. Managing to stay calm and maintain your internal composure is very important in the moment.

In a situation like this you need to be able to think on your feet and choose your words carefully, which can be very difficult if you have reverted to a defensive or fearful "fight or flight" mind state.

I personally have benefited a lot from biofeedback and meditation over the years, if only because it has given me the tools to recognize when I am in a fearful state and calm myself down.

The "fear is the mind-killer" mantra from Dune is not really fiction!

[emerongi]

Mistakes are a part of life. Do not be ashamed of mistakes, you will only limit yourself. I'm sure you're already aware of this, but sometimes we all need a reminder.

As for the project, you should consider how much mentorship you received. If there was none, then obviously a high degree of mistakes is natural, especially for someone new to "professional software development" (if such a thing exists). If there was a lot of it and you blatantly ignored it, you should take responsibility for it.

Most importantly, keep a healthy work-life balance. It's easy to forget it, especially when first entering the workforce and thinking that you need to "prove yourself". Most of us are average; if you are too, accept it and keep living as best as you can. The 10x coders can keep on 10x-ing, but the world depends on the average person.

[cgio]

I think your last statement indicates how bad that feedback session reflects, not on you, but on the “boss”. On the one hand, we all have bad moments, that might have been theirs, which sounds pretty terrible though, especially in context of you having limited experience. On the other hand, while if you discuss he/she would probably apologise, it sounds exactly like the kind of boss that will throw you under the bus when the going gets tough.

Early days. One of the key things you get with experience is the cold blood to wait some things out and to not let minor or major incidents get under your skin. If/when this becomes a pattern assess it against the rest of your experience and decide on your best path forward.

[water8]

I think just about every new developer makes mistakes that make a project take longer than it had to but this is how you learn and improve for next time.

[aprinsen]

I mean, at the baseline I think it's useful to know you're not meeting expectations. Of course it's more useful to know in a timely manner.

[seneca]

> I am trying to think of one way it was useful to tell you that, but I can’t.

It's useful if it's a warning that OP isn't meeting expectations. Getting that feedback before a formal review, when there is still time to turn it around, is beneficial.

I've seen junior engineers be blindsided during a review more than once. They go in thinking they're doing great, because they've gotten no incremental feedback and lack the experience necessary to guage on their own, and then hear they're not cutting it. Getting this feedback before review time (and preferably even earlier than OP did) is good, even if it hurts to hear.

Obviously that feedback should have gone through their manager though. OP's manager should have rescheduled this meeting if they couldn't make it, since they probably already knew the feedback was negative.

[agumonkey]

I have this feeling most workplace structures are pressure trickling systems. Nobody really knows how, but things get pushed down blindly, everybody grinds hard and higher ups complain about progress not being good enough. People grind again through fear. Rince, repeat.