7 ms·

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, t

• nlh 5y ago
  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.
  • SilasX 5y ago
    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".
  • xupybd 5y ago
    The only counterexample I can think of is the present tense. For example: You have kids, you should have life insurance.
    • nlh 5y ago
      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. ;)
  • neutronicus 5y ago
    Your phrase is also a good replacement for "why didn't you ..."
  • rdtwo 5y ago
    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
    • nlh 5y ago
      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 5y ago
        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 5y ago
          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.
    • kmonsen 5y ago
      (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.
  • HWR_14 5y ago
    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.
    • fernandotakai 5y ago
      >"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.
    • nlh 5y ago
      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 5y ago
        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.
  • allenu 5y ago
    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 5y ago
      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.
  • russelg 5y ago
    At my workplace, we have explicitly banned the use of "should have".
• cocoggu 5y ago
  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.
• seneca 5y ago
  > 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.
• dazeandconfuse 5y ago
  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.
  • water8 5y ago
    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.
  • emerongi 5y ago
    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 5y ago
    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.
  • 5y ago
• aprinsen 5y ago
  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.
• lmeyerov 5y ago
  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 5y ago
    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.
    • deleted 5y ago
      [deleted]
• agumonkey 5y ago
  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.