There's no such thing as a hard deadline. Everything is made up. What your manager is saying is: "To be successful in the market, I think I need to have X thing in Y days."

It's the engineer's responsibility to provide information and estimates that will shape the business's direction. If you don't clarify or negotiate requirements based on your technical knowledge and experience and just take requirements as law written in stone you are not providing the true value of an engineer.

If you are doing that - pushing back and grounding requirements in reality - and the business plows ahead with unrealistic goals anyway, then that simply means the people you work with are unreasonable and you should seek employment elsewhere. If they're not even willing to listen to people they're paying to have expertise then they're probably reading the market wrong too and I wouldn't trust them to be around long anyway.

"This video processing software needs to be ready by the Superbowl" or "This electronic voting software needs to be done by election day" don't strike you as hard deadlines?

You don’t get sacked, you just get to work on the next death-march project. And for your two examples, it might be punted to the next Superbowl or election.

Hard deadlines are not often deadly.

I mean, honestly, yes. That's kinda the point of "dead"lines, isn't it?

Finishing your term paper the night before it’s due was a thing we were supposed to outgrow in college.

The direct eng manager (or PM sometimes) should be in a position to fight against this sort of absurdity, give the IC a few days to scope the project, etc. One of the eng managers at a previous employer wasnt a great technical mind but was stellar at playing defense against managament. We all had great respect for him repeatedly taking it on the chin for his team.

The power the engineers have is to exit. In some organizations, the engineers can exit to another part of the organization. In others, they exit the organization entirely. This does actually work in aggregate if you just look at it on a longer timescale.

Applies to non-dev work as well.

This industry is like any (every?) other: a minefield of incompetence and laziness interwoven with an unhealthy dose of unjustifiable arrogance.

If they are freezing time and resources and scope, and you dont have much room to move except with quality and debt. But those catch up. If that is the consistent trade-off, i'd go with my original recommendations: trade this stupidity for more salary or find a new employer with better management. Or seek the managerial position yourself and do a better job at it.

As a plus this also gives you the ability to more effectively gauge the difficulty of the rest of the project. The things you thought were simple might be much worse. And then as long as you get concrete feedback, you'll be able to much better predict the amount of time and effort required going forward.

I just said, I'll need to work Saturdays to make this happen, and will need at least 2 others in on Saturdays (in office - full day work). I asked for +50% and got it.

It helped I'd been clear that my schedule was 8:30-5:00 M-F to start and was younger at the time.

Ironically - these days I just wish I had free time and curse myself fairly often for being over-committed. So rarely worth it even for more $ especially if you have kids and are a stranger to them. While I'm paid extremely well QOL is WAY down and stress is very high.

I traded stupidity for money. Don't do it.

My recommendation: try to evaluate your employer on the above.

I've traded stupidity for money for money earlier in my life, and it made sense. But people underestimate the break-even. You deserve a lot of money (50% or 75% premium) for some of the stupidity I've seen.

On the flip side, i've also traded a salary discount for a well-run org -- a job where i have 90min max meetings a day with lots of good ASYNC communications, good project planning, estimation, and good sprint cadences. I work a lot, but only when I want to (often late nights), bike outside when I want to, work heads-down w/o disturbances, etc.

Just be careful when headhunters come offering a 10 or 15% increase in comp except w/ a very different culture. You have to compare like to like.

And better do it in a nuanced way, not the yes/no checkmarks that Stackoverflow Jobs is using for those points. I've worked for companies that were a mess and would get 11/12, as they _technically_ were using source control and tracking bugs etc., just in the most unproductive/useless way.

ie: Security Auditing Style...

It looks like they're assuming we're all lazy. They think the job isn't that hard. A fundamental lack of respect.

They can. I've had a time where a project manager came by no less than 3 times asking me to re-estimate the same project, tweaked ever so slightly each time. Turned out that they had made an impossible promise to the client. Upon learning that, I just said, listen that can't be done within that budget, end of story. You have to go reduce the scope. In the end, they had to go back, loop in the account manager and have the awkward conversation with the client.

No offence to Geordi La Forge.

https://youtu.be/latWmQtm8fw?t=22

In your estimating, remember to always add buffer time.

It is by trading quality pretty often, but that often is exactly trade off managers want. It is often by trading future productivity - engineers burning out or at least having drop after deadline.

Future productivity? If engineers are burning out in an attempt to meet otherwise impossible deadlines, it means they're being placed under enough stress that it's threatening their mental and possibly physical health. Is employee health really something that can be traded away?

In theory? No. In practice? Very much yes.

Health (particularly mental well-being) isn't readily and reliably quantifiable. As a manager, you may think your subordinate is happy and productive all the way up to the point they hand you their resignation letter. Meanwhile, employees have every reason to pretend everything is OK up to the very moment they secure a new job elsewhere. And to the extent they're becoming less productive due to burnout, most software jobs has a lot of slack in it - between high variance in problem solving and plenty of bullshit tasks to juggle, someone working at 10% of their normal capacity can stay unnoticed for a while.

With no good feedback being available, it's hard to see you're putting too much pressure on your employees, particularly if you don't look for it (whether because you're too busy or just don't care).

There are resources which may help. Here's an article that's specific to stress:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6345505/

> As a manager, you may think your subordinate is happy and productive all the way up to the point they hand you their resignation letter.

This is the same problem we have with depression and suicide. The answer is to actively look for it.

> Meanwhile, employees have every reason to pretend everything is OK up to the very moment they secure a new job elsewhere.

An evaluation of a person's mental health produces medical information which should of course be confidential. People will not open up if they think this information will be shared with others, especially their bosses or colleagues.

> And to the extent they're becoming less productive due to burnout, most software jobs has a lot of slack in it - between high variance in problem solving and plenty of bullshit tasks to juggle, someone working at 10% of their normal capacity can stay unnoticed for a while.

Many diseases also have a subclinical phase where they show few or no symptoms. This is actually a good thing since it allows you to intervene before a complication manifests itself. The answer is to actively look for them.

> it's hard to see you're putting too much pressure on your employees, particularly if you don't look for it (whether because you're too busy or just don't care).

Hard, but not impossible. The answers won't be found if the people responsible aren't looking for them. If managers are too busy, maybe they should make the time. If they don't care, they should straight up be fired for gross negligence.

How would this information be useful if it's not shared with the boss?

Regardless, I don't think the biggest issue is people are afraid that the information will be shared, but that there's a stigma around being associated with a mental health issue that causes lower productivity in the workplace. Employees are more likely to keep that kind of thing a secret because they likely believe knowledge of it will make it harder to get raises and promotions.

Indirection and anonymization. The details of each individual aren't supposed to be shared but a healthcare professional can recommend changes to the manager that if implemented would promote a healthier workplace. They can point out that the whole workplace is stressful and talk to the managers about how they can improve that. Hopefully deadlines will be addressed.

There's an entire medical specialty devoted to this: occupational medicine.

> Employees are more likely to keep that kind of thing a secret because they likely believe knowledge of it will make it harder to get raises and promotions.

Unreasonable deadlines are likely to stress entire groups of people, not single individuals. It's worth addressing as an issue affecting the collective workforce.

Practically yes. Not necessary because management are all sociopaths and narcissists (some are). What management see is well performing motivated employee that does not complain. People are expected to not talk about about them being tired, about their mental issues and put themselves at disadvantage if they show weakness.

Employees in order to look good and for the sake of own ego, dont admit they are at limit. The ego thing is big co-reason, that is what prevents employee from taking action. (And yes employee often has that option.)

When employee breaks and stops performing, he is kept around for the sake of old glory for a while. Then he is either replaced or hidden in one of those sleepy corporate departments full of considered loosers. The employee is then blamed for consequences of break down.

Any remotely healthy team will perform estimation and scoping as a discussion with the developers involved. The author of this post sounds like he has worked at an extremely dysfunctional company, not a company that understands how to develop software.

This idea that managers are universally incompetent just isn't true. The best thing you can do is refuse to support incompetent managers. Change teams or change jobs if you must. There are many, many great managers out there who won't try to pull nonsense like this.

Examples: if I didn't happen to have an accurate-enough figure for the diameter of the Earth in miles, plus a formula for the surface area of a sphere, plus roughly the proportion of the Earth's surface that's land, all in my head, there's no chance at all I could produce a useful-for-any-purpose-whatsoever estimate of "area of the Asian continent" without researching it (at which point I could just look up a fairly exact figure, without knowing any of that). Year of Alexander the Great's birth, well I happen to know roughly when Aristotle was active and that they were alive at the same time. Otherwise, again, I'd produce a useless-for-most-any-purpose guess. Total US currency, I bet knowing something like the current annual GDP of the US would at least narrow that down, and is something someone might plausibly have at hand (I don't, my guessed range on that would be hilariously bad). If you have a sense of blockbuster movie budgets and/or returns, which one can acquire from paying attention to entertainment headlines, it's easy to come up with a reasonable range for Titanic's box office receipts. And so on.

Is the point that trivia's highly valuable, actually, if you have to estimate a bunch of arbitrary stuff purely from memory?

The point of the test -- as shown by the response graph after it -- is to show that when someone asks us for a 90%-confidence estimate, we don't really understand what that means, and end up giving 30%-confidence estimates. The point is that people need to understand what they do and don't know, and reflect their level of uncertainty with the width of the range.

If I have a trivial task that I've done a hundred times before, I might say that it'll take me 45-60 minutes to complete, and 90% of the time I'd be right. But if it's something I've never done before, and I don't understand the steps or complexity, I might say that it'll take me between 30 minutes and 8 hours.

This scales up, too. For a larger project that I understand well, I might say 6-8 weeks, while for something I don't understand, I might say 4-12 weeks.

Over time, I can determine if I make good-enough estimates by checking to see if 90% of the time the actual time to delivery fell within the stated range. It doesn't matter if it's at the beginning of the range, end of the range, or right in the middle. I just need to hit somewhere in the range, 90% of the time.

For example, for the Alexander the Great question, I don't have a clue. Your mention that he was a contemporary of Aristotle actually made me realize I believed he was much more modern-day than he is. So I might give a range of like 1000BC to 0AD, because I recall that Aristotle was definitely BC, but I don't really have much confidence as to when. Looks like the right answer is 356BC. So my estimate was correct, even though it had a wide range. Giving people (like your manager) a wider range also communicates your uncertainty, which is a useful piece of information for them to have. The issue is that I think many engineering managers simply won't accept a true 90% estimate if it's wider than they know what to do with from a planning perspective.

For that matter they tend to be pretty bad at anything even adjacent to experimental design, but god help you if you point out that the data they're so proud to present to the C-suite next week is, actually, meaningless (rare is the C-suite that'll catch it and call them on it, anyway, so from the perspective of the presenter it's almost beside the point; a disturbing amount of "data driven" leadership is pure fairy dust).

For a good proportion of programmers I'd expect education and professional work experience to have them comfortable with wide estimate ranges being typical and honest for many "90%" estimates, but business-social experience having convinced them, correctly, that honest estimates aren't what a hell of a lot of people actually want and do, "make us appear ignorant or incompetent" (from the book), in actual fact from the perspectives of people who control our budgets and wages.

Personally I tend to try to narrow the range as much as possible while keeping my upper bound as fixed as possible, but that doesn't always work either, and I think I still unconsciously try to go too far toward making everyone happy, and underestimate.

I think part of it is just our collective feelings of powerlessness that keeps us in this uncomfortable position. If a significant number of developers were to put their foot down and give real estimates that actually express uncertainty properly, and stick with them, management would start to understand, or at least accept, what's going on. But "getting a bunch of random people to change their behavior all at once" isn't a reliable strategy, so here we are, and here we'll continue to be.

For my part I definitely tend to squeeze my "90%"s down to more like "30-40%" when asked for a "90%", for that reason. I might try out an honest and accurate estimate on someone I kinda know, and suspect won't quietly re-evaluate me as a useless moron or "one of those asshole 'programmer' types who doesn't get business" in response, though.