5 ms·

> They probably don’t want you to lie, but there is a small chance that they pruessure you to. In my experience, most of the time there was pressure. I remembe

> They probably don’t want you to lie, but there is a small chance that they pruessure you to. In my experience, most of the time there was pressure. I remember a funny conversation between my project manager and a colleague: PM: "We need to have X as soon as possible, how long will it take you?" Dev: "Oh that's, easy, I can finish it tomorrow." PM: "Tomorrow??? That's impossible, because it needs a and b, no?" Dev: "Yes you are right... I can probably finish it by next week." PM: "Next week??? That is a long time! It's only a, b, c and d that needs to be done. Does it all take that long?" Dev: "You are right, I can probably finish it sooner. I can get it ready by this Friday." PM: "That is perfect! The customer wanted to put in production on Monday, so we can now confirm. Thanks!" I overheard that story (open office), and it was a real facepalm moment.

golergka 8y ago
> Does it all take that long? That's just a question. Asking questions is OK. If you have such a high need to please other people and such a low self-confidence that you will change your answer simply if someone asks you twice, that's the problem with you, not them. I say it as someone who have been like that and have changed it through therapy. I was a nervous mess and always thought that people around me don't like me, pressure me and in general was very nervous around any interaction where I and other person have some disagreement. But turns out, firmly saying "No" is quite OK, people react well to it, respect you for it and nobody is going to fire you for giving good estimates.
- afarrell 8y ago
  This is the core of my point. Therapy was helpful for me learning it as well.
- biql 8y ago
  This is gold. Besides, if someone doesn't react well to your honest estimates, this is probably a red flag and you're better off letting them find someone else. After all, this is supposed to be in everyone's best interests.
- jshowa3 8y ago
  It actually is a problem with them because when someone asks "Does it really take that long?", they're implying that it shouldn't. Of course, in reality, they have no idea either and if they're asking you how long it should take, they should accept your answer, not try to weasel out less time. But are they ever going to admit that they have no idea and accept your estimate on face without playing BS mind games? Probably not. But for some reason that doesn't stop them from trying. I've never seen someone try and do this with a home contractor.
  - afarrell 8y ago
    It can also be that they flubbed at communicating and meant to ask, “what are the things that make it take that long?” Underlying that question would be, “are we on the same page about the scope of this?”, “Are you making business assumptions that I can actually provide updated information about?”, and “Are you lacking resources/clarity that I can get delivered to you?”. Thats a charitable interpretation but it’s occasionally the correct one. It might also be that they’re surprised at the complexity and want to know more. For this reason, the important part of an estimate isn’t the number. Its the task-breakdown and the identification of risk.
  - golergka 8y ago
    Explicit is better than implicit. Asking is better than guessing. If you think that someone is implying something, ask them. In most cases, people who ask "Does it really take that long?" are giving you their first emotional reaction and haven't actually thought it through deep enough to decide to manipulate you. They're upset and they want to make sure that they understood you right - which is a thing people often do when they get bad news, and I cannot blame them: if you get upset about something, at least make sure you really should be upset. So, you should react either in a spock-like "stupid rational", giving no thought to what they might be implying whatsoever with a simple "yes", or, even better, in an emotionally-aware rational way: acknowledge their emotions and offer options. There are always options and trade-offs, they just need to be clearly communicated. Not "OK, I'll do it in three days instead of five", but "I'll can do it in three days with prototype quality so we can test it out, but it will be buggy as hell, not fit for production, and you should document it". I've never had a manager who had a problem with that, and I despite how popular horror stories are, I really doubt that there's a lot of them out there. Your manager cares about the product, he's emotionally invested in it and wants everything to go as fast as possible - it's not a bad thing! It's only bad if you view his disappointment as your fault - but it's not. It's just how things are. As a developer, you're often a messenger bringing bad news. There's no way around it, and you have to learn to deliver bad news for people. And separate these bad news from you and your professional self-confidence.
- SkyBelow 8y ago
  >Asking questions is OK. Is it? Questions have built in assumptions and implications. Most questions don't have enough to be of concern, but some questions definitely imply things beyond the question itself. When asked 'Does it all take that long?', many hear an implied 'Make it not take so long.' command. It is not implied all the time, but it is implied often enough. This does not mean someone has low self-confidence or needs therapy.
  - afarrell 8y ago
    If you hear a 'Make it not take so long.' command, thats not an unreasonable interpretation. However, it is also one that should be questioned because it clashes with how software projects work. If you go from "my boss gave me a command" to "I must execute the command and not question it" without exercising independent judgement, then I would assert that you do have low self-confidence. Whether someone needs therapy is a deeper question that we should be hesitant to answer for another person. But therapy was tremendously helpful for me in realising how my personal and professional life were held back by my reluctance to trust my own judgement or endure the discomfort that can come with honest, respectful, collaborative confrontation.
    - afarrell 8y ago
      > reluctance to trust my own judgement I should make explicit: Part of trusting ones own judgement is also being willing to say, “I don’t have enough knowledge/experience to make a trustworthy judgement here.”
analog31 8y ago
And this conversation is happening in a two hour stand up meeting with a dozen people including upper managers.
commandlinefan 8y ago
Remember - the pressure is to get you to work unpaid overtime under the (mistaken) belief that more hours = more software.
- rick22 8y ago
  "We want only people who are passionate and are risk takers"
- bg4 8y ago
  It's about having "passion"!
  - haggy 8y ago
    oh man this hits close to home
- maerF0x0 8y ago
  to avoid downvotes add sources.
  - jnaddef 8y ago
    Can you add sources to justify this statement?
    - maerF0x0 8y ago
      I was trying to say, In my experience controversial comments are better received w/ sources to back the items. At the time I made my comment the Parent comment had a negative score and I was trying to be helpful to commandlinefan .
      - regular_person 8y ago
        Just curious, what sort of source would you expect for that? An article from Manager's Monthly about tips on tricking your employees to do free work?
squarecog 8y ago
Can you explain which part, in your opinion, is facepalm worthy? In your example conversation, the developer starts off by demonstrating that they are not good at thinking through how long things take them, by giving an impossibly optimistic estimate. Even the PM, whose job is not to figure out how to build stuff or how long building stuff takes, knows the estimate is wrong, and pushes back on it, pointing out dependencies the Dev appears to not have considered. The dev comes back with another estimate, also provided on the spot, without actually thinking through all the tasks, problems, and potential ways to streamline / accelerate. The PM, having just had the dev's lack of thorough thinking with regards to complexity estimation amply demonstrated, asks the Dev to think more carefully, a third time. Are we facepalming at the dev who can't be bothered to actually consider what it will take to get the thing done, or the PM who for some reason accepts the 3rd estimate, even though the dev appears to just be randomly generating numbers? Both?
- afarrell 8y ago
  > can't be bothered or who doesn't know that "I'll need some time to get back to you on that" is an acceptable part of their vocabulary.
- flukus 8y ago
  It's this part where the estimate becomes a deadline: > PM: "That is perfect! The customer wanted to put in production on Monday, so we can now confirm. Thanks!" > pointing out dependencies the Dev appears to not have considered. I'm not sure if they're dependencies or other priorities in this case. I've had managers before ask for an estimate and and I've given them one (2 days), then they've assumed that I'm dropping everything I'm in the middle of and told clients it would be done in 2 days. The problem with estimates is that the people asking for them really want promises.
- koonsolo 8y ago
  I'm facepalming at both of them: 1. The PM just wanted it done by Friday, because the customer wanted it by Monday. This was clear at the end of the conversation, not at the beginning. So it just could have been a "Can you get this done by Friday? Because the customer wants to use it on Monday" 2. The developer clearly had no backbone, and was just throwing numbers to see what the project manager would like. 1 day? Too short! 5 days? Too long! 3? Perfect! Estimates might be a guessing game, but not a guessing game on how long the PM thinks it should take. So yeah, facepalm to both of them, and the whole situation. But I must say that they were definitely not incompetent people. The PM was one of the best I worked with, and the dev was a smart passionate coder. It was just that situation that was a bit absurd. Proper way on how to do this: PM: Can you give me a deadline (not estimate!) on when you can finish X? The customer needs this ASAP, so it has priority over your other tasks. DEV: Let me look into it and I'll let you know in half an hour. (Works out estimate, possibly asking input, adds a buffer because deadline != estimate, looks into his own schedule of meetings etc). DEV: I can get it ready by Tuesday. PM: I'll notify the customer.
slavik81 8y ago
> That is perfect! The customer wanted to put in production on Monday, so we can now confirm. Here you can see the exact moment when an estimate became a commitment.

golergka 8y ago

> Does it all take that long? That's just a question. Asking questions is OK. If you have such a high need to please other people and such a low self-confidence that you will change your answer simply if someone asks you twice, that's the problem with you, not them. I say it as someone who have been like that and have changed it through therapy. I was a nervous mess and always thought that people around me don't like me, pressure me and in general was very nervous around any interaction where I and other person have some disagreement. But turns out, firmly saying "No" is quite OK, people react well to it, respect you for it and nobody is going to fire you for giving good estimates.

afarrell 8y ago
This is the core of my point. Therapy was helpful for me learning it as well.
biql 8y ago
This is gold. Besides, if someone doesn't react well to your honest estimates, this is probably a red flag and you're better off letting them find someone else. After all, this is supposed to be in everyone's best interests.
jshowa3 8y ago
It actually is a problem with them because when someone asks "Does it really take that long?", they're implying that it shouldn't. Of course, in reality, they have no idea either and if they're asking you how long it should take, they should accept your answer, not try to weasel out less time. But are they ever going to admit that they have no idea and accept your estimate on face without playing BS mind games? Probably not. But for some reason that doesn't stop them from trying. I've never seen someone try and do this with a home contractor.
- afarrell 8y ago
  It can also be that they flubbed at communicating and meant to ask, “what are the things that make it take that long?” Underlying that question would be, “are we on the same page about the scope of this?”, “Are you making business assumptions that I can actually provide updated information about?”, and “Are you lacking resources/clarity that I can get delivered to you?”. Thats a charitable interpretation but it’s occasionally the correct one. It might also be that they’re surprised at the complexity and want to know more. For this reason, the important part of an estimate isn’t the number. Its the task-breakdown and the identification of risk.
- golergka 8y ago
  Explicit is better than implicit. Asking is better than guessing. If you think that someone is implying something, ask them. In most cases, people who ask "Does it really take that long?" are giving you their first emotional reaction and haven't actually thought it through deep enough to decide to manipulate you. They're upset and they want to make sure that they understood you right - which is a thing people often do when they get bad news, and I cannot blame them: if you get upset about something, at least make sure you really should be upset. So, you should react either in a spock-like "stupid rational", giving no thought to what they might be implying whatsoever with a simple "yes", or, even better, in an emotionally-aware rational way: acknowledge their emotions and offer options. There are always options and trade-offs, they just need to be clearly communicated. Not "OK, I'll do it in three days instead of five", but "I'll can do it in three days with prototype quality so we can test it out, but it will be buggy as hell, not fit for production, and you should document it". I've never had a manager who had a problem with that, and I despite how popular horror stories are, I really doubt that there's a lot of them out there. Your manager cares about the product, he's emotionally invested in it and wants everything to go as fast as possible - it's not a bad thing! It's only bad if you view his disappointment as your fault - but it's not. It's just how things are. As a developer, you're often a messenger bringing bad news. There's no way around it, and you have to learn to deliver bad news for people. And separate these bad news from you and your professional self-confidence.
SkyBelow 8y ago
>Asking questions is OK. Is it? Questions have built in assumptions and implications. Most questions don't have enough to be of concern, but some questions definitely imply things beyond the question itself. When asked 'Does it all take that long?', many hear an implied 'Make it not take so long.' command. It is not implied all the time, but it is implied often enough. This does not mean someone has low self-confidence or needs therapy.
- afarrell 8y ago
  If you hear a 'Make it not take so long.' command, thats not an unreasonable interpretation. However, it is also one that should be questioned because it clashes with how software projects work. If you go from "my boss gave me a command" to "I must execute the command and not question it" without exercising independent judgement, then I would assert that you do have low self-confidence. Whether someone needs therapy is a deeper question that we should be hesitant to answer for another person. But therapy was tremendously helpful for me in realising how my personal and professional life were held back by my reluctance to trust my own judgement or endure the discomfort that can come with honest, respectful, collaborative confrontation.
  - afarrell 8y ago
    > reluctance to trust my own judgement I should make explicit: Part of trusting ones own judgement is also being willing to say, “I don’t have enough knowledge/experience to make a trustworthy judgement here.”

analog31 8y ago

And this conversation is happening in a two hour stand up meeting with a dozen people including upper managers.

commandlinefan 8y ago

Remember - the pressure is to get you to work unpaid overtime under the (mistaken) belief that more hours = more software.

rick22 8y ago
"We want only people who are passionate and are risk takers"
bg4 8y ago
It's about having "passion"!
- haggy 8y ago
  oh man this hits close to home
maerF0x0 8y ago
to avoid downvotes add sources.
- jnaddef 8y ago
  Can you add sources to justify this statement?
  - maerF0x0 8y ago
    I was trying to say, In my experience controversial comments are better received w/ sources to back the items. At the time I made my comment the Parent comment had a negative score and I was trying to be helpful to commandlinefan .
    - regular_person 8y ago
      Just curious, what sort of source would you expect for that? An article from Manager's Monthly about tips on tricking your employees to do free work?

squarecog 8y ago

Can you explain which part, in your opinion, is facepalm worthy? In your example conversation, the developer starts off by demonstrating that they are not good at thinking through how long things take them, by giving an impossibly optimistic estimate. Even the PM, whose job is not to figure out how to build stuff or how long building stuff takes, knows the estimate is wrong, and pushes back on it, pointing out dependencies the Dev appears to not have considered. The dev comes back with another estimate, also provided on the spot, without actually thinking through all the tasks, problems, and potential ways to streamline / accelerate. The PM, having just had the dev's lack of thorough thinking with regards to complexity estimation amply demonstrated, asks the Dev to think more carefully, a third time. Are we facepalming at the dev who can't be bothered to actually consider what it will take to get the thing done, or the PM who for some reason accepts the 3rd estimate, even though the dev appears to just be randomly generating numbers? Both?

afarrell 8y ago
> can't be bothered or who doesn't know that "I'll need some time to get back to you on that" is an acceptable part of their vocabulary.
flukus 8y ago
It's this part where the estimate becomes a deadline: > PM: "That is perfect! The customer wanted to put in production on Monday, so we can now confirm. Thanks!" > pointing out dependencies the Dev appears to not have considered. I'm not sure if they're dependencies or other priorities in this case. I've had managers before ask for an estimate and and I've given them one (2 days), then they've assumed that I'm dropping everything I'm in the middle of and told clients it would be done in 2 days. The problem with estimates is that the people asking for them really want promises.
koonsolo 8y ago
I'm facepalming at both of them: 1. The PM just wanted it done by Friday, because the customer wanted it by Monday. This was clear at the end of the conversation, not at the beginning. So it just could have been a "Can you get this done by Friday? Because the customer wants to use it on Monday" 2. The developer clearly had no backbone, and was just throwing numbers to see what the project manager would like. 1 day? Too short! 5 days? Too long! 3? Perfect! Estimates might be a guessing game, but not a guessing game on how long the PM thinks it should take. So yeah, facepalm to both of them, and the whole situation. But I must say that they were definitely not incompetent people. The PM was one of the best I worked with, and the dev was a smart passionate coder. It was just that situation that was a bit absurd. Proper way on how to do this: PM: Can you give me a deadline (not estimate!) on when you can finish X? The customer needs this ASAP, so it has priority over your other tasks. DEV: Let me look into it and I'll let you know in half an hour. (Works out estimate, possibly asking input, adds a buffer because deadline != estimate, looks into his own schedule of meetings etc). DEV: I can get it ready by Tuesday. PM: I'll notify the customer.

slavik81 8y ago

> That is perfect! The customer wanted to put in production on Monday, so we can now confirm. Here you can see the exact moment when an estimate became a commitment.