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