7 ms·

I got a harsh lesson about this in one of my very first jobs. A senior engineer on my team had built a rather complicated system. He was accordingly intimately

by Kalium 5y ago

I got a harsh lesson about this in one of my very first jobs. A senior engineer on my team had built a rather complicated system. He was accordingly intimately familiar with all aspects of it. So when he estimated something on that system, it came with nearly all the discovery work already done. The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me.

onion2k 5y ago
The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me. This is a really good thing to learn from, although I doubt it felt like it at the time. The key thing that every junior dev needs to take from it is that it's fine if things don't take however long the estimate is so long as you're regularly communicating with the PM. PMs hate surprises. They need to know exactly what the state of the project is at any given moment. For them to think that a story is progressing on track when it's not is very, very bad (in their minds; it doesn't actually matter most of the time.) If you work on a story that's estimated to take 3 days and come back after 3 days saying "It's not done yet. I'm only half way through. I had to learn a ton of stuff!" then that knocks out loads of other things, and people get pissed off. If you work on a story that's estimated to take 3 days, and in the stand up on day 2 you say "I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days" then your PM will (...should?) respect that you're keeping them informed. The senior might even step up to help you get there faster. Practically all the actual work a PM does is communication. If you're not communicating with them then you're blocking them. No one likes that.
- lifeisstillgood 5y ago
  >>> Practically all the actual work a PM does is communication. Practically all the actual work a PM does can be replaced with a script and dashboard
  - onion2k 5y ago
    Practically all the actual work a PM does can be replaced with a script and dashboard That is entirely true if you have an organised, disciplined dev team that communicates well. Good luck with that.
    - kayodelycaon 5y ago
      This isn't true even with a organized, disciplined team. What happens is the responsibilities of get divided out to other people on the team. Usually not the entire team, so some people are stuck with unacknowledged overhead.
      - nzmsv 5y ago
        Unacknowledged overhead happens even with a PM present. Usually it's work that is absolutely critical to getting a project done but a PM would tell you it's a waste of time if you brought it up with them.
        lifeisstillgood 5y ago
        Thank you. Another vital point - trying to tell people the real critical path is over there but no-one agreed it in the plan is .. ahh well
  - subsubzero 5y ago
    For small tasks, yes this works. For larger feature work that involves cross-team collaboration, including legal, security etc, a pm is a godsend.
    - lifeisstillgood 5y ago
      meh. The problem is authority. PM / manager as described above is a co-ordination issue. Often administrative as well. Either the company is imposing administrative burden a that it can remove with a little effort and scripting, or again it is co-ordination - which software usually excels at. We can endlessly debate specifics but yes, there are many corporate environments that are almost impossible to navigate without full-time skilled administration - it that is a choice by the company not an inherent law of nature. I seem to recall a Microsoft anecdote where someone released an internal form for developers to fill out, and billg personally sent round collecting the form telling people that sort of thing was not the Microsoft way. Far be MSFT from an ideal but bureaucracy is a choice. Edit: my take on hierarchy and decision making is that it is clearly "obvious" that in war and times of stress there is only enough time for one person, the "hero", to review the battlefield and make decisions, which everyone else then follows. The problem with that is throughout human history that idea has literally had no better than 50/50 chance of succeeding. I am very much short on Project management, administrative management as authority and generally anything that points away from democracy.
- BobbyJo 5y ago
  > I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days Their first question after you say this will be "well, how long will it take?" Whether or not you actually have any idea how much time you'll need, you'll have to give an answer, and on that blows the schedule up too much will be strongly frowned upon. Now you've realized you're working for a crappy PM/EM who wants you to do their job for them, since they should have already known that the estimate from the first engineer will be nowhere close to the reality from the second. The best managers I've had have been the ones that rarely need time estimates. They know enough about what's going on, and the comparative skill levels of the engineers, to give reasonable estimates themselves in most cases.
  - ebiester 5y ago
    That is a function of time in company and continuity of team more than skill of manager.
    - BobbyJo 5y ago
      I disagree. I think skill of manager plays into it more than anything. I've seen managers come on board and within 3-6 months were able to operate like this. They focused on learning the technology and getting to know the people before they started actively managing. These were large, long running teams they were joining too.
      - mcspiff 5y ago
        Yup, definitely agree with this. I’ve noticed these are the managers that “feel like they’ve always been there”.
      - pojzon 5y ago
        I can double tap on that. Good manager is able to understand the product and estimate by himself. Ive had quite a bit of experience working with different managers and overall those who were „invested” and got familiar with the product „really well” could estimate for the team.
radicalbyte 5y ago
That engineer is Senior in title only. Unfortunately this is a common pattern - a mid-level developer will play "hero", make a mess that only they understand, and - if given the title/responsibility by immature management - proceed to royally screw their team. Actual Seniors have the experience and foresight to handle this properly. Either build code with enough documentation/tests that others can understand it, or make an onboarding/mentoring plan for team mates, or estimate based on a teammate doing the work. In this position: the engineering manager should remove the fake Senior from the team, that will force them to get up to speed.
- blindmute 5y ago
  The management graciously allocated all the time that the senior needed for all this documentation and onboard plan, then everyone in the company clapped
- nzmsv 5y ago
  Up to speed on their way out the door if they have any self esteem at all.
astura 5y ago
This is just extremely (almost comically) bad project management - nobody should take a senior engineer's estimate and apply it to a new hire or jr engineer. I've never been a PM but from my planning discussions with mine all have adjusted for seniorness, familiarity with the codebase, and skillset. When I give an estimate I am only asked to give it for myself, it's the PMs job to adjust. I guess I've been lucky because I've never had a PM that did that poor of a job. Maybe because it's because I've almost exclusively worked at companies that provide work to a paying customer, because that environment really depends on good project management.
siva7 5y ago
I think most of us have been in your situation in the early days of our career. I still remember these PMs after all those years as rather inexperienced or incompetent and try to make sure that it does not happen on the teams i oversee.
jseban 5y ago
Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this. When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a programmer is productive from day zero and all programmers have exactly the same output. It's so wrong
- markus_zhang 5y ago
  I think it depends on the culture of the company. Some companies do allow engineers say a month to catch up.
- wyclif 5y ago
  Any tech recruiter who tells you there should be no ramp-up for programmers is lying, and you should be accordingly wary if they use a lot of "hit the ground running" talk. Fact is, nobody does that. In some jobs it might take as long as six months for programmers to reach the desired level of productivity.
- hyperman1 5y ago
  I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.
  - rramadass 5y ago
    >I think they underestimate the value of specific knowledge This is the crux of the issue. When it comes to "Knowledge Work" almost every step sooner or later becomes a specialization. For example, I used to sneer at the role of a "Build Engineer" until i was forced to take up that role in one project. The combination of HW Platforms, OS versions, config switches, build flags, magic incantations etc. quickly gave me a new found respect for a job which i had considered "trivial".

by Kalium 5y ago

onion2k 5y ago

The PM proceeded to take an estimate from this person, hand it to a brand new hire, and expect them to deliver on that. Needless to say it could have gone better for me. This is a really good thing to learn from, although I doubt it felt like it at the time. The key thing that every junior dev needs to take from it is that it's fine if things don't take however long the estimate is so long as you're regularly communicating with the PM. PMs hate surprises. They need to know exactly what the state of the project is at any given moment. For them to think that a story is progressing on track when it's not is very, very bad (in their minds; it doesn't actually matter most of the time.) If you work on a story that's estimated to take 3 days and come back after 3 days saying "It's not done yet. I'm only half way through. I had to learn a ton of stuff!" then that knocks out loads of other things, and people get pissed off. If you work on a story that's estimated to take 3 days, and in the stand up on day 2 you say "I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days" then your PM will (...should?) respect that you're keeping them informed. The senior might even step up to help you get there faster. Practically all the actual work a PM does is communication. If you're not communicating with them then you're blocking them. No one likes that.

lifeisstillgood 5y ago
>>> Practically all the actual work a PM does is communication. Practically all the actual work a PM does can be replaced with a script and dashboard
- onion2k 5y ago
  Practically all the actual work a PM does can be replaced with a script and dashboard That is entirely true if you have an organised, disciplined dev team that communicates well. Good luck with that.
  - kayodelycaon 5y ago
    This isn't true even with a organized, disciplined team. What happens is the responsibilities of get divided out to other people on the team. Usually not the entire team, so some people are stuck with unacknowledged overhead.
    - nzmsv 5y ago
      Unacknowledged overhead happens even with a PM present. Usually it's work that is absolutely critical to getting a project done but a PM would tell you it's a waste of time if you brought it up with them.
      - lifeisstillgood 5y ago
        Thank you. Another vital point - trying to tell people the real critical path is over there but no-one agreed it in the plan is .. ahh well
- subsubzero 5y ago
  For small tasks, yes this works. For larger feature work that involves cross-team collaboration, including legal, security etc, a pm is a godsend.
  - lifeisstillgood 5y ago
    meh. The problem is authority. PM / manager as described above is a co-ordination issue. Often administrative as well. Either the company is imposing administrative burden a that it can remove with a little effort and scripting, or again it is co-ordination - which software usually excels at. We can endlessly debate specifics but yes, there are many corporate environments that are almost impossible to navigate without full-time skilled administration - it that is a choice by the company not an inherent law of nature. I seem to recall a Microsoft anecdote where someone released an internal form for developers to fill out, and billg personally sent round collecting the form telling people that sort of thing was not the Microsoft way. Far be MSFT from an ideal but bureaucracy is a choice. Edit: my take on hierarchy and decision making is that it is clearly "obvious" that in war and times of stress there is only enough time for one person, the "hero", to review the battlefield and make decisions, which everyone else then follows. The problem with that is throughout human history that idea has literally had no better than 50/50 chance of succeeding. I am very much short on Project management, administrative management as authority and generally anything that points away from democracy.
BobbyJo 5y ago
> I think I'm going quite slowly because I'm having to learn a lot, and I don't think I'll deliver this in 3 days Their first question after you say this will be "well, how long will it take?" Whether or not you actually have any idea how much time you'll need, you'll have to give an answer, and on that blows the schedule up too much will be strongly frowned upon. Now you've realized you're working for a crappy PM/EM who wants you to do their job for them, since they should have already known that the estimate from the first engineer will be nowhere close to the reality from the second. The best managers I've had have been the ones that rarely need time estimates. They know enough about what's going on, and the comparative skill levels of the engineers, to give reasonable estimates themselves in most cases.
- ebiester 5y ago
  That is a function of time in company and continuity of team more than skill of manager.
  - BobbyJo 5y ago
    I disagree. I think skill of manager plays into it more than anything. I've seen managers come on board and within 3-6 months were able to operate like this. They focused on learning the technology and getting to know the people before they started actively managing. These were large, long running teams they were joining too.
    - mcspiff 5y ago
      Yup, definitely agree with this. I’ve noticed these are the managers that “feel like they’ve always been there”.
    - pojzon 5y ago
      I can double tap on that. Good manager is able to understand the product and estimate by himself. Ive had quite a bit of experience working with different managers and overall those who were „invested” and got familiar with the product „really well” could estimate for the team.

radicalbyte 5y ago

That engineer is Senior in title only. Unfortunately this is a common pattern - a mid-level developer will play "hero", make a mess that only they understand, and - if given the title/responsibility by immature management - proceed to royally screw their team. Actual Seniors have the experience and foresight to handle this properly. Either build code with enough documentation/tests that others can understand it, or make an onboarding/mentoring plan for team mates, or estimate based on a teammate doing the work. In this position: the engineering manager should remove the fake Senior from the team, that will force them to get up to speed.

blindmute 5y ago
The management graciously allocated all the time that the senior needed for all this documentation and onboard plan, then everyone in the company clapped
nzmsv 5y ago
Up to speed on their way out the door if they have any self esteem at all.

astura 5y ago

This is just extremely (almost comically) bad project management - nobody should take a senior engineer's estimate and apply it to a new hire or jr engineer. I've never been a PM but from my planning discussions with mine all have adjusted for seniorness, familiarity with the codebase, and skillset. When I give an estimate I am only asked to give it for myself, it's the PMs job to adjust. I guess I've been lucky because I've never had a PM that did that poor of a job. Maybe because it's because I've almost exclusively worked at companies that provide work to a paying customer, because that environment really depends on good project management.

siva7 5y ago

I think most of us have been in your situation in the early days of our career. I still remember these PMs after all those years as rather inexperienced or incompetent and try to make sure that it does not happen on the teams i oversee.

jseban 5y ago

Yeah why do people have this view on programmers I just don't understand, every other single effing job in the world requires training and ramp-up, except programmers? And the fact that programming is depending on a unique pre-existing really complex code base further speaks against this. When my product owner quit, the new guy was working in parallel for 2 months to learn the ropes, noboby bats an eye, but a programmer is productive from day zero and all programmers have exactly the same output. It's so wrong

markus_zhang 5y ago
I think it depends on the culture of the company. Some companies do allow engineers say a month to catch up.
wyclif 5y ago
Any tech recruiter who tells you there should be no ramp-up for programmers is lying, and you should be accordingly wary if they use a lot of "hit the ground running" talk. Fact is, nobody does that. In some jobs it might take as long as six months for programmers to reach the desired level of productivity.
hyperman1 5y ago
I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.
- rramadass 5y ago
  >I think they underestimate the value of specific knowledge This is the crux of the issue. When it comes to "Knowledge Work" almost every step sooner or later becomes a specialization. For example, I used to sneer at the role of a "Build Engineer" until i was forced to take up that role in one project. The combination of HW Platforms, OS versions, config switches, build flags, magic incantations etc. quickly gave me a new found respect for a job which i had considered "trivial".