Live data from Hacker News

Ways to annoy your senior engineer

thecaringtechie.com

51–60 of 91 posts

Re: Ways to annoy your senior engineer

#51
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…

Your analogy falls flat, because building software is not the same as building a house. In fact, unusual construction projects with unknown dependencies and shifting requirements are just as unplannable as software development, and are just as liable to go over budget.

Re: Ways to annoy your senior engineer

#52

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…

And since everybody knows that this is how management deals with estimates, there is no incentive to improve upon their own.

True. But I'm not measuring their performance relative to their estimates. I'm measuring performance relative to their peers and their previous performance. So giving me a padded estimate won't make much of a difference. Obviously, judgements are deeply subjective, since no two programming tasks are ever identical or even alike, but if you code a lot like, me you have a pretty good idea of what constitutes good.

Re: Ways to annoy your senior engineer

#53
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…

You can tell they aren’t proper because if they were you’d finish half the stories ahead of the estimate and half after.

The moment you get judged on your estimates they lose all value.

Re: Ways to annoy your senior engineer

#54

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…

> 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 d…

Even before I owned a house, I had watched enough This Old House to know how completely out of touch GP’s assertion was.

Re: Ways to annoy your senior engineer

#55
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…

I think you’ve forgotten how this goes already.

“What’s your estimate? No, that won’t work.”

Don’t ever start that bullshit conversation with people. You’ve now signaled that they can’t trust you and now any “information” they give you will now be untrustworthy because you’re untrustworthy and turnabout is fair play.

If you’re trying to control ROI and manpower, you tell us what date ranges work for the org and we figure out what we can fit in that time. And if you don’t get any nice to haves in that initial estimate you might as well pull the plug now because everyone knows that scope will have to be shed to hit the date. And that we try to pretend anything different is happening is part of that illusion of control thing GP mentioned. If we can’t build a thing by whenever then it’s time to rethink the project. A different approach, possibly involving buying part of the solution instead of building the whole thing. Or we do some other project first that will teach us how to do this project better.

Re: Ways to annoy your senior engineer

#56

First reaction: Has this person been my coworker? I feel like someone’s been taking notes on places I’ve worked. Second: But OK, those ones about shifting priorities? That’s startup life. Sometimes you throw something out the door because a customer wants to pay you $12M if you can salve over that one pain point. You know darn well that hack’s going to be there until The Rewrite (which, if you’re lucky, will never co…

I have worked at places that prioritized the wrong customer and ended up with a product that was tuned to work only for the ones who won’t pay more than what we originally offered the product for. Even inflation adjusted I’m sure it was less than $12M. You have to watch what your costs per year end up being for that check you got three years ago. The VCs will notice when they look at your books.

Re: Ways to annoy your senior engineer

#57
post #22

Earlier quoted context omitted.

If you're following the bullshit that is SAFe/"Agile" at a startup, you're going to fail. Capital-A Agile is project management for dummies that won't learn about things like GANTT charts, what "slack" means in links between dependent tasks, what a "critical path" is or how to analyze it, let alone things like S-curves and earned value.

> GANTT charts Can you give me an estimate for these sixteen different things, and also verify which ones depend on each other?

The Gantt is a lie to get the project approved and then beg forgiveness later.

Nobody ever figures bus numbers into the chart, because it would make the timelines so much worse that management wouldn’t approve it. But the blame for going over the estimates rolls downhill. Those stupid devs can’t get anything done on time.

Thankfully I haven’t had to look at one of those stupid things in about 20 years. They used to make me see red.

Re: Ways to annoy your senior engineer

#58
I have this recurring thought that every task I do seems to take either 10 minutes or 3 days and I never really know which it will beforehand.

Of course that's an exaggeration, but I've always found software time estimation to be difficult compared to actually writing the software and usually not very accurate.

Re: Ways to annoy your senior engineer

#59
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…

We make great layoff candidates because most of our code is something other people can take over maintaining. They keep the jackass who makes things nobody else understands.

Re: Ways to annoy your senior engineer

#60

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…

Yeah, the general attitude that estimation is impossible, guesswork, or useless is simply not commercially or professionally defensible. Other fields do it all the time without our tools, competencies, supposed specialties, or environmental control.

If one needs more information to articulate the issue at hand, get it. If the estimate is being misrepresented (ideal days vs calendar days), clarify. If methodology is uncertain, do it and iterate and improve it with experience.

Playing coy about how long it takes to build a deck based on a sketch and current availability, while making cute wordplay about how ‘the deck has to be built before one can know what deck there was to build to begin with’…? Whatever, Confucius, it really doesn’t sound like there’s enough deck building experience here, and the obfuscation seems unserious and anxiety related.

Post reply on HN