Little Tasks, Little Trust • Hacker News Board

Re: Little Tasks, Little Trust

#81

Post by emeraldd » Wed, Dec 09, 2020, 2:52 PM UTC

vosper wrote: post #62

cbanek wrote: post #59

One thing I think missed in this is talking about one of the reasons to break things down into the smallest portion - it's not only the metrics, but it's to make everyone look the same to management. Each person can take any of the work, in theory. In practice, this never happens. You'd rather wait for the expert to do the work, because it will take them less time and probably produce better quality. Good people beco…

> Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work. If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come t…

Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and everyone knows "oh it's just doing that ...". Anytime you move into creating something new, you're basically hosed. Especially if you have heterogeneous work streams in the same sprint. That just any hope of planning things that much harder.

Re: Little Tasks, Little Trust

#82

Post by dragonwriter » Wed, Dec 09, 2020, 3:06 PM UTC

emeraldd wrote: post #81

vosper wrote: post #62

Earlier quoted context omitted.

> Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work. If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come t…

Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and everyone knows "oh it's just doing that ...". Anytime you move into creating something new, you're basically hosed. Especially if you have heterogeneous work streams in the same sprint. That just any hope of planning things that much harder.

> Honestly, I've never found story pointing exercises to result in anything resembling reality.

IIRC, story points are a replacement for detailed hour estimates that were created specifically because of research dating back through the 1940s shows clearly that estimates of original intellectual work of any detail are essentially impossible; story points are literally throwing in the towel on that issue and wasting less time chasing something you aren't going to get. With tracking of velocity and history you get better numbers with story points than when people try to estimate in hours, because people are better at rough relative size estimates than detailed estimates, but that's a marginal improvement. The big win is you spend less time chasing false precision with them.

Re: Little Tasks, Little Trust

#83

Post by hda111 » Wed, Dec 09, 2020, 4:14 PM UTC

specialist wrote: post #79

superbaconman wrote: post #9

I had a project assigned that I was completely responsible for, except that every technical and architectural decision was made for me. As I became more familiar with the project I raise concerns about these choices as they introduced maintainability and performance issues, but was overruled and told to stay the course. The project was a failure. I feel like if you're not coding a project, your opinion on it is less…

All of the responsibility without any of the authority.

Every infosec role ever. Glad I’m just a developer.

Re: Little Tasks, Little Trust

#84

Post by emeraldd » Wed, Dec 09, 2020, 4:31 PM UTC

dragonwriter wrote: post #82

emeraldd wrote: post #81

Earlier quoted context omitted.

Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and everyone knows "oh it's just doing that ...". Anytime you move into creating something new, you're basically hosed. Especially if you have heterogeneous work streams in the same sprint. That just any hope of planning things that much harder.

> Honestly, I've never found story pointing exercises to result in anything resembling reality. IIRC, story points are a replacement for detailed hour estimates that were created specifically because of research dating back through the 1940s shows clearly that estimates of original intellectual work of any detail are essentially impossible; story points are literally throwing in the towel on that issue and wasting le…

That's reasonable ... The times I've worked with hour based estimates, we were assigning tickets to people up front and there always had to be a bit of a scaling factor based on who was doing the work. (mostly relative to their skill level and how familiar they were with a particular piece of code). There are at least a couple of no-nos for scrum style processes in there. Still, I find it more useful to look at the number of tickets and what's actually being done in them and ignore the point/hour values when trying to come up with what's a good break down of work for a sprint. The point values are just too opaque to convey anything that can be substantively predictive. (At least for me..)

Re: Little Tasks, Little Trust

#85

Post by lliamander » Wed, Dec 09, 2020, 6:36 PM UTC

monkeybutton wrote: post #18

vorpalhex wrote: post #11

Earlier quoted context omitted.

Delegating and trusting someone doesn't mean a task never goes badly. Part of delegation is meeting and touching base with work that is ongoing. Participate in code reviews, have regular 1:1s with people you are delegating to. And yes, you're not going to end up with your exact vision when you delegate. The question is whether the end goal is sufficient and minimal, and if not then you should evolve that with the oth…

Absolutely delegation should still mean being involved in the process and being receptive to course correction from the people carrying out the work. This is how things should work. Ideally. In practice I've seen it go the opposite way where management's reaction is trust less and less, making smaller and smaller tasks. Developers aren't innocent either, instead of griping about having less control, they throw up the…

> Maybe it's high time to leave where I am seeing this all go on.

From my own experience, I would say yes.

Re: Little Tasks, Little Trust

#86

Post by valiantlord » Wed, Dec 09, 2020, 7:00 PM UTC

Though the Little Tasks Model is very good for beginners joining the software development industry (as they can quickly come up to speed under this model), this is an absolutely terrible model for senior developers, as this model by itself limits freedom, growth and career progression as it is difficult for senior developers to prove their worth when they are only given Little tasks perpetually.

Re: Little Tasks, Little Trust

#87

Post by dang » Wed, Dec 09, 2020, 7:42 PM UTC

throwingaway0 wrote: post #80

fogetti wrote: post #69

Earlier quoted context omitted.

If you are a technical lead as you claim and that's your reaction to developers' need for responsibility it tells a lot about you. You seem like a control freak and a person who quickly puts down anyone without even considering new thoughts and opposing perspectives. Which can be completely hold against anyone who works as a consultant, because that's a red flag that the person is not cooperative enough. Please post…

Hi [redacted] (fogetti), It’s humorous that I came across your post calling someone a "control freak" and to expose themselves on HN so you can avoid working with them. Last I remember you got fired from our company within a year. The reason was mostly for bad mouthing every single engineer as well as the CEO behind their backs and sometimes even to their faces when you were in a managerial role. You constantly power…

Personal attacks like this are not allowed on HN. Regardless of how badly someone has behaved or you feel that they have, it's not what this site is for. Perhaps you don't owe the other person better, but you owe this community better if you're posting to it, so please don't create accounts to break the site guidelines.

https://news.ycombinator.com/newsguidelines.html

I've banned this account and redacted a name from the post.

Re: Little Tasks, Little Trust

#88

Post by dang » Wed, Dec 09, 2020, 7:46 PM UTC

fogetti wrote: post #69

olsonjeffery wrote: post #20

This essay is full of awful advice and is more about the author venting that their work isn't organized how they like. I would recommend they found a startup and experiment with the kind of structure they think would work best and see how it scales! >No backlog grooming meetings or burn-down charts either. Your manager simply looked at how your products were coming along. A little trust, some accountability, and a he…

If you are a technical lead as you claim and that's your reaction to developers' need for responsibility it tells a lot about you. You seem like a control freak and a person who quickly puts down anyone without even considering new thoughts and opposing perspectives. Which can be completely hold against anyone who works as a consultant, because that's a red flag that the person is not cooperative enough. Please post…

Personal attacks aren't allowed on HN and we ban accounts that post like this. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and using HN in the intended spirit? We'd appreciate it.

Re: Little Tasks, Little Trust

#89

Post by eropple » Thu, Dec 10, 2020, 3:33 PM UTC

lliamander wrote: post #68

eropple wrote: post #60

Earlier quoted context omitted.

> Estimates also need to capture the level of uncertainty. As a junior developer, I was asked to provide LOEs for tickets and tasks. I just looked at my boss. "How should I know?" "Come up with your best answer." So I did. I gave him my best guess, plus some error bars. The error bars were promptly discarded. And while when I went over estimates I didn't feel bad , there was obviously some static there from my boss w…

A manager who cannot deal in error bars is not doing their job correctly, although I would also point out that it is important to re-estimate and update your boss as soon as you think you will miss the estimate (which you may have done). In my previous environment, we were only allowed to give estimates in terms of a range of time. We had a series of predefined "buckets" of time ranges (e.g. less than a day, 1-2 days…

I mean, I was a junior engineer. I didn't know when I was gonna miss the estimate, when you're heads-down like that you don't know if you're 25% in or 80% in until you've gotten a lot more experience. Hence the error bars in the first place. ;)

Re: Little Tasks, Little Trust

#90

Post by curryst » Thu, Dec 10, 2020, 8:57 PM UTC

emeraldd wrote: post #81

vosper wrote: post #62

Earlier quoted context omitted.

> Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work. If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come t…

Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and everyone knows "oh it's just doing that ...". Anytime you move into creating something new, you're basically hosed. Especially if you have heterogeneous work streams in the same sprint. That just any hope of planning things that much harder.

> Honestly, I've never found story pointing exercises to result in anything resembling reality.

I've never found story pointing exercises to provide anything meaningful. Goodhart's law in action; you either ignore the story points, making them useless, or you use them to estimate productivity, causing people to game them.

I understand that gauging velocity and individual contributions is important, I just think story points or work estimates are a bad way to do it in the context of sprints. An individual task, or even a sprint, is too micro to get any decent measure out of. I much more strongly prefer evaluations based on longer milestones (monthly or quarterly). Someone being low on story points for a sprint means nothing without a lot of context on why. Someone missing a milestone on a month or quarter long project is much more indicative of a problem, because they've had enough time to ask for help, or to smooth out bursty progress.