Live data from Hacker News

Ways to annoy your senior engineer

thecaringtechie.com

41–50 of 91 posts

Re: Ways to annoy your senior engineer

#41
post #27

All of these are familiar, unfortunately. Just one nitpick: > Proper estimations take time. IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion. Software development is inherently chaotic. Every task is different from another, and d…

As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years. Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in…

Why not then be honest about what kind of estimate is being made? How about saying "Can you give me ballpark estimates? On the order of days, weeks, months, years?" Then everyone knows it is a rough estimate and no one is forced to make impossible promises and trying to do the dumb "what I think multiply by 3" or whatever stuff goes on. Framed as ballpark or "rough" there's a clearer sense of shared ambiguity

Re: Ways to annoy your senior engineer

#42

The only correct estimation is actually doing the work and looking at how long it took. The closest to that is half-assing the task at hand and multiplying the time it took by ten. For prototype to actual application, you multiply it by a hundred. This also applies for the prototypes of the prototypes (100x for the actual prototype, then 100x of that for the proper implementation), and yes, those exist, but they are…

> The only correct estimation is actually doing the work and looking at how long it took.

You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely.

If you ask a civil engineer to estimate the cost and timeline of building a bridge, they'll get you an estimate. It'll likely be within 1-2 orders of magnitude of the actual cost/time, due to a bunch of unknown-unknowns that are hard to factor in (things like: how long the legislature will take to permit the build). But it'll still give you useful data about the differences between building a $million foot bridge, and a $100 billion highway bridge...

Re: Ways to annoy your senior engineer

#43
post #24

> [Senior engineers] keep things running, ensure projects get delivered, and prevent your codebase from turning into spaghetti. The good ones? They’re rare and highly sought after. I didn’t see much of the ”highly sought after” bit in the recent years. On the contrary, the job market looks employer-friendly and the strategies for recruiting senior engineers seem increasingly backwards. Or is it expected that good sen…

> Or is it expected that good senior engineers skip recruiting and rely on networking alone?

Pretty much, yeah. I don't know anyone at a senior-or-above level who spends much effort sending resumes through the front door.

Re: Ways to annoy your senior engineer

#44
post #30

I fixed giving “napkin” or “rough estimate” times out. I roll a D6 for number of people, D12 for number of months, D20 for the day we will go to production ( not allowed to do installation during end of month). D% is used to say how accurate the estimate is. With the requester there, I pull them out, roll them, give the estimate. I did have a VP in a meeting go “I don’t like that estimate.” I pushed the dice over and…

I like your style https://en.wikipedia.org/wiki/The_Dice_Man >The Dice Man is a 1971 novel by American novelist George Cockcroft, writing under the pen name "Luke Rhinehart".[1] The book tells the story of a psychiatrist who makes daily decisions based on the casting of a die.[2] Cockcroft describes the origin of the title idea variously in interviews, once recalling a college "quirk" he and friends used to decide "w…

There's a great Donald Duck comic on making decisions based on a coin flip, written by the legendary Carl Barks:

https://en.wikipedia.org/wiki/Flip_Decision

Didn't end too well for Donald and the boys.

Re: Ways to annoy your senior engineer

#45

The only correct estimation is actually doing the work and looking at how long it took. The closest to that is half-assing the task at hand and multiplying the time it took by ten. For prototype to actual application, you multiply it by a hundred. This also applies for the prototypes of the prototypes (100x for the actual prototype, then 100x of that for the proper implementation), and yes, those exist, but they are…

> The only correct estimation is actually doing the work and looking at how long it took. You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely. If you ask a civil engineer to estimate the cost…

I don't think you are contradicting me, but I'm not really sure.

Re: Ways to annoy your senior engineer

#46
post #2

This is what is going on in the enterprise. I wonder why I mostly see posts from people in this type of environment here on Hacker News. I would love something like Hacker News, but for indie makers, entrepreneurs and bootstrapped startups. Is there something like this?

> This is what is going on in the enterprise

This same shit also goes on at all the 10-person startups formed by former-enterprise folks, which covers a pretty big swathe of hacker news audience

Re: Ways to annoy your senior engineer

#47
post #27

All of these are familiar, unfortunately. Just one nitpick: > Proper estimations take time. IME there's no such thing as "proper" estimations. They're all a wild guess with little basis in reality. Scrum came along to make us pretend that relative estimates ("story points") are somehow more accurate, but they're the same illusion. Software development is inherently chaotic. Every task is different from another, and d…

As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years. Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in…

> You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done."

I see you haven't needed to hire many building contractors. "I won't know until I'm done" wasn't how the engagements started, but it's how they all ended up. When the budget's gone and they're only halfway done what are you gonna do, live with a hole in the wall and no running water? If you got a home renovation done on time or on budget (I refuse to believe both), congrats on catching a unicorn.

Re: Ways to annoy your senior engineer

#48

Earlier quoted context omitted.

As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years. Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in…

Why not then be honest about what kind of estimate is being made? How about saying "Can you give me ballpark estimates? On the order of days, weeks, months, years?" Then everyone knows it is a rough estimate and no one is forced to make impossible promises and trying to do the dumb "what I think multiply by 3" or whatever stuff goes on. Framed as ballpark or "rough" there's a clearer sense of shared ambiguity

I feel like this is the crux of the issue. Dev estimates should be taken with large error bars, and I think the entire problem is caused by people who take them at face value, making developers not want to give estimates at all next time.

Re: Ways to annoy your senior engineer

#49
post #23

I'm the 'pointy-haired' boss and I usually don't take my engineering teams estimates at face value. I've learned to multiply the estimates to know when I can reasonably expect something to be completed. The multiplier is never less than 1.5. And I can see if they are making progress and where they might be hitting difficulties. (Most roadblocks have nothing to do with the tech. It's usually either some organisational…

"Double it and raise it to the next time unit" still works. A 1 hour job will take 2 days. A 1 day job will take 2 weeks. etc.

For me that's only true for projects/fixes with low time unit.

When I say 'it'll take a month', I usually took into account testing and deployment, so it usually take a month (and a week or two because I still overestimate myself).

When I say 'it should take an hour/half a day/a day', yes you are definitely right, and my manager is in trouble.

Re: Ways to annoy your senior engineer

#50
post #32

Earlier quoted context omitted.

When I'm told " I don't like that estimate " I take it as an invitation to negotiate (same as when you don't like a quote from a tradesman) and so counter with " OK, we may be able to shave x off of it if you give us y and z in addition to what we have now or if we cut w out of the scope ".

This turns into nickel and diming, then bike shedding. For me, it's easier not to enter the process

And then a year later I’m the only one who can remember that the reason we are in the middle of a grotesque rewrite is that we got a promise from management that we could treat all X as Y and they didn’t keep their word because that was last year and this is now.

Why can’t you idiots figure out how to code?

I have told a few people that when we substituted their judgment for mine this became their problem. I really think I should have said it more often.

Post reply on HN