There's an old saying that you can tell developer maturity by the units of time they use for estimating code.
Only brand-new developers (and Sith?) estimate things in hours. Experienced devs estimate in days, but senior developers won't give you a number in increments smaller than weeks.
Also, any manager who trusts an estimate from a new employee or especially a new developer is an ass. They should have known better, and giving you grief about it is just doubling down on a category error. We've all had that experience, but I'd like it if we all learned to reframe such experiences as abusive. Especially if you're going to be in a position to repeat those sorts of experiences on a new generation. Break the cycle of stupid.
In most of these cases, I actually suspect malice over ignorance. They figure they can squeeze some unpaid overtime out of an unsuspecting junior by pressuring them to "commit" to an unreasonable deadline and then trying to hold them to it.
I had a shocking realization one day that the incompetent PO I was dealing with had not bumbled his way into that position but been placed there on purpose by his manager.
There are certain brands of incompetence that get results, and you don't have to be the one that is aware of that fact to reap the rewards of manipulating people in that way.
Only brand-new developers (and Sith?) estimate things in hours. Experienced devs estimate in days, but senior developers won't give you a number in increments smaller than weeks
That just reflects the size and complexity of stories they're asked to estimate.
I think it has a lot more to do with how far away from academia they are. I side job as an external examination for CS students, and the way they are taught to do estimates are some of the most useless ways imaginable.
Have you ever actually seen something like a planning poker session in action amongst only juniors? I have, and while this is very anecdotal, it has always played out like this: the most confident programmer in the group grossly underestimated the task. Often this person has a valid reason to be confident, but because of this, their opinion also weighs much more heavily in the group, so that even if someone throws the 100 card, the task will still end up with a 2.
The longer you work in the real world, the more you realise that estimates aren’t a showcase of you. They are timeline project managers need to implement projects, and if you fail to give a realistic estimate then you fuck with that timeline which is often the worst thing you can possibly do as a software developer.
Even if you “know” how to implement a really simple task, you simply need to make sure there is room for a days worth of searching for something really stupid, and you’re never going to be asked to estimate something really simple. Not as a junior, not as an experienced developer and not as a senior.
I do understand why students are taught to estimate wrongly though. Their projects aren’t very long. But I personally think we are doing them a huge disfavour by making them estimate in hours. Because why wouldn’t they expect that to be the norm if that’s what they’ve learned to do?
> That just reflects the size and complexity of stories they're asked to estimate.
In any reasonably complex application even the smallest task will likely not be available to anyone in under a week anyway. Need to change a button? Sure, that's an hour or two to change it and ensure it didn't break some other scenario. Maybe that takes another day or so to verify with team X or dev Y in a PR. Wait for tests and processing for release to QA environment. Maybe another roundtrip if something is found, at which point you might be working on another button. Then it sits for a while until it can catch a production push.
I'm also assuming that the senior dev is working in a fairly large machine. If it's a startup then sure, anything goes depending on what shortcuts are in place.
Only brand-new developers (and Sith?) estimate things in hours. Experienced devs estimate in days, but senior developers won't give you a number in increments smaller than weeks.
Also, any manager who trusts an estimate from a new employee or especially a new developer is an ass. They should have known better, and giving you grief about it is just doubling down on a category error. We've all had that experience, but I'd like it if we all learned to reframe such experiences as abusive. Especially if you're going to be in a position to repeat those sorts of experiences on a new generation. Break the cycle of stupid.