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…
Ways to annoy your senior engineer
41–50 of 91 posts
Re: Ways to annoy your senior engineer
#42The 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…
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> [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…
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
#44I 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…
https://en.wikipedia.org/wiki/Flip_Decision
Didn't end too well for Donald and the boys.
Re: Ways to annoy your senior engineer
#45The 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…
Re: Ways to annoy your senior engineer
#46This 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 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
#47All 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…
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
#48Earlier 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
Re: Ways to annoy your senior engineer
#49I'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.
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
#50Earlier 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
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.