3 ms·

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 s

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.

moksly 5y ago
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?
wingerlang 5y ago
> 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.

moksly 5y ago

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?

wingerlang 5y ago

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