At a well-managed company that's growing properly, such as Apple was from 1998-2012, this effect is employed in a way that compensates engineers very well via the gains in stock price.
If you're a great engineer, it behooves you to see yourself as an investor in the company you end up choosing to work for.
This means learning about things like the disruptive growth era we're in, how monetary policy affects growth, etc. You should know what an inverted yield curve is, and where to look to keep up with those charts (https://fred.stlouisfed.org/series/T10Y2Y).
It's important to read Clayton Christensen "The Innovator's Dilemma". I also highly recommend reading ARK Invest's research reports. They cost nothing but an email address, and I have found these all to be enormously valuable in my own research on this. If you just want to sit and watch some stuff on YouTube that can help, give "Chicken Genius Singapore", "Dave Lee on Investing", and "Solving the Money Problem" a whirl.
Great management is incredibly rare. But it's on you to learn how to identify it. If you want to be paid the most, you have to know more than just the field you specialize in! There is little value in putting your head in the sand.
Thanks for "Chicken Genius Singapore", "Dave Lee on Investing", and "Solving the Money Problem" -- these look great! Do you have any other recommendations?
Are organizations that are prone to dramatic underestimations and overworking people also prone to keeping slackers or incompetent developers on staff? But, also, is there a scenario in which the work takes longer _because_ of the incompetence? Meaning the competent developers are working reasonable hours?
> overworking genius.
I'd again wager a guess that most of those struggling with overworking at companies are not geniuses, as a legitimate genius might be more inclined to just find a new job
> such as Apple was from 1998-2012, this effect is employed in a way that compensates engineers very well via the gains in stock price.
As nice as equity compensation plans are, they definitely don't make up for the gains.
The divisional VP gets the lions share of the gains in stock for properly managing/motivating the engineering talent (the engineer is lucky to get a raise above inflation).
It's easy to say that for one person, but these are some of the largest tech companies around, and you're talking about 10s of thousands of engineers. Where are they all supposed to go? FAANG won't hire most of them, and it's not because they're incompetent.
I'm 39, and I didn't major in CS. FAANG wouldn't touch me with a 10-foot pole.
What to do? Take your skills and put them into your own startup. I rolled with the times, hedged my bets and invested my life savings, as documented here:
(The only thing I'd amend my 4-month old comments with, is, chill out! The daily ups and downs are not important compared to the Fed Put. And, long-term, watch out for the ultimate decline of the dollar, the shift from fiat to bitcoin. Palihapitiya has sage advice in keeping at least 1% of your net worth in bitcoin.)
Investing well is a mindset, and the essential thing to do is focus on your methodology, and your connection to the world around you. There is no substitute for critical, rational, non-cynical thinking.
>>The engineer's boss, an engineering manager, asks him how long a new task will take to complete. Sometimes the engineer has not done this particular thing before, so he responds honestly that he has no idea how long it will take. His boss will not accept that answer. He asks again. So, the engineer makes a wild guess and his boss responds with, "That's too long." Even if the engineer knows how long a task will take to complete and gives a realistic estimate, his boss often responds with, "That's too long. You have until Friday." When the engineer asks how long his boss has known about the task, the boss says he has known for a month. When the engineer asks why he didn't tell him a month ago, the boss just looks at the engineer like he doesn't understand the question.
If this describes your workplace, please find a better managed workplace if you can. They are out there
The correct way to do things here would be to:
1. Do a probe project to evaluate complexity and/or look at similar projects
2. Trade time (deadlines) for scope and resources. Yes, we can deliver in a month, but only if we cut scope and get 2 more QA folks, etc.
EDIT 2a: You can also negotiate to trade time for quality and/or take on technical debt knowing it reduces future velocity.
3. If neither of the above happen, you should trade absurdity for more salary/growth. I've seen this at places such as hedge funds and consultancies and they compensate and "pay" for it with better comp and growth.
I would also read books by steve mcconnell. The book on software estimation is awesome with respect to schedule. Just taking the quiz at the beginning of the book is eye-opening.
What's supposed to be the take-away from this? Is it to prove that knowing one or two bits of trivia and maybe a formula, by rote, can make your (unaided) estimation of related things vastly more accurate? That's all I'm getting from it, but maybe that's what's intended.
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 quiz asks for a range that will include the correct answer 9/10 times. Not a point estimate. If you don't have the relevant trivia in your head, broaden the range proportionally. I think the intended point is that we're bad at judging probabilities. Getting 100% right (within range) is probably supposed to be as concerning as getting 0% right.
Ah, right, I've always taken that effect in software estimation to be a result of business people hating how wide an actual "90% accurate" estimate is. Not many managers will accept "8 to 30 months" as a 90% estimate at the start of a project with a fairly typical set of unknowns. Especially they seem to really hate ranges that aren't quite a lot narrower than the size of the lower bound. But maybe it's actually driven by the people doing the estimating.
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.
You're supposed to put down ranges such that you have a 90% confidence that the correct answer is in that range, and then can expect to get roughly 9 of them "correct" (that is, the actual correct answer is included in your range).
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.
Yeah, I get that and name narrower ranges in a business context (trying to keep the upper bound from getting too much lower) because most biz-school types don't get that, and tend to think you're full of shit, being passive-aggressive or otherwise deliberately obtuse, or else it doesn't actually matter and they just wanted a happy number to put on a powerpoint and now you're making their life more difficult for no reason.
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.
Yeah, I definitely agree that the business types just don't get it. If you give a wide range, they either think you're messing with them, or are incompetent.
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.
To make things a bit more fair I'd definitely allow that plenty of business-types do get it, but I think enough don't that treating them all like they do before you know them fairly well is probably a bad move, career-wise, especially if you're not senior and important-enough to thrive despite pissing some of them off. Enough either don't understand or don't want honest estimating that the best you can really do is play the game wisely and hope it goes OK, until/unless you develop a rapport with a "good" one. I'd further admit that being one of the "good" ones may not actually be that useful in a business-type, overall, especially so far as their personal career prospects. They're just... to be approached differently.
Number 2 is very important and not obvious. Give your manager options to choose from. It makes you a cooperative problem solver rather than someone who is pessimistic and can't manage deadlines. Shrugging and saying that scope management is the manager's job is equally as bad as the manager shrugging and saying implementation is the dev's job.
In some ways, that might be a good situation -- it means they are leaving all the trade-off decisions to you. If they are only specifying time and resources, you can trade scope, quality, debt.
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.
If this doesn't work, then I think the most important thing is to implement the most simplistic basic solution as fast as possible and then explicitly ask for feedback. Hard-code whatever portions that take time, but you're not worried about (e.g. database portions). Focus on the parts that are vague that you don't understand and provide a _concrete_ realization of the those vague ideas. This shifts decision-making responsibility away from you.
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.
Why can't engineers simply tell managers that it can't be done by the specified deadline? Why do managers even ask this question if they're gonna ignore the answer and impose an impossible deadline anyway?
It looks like they're assuming we're all lazy. They think the job isn't that hard. A fundamental lack of respect.
Perhaps some managers think they are a clever Cpt Kirk who's gotten wise to their Scotty's miracle-worker tactics, even though they're a manager with an honest Geordi La Forge.
Because in majority of the case engineers after manage to hit the deadline. That is managerial experience. What management learns over time is that engineers say it is impossible but if you insist they will then do it.
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.
> 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?
> 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).
> 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.
> 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.
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.
> How would this information be useful if it's not shared with the boss?
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.
> Is employee health really something that can be traded away?
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.
Managers don't operate like this at well-run companies.
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.
I also noticed that the author is in a bias, this is not a problem of the "software companies", this is a problem of "some software companies" that have a very bad administration, lack of experience in the industry or who intend to apply a disguised labor exploitation
> Why can't engineers simply tell managers that it can't be done by the specified deadline
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.
> If neither of the above happen, you should trade absurdity for more salary/growth. I've seen this at places such as hedge funds and consultancies and they compensate and "pay" for it with better comp and growth.
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.
> My recommendation: try to evaluate your employer on the above.
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.
> 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.
This reads more like the"engineering manager" has had a sales role for too long. I think most frequently this is at the VP level.
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.
Yeah, anyone who knows about a deadline for a project for a month and hasn't bothered scoping it or estimating with their team is massively failing at their job.
Most tech companies are set up such that managers are not incentivized to play defense for their team. Managers switch teams too often (usually on an annual cycle). Teams get reorganized almost as often. Managers have to please their boss or someone higher up.
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.
I'm a manager who has to speak directly to paying customers about how long they have to wait to get what they paid for and even I will never give a deadline or date. Most customers are actually pretty reasonable and know you can't predict everything. Most are thoroughly aware of how terrible they are at giving clear direction. It's important as a leader to exactly why things take time or why timing is unclear. Risks, uncertainty, quality takes time. There's also plenty of things you can do as a manager to de-risk a delivery and avoid being bottlenecked by risky tasks. It's also much easier (not easy, but easier) to estimate larger buckets of tasks than individual ones knowing that some will be harder than expected and some will be faster.
I agree with this wholeheartedly. The article seems to be written by someone who has not yet learned the life lesson that "everything is a negotiation".
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.
There's no such thing as a hard deadline. Everything is made up.
"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?
Often this video processing software wasn’t ready by the Superbowl, and this electronic voting software wasn’t completed by election day.
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.
I guess that depends on your definition of "hard". Will the world end if you don't meet that regulatory deadline? No. Will the company survive? Maybe. Will you lose your job? Maybe. Are there other jobs for you? Yes.
When we can't change the deadline, it's obvious that we should shift the scope. If that breaks down, the problem becomes not losing your entire engineering team while the deadline looms.
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 feel like large companies see developers/engineers like a commodity, give them a spoon and tell them to move a mound of sand. As soon as you tell them you have a shovel, they'll say... well we have spoons, we've always used spoons and you need to continue to use a spoon. We have managers and vendors that take them out golfing that we pay millions of dollars to and we signed a 5 year contract to use spoons, so use a spoon.
Eh... you never lived in a corrupt state, have you?
"Never attribute stupidity what can be explain as sheer corruption, aka malice"
That thin concrete that doesn't meet requirements, was put there not b/c of stupidity, but because someone lined up their pockets down the line, and the quality assurance people were paid to look the other way.
Hanlon’s razor is obviously nonsensical. Malice is fundamentally stupid and obstinate stupidity rises to the level of malice so the distinction makes no difference.
Usual disclaimer: does not apply to most civilized countries with mandatory overtime pay (including nighttime and weekend multipliers), maximum hours worked per week etc..
I'm still amazed that there is so much migration into the US at this point. (But I also do get it.)
Good question. I don't personally know any, so here's pure conjecture, and please read it as such. I'm totally open for feedback!
(I'm internally sort-of answering "Why wouldn't you move to Germany?" since that is where I was born)
* English is easy. It's probably already required to become an engineer. So you move to an English-speaking country.
* Everything is cheap. Labor is cheap, bureaucracy is low. If you dream about starting your own company/idea/dream some time, the US seems like the place to do it.
* The people have a reputation of being easy-going (if superficial) and the country is already culturally mixed. You're not going to stand out.
* It is culturally dominating. Name any piece of popular media that was made in the last 50 years and chances are 95% that it's American. That's not a good reason, but I would say it's a strong biasing factor.
Right -- in those "civilized" countries (you probably mean the higher income European countries?) the total pay is just 20 Euros an hour net of taxes, so software engineers' salaries even with overtime don't match the US. But at least your boss can't play these games.
For skilled programmers, pay in Germany tends to be $5k to $6k per month after all taxes and the highest level of health insurance and a generous retirement insurance and disability and private unemployment insurance (additional to the government one).
That is enough for an entire family to rent a house and live a very comfortable life pretty much everywhere in Germany, except maybe Munich city center.
There are strong overtime protections, I've heard from people who were paid 4x their regular salary because they were called in on a Sunday.
I'm sure the FAANG pay better, but maybe house + family + free time is nicer than high numbers in your online banking?
The US is pretty awesome if you're in the top 10%. Of course, more than 10% of the US population likes to believe they are in the top 10% or have a chance at being in the top 10% in the future.
Then again, maybe the lack of insane regulations on labor (amongst other things) is why the US has managed to produce new, highly-valuable companies at a much higher clip than Europe has, and is also the reason why software engineers in Europe get paid far less than their counterparts in America.
Ignoring the bias in your chosen language, I do somewhat agree with your point.
I would also say that "highly-valuable" is not what a country should strive for its companies to be. I would argue that the good of its citizens should be - and rather than $10b of company valuation, the citizens would profit more from that $10b going into labor regulations and social security.
It happens in the UK. I know plenty of devs here who complain about the "crunch" on projects that really don't need it.
Mind you, I also think there's an element of developers lowballing estimates and then putting in extra time to make themselves much more productive than they actually are. I've worked with a few people who management believed were fantastic but who actually just worked 50% longer hours. I fight hard against those kinds of people being on my team because it destroys morale and absolutely ruins my burndown charts any time they're not available.
If you do 20h overtime, that just means you spent 20h extra on this sprint, and SP/h should be unaffected (thus also the burndown chart).
In my experience time isn't recorded, or isn't recorded very accurately, especially when it's unsanctioned and unpaid overtime. Burndown charts report the daily change rather than the hourly change. Consequently it looks like stories are moving quickly but really it's just that more effort is being put in every day, but the chart doesn't reflect that.
Now that you mention it, that was also what our burndown charts looked like (unaffacted).
Our Scrum Master did use a factor of "actual hours worked vs. planned hours worked" to determine how accurate our SP totals per sprint were. I.e. if we did 100SP in Sprint 1 with no overtime, then 100SP in Sprint 2 with 20h of overtime, we underestimate the SP in Sprint 2.
I am generally not a fan of time tracking (especially not down to minute accuracy or per-story), but I see sth. like "8.7 hours worked on Tuesday" as a useful but not misleading measure.
"So, the engineer makes a wild guess and his boss responds with, "That's too long."" -> You have a dysfunctional relationship with your boss. They don't trust your estimates - whether based on their hubris, or your past results, or something else. You need to either find a way to reset that trust or leave the company and start anew with a new manager. Otherwise you'd going to have this same problem forever and neither of you will be happy.
"Very often, if he chooses to do a lousy job, everyone seems happy that something was produced, even though what was produced may have been total garbage that was good for absolutely nothing." Reading between the lines here, this sounds like an engineer who wants to satisfy requirements that the project doesn't actually have. In my experience, this often looks like an engineer who wants to add more adjectives (modifiability, robustness, scalability, etc) than is actually needed. If you delivered a result that the stakeholders are happy with, that's a good outcome as an engineer. If you want to overengineer something, consider either doing it on your own time or switching to a job where, for example, more scalability, is actually a requirement.
"In other words, if a boss is not totally clueless (which some seem to be), he knows an engineer can't complete a job in three days that will take a month" -> the author clearly assumes their boss has a ton more insight into the engineering work than most do. Actual engineers working on a given project are usually pretty bad at estimating how long tasks will take - a manager (even a non-"clueless", technical one) generally has very little idea how long something will actually take. Assuming that their manager knows and is intentionally screwing you over is just another sign that the author has a completely broken relationship with their boss and is incredibly bitter about it. They would probably benefit from a reset (eg at a new job).
> Reading between the lines here, this sounds like an engineer who wants to satisfy requirements that the project doesn't actually have.
In my experience, this is one of the least understood aspects of the engineer's job, often by engineers themselves. An engineer's job is not to create the absolute highest quality solution every time. The engineer's job is to match solutions with requirements. Often that means not implementing something that, from a purely technical perspective, would be an improvement, because it's not needed to meet the actual requirement, and would take time and effort from something that is needed.
I get frustrated when it seems like no one is maintaining requirements (or aware of them) and I'm just expected to make something work, as though I can read minds about what's expected.
I have no problem with developing solutions on my own with the right accommodations and compensation - but stop handing me sprints based on things where the greatest extent of planning is a single sentence fragment of a Jira issue title.
> I get frustrated when it seems like no one is maintaining requirements (or aware of them) and I'm just expected to make something work, as though I can read minds about what's expected.
Yes, another (often frustrating) part of the engineer's job is to try to get the client (or a manager or someone else who is supposed to be communicating the client's requirements to you) to understand what "requirements" actually means and what does and doesn't count as actually specifying a requirement so it can be met, or at least so that a reasonable estimate of the time and resources required can be given.
As others in this thread have said, sometimes the only real cure for this problem is to find a new job where you have different, and more reasonable, clients and/or managers.
> If you delivered a result that the stakeholders are happy with, that's a good outcome as an engineer. If you want to overengineer something, consider either doing it on your own time or switching to a job where, for example, more scalability, is actually a requirement.
On the flip side, that sounds like a fast track to making shitty products that cause financial losses to the users (or, depending on industry, loss of life and limb). There are always implicit requirements to balance that stakeholders don't think of (or sometimes can't even conceptualize). Like, "satisfy the obvious safety constraints despite them not being mentioned in the spec", or "don't ship kludges that will slow everyone else down later on". Sometimes, part of being an engineer is saving stakeholders from themselves.
Might depend on the company culture, but personally I do not want to work in the place where the engineering culture is "ours not to reason why, ours but to do and die".
This author is writing about a situation in which the employee is earning a fixed salary but his time is billed out on an hourly basis. That is very much a recipe for abuse, and may well have been designed to be exploited from the very beginning.
I'm curious to know how common this employment situation is in engineering. Perhaps only in the large consulting firms? But... aren't annual bonuses supposed to compensate for the "extra" time?
It's every consulting firm. Given that consulting doesn't scale, I would not be surprised if consulting firms represented the majority of software engineering employment.
I've also never worked at any consulting firm that gave an annual bonus, except for one, and it was a joke. I think I got $1.5k one year, after having worked 65hr weeks for the entire year (and some part time while I was supposed to be on family leave).
In my experience many (though not all) deadlines are simple mitigation of Parkinson's Law[0], not exploitation of workers. I don't work in the commercial game industry though, so YMMV.
There are a number of (good) reasons for deadlines--even deadlines that are a bit of a stretch goal.
- One is as you say. Absent a deadline, a lot of projects will meander along forever iterating endlessly to refine and improve or even just dither around. A deadline serves as a forcing function to decide what's actually important and ship it.
- Another is that projects often don't exist in isolation. Even if they are somewhat standalone, like a game, they certainly don't exist outside of revenue targets, big retail selling seasons, advertising plans, etc. It often isn't practical to say "It will be done when it's done and you'll be the first to know."
I don't know if I agree with the word "design". In my experience most managers aren't trying to design a way to force people to work for free (though that may be the unintended result). Most managers seem to fly by the seat of their pants and make up deadlines based on what will make the client/stakeholders happy and not as some sort of malicious design.
I've worked on both sides of that relationship. Believe me, most managers don't think about the details of building software and are just flying by the seat of their pants trying not to look dumb and get fired.
> Most managers seem to fly by the seat of their pants and make up deadlines based on what will make the client/stakeholders happy and not as some sort of malicious design.
So developers must suffer because managers routinely make promises they can't keep?
Isn't understanding the capabilities of the people they manage the job of the manager? I always thought that was the whole point. If they don't know this, then maybe they shouldn't be making any promises at all.
Making correct estimate on how much time feature will take is something different then just understanding the capabilities of the people.
Even developers themselves are often unable to produce good estimates. In fact, most developers tend to systematically underestimate how much time they will need for this or that task.
I have seen management to even add padding to estimate and it is still not enough in the end.
Isn't that up to the developers to provide reasonable estimates? I regularly tell the higher ups estimates that are 3x what I actually think because I know I suck at estimates.
If the problem is that your manager isn't listening to your estimates, then find a new manager. Plenty of fish in the sea.
Can software development jobs actually be reliably estimated though? It's not like other jobs where you can statistically analyze the performance of workers and estimate how long they take to perform tasks. There are too many factors at work here, no doubt there's going to be high variance from developer to developer, from project to project, from team to team, from feature to feature. The work isn't an uniform task like brick laying.
> Can software development jobs actually be reliably estimated though?
That's why I often 3x my estimates. It works great for me.
It's never a problem that I finish a project early. But when external launch plans are on the line, it can definitely be a problem to finish a project late.
Finishing a project on time is one of the things you get evaluated on in performance reviews as a software engineer. It's also up to the software engineer to provide reasonable estimates and to push back on requirements or incorrect estimates coming from higher up.
The irony though is that the code that is written is shit and will cost the company so much to maintain, which eventually leads to that shitty manager being fired. The poor souls are the ones who need to maintain that crap software after
IMO the whole "we don't pay for overtime" thing with salaried employees is a scam that needs to be made illegal. There were times in my career (in the past now) where I had to put in 10-12 hours a day, and often without weekends just to meet the schedule, because some manager somewhere wanted the product for the trade show. I don't see how this is reasonable, or why it should be legal, yet under the current US labor laws it is legal.
When I managed my own teams, the most I would ask folks to do is to very rarely work a bit more for a day or two (there are sometimes legitimate reasons why things need to be done by a certain date, or crises to resolve ASAP), giving them days off later to compensate. This was entirely voluntary, with NO repercussions, career or otherwise, if they don't want to do it. There always were 3-4 folks who were happy to oblige. I'm also proud to say, that not once have I made anyone work over a weekend.
I've no doubt some folks do that thing with the intent described in the article "force engineers to work for free".
But I also think people are really quick to imagine managers / bosses to be Snidely Whiplash or something when really it's more ignorance and bad choices and etc.
I wonder if the introverted engineering culture has something to do with it too?
I used to work in other fields until I started coding later in life. I've found a huge % of engineers asking about what to do about situations and my first question is:
"Wait ... have you talked to your manager about this yet?"
And the answer very often is "no" and they're talking about really strong feelings of pressure and rage quitting is pretty shocking to me. This was very rare in other fields that I was in, but in engineering it seems surprisingly common.... Let alone the stories where it seems like the manager and the employee only talk during quarterly meetings and that's it.
I think without any kind of relationship with your manager, team or employer can make a given situation seem like it is menacing, manipulative.... but you really don't know.
Granted, there are bad managers who do such things intentionally, but if you talk to them you'll probably figure that out too. If you don't, you don't know.
I've worked with plenty of folks who were very sure / felt strongly about some management manipulation and yet I saw no reason to think it was occurring at all.
It isn’t just engineers—it’s all employees. Deadlines are often unrealistic or arbitrary. It’s just something to use as a cudgel to beat your employees over the head with.
The picture this paints of a career in software engineering is utterly unrecognizable to me, someone who has worked in this industry for well over a decade at this point. I can't tell how much of this is pertains to whatever specific situation the author finds himself in vs. how much of it relates to the author's worldview. If I treated team members like this author describes being treated, they would leave in an instant for any of the myriad of companies hungry for engineers that will not treat them like crap.
Having a job is an abstraction. It allows you to trade predictable effort for predictable pay. Deadlines are an abstraction leak: Ultimately, market dynamics and business P&L exists, it can't be totally ignored in a healthy organization.
Also has the effect of having most engineers with a track record of "missed deadlines" and "failures". So they are continually in fear of their managers and review time.
Here is the thing: most developers have very weak personalities. So yes, the sociopaths figured out that by stressing the engineers, they can get more work done, until they burnout at least.
You owe it to society to let a deadline slide by a large margin.
>> Unfortunately, many of our companies appear to have become Orwellian machines that put these people in power, and once there, they create utter chaos for the rest of us.
I keep saying this because it's relevant to so many topics and so many problems that people talk about these days...
The way all newly 'printed' money enters into our economy is through big financial institutions - This means that the financial institutions are in the position of choosing who will get a share of that new money (which the Fed printed out of thin air).
Once you understand that the global monetary system is a scam, you'll understand why psychopaths rise to the top; because the psychopaths who run the world can't rely on altruists to keep their mouths shut.
This is how I feel as well, and I can't tell if the author has only ever worked in really bad companies, or doesn't have the maturity to understand his work relationships or how a business runs. The anecdotes in the article also feel cliche, they feel like something pulled out of generic articles about "bad bosses". Are there actually many engineering managers like this in tech companies in the modern day? Have I just been lucky in the past 15 years in my career?
197 comments
[ 2.9 ms ] story [ 200 ms ] threadIf you're a great engineer, it behooves you to see yourself as an investor in the company you end up choosing to work for.
This means learning about things like the disruptive growth era we're in, how monetary policy affects growth, etc. You should know what an inverted yield curve is, and where to look to keep up with those charts (https://fred.stlouisfed.org/series/T10Y2Y).
It's important to read Clayton Christensen "The Innovator's Dilemma". I also highly recommend reading ARK Invest's research reports. They cost nothing but an email address, and I have found these all to be enormously valuable in my own research on this. If you just want to sit and watch some stuff on YouTube that can help, give "Chicken Genius Singapore", "Dave Lee on Investing", and "Solving the Money Problem" a whirl.
Great management is incredibly rare. But it's on you to learn how to identify it. If you want to be paid the most, you have to know more than just the field you specialize in! There is little value in putting your head in the sand.
> The slacker / incompetent
Are organizations that are prone to dramatic underestimations and overworking people also prone to keeping slackers or incompetent developers on staff? But, also, is there a scenario in which the work takes longer _because_ of the incompetence? Meaning the competent developers are working reasonable hours?
> overworking genius.
I'd again wager a guess that most of those struggling with overworking at companies are not geniuses, as a legitimate genius might be more inclined to just find a new job
As nice as equity compensation plans are, they definitely don't make up for the gains.
The divisional VP gets the lions share of the gains in stock for properly managing/motivating the engineering talent (the engineer is lucky to get a raise above inflation).
That's great for Apple engineers but what if you work for HP/Intel/IBM and just see a steady declining stock?
What to do? Take your skills and put them into your own startup. I rolled with the times, hedged my bets and invested my life savings, as documented here:
https://news.ycombinator.com/item?id=22958528 https://news.ycombinator.com/item?id=22970810
(The only thing I'd amend my 4-month old comments with, is, chill out! The daily ups and downs are not important compared to the Fed Put. And, long-term, watch out for the ultimate decline of the dollar, the shift from fiat to bitcoin. Palihapitiya has sage advice in keeping at least 1% of your net worth in bitcoin.)
Investing well is a mindset, and the essential thing to do is focus on your methodology, and your connection to the world around you. There is no substitute for critical, rational, non-cynical thinking.
If this describes your workplace, please find a better managed workplace if you can. They are out there
The correct way to do things here would be to:
1. Do a probe project to evaluate complexity and/or look at similar projects
2. Trade time (deadlines) for scope and resources. Yes, we can deliver in a month, but only if we cut scope and get 2 more QA folks, etc.
EDIT 2a: You can also negotiate to trade time for quality and/or take on technical debt knowing it reduces future velocity.
3. If neither of the above happen, you should trade absurdity for more salary/growth. I've seen this at places such as hedge funds and consultancies and they compensate and "pay" for it with better comp and growth.
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?
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.
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.
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.
It looks like they're assuming we're all lazy. They think the job isn't that hard. A fundamental lack of respect.
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.
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.
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...
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.
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.
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.
(tongue-in-cheek...I just feel like every day there's a new law I learn that applies perfectly to a situation. I can't keep track of them all!)
-- Yours Truly's Razor ;) (though I still prefer "Hanlon's Handgun")
https://news.ycombinator.com/item?id=21691718
"Never attribute stupidity what can be explain as sheer corruption, aka malice"
That thin concrete that doesn't meet requirements, was put there not b/c of stupidity, but because someone lined up their pockets down the line, and the quality assurance people were paid to look the other way.
Mafia 101
I'm still amazed that there is so much migration into the US at this point. (But I also do get it.)
(I'm internally sort-of answering "Why wouldn't you move to Germany?" since that is where I was born)
* English is easy. It's probably already required to become an engineer. So you move to an English-speaking country.
* Everything is cheap. Labor is cheap, bureaucracy is low. If you dream about starting your own company/idea/dream some time, the US seems like the place to do it.
* The people have a reputation of being easy-going (if superficial) and the country is already culturally mixed. You're not going to stand out.
* It is culturally dominating. Name any piece of popular media that was made in the last 50 years and chances are 95% that it's American. That's not a good reason, but I would say it's a strong biasing factor.
That is enough for an entire family to rent a house and live a very comfortable life pretty much everywhere in Germany, except maybe Munich city center.
There are strong overtime protections, I've heard from people who were paid 4x their regular salary because they were called in on a Sunday.
I'm sure the FAANG pay better, but maybe house + family + free time is nicer than high numbers in your online banking?
Seattle salaries: https://www.levels.fyi/Salaries/Software-Engineer/Greater-Se...
Switzerland salaries: https://www.levels.fyi/Salaries/Software-Engineer/Switzerlan...
Cost-of-living Seattle vs. Zurich: https://www.numbeo.com/cost-of-living/compare_cities.jsp?cou...
Income tax burden in Seattle @200k p.a. was 26.28% in 2019: https://smartasset.com/taxes/income-taxes#qWHU75h5ug
Income tax burden in Zurich @200k p.a. was 20.41% in 2019: https://swisstaxcalculator.estv.admin.ch/#/taxburden/income-...
So you "pay" 8% of purchasing power to get everything I mentioned (plus socialized health care but let's not go there).
I would also say that "highly-valuable" is not what a country should strive for its companies to be. I would argue that the good of its citizens should be - and rather than $10b of company valuation, the citizens would profit more from that $10b going into labor regulations and social security.
Mind you, I also think there's an element of developers lowballing estimates and then putting in extra time to make themselves much more productive than they actually are. I've worked with a few people who management believed were fantastic but who actually just worked 50% longer hours. I fight hard against those kinds of people being on my team because it destroys morale and absolutely ruins my burndown charts any time they're not available.
This is the one point where I'm very happy that my work committed to the (legally already obligatory) time tracking.
If you do 20h overtime, that just means you spent 20h extra on this sprint, and SP/h should be unaffected (thus also the burndown chart).
In my experience time isn't recorded, or isn't recorded very accurately, especially when it's unsanctioned and unpaid overtime. Burndown charts report the daily change rather than the hourly change. Consequently it looks like stories are moving quickly but really it's just that more effort is being put in every day, but the chart doesn't reflect that.
Our Scrum Master did use a factor of "actual hours worked vs. planned hours worked" to determine how accurate our SP totals per sprint were. I.e. if we did 100SP in Sprint 1 with no overtime, then 100SP in Sprint 2 with 20h of overtime, we underestimate the SP in Sprint 2.
I am generally not a fan of time tracking (especially not down to minute accuracy or per-story), but I see sth. like "8.7 hours worked on Tuesday" as a useful but not misleading measure.
"So, the engineer makes a wild guess and his boss responds with, "That's too long."" -> You have a dysfunctional relationship with your boss. They don't trust your estimates - whether based on their hubris, or your past results, or something else. You need to either find a way to reset that trust or leave the company and start anew with a new manager. Otherwise you'd going to have this same problem forever and neither of you will be happy.
"Very often, if he chooses to do a lousy job, everyone seems happy that something was produced, even though what was produced may have been total garbage that was good for absolutely nothing." Reading between the lines here, this sounds like an engineer who wants to satisfy requirements that the project doesn't actually have. In my experience, this often looks like an engineer who wants to add more adjectives (modifiability, robustness, scalability, etc) than is actually needed. If you delivered a result that the stakeholders are happy with, that's a good outcome as an engineer. If you want to overengineer something, consider either doing it on your own time or switching to a job where, for example, more scalability, is actually a requirement.
"In other words, if a boss is not totally clueless (which some seem to be), he knows an engineer can't complete a job in three days that will take a month" -> the author clearly assumes their boss has a ton more insight into the engineering work than most do. Actual engineers working on a given project are usually pretty bad at estimating how long tasks will take - a manager (even a non-"clueless", technical one) generally has very little idea how long something will actually take. Assuming that their manager knows and is intentionally screwing you over is just another sign that the author has a completely broken relationship with their boss and is incredibly bitter about it. They would probably benefit from a reset (eg at a new job).
In my experience, this is one of the least understood aspects of the engineer's job, often by engineers themselves. An engineer's job is not to create the absolute highest quality solution every time. The engineer's job is to match solutions with requirements. Often that means not implementing something that, from a purely technical perspective, would be an improvement, because it's not needed to meet the actual requirement, and would take time and effort from something that is needed.
I have no problem with developing solutions on my own with the right accommodations and compensation - but stop handing me sprints based on things where the greatest extent of planning is a single sentence fragment of a Jira issue title.
Yes, another (often frustrating) part of the engineer's job is to try to get the client (or a manager or someone else who is supposed to be communicating the client's requirements to you) to understand what "requirements" actually means and what does and doesn't count as actually specifying a requirement so it can be met, or at least so that a reasonable estimate of the time and resources required can be given.
As others in this thread have said, sometimes the only real cure for this problem is to find a new job where you have different, and more reasonable, clients and/or managers.
On the flip side, that sounds like a fast track to making shitty products that cause financial losses to the users (or, depending on industry, loss of life and limb). There are always implicit requirements to balance that stakeholders don't think of (or sometimes can't even conceptualize). Like, "satisfy the obvious safety constraints despite them not being mentioned in the spec", or "don't ship kludges that will slow everyone else down later on". Sometimes, part of being an engineer is saving stakeholders from themselves.
Might depend on the company culture, but personally I do not want to work in the place where the engineering culture is "ours not to reason why, ours but to do and die".
I'm curious to know how common this employment situation is in engineering. Perhaps only in the large consulting firms? But... aren't annual bonuses supposed to compensate for the "extra" time?
[0] https://en.wikipedia.org/wiki/Parkinson%27s_law
- One is as you say. Absent a deadline, a lot of projects will meander along forever iterating endlessly to refine and improve or even just dither around. A deadline serves as a forcing function to decide what's actually important and ship it.
- Another is that projects often don't exist in isolation. Even if they are somewhat standalone, like a game, they certainly don't exist outside of revenue targets, big retail selling seasons, advertising plans, etc. It often isn't practical to say "It will be done when it's done and you'll be the first to know."
-Hanlon's razor
So developers must suffer because managers routinely make promises they can't keep?
Even developers themselves are often unable to produce good estimates. In fact, most developers tend to systematically underestimate how much time they will need for this or that task.
I have seen management to even add padding to estimate and it is still not enough in the end.
If the problem is that your manager isn't listening to your estimates, then find a new manager. Plenty of fish in the sea.
That's why I often 3x my estimates. It works great for me.
It's never a problem that I finish a project early. But when external launch plans are on the line, it can definitely be a problem to finish a project late.
Finishing a project on time is one of the things you get evaluated on in performance reviews as a software engineer. It's also up to the software engineer to provide reasonable estimates and to push back on requirements or incorrect estimates coming from higher up.
When I managed my own teams, the most I would ask folks to do is to very rarely work a bit more for a day or two (there are sometimes legitimate reasons why things need to be done by a certain date, or crises to resolve ASAP), giving them days off later to compensate. This was entirely voluntary, with NO repercussions, career or otherwise, if they don't want to do it. There always were 3-4 folks who were happy to oblige. I'm also proud to say, that not once have I made anyone work over a weekend.
But I also think people are really quick to imagine managers / bosses to be Snidely Whiplash or something when really it's more ignorance and bad choices and etc.
I wonder if the introverted engineering culture has something to do with it too?
I used to work in other fields until I started coding later in life. I've found a huge % of engineers asking about what to do about situations and my first question is:
"Wait ... have you talked to your manager about this yet?"
And the answer very often is "no" and they're talking about really strong feelings of pressure and rage quitting is pretty shocking to me. This was very rare in other fields that I was in, but in engineering it seems surprisingly common.... Let alone the stories where it seems like the manager and the employee only talk during quarterly meetings and that's it.
I think without any kind of relationship with your manager, team or employer can make a given situation seem like it is menacing, manipulative.... but you really don't know.
Granted, there are bad managers who do such things intentionally, but if you talk to them you'll probably figure that out too. If you don't, you don't know.
I've worked with plenty of folks who were very sure / felt strongly about some management manipulation and yet I saw no reason to think it was occurring at all.
You owe it to society to let a deadline slide by a large margin.
I keep saying this because it's relevant to so many topics and so many problems that people talk about these days...
The way all newly 'printed' money enters into our economy is through big financial institutions - This means that the financial institutions are in the position of choosing who will get a share of that new money (which the Fed printed out of thin air). Once you understand that the global monetary system is a scam, you'll understand why psychopaths rise to the top; because the psychopaths who run the world can't rely on altruists to keep their mouths shut.
If you don't believe me, just watch Hidden Secrets of Money: https://www.youtube.com/watch?v=DyV0OfU3-FU&t=2s
The good news is that this is likely a sign that the system is on the brink of failure.
Now to figure out how to set boundaries in the abusive relationship.
I've only been at well run tech companies, and have a very different experience.
I would never refer to my manager as "boss". Lol, I've rarely been told what to do next..
My current manager describes his job as "herding cats" :)