12 ms·

I suspect many task deadlines are designed to force engineers to work for free

270 points by sT370ma2 6y ago

maxharris 6y ago
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 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.
- TuringNYC 6y ago
  Thanks for "Chicken Genius Singapore", "Dave Lee on Investing", and "Solving the Money Problem" -- these look great! Do you have any other recommendations?
  - maxharris 6y ago
    Cathie D. Wood, founder and CEO of ARK Invest, also does periodic YouTube videos. I love her!
- gowld 6y ago
  That seems not true. The slacker / incompetent gets the same stock growth as the overworking genius.
  - bird_monster 6y ago
    This statement is a lot to unpack. > 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
- htrp 6y ago
  > 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).
- x87678r 6y ago
  > 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. That's great for Apple engineers but what if you work for HP/Intel/IBM and just see a steady declining stock?
  - someguydave 6y ago
    they should realize their company business model sucks and bail
    - rabidrat 6y ago
      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.
      - maxharris 6y ago
        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: https://news.ycombinator.com/item?id=22958528 https://news.ycombinator.com/item?id=22958528 https://news.ycombinator.com/item?id=22970810 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.
- deleted 6y ago
  [deleted]
jimbob45 6y ago
It goes both ways. Many weak deadlines allow engineers to slack off when they otherwise might not have.
TuringNYC 6y ago
>>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.
- m463 6y ago
  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.
  - cwillu 6y ago
    For those interested in the quiz: https://books.google.ca/books?id=U5VCAwAAQBAJ&lpg=PP1&pg=PT58#v=onepage&q&f=false https://books.google.ca/books?id=U5VCAwAAQBAJ&lpg=PP1&pg=PT5...
    - Zippogriff 6y ago
      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?
gorzynsk 6y ago
Hanlon's razor is an aphorism, "Never attribute to malice that which is adequately explained by stupidity"
- bravura 6y ago
  “Any sufficiently advanced incompetence is indistinguishable from malice.” - Grey's law
  - RankingMember 6y ago
    Is there a law yet that describes how, for any situation, someone's created a law that applies to it? (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!)
  - AnimalMuppet 6y ago
    I've quoted that before, but never heard it called "Grey's law". Who is Grey?
  - TeMPOraL 6y ago
    "Never attribute to stupidity that which can be adequately explained by systemic incentives promoting malice." -- Yours Truly's Razor ;) (though I still prefer "Hanlon's Handgun") https://news.ycombinator.com/item?id=21691718 https://news.ycombinator.com/item?id=21691718
- ouid 6y ago
  Hanlon's razor is a boundary condition. Over time strategies improve, including malicious ones.
- ardit33 6y ago
  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. Mafia 101
ThePadawan 6y ago
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.)
- pkaye 6y ago
  Then why do so many engineers come to work in the US?
  - irrational 6y ago
    Is this still the case?
    - MiroF 6y ago
      Yes? As long as the pay differences are what they are, why wouldn't it be?
      - irrational 6y ago
        I thought the Trump administration was working overtime to limit HB1, immigration,etc.
  - ThePadawan 6y ago
    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.
deleted 6y ago
[deleted]
fishtoaster 6y ago
There's a lot to unpack here. "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).
- pdonis 6y ago
  > 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.
OldHand2018 6y ago
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?
- moron4hire 6y ago
  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.
  - OldHand2018 6y ago
    That's a good point. And except in fixed-price contracts, there is no incentive to become more productive - they would rather you work more hours.
    - moron4hire 6y ago
      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).
umvi 6y ago
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. [0] https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law
- ghaff 6y ago
  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."
irrational 6y ago
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.
- Clubber 6y ago
  "Never attribute to malice that which is adequately explained by stupidity" -Hanlon's razor
  - liability 6y ago
    Advanced malicious actors often feign incompetence when caught, to take advantage of the naive and forgiving.
    - quickthrower2 6y ago
      This is a basic part of the human OS. It’s a skill that can be seen from 4 years of age. It’s the other way around: We learn not to do this.
    - lotsofpulp 6y ago
      Maybe one should assume the people who say the hanlon razor saying are advanced malicious actors.
    - Clubber 6y ago
      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.
- matheusmoreira 6y ago
  > 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?
deleted 6y ago
[deleted]
cortesoft 6y ago
This seems to be describing a particular problem of working at an engineering consulting company. I have never had this experience in my career.
snarkypixel 6y ago
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
m0zg 6y ago
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.
duxup 6y ago
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.
diogenescynic 6y ago
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.
skwirl 6y ago
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.
zwieback 6y ago
It's not like that where I work. Scheduling and tracking tasks is hard but it sounds like the author needs to find a new job.
encoderer 6y ago
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.
JJMcJ 6y ago
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.
- deleted 6y ago
  [deleted]
GoToRO 6y ago
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.
cryptica 6y ago
>> 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. If you don't believe me, just watch Hidden Secrets of Money: https://www.youtube.com/watch?v=DyV0OfU3-FU&t=2s 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.
reillyse 6y ago
Is this article set in the late 90's. Times have changed, get a new job.
dboreham 6y ago
Penny dropping.. Now to figure out how to set boundaries in the abusive relationship.
jopsen 6y ago
Wow, I suspect milage may vary depending on where you work. 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" :)
- godot 6y ago
  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?
crazygringo 6y ago
As a former product manager with lots of experience with both engineering and management: no, that's not what deadlines are designed for. Deadlines exist because software doesn't exist in a vacuum, but other people depend on it being delivered. Whether so it can be sold to make money before someone goes out of business or a partnership fails, or its features arrive on time as promised for the start of the school year which can't be moved, or as the foundation for another project that has its own equally valid deadline later on. Deadlines exist because people need to make plans and be able to rely on them, which is how our entire society and economy function. People work overtime in every industry to meet deadlines, it's not just engineers. The only question is whether or it's good for you financially. Whenever you take a job, it's up to you to do your due diligence in talking to other employees to find out what the working hours and flexibility are like in practice, and judge that against the salary, and decide if it makes sense for you. Fortunately, there is huge variation in both salaries and expectations of hours per week, and the best thing you can do about places that pay little and work you long is to not take their job offer, or leave. Then supply and demand can do its thing and they'll be forced to adjust or go out of business.
- marcinzm 6y ago
  >Deadlines exist because software doesn't exist in a vacuum, but other people depend on it being delivered. Exactly, even without external deliverables there are likely other internal initiatives that depend on the project or tie into it. Might even be something as simple as the QA team being booked on another project in a month that does have a hard deadline. So as long as something in the org has a hard external deadline there are going to be ripples that touch all projects in the org. Also, my experience is that if you communicate early that features need to be cut to meet the deadlines most managers will be happy.
- thomas 6y ago
  Well put and fully agreed. I don’t think engineers are in any way a special case here. In fact it can be much worse for people whose skillset is easier to replace.
  - 6y ago
kache_ 6y ago
Leverage is your tool. If you don't have enough, create more. You won't get fired if they need you. You can always find a place that compensates you enough for your work. Forget about what the engineering managers want. What's in your power? If you're a professional, give your stakeholders a meaningful time quote. If they don't like it, they can try finding someone who can satisfy their requirements. Or they can make sacrifices so that you can satisfy their requirements, given the amount of workers they have. If you were selling someone watermelons, yet your client wants to pay you 50%, should you give it away for free? There are other people that like watermelons. And if he's the only guy out there that likes watermelons, it's time to start selling oranges. Start cooperating. If your stakeholders won't, find ones that do.
- ipnon 6y ago
  We as laborers have cognitive bias towards the commodity we sell: our time.
deleted 6y ago
[deleted]
Justsignedup 6y ago
This write-up indicates a serious problem in the org: - the tasks are not scoped and thus arbitrary dates are given - the tasks are not scoped and thus no trade-off discussions are had Every time I had to work crazy hrs it was for a good reason in decent companies. Examples being: We literally don't have the money to operate if xyz doesn't get delivered by a specific date. Cut what you can, but not what is critical. With good managers / execs you always debate between what they want build, and what can be built given current realities. If your company just throws arbitrary dates and wants the perfect product expecting you to work like mad... there is a problem in that company.
orf 6y ago
If this is you, then quit. You’re not cattle, and there are better environments to spend your time in.
golemiprague 6y ago
The main reason engineers work for free is immigration, there is a lot of competition and if you refuse to work they will get a slave from India who is willing to work even double the time for free. Lawyers or doctors also have to do overtime but they get payed for it because they have artificial barriers for bringing too many immigrants into their industry. The problem is that most SV types are pro immigration, legal and illegal. They didn't care when it screwed up the working classes and they don't care now when it screws certain white collar jobs.
kerblang 6y ago
A lot of the comments on here seem to have missed the fact that this is about _engineering firms_, not tech companies that employee "software engineers" and what have you. It's not the same world at all.
lisper 6y ago
I think there is a better explanation here, one that does not require such nefarious motives. If you're producing a physical product, then there is usually a more or less linear relationship between the amount of product you produce and the time and effort you put into producing it. If you can make a widget in an hour, then it probably will take you more or less two hours to make two widgets. The constant of proportionality can change with practice and according to skill, but there probably isn't an order of magnitude of difference between an extraordinarily skilled factory worker and a moderately skilled one. With engineering things are radically different. In engineering, and particularly in software engineering, everything is easy once you know how, otherwise it is borderline impossible. Most of the effort involved in engineering work is not in the actual work, but in the figuring-out-how. As a result, there can be multi-order-of-magnitude differences between the effort required by someone who already knows how to do something and someone who still needs to figure it out for the first time. This difference is most pronounced at the bleeding edge of theoretical research, where it can literally take decades to figure out something for the first time, after which the same problem (or variations on the theme) can be solved in minutes or seconds. So the problem becomes: do you pay someone for their efforts or do you pay them for the results? Historically we've paid people for their effort because that was correlated with results, but that is no longer the case. But people tend to bristle at paying for results, particularly if they see that very little (apparent) effort was involved in producing it. There's the old chestnut about the plumber who charged $100 for banging on a pipe. When challenged, the plumber produced an itemized invoice: $5 for banging on the pipe and $95 for knowing where to bang. Engineering problems are often solved by taking a shower. But Harvard MBAs don't like to pay people to take showers. We really need a radical re-thinking of the whole compensation model for this kind of work.
ChrisMarshallNY 6y ago
Marketing and Sales don't seem to have much respect for the laws of physics. They aren't deliberately assuming that engineers will work for free; they just don't care. I removed an anecdote, here, to protect the guilty. Let's say that you talk to a marketing/sales person, and they give an absurdly optimistic estimate for a significant project. So either they would deliver a steaming heap of garbage, at their estimate, or (more likely), the project would take a lot longer than the estimate. Since it is often a "cost plus" contract, we are unlikely to be happy with the outcome. It would probably still be a steaming heap of garbage, but at a much higher price and months late. The thing about late projects, is that there's this huge rush to deliver all the features by the ridiculous date, and, when it gets there, you have this horrendous Rube Goldberg device that is a creaking, barely-usable bug farm. All the rest of the time is spent trying to get it working properly[0]. It would consist of slapping kludge on top of kludge, until the result is 90% cruft. Good estimation is a black art that no one I know has ever gotten right. That includes Yours Truly. I have a friend that wants to do a fairly ambitious NPO project. I was unsatisfied with the interactions he's been having with potential contractors, and just started to do the project myself, which includes adapting the backend (which I already wrote, taking seven months), and writing one of the frontends (which looks to be on track for a couple of months, at least). As usual, it's going about 50% slower than I had planned, but it's definitely coming along. It will be really, really good, but quality takes time. One of the things that I do, is have a very loose project plan that solidifies as the project progresses. It really requires me working alone. Doesn't scale well to teams. Since I'm working on it for free, I guess that I'm a chump, eh? [0] https://www.youtube.com/watch?v=NkQ58I53mjk https://www.youtube.com/watch?v=NkQ58I53mjk
supernova87a 6y ago
I'm going to provide a contrarian opinion here: Managers do this because engineers can rarely be trusted to estimate timelines properly, or at least communicate them. Or it's a rare engineer who does this well. Either they don't even think about timelines, or they grossly underestimate the amount of time that something will take, find dependencies that add a week of unexplained time to fix, or handwave off the parts with least clarity, assuming it will be straightforward. And then you find out it actually takes double the time to do it properly, or the original timeline produced an output that was fully of bugs in the edge cases. So, what happens, managers start to not trust when engineers give estimates, make up their own more "believable" estimates, and also start to expect that if they compress the timeline, it won't be a major issue because the engineering team is putzing around with non-essential work anyway. So, if you want managers to respect and work with realistic timelines, you'd better give them a solid track record of delivering what you said you would in the past. There's blame to go around.
fizixer 6y ago
IMO, and this is what the engineers never get to find out, at the managerial level, a big concern is to keep the 'labor' "fed" (fed here means fed with list of tasks). Meaning, an ideal for a manager in this aspect is to have tasks ready one after the other, so that there is no time during the work week where the engineer is under the impression that (s)he doesn't have anything to do. This is actually not easy. Real work, and real productivity is nonlinear. You have times of serious crunch, and times where there really is not much to do. Entrepreneurs do this better, but in startups there is almost never a time where there is not much to do (there is always something to do). Or flat hierarchies, especially one where the boss is also an ex-engineer, also do relatively better. This really gets worse in the case of org-chart hierarchies in established/blue-chippy companies, where middle management, especially one that has no clue of tech work, solves this problem by creating pipelines of tasks that can safely be described as "bullshit jobs". Some middle managers decide to use up the pipeline in a way so as to keep the engineers occupied 60-70 hours a week, others 40-50 hours a week, something that varies from team to team.
darekkay 6y ago
> The company wants the engineer working unpaid overtime, as much unpaid over time as the engineer can possibly endure. This is why so many engineers at some companies routinely work 70 hour weeks. I am fine doing (justified) overtime, but there's no way I will do this from the goodness of my heart. Some additional work is required for the upcoming release? No problem, but make sure to plan some overtime reduction for me next month.
Animats 6y ago
This is why film scheduling is a real discipline, while software scheduling is not. Film production is unionized, and overtime costs real money, at least time and a half, often more. As I've mentioned before, there's something called a "completion bond" in the film industry.[1] A completion bond guarantees third party investors that a completed, releasable film results, or your money back. Completion bond companies will take a shooting script and cost it out, then quote on what the bond will cost. It's usually 3-5% of production cost. Completion bond companies are thus very good at cost estimation. They keep records on what and who has overrun budgets in the past, and by how much, and adjust their estimates accordingly. The completion bond company has several options when a film is in trouble. They can put people on set to watch where the money is going. They can put in more money, which is the first thing to be paid back when the film releases. As a last resort, they can fire the director and producer and put their own people in, to get something finished. That's seldom done. "Bad Girls" (1994) is a film where that happened. It's a terrible movie, but they got half the production cost back, which beats zero. The threat of that happening keeps management in line. Big career setback for a director and producer when that happens. [1] https://www.eqgroup.com/completion_bond/ https://www.eqgroup.com/completion_bond/
- kthejoker2 6y ago
  Film scheduling is a "real" discipline because the range of effort for (major motion picture) filmmaking projects is extremely narrow, the dependencies are all known, and all the projects are bottom up in nature i.e. this number of shots, sets, cameras, explosions, etc. equals X more dollars and Y more hours to produce it. If every software project ever made was just a CRUD app, with the only variations being the number of fields and the amount of data validation, and we'd been doing it for 100 years, I'm sure our ability to finish on time and on budget would be much less maligned.
  - Animats 6y ago
    Someone directly involved with movie production should comment on this.
riazrizvi 6y ago
Perhaps. But in my experience as an engineer, there is a widespread human tendency to take requests into a cave and not come out until something too 'opinionated' is built. When creating for/with others, often what is preferred is a 'dialogue' approach, because everyone has an opinion on what to build. If a product manager asks you to build a Twitter clone, which you reply would take a year, and they counter with 'you've got two days', then make a 2-day Twitter clone. You might build just a couple of key interactions, and it might only operate at toy-scale, or you might just write a bunch of stubs that print out what the system would do, but in general, if someone counters in response to your estimate with a request to do it in 1/x of the time, they are usually communicating "I don't need something built to that level, I want a 1/x pass of what you imagine". So really these aggressive deadlines are more about project stakeholder's desire to have more control over the design process. Of course a creator might not want to share control, but that is a different issue to 'being forced to work for free'.
curiousllama 6y ago
This is interesting because one of the first project scoping lessons I learned was that engineers rarely give accurate time estimates. I would always go back to my boss having tacked on 20-30% of the time and make sure it’s clear that it’s an estimate and could take longer. Who wants a product that was rushed? If there’s not enough time, cut scope. As a Project/product/eng manager, it’s my job to buy time, hit the dates I set, and make my boss more $$$. If I’m saying stuff like “a month is too long; you have until Friday,” I screwed something up or got screwed by someone else. Regardless, the engineers should leave because it’ll keep happening.
deleted 6y ago
[deleted]
wdb 6y ago
My pet peeve was managers that didn’t ask for an estimation and said to be done in Feb 2021 and then forced you to work late/do overtime while they went home at 5pm every day. Long ago I decided if the (project) manager can’t be arsed to be around, to answer questions, arrange dinner, why should I work late? If it’s not that important for the manager stay late too, even to give moral support.
jchook 6y ago
Hm this article describes a bureaucratic management nightmare BUT, the opposite is also bad. Parkinson’s Principle is real. If you give yourself a long time to complete a project, it will take that long. Also many projects are a total waste of time. It’s often a good strategy to get the smallest possible experiment (to test your hypothesis) in front of customers ASAP and get the feedback loop rolling before you sink months into something untested.
stefs 6y ago
>It probably has something to do with the fact that large engineering companies can afford to hire lobbyists and engineers cannot. i'd lobbyists for employees are called unions. you can afford to hire lobbyists by paying union dues.
gwbas1c 6y ago
I figured this out shortly before I started my career and screen out these kinds of employers.
forgotmypw17 6y ago
I've seen this many places I worked. Probably most. It's especially prevalent in agencies, because the are two or more layers of this crap happening simultaneously. First, the client does it to the agency, then the big boss does it to the managers, then the managers do it to the programmers. I think it is also [connected with|the primary reason for] ageism in the industry: As you gain experience, you learn to not fall for this kind of crap anymore. When I was new and insecure, clinging to my job thinking no one else will hire me, I put up with all sorts of crap I wouldn't put up with later in my career.
dorkwood 6y ago
"My suspicion is that this interplay between engineering manager and engineer is nothing but a game. Either to the manager, or to the company. Either it is a show of power by the manager, or it is a strategy for increasing the company's profits. 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. But, he must appear to be playing the company's game. The company wants the engineer working unpaid overtime, as much unpaid over time as the engineer can possibly endure." At my last job, this was definitely the case. I'd come in with a realistic estimate, and everyone would be shocked. This is too much time, they'd say. How can we cut this down? There would be a discussion. We'd play a little game where we'd pretend we could cut corners over here and find efficiencies over there, and hey presto, we'd get it done in half the time. Now everyone is happy. Except nothing has changed. The job ends up taking as long, or longer, than the original estimate, but everyone has to work overtime to reach the deadline. I suspect the same thing as the author; everyone knew we weren't actually cutting the time down. We were just promising to get it done faster for free.
hevelvarik 6y ago
Don’t need to read the comments to know mine is redundant but whatever drives one to leave comments on websites compels me. I have never worked in such an environment and don’t see how one could. You can demand someone jump off the building but not onto it. If there isn’t enough time, then there isn’t enough time.
blnqr 6y ago
I had a co-founder who really thrived on challenges. Not impossible deadlines, but almost "I dare you to do this by Monday" kind of thing.
mostlyghostly 6y ago
It started well and devolved into a bitter rant about the universe. So... here's some perspective from a career on both sides of the table.... (manager and engineer) - For many teams and personalities, it is very hard to ship anything without a deadline. (as a solo founder, I actually use this psychology on myself to stay on track.) - Short chunks and deadlines work better than longer ones. - Peer pressure is a powerful stimulant. - Your time is not of equal value. You don't really have seventy hours of quality work in a week. You've got maybe 15 "truly inspired" hours, 25 "grind it out" hours, and a lot of filler, face time, and paper shuffling after that. If you're smart, you slip in some employer funded personal growth & education time into that mix. The classic mistake is to screw up the mix. I actually run into this as a freelancer. My rate for "truly inspired" time (real thinking about theory, architecture, influencing others, lecturing, or consulting on high level topics - eg. I must be fully present and prepared) is between $150 - $500 per hour (depending on the degree to which I'm inspired by the topic in question; $500 if I couldn't give a crap, $150 if I'm truly interested), "grind time" is $75 - $90 (you're paying for work without face time or deep insights, done at my convenience), and I'm unsure how to sell people filler, face-time, and paper shuffling. My typical solution is to go take a nap. By the way... once you deduct pitching and running the business (10 hours, mix of inspired & grind), that means a freelancer REALLY has only 20 - 25 hours of useful time to sell in the course of a week. Past that, you're either working much harder than an employee or trying sub in filler and hoping your client doesn't notice it... The typical employee is selling 15 - 25 hours of grind, perhaps 5 of inspired time (if you're lucky) and as much filler and self-directed time as you can get away with. From an employee satisfaction perspective, inspired is a win, filler / self-directed time is neutral to a win (depending on how well you entertain yourself), grind is a negative. Grind time is less onerous if you feel like you are accomplishing something in the process. My goal as a boss is to get as much grind / inspired time for my buck as possible, since that's what generates output. (employee development matters but is a complex payback balancing future productivity / retention / motivation; filler doesn't really help me at all) The essential management challenge is spotting people slipping filler into a day and telling them to get back to grind. Good bosses protect your inspired time. Someday I'll hopefully get to work for one again.... (LOL) There's nothing REALLY wrong with doing an 80 hour sprint one week if you can engineer some paid downtime later. I have weeks where I'm exploited and - to be fair - others where I'm massively overcharging my employer. It evens out.
stephenboyd 6y ago
I hope the author and the 200 upvoters find better employment soon. The tone of the article suggests that this is assumed to be the universal way of software development, but it's basically the opposite of how things are done at my workplace. OP's company sounds like it's run by some Charles Dickens villains. My manager only gives me a few tasks per year, mostly administrative things like peer reviews that everyone at the company needs to do. All my real work comes from my team's product owner (not in my reporting chain, aka a product manager), who defines objectives and sets priorities for my team. My fellow developer teammates and I collaborate to give an estimate for the objective, architect a plan for it, break it down into smaller 'stories' that ideally take less than a week each to complete, and then actually implement those stories with programming. If we don't know enough to estimate something, we'll make a task devoting some time to researching just enough for an estimate. It's always collegial, often fun, and very efficient at producing high quality software on a predictable timeline. But my employer's product is basically a SaaS and the author works at a consulting company that rents our engineers by the hour. Is this kind of dysfunction the norm at consulting companies?
ineedasername 6y ago
If this is true, it's too focused on engineering. This is project management in general, not just for technical jobs. But I also think the author gives too much credit to management. There's no conspiracy to tighten deadlines to get free work, at least not in a vast majority of places. Hanlon's Razor comes in to play here: don't attribute it to malice if it can also be attributed to stupidity.
zalkota 6y ago
Engineer here, i can’t relate to this. Find a new job.
kinkrtyavimoodh 6y ago
Is it unreasonable to expect someone being paid 300K a year to work more than an average of eight hours a day every once in a while? It's hilarious how when there is a general article about developer productivity, the comments section is full of people claiming how programming is not like manual labor that you can do for eight hours straight, and that most work in bursts of a few hours of intense intellectual activity surrounded by taking time off. How many software engineers can, hand to heart, claim honestly that they put in 8 full productive working hours day after day the way a cashier or warehouse worker does?
- jaaames 6y ago
  Very few, and I don't think it's a reasonable parallel. I don't think 8 hours of cognitively demanding, yet physically sedentary work, is part of our human nature. If you frame it in the sense that we are just monkeys in shoes, it wouldn't be at all reasonable to expect someone to crouch in the grass and be highly alert for hours at a time. The corollary would be a job that's physically engaging (read, not demanding) but cognitively basic, e.g. moving boxes in a warehouse, gardening. The difference is one form of labor has leveraged output (writing code), vs linear output (moving boxes).
  - kinkrtyavimoodh 6y ago
    You are completely right but that is precisely my point. Counting hours for a job like programming is pointless. If you also agree that it's not reasonable to expect 8 continuous hours of intellectual labor, it should also not be reasonable on part of employees to be wedded to their 8-hour-workday. No one seems to have a problem chit-chatting at work, or engaging in other forms of recreation, but everyone seems to love counting hours when it comes to reasonable work expected from them. I notice this in my job working with a team in Europe that my company has acqui-hired (this is relevant because until then they were a purely European company in terms of composition and culture). We are a pretty standard SV startup in terms of culture, we are in the office for ~9 hours a day (that includes lunch etc.) but we trust our employees to manage their work, which includes the self-awareness of knowing when you have not done enough during the day and compensating by working a bit more whenever you see fit. In contrast, the European team does strict 8 hours a day (including lunch), does NOT have better average productivity than ours, but gets very upset at the occasional expectation that they meet deadlines with similar 'vigor' as their SV counterparts. I'm sure the same people would complain about pay disparity between the bay area and Europe and find it unfair.
flubert 6y ago
I'm sure none of this applies to any of us here, but I've heard rumors that some people need deadlines to complete tasks. As in you set a deadline, and it doesn't really matter when, and check up with the employee on a regular basis. The interim feedback is always that things are coming along, but there is an awful lot of office chit-chat, browsing Facebook when I walk by, etc.. And then one week before the deadline all of a sudden there is griping and moaning about crunch time, but now there is sudden focus, and things get done. I'm a new manager, so I wish I had a better way to work with this dynamic. Smaller milestones? How small before it becomes micromanaging? But to the main point, if you are routinely working 70 hours a week that is a toxic work environment and you should leave.
dastx 6y ago
I'm only about 8 years into my career and if there is one thing I've come to realise, it's that a good chunk of deadlines are arbitrary dates plucked out of thin air. We as engineers are horrible at guessing how long something things. I've yet to meet anyone who has been able to accurately guess how long a certain task takes. Rightly so, because engineering wouldn't be engineering if all the problems were already solved. If you're in a workplace that imposes arbitrary dates on you, you should probably look elsewhere. There are better companies out there.
tanseydavid 6y ago
Thank you so much for this. I think you have managed to strike a perfect balance in tone -- no small task. You are quite direct in your message and do not sugar-coat any of your points but still avoid sounding 'bitter'. It has been my direct experience that the phenomenon you describe seems to be widely in practice at this point, across many organization of different size and disciplines.
awillen 6y ago
This is one of those times when you shouldn't attribute malice (or greed, I guess) to something that ought to be attributed to incompetence. I've been a PM for long enough to have dealt with lots of situations like this, and never once have I had the slightest inkling that there was any plan to overwork engineers in order to get them to work for free. The good companies I've dealt with understood that engineers are vital to their success and try to make them happy. The short term benefits of getting free work by bullying them with deadlines doesn't outweigh the downside of them leaving. The bad companies just don't think like this - they want cheap labor so they outsource engineering to the cheapest possible places. Based on this post, I would strongly recommend the author get a new job.
BMSmnqXAE4yfe1 6y ago
I have an impression that the article is about programmers, not engineers.
WrtCdEvrydy 6y ago
From a good manager of mine, "deadlines are cost control methods, unless we sent an email to a client or there's some pending legal requirement, those deadlines are to keep the costs of a project from skyrocketing". 2 years later, only two deadlines have ever been set in stone: the GDPR one and one we sent an email from Marketing about. I think he was right.
pkalinowski 6y ago
In Europe, giving employee less time than it's needed to complete a task is called mobbing.
dexterlagan 6y ago
IT director for a multinational here: I apologize if this has been said, but here are a few reasons why these deadlines are set to be broken from the start: 1) estimating dev time is a hard (as in NP-hard) problem. Nobody in the world can do it well. Ultimately, deadlines are meaningless in terms of actual dev time. 2) being an engineer myself, I know full well that if I'm given a fair or comfortable deadline, I'll code the thing quickly and enjoy some free time until the deadline. When the deadline comes, we'll find out there was lots of bugs. We're lazy/efficient animals. 3) if I'm given a short deadline, I'll complain but will work much harder under pressure. I'll still deliver something with bugs, but they will be fixed quickly, still under pressure. And so we give deadlines that are far off the mark, sometimes knowingly, in order to make sure the actual finished, *debugged* product is ready by the time we make the announcement/presentation/sale.
mbrodersen 6y ago
If you don't stand up for yourself, and accept whatever shit people throw at you, then you will get crushed.

270 points by sT370ma2 6y ago

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 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.

TuringNYC 6y ago
Thanks for "Chicken Genius Singapore", "Dave Lee on Investing", and "Solving the Money Problem" -- these look great! Do you have any other recommendations?
- maxharris 6y ago
  Cathie D. Wood, founder and CEO of ARK Invest, also does periodic YouTube videos. I love her!
gowld 6y ago
That seems not true. The slacker / incompetent gets the same stock growth as the overworking genius.
- bird_monster 6y ago
  This statement is a lot to unpack. > 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
htrp 6y ago
> 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).
x87678r 6y ago
> 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. That's great for Apple engineers but what if you work for HP/Intel/IBM and just see a steady declining stock?
- someguydave 6y ago
  they should realize their company business model sucks and bail
  - rabidrat 6y ago
    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.
    - maxharris 6y ago
      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: https://news.ycombinator.com/item?id=22958528 https://news.ycombinator.com/item?id=22958528 https://news.ycombinator.com/item?id=22970810 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.
deleted 6y ago
[deleted]

jimbob45 6y ago

It goes both ways. Many weak deadlines allow engineers to slack off when they otherwise might not have.

TuringNYC 6y ago

>>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.

m463 6y ago
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.
- cwillu 6y ago
  For those interested in the quiz: https://books.google.ca/books?id=U5VCAwAAQBAJ&lpg=PP1&pg=PT58#v=onepage&q&f=false https://books.google.ca/books?id=U5VCAwAAQBAJ&lpg=PP1&pg=PT5...
  - Zippogriff 6y ago
    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?

gorzynsk 6y ago

Hanlon's razor is an aphorism, "Never attribute to malice that which is adequately explained by stupidity"

bravura 6y ago
“Any sufficiently advanced incompetence is indistinguishable from malice.” - Grey's law
- RankingMember 6y ago
  Is there a law yet that describes how, for any situation, someone's created a law that applies to it? (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!)
- AnimalMuppet 6y ago
  I've quoted that before, but never heard it called "Grey's law". Who is Grey?
- TeMPOraL 6y ago
  "Never attribute to stupidity that which can be adequately explained by systemic incentives promoting malice." -- Yours Truly's Razor ;) (though I still prefer "Hanlon's Handgun") https://news.ycombinator.com/item?id=21691718 https://news.ycombinator.com/item?id=21691718
ouid 6y ago
Hanlon's razor is a boundary condition. Over time strategies improve, including malicious ones.
ardit33 6y ago
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. Mafia 101

ThePadawan 6y ago

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.)

pkaye 6y ago
Then why do so many engineers come to work in the US?
- irrational 6y ago
  Is this still the case?
  - MiroF 6y ago
    Yes? As long as the pay differences are what they are, why wouldn't it be?
    - irrational 6y ago
      I thought the Trump administration was working overtime to limit HB1, immigration,etc.
- ThePadawan 6y ago
  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.

deleted 6y ago

[deleted]

fishtoaster 6y ago

There's a lot to unpack here. "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).

pdonis 6y ago
> 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.

OldHand2018 6y ago

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?

moron4hire 6y ago
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.
- OldHand2018 6y ago
  That's a good point. And except in fixed-price contracts, there is no incentive to become more productive - they would rather you work more hours.
  - moron4hire 6y ago
    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).

umvi 6y ago

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. [0] https://en.wikipedia.org/wiki/Parkinson%27s_law https://en.wikipedia.org/wiki/Parkinson%27s_law

ghaff 6y ago
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."

irrational 6y ago

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.

Clubber 6y ago
"Never attribute to malice that which is adequately explained by stupidity" -Hanlon's razor
- liability 6y ago
  Advanced malicious actors often feign incompetence when caught, to take advantage of the naive and forgiving.
  - quickthrower2 6y ago
    This is a basic part of the human OS. It’s a skill that can be seen from 4 years of age. It’s the other way around: We learn not to do this.
  - lotsofpulp 6y ago
    Maybe one should assume the people who say the hanlon razor saying are advanced malicious actors.
  - Clubber 6y ago
    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.
matheusmoreira 6y ago
> 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?

deleted 6y ago

[deleted]

cortesoft 6y ago

This seems to be describing a particular problem of working at an engineering consulting company. I have never had this experience in my career.

snarkypixel 6y ago

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

m0zg 6y ago

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.

duxup 6y ago

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.

diogenescynic 6y ago

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.

skwirl 6y ago

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.

zwieback 6y ago

It's not like that where I work. Scheduling and tracking tasks is hard but it sounds like the author needs to find a new job.

encoderer 6y ago

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.

JJMcJ 6y ago

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.

deleted 6y ago
[deleted]

GoToRO 6y ago

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.

cryptica 6y ago

>> 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. If you don't believe me, just watch Hidden Secrets of Money: https://www.youtube.com/watch?v=DyV0OfU3-FU&t=2s 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.

reillyse 6y ago

Is this article set in the late 90's. Times have changed, get a new job.

dboreham 6y ago

Penny dropping.. Now to figure out how to set boundaries in the abusive relationship.

jopsen 6y ago

Wow, I suspect milage may vary depending on where you work. 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" :)

godot 6y ago
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?

crazygringo 6y ago

As a former product manager with lots of experience with both engineering and management: no, that's not what deadlines are designed for. Deadlines exist because software doesn't exist in a vacuum, but other people depend on it being delivered. Whether so it can be sold to make money before someone goes out of business or a partnership fails, or its features arrive on time as promised for the start of the school year which can't be moved, or as the foundation for another project that has its own equally valid deadline later on. Deadlines exist because people need to make plans and be able to rely on them, which is how our entire society and economy function. People work overtime in every industry to meet deadlines, it's not just engineers. The only question is whether or it's good for you financially. Whenever you take a job, it's up to you to do your due diligence in talking to other employees to find out what the working hours and flexibility are like in practice, and judge that against the salary, and decide if it makes sense for you. Fortunately, there is huge variation in both salaries and expectations of hours per week, and the best thing you can do about places that pay little and work you long is to not take their job offer, or leave. Then supply and demand can do its thing and they'll be forced to adjust or go out of business.

marcinzm 6y ago
>Deadlines exist because software doesn't exist in a vacuum, but other people depend on it being delivered. Exactly, even without external deliverables there are likely other internal initiatives that depend on the project or tie into it. Might even be something as simple as the QA team being booked on another project in a month that does have a hard deadline. So as long as something in the org has a hard external deadline there are going to be ripples that touch all projects in the org. Also, my experience is that if you communicate early that features need to be cut to meet the deadlines most managers will be happy.
thomas 6y ago
Well put and fully agreed. I don’t think engineers are in any way a special case here. In fact it can be much worse for people whose skillset is easier to replace.
- 6y ago

kache_ 6y ago

Leverage is your tool. If you don't have enough, create more. You won't get fired if they need you. You can always find a place that compensates you enough for your work. Forget about what the engineering managers want. What's in your power? If you're a professional, give your stakeholders a meaningful time quote. If they don't like it, they can try finding someone who can satisfy their requirements. Or they can make sacrifices so that you can satisfy their requirements, given the amount of workers they have. If you were selling someone watermelons, yet your client wants to pay you 50%, should you give it away for free? There are other people that like watermelons. And if he's the only guy out there that likes watermelons, it's time to start selling oranges. Start cooperating. If your stakeholders won't, find ones that do.

ipnon 6y ago
We as laborers have cognitive bias towards the commodity we sell: our time.

deleted 6y ago

[deleted]

Justsignedup 6y ago

This write-up indicates a serious problem in the org: - the tasks are not scoped and thus arbitrary dates are given - the tasks are not scoped and thus no trade-off discussions are had Every time I had to work crazy hrs it was for a good reason in decent companies. Examples being: We literally don't have the money to operate if xyz doesn't get delivered by a specific date. Cut what you can, but not what is critical. With good managers / execs you always debate between what they want build, and what can be built given current realities. If your company just throws arbitrary dates and wants the perfect product expecting you to work like mad... there is a problem in that company.

orf 6y ago

If this is you, then quit. You’re not cattle, and there are better environments to spend your time in.

golemiprague 6y ago

The main reason engineers work for free is immigration, there is a lot of competition and if you refuse to work they will get a slave from India who is willing to work even double the time for free. Lawyers or doctors also have to do overtime but they get payed for it because they have artificial barriers for bringing too many immigrants into their industry. The problem is that most SV types are pro immigration, legal and illegal. They didn't care when it screwed up the working classes and they don't care now when it screws certain white collar jobs.

kerblang 6y ago

A lot of the comments on here seem to have missed the fact that this is about _engineering firms_, not tech companies that employee "software engineers" and what have you. It's not the same world at all.

lisper 6y ago

I think there is a better explanation here, one that does not require such nefarious motives. If you're producing a physical product, then there is usually a more or less linear relationship between the amount of product you produce and the time and effort you put into producing it. If you can make a widget in an hour, then it probably will take you more or less two hours to make two widgets. The constant of proportionality can change with practice and according to skill, but there probably isn't an order of magnitude of difference between an extraordinarily skilled factory worker and a moderately skilled one. With engineering things are radically different. In engineering, and particularly in software engineering, everything is easy once you know how, otherwise it is borderline impossible. Most of the effort involved in engineering work is not in the actual work, but in the figuring-out-how. As a result, there can be multi-order-of-magnitude differences between the effort required by someone who already knows how to do something and someone who still needs to figure it out for the first time. This difference is most pronounced at the bleeding edge of theoretical research, where it can literally take decades to figure out something for the first time, after which the same problem (or variations on the theme) can be solved in minutes or seconds. So the problem becomes: do you pay someone for their efforts or do you pay them for the results? Historically we've paid people for their effort because that was correlated with results, but that is no longer the case. But people tend to bristle at paying for results, particularly if they see that very little (apparent) effort was involved in producing it. There's the old chestnut about the plumber who charged $100 for banging on a pipe. When challenged, the plumber produced an itemized invoice: $5 for banging on the pipe and $95 for knowing where to bang. Engineering problems are often solved by taking a shower. But Harvard MBAs don't like to pay people to take showers. We really need a radical re-thinking of the whole compensation model for this kind of work.

ChrisMarshallNY 6y ago

Marketing and Sales don't seem to have much respect for the laws of physics. They aren't deliberately assuming that engineers will work for free; they just don't care. I removed an anecdote, here, to protect the guilty. Let's say that you talk to a marketing/sales person, and they give an absurdly optimistic estimate for a significant project. So either they would deliver a steaming heap of garbage, at their estimate, or (more likely), the project would take a lot longer than the estimate. Since it is often a "cost plus" contract, we are unlikely to be happy with the outcome. It would probably still be a steaming heap of garbage, but at a much higher price and months late. The thing about late projects, is that there's this huge rush to deliver all the features by the ridiculous date, and, when it gets there, you have this horrendous Rube Goldberg device that is a creaking, barely-usable bug farm. All the rest of the time is spent trying to get it working properly[0]. It would consist of slapping kludge on top of kludge, until the result is 90% cruft. Good estimation is a black art that no one I know has ever gotten right. That includes Yours Truly. I have a friend that wants to do a fairly ambitious NPO project. I was unsatisfied with the interactions he's been having with potential contractors, and just started to do the project myself, which includes adapting the backend (which I already wrote, taking seven months), and writing one of the frontends (which looks to be on track for a couple of months, at least). As usual, it's going about 50% slower than I had planned, but it's definitely coming along. It will be really, really good, but quality takes time. One of the things that I do, is have a very loose project plan that solidifies as the project progresses. It really requires me working alone. Doesn't scale well to teams. Since I'm working on it for free, I guess that I'm a chump, eh? [0] https://www.youtube.com/watch?v=NkQ58I53mjk https://www.youtube.com/watch?v=NkQ58I53mjk

supernova87a 6y ago

I'm going to provide a contrarian opinion here: Managers do this because engineers can rarely be trusted to estimate timelines properly, or at least communicate them. Or it's a rare engineer who does this well. Either they don't even think about timelines, or they grossly underestimate the amount of time that something will take, find dependencies that add a week of unexplained time to fix, or handwave off the parts with least clarity, assuming it will be straightforward. And then you find out it actually takes double the time to do it properly, or the original timeline produced an output that was fully of bugs in the edge cases. So, what happens, managers start to not trust when engineers give estimates, make up their own more "believable" estimates, and also start to expect that if they compress the timeline, it won't be a major issue because the engineering team is putzing around with non-essential work anyway. So, if you want managers to respect and work with realistic timelines, you'd better give them a solid track record of delivering what you said you would in the past. There's blame to go around.

fizixer 6y ago

IMO, and this is what the engineers never get to find out, at the managerial level, a big concern is to keep the 'labor' "fed" (fed here means fed with list of tasks). Meaning, an ideal for a manager in this aspect is to have tasks ready one after the other, so that there is no time during the work week where the engineer is under the impression that (s)he doesn't have anything to do. This is actually not easy. Real work, and real productivity is nonlinear. You have times of serious crunch, and times where there really is not much to do. Entrepreneurs do this better, but in startups there is almost never a time where there is not much to do (there is always something to do). Or flat hierarchies, especially one where the boss is also an ex-engineer, also do relatively better. This really gets worse in the case of org-chart hierarchies in established/blue-chippy companies, where middle management, especially one that has no clue of tech work, solves this problem by creating pipelines of tasks that can safely be described as "bullshit jobs". Some middle managers decide to use up the pipeline in a way so as to keep the engineers occupied 60-70 hours a week, others 40-50 hours a week, something that varies from team to team.

darekkay 6y ago

> The company wants the engineer working unpaid overtime, as much unpaid over time as the engineer can possibly endure. This is why so many engineers at some companies routinely work 70 hour weeks. I am fine doing (justified) overtime, but there's no way I will do this from the goodness of my heart. Some additional work is required for the upcoming release? No problem, but make sure to plan some overtime reduction for me next month.

Animats 6y ago

This is why film scheduling is a real discipline, while software scheduling is not. Film production is unionized, and overtime costs real money, at least time and a half, often more. As I've mentioned before, there's something called a "completion bond" in the film industry.[1] A completion bond guarantees third party investors that a completed, releasable film results, or your money back. Completion bond companies will take a shooting script and cost it out, then quote on what the bond will cost. It's usually 3-5% of production cost. Completion bond companies are thus very good at cost estimation. They keep records on what and who has overrun budgets in the past, and by how much, and adjust their estimates accordingly. The completion bond company has several options when a film is in trouble. They can put people on set to watch where the money is going. They can put in more money, which is the first thing to be paid back when the film releases. As a last resort, they can fire the director and producer and put their own people in, to get something finished. That's seldom done. "Bad Girls" (1994) is a film where that happened. It's a terrible movie, but they got half the production cost back, which beats zero. The threat of that happening keeps management in line. Big career setback for a director and producer when that happens. [1] https://www.eqgroup.com/completion_bond/ https://www.eqgroup.com/completion_bond/

kthejoker2 6y ago
Film scheduling is a "real" discipline because the range of effort for (major motion picture) filmmaking projects is extremely narrow, the dependencies are all known, and all the projects are bottom up in nature i.e. this number of shots, sets, cameras, explosions, etc. equals X more dollars and Y more hours to produce it. If every software project ever made was just a CRUD app, with the only variations being the number of fields and the amount of data validation, and we'd been doing it for 100 years, I'm sure our ability to finish on time and on budget would be much less maligned.
- Animats 6y ago
  Someone directly involved with movie production should comment on this.

riazrizvi 6y ago

Perhaps. But in my experience as an engineer, there is a widespread human tendency to take requests into a cave and not come out until something too 'opinionated' is built. When creating for/with others, often what is preferred is a 'dialogue' approach, because everyone has an opinion on what to build. If a product manager asks you to build a Twitter clone, which you reply would take a year, and they counter with 'you've got two days', then make a 2-day Twitter clone. You might build just a couple of key interactions, and it might only operate at toy-scale, or you might just write a bunch of stubs that print out what the system would do, but in general, if someone counters in response to your estimate with a request to do it in 1/x of the time, they are usually communicating "I don't need something built to that level, I want a 1/x pass of what you imagine". So really these aggressive deadlines are more about project stakeholder's desire to have more control over the design process. Of course a creator might not want to share control, but that is a different issue to 'being forced to work for free'.

curiousllama 6y ago

This is interesting because one of the first project scoping lessons I learned was that engineers rarely give accurate time estimates. I would always go back to my boss having tacked on 20-30% of the time and make sure it’s clear that it’s an estimate and could take longer. Who wants a product that was rushed? If there’s not enough time, cut scope. As a Project/product/eng manager, it’s my job to buy time, hit the dates I set, and make my boss more $$$. If I’m saying stuff like “a month is too long; you have until Friday,” I screwed something up or got screwed by someone else. Regardless, the engineers should leave because it’ll keep happening.

deleted 6y ago

[deleted]

wdb 6y ago

My pet peeve was managers that didn’t ask for an estimation and said to be done in Feb 2021 and then forced you to work late/do overtime while they went home at 5pm every day. Long ago I decided if the (project) manager can’t be arsed to be around, to answer questions, arrange dinner, why should I work late? If it’s not that important for the manager stay late too, even to give moral support.

jchook 6y ago

Hm this article describes a bureaucratic management nightmare BUT, the opposite is also bad. Parkinson’s Principle is real. If you give yourself a long time to complete a project, it will take that long. Also many projects are a total waste of time. It’s often a good strategy to get the smallest possible experiment (to test your hypothesis) in front of customers ASAP and get the feedback loop rolling before you sink months into something untested.

stefs 6y ago

>It probably has something to do with the fact that large engineering companies can afford to hire lobbyists and engineers cannot. i'd lobbyists for employees are called unions. you can afford to hire lobbyists by paying union dues.

gwbas1c 6y ago

I figured this out shortly before I started my career and screen out these kinds of employers.

forgotmypw17 6y ago

I've seen this many places I worked. Probably most. It's especially prevalent in agencies, because the are two or more layers of this crap happening simultaneously. First, the client does it to the agency, then the big boss does it to the managers, then the managers do it to the programmers. I think it is also [connected with|the primary reason for] ageism in the industry: As you gain experience, you learn to not fall for this kind of crap anymore. When I was new and insecure, clinging to my job thinking no one else will hire me, I put up with all sorts of crap I wouldn't put up with later in my career.

dorkwood 6y ago

"My suspicion is that this interplay between engineering manager and engineer is nothing but a game. Either to the manager, or to the company. Either it is a show of power by the manager, or it is a strategy for increasing the company's profits. 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. But, he must appear to be playing the company's game. The company wants the engineer working unpaid overtime, as much unpaid over time as the engineer can possibly endure." At my last job, this was definitely the case. I'd come in with a realistic estimate, and everyone would be shocked. This is too much time, they'd say. How can we cut this down? There would be a discussion. We'd play a little game where we'd pretend we could cut corners over here and find efficiencies over there, and hey presto, we'd get it done in half the time. Now everyone is happy. Except nothing has changed. The job ends up taking as long, or longer, than the original estimate, but everyone has to work overtime to reach the deadline. I suspect the same thing as the author; everyone knew we weren't actually cutting the time down. We were just promising to get it done faster for free.

hevelvarik 6y ago

Don’t need to read the comments to know mine is redundant but whatever drives one to leave comments on websites compels me. I have never worked in such an environment and don’t see how one could. You can demand someone jump off the building but not onto it. If there isn’t enough time, then there isn’t enough time.

blnqr 6y ago

I had a co-founder who really thrived on challenges. Not impossible deadlines, but almost "I dare you to do this by Monday" kind of thing.

mostlyghostly 6y ago

It started well and devolved into a bitter rant about the universe. So... here's some perspective from a career on both sides of the table.... (manager and engineer) - For many teams and personalities, it is very hard to ship anything without a deadline. (as a solo founder, I actually use this psychology on myself to stay on track.) - Short chunks and deadlines work better than longer ones. - Peer pressure is a powerful stimulant. - Your time is not of equal value. You don't really have seventy hours of quality work in a week. You've got maybe 15 "truly inspired" hours, 25 "grind it out" hours, and a lot of filler, face time, and paper shuffling after that. If you're smart, you slip in some employer funded personal growth & education time into that mix. The classic mistake is to screw up the mix. I actually run into this as a freelancer. My rate for "truly inspired" time (real thinking about theory, architecture, influencing others, lecturing, or consulting on high level topics - eg. I must be fully present and prepared) is between $150 - $500 per hour (depending on the degree to which I'm inspired by the topic in question; $500 if I couldn't give a crap, $150 if I'm truly interested), "grind time" is $75 - $90 (you're paying for work without face time or deep insights, done at my convenience), and I'm unsure how to sell people filler, face-time, and paper shuffling. My typical solution is to go take a nap. By the way... once you deduct pitching and running the business (10 hours, mix of inspired & grind), that means a freelancer REALLY has only 20 - 25 hours of useful time to sell in the course of a week. Past that, you're either working much harder than an employee or trying sub in filler and hoping your client doesn't notice it... The typical employee is selling 15 - 25 hours of grind, perhaps 5 of inspired time (if you're lucky) and as much filler and self-directed time as you can get away with. From an employee satisfaction perspective, inspired is a win, filler / self-directed time is neutral to a win (depending on how well you entertain yourself), grind is a negative. Grind time is less onerous if you feel like you are accomplishing something in the process. My goal as a boss is to get as much grind / inspired time for my buck as possible, since that's what generates output. (employee development matters but is a complex payback balancing future productivity / retention / motivation; filler doesn't really help me at all) The essential management challenge is spotting people slipping filler into a day and telling them to get back to grind. Good bosses protect your inspired time. Someday I'll hopefully get to work for one again.... (LOL) There's nothing REALLY wrong with doing an 80 hour sprint one week if you can engineer some paid downtime later. I have weeks where I'm exploited and - to be fair - others where I'm massively overcharging my employer. It evens out.

stephenboyd 6y ago

I hope the author and the 200 upvoters find better employment soon. The tone of the article suggests that this is assumed to be the universal way of software development, but it's basically the opposite of how things are done at my workplace. OP's company sounds like it's run by some Charles Dickens villains. My manager only gives me a few tasks per year, mostly administrative things like peer reviews that everyone at the company needs to do. All my real work comes from my team's product owner (not in my reporting chain, aka a product manager), who defines objectives and sets priorities for my team. My fellow developer teammates and I collaborate to give an estimate for the objective, architect a plan for it, break it down into smaller 'stories' that ideally take less than a week each to complete, and then actually implement those stories with programming. If we don't know enough to estimate something, we'll make a task devoting some time to researching just enough for an estimate. It's always collegial, often fun, and very efficient at producing high quality software on a predictable timeline. But my employer's product is basically a SaaS and the author works at a consulting company that rents our engineers by the hour. Is this kind of dysfunction the norm at consulting companies?

ineedasername 6y ago

If this is true, it's too focused on engineering. This is project management in general, not just for technical jobs. But I also think the author gives too much credit to management. There's no conspiracy to tighten deadlines to get free work, at least not in a vast majority of places. Hanlon's Razor comes in to play here: don't attribute it to malice if it can also be attributed to stupidity.

zalkota 6y ago

Engineer here, i can’t relate to this. Find a new job.

kinkrtyavimoodh 6y ago

Is it unreasonable to expect someone being paid 300K a year to work more than an average of eight hours a day every once in a while? It's hilarious how when there is a general article about developer productivity, the comments section is full of people claiming how programming is not like manual labor that you can do for eight hours straight, and that most work in bursts of a few hours of intense intellectual activity surrounded by taking time off. How many software engineers can, hand to heart, claim honestly that they put in 8 full productive working hours day after day the way a cashier or warehouse worker does?

jaaames 6y ago
Very few, and I don't think it's a reasonable parallel. I don't think 8 hours of cognitively demanding, yet physically sedentary work, is part of our human nature. If you frame it in the sense that we are just monkeys in shoes, it wouldn't be at all reasonable to expect someone to crouch in the grass and be highly alert for hours at a time. The corollary would be a job that's physically engaging (read, not demanding) but cognitively basic, e.g. moving boxes in a warehouse, gardening. The difference is one form of labor has leveraged output (writing code), vs linear output (moving boxes).
- kinkrtyavimoodh 6y ago
  You are completely right but that is precisely my point. Counting hours for a job like programming is pointless. If you also agree that it's not reasonable to expect 8 continuous hours of intellectual labor, it should also not be reasonable on part of employees to be wedded to their 8-hour-workday. No one seems to have a problem chit-chatting at work, or engaging in other forms of recreation, but everyone seems to love counting hours when it comes to reasonable work expected from them. I notice this in my job working with a team in Europe that my company has acqui-hired (this is relevant because until then they were a purely European company in terms of composition and culture). We are a pretty standard SV startup in terms of culture, we are in the office for ~9 hours a day (that includes lunch etc.) but we trust our employees to manage their work, which includes the self-awareness of knowing when you have not done enough during the day and compensating by working a bit more whenever you see fit. In contrast, the European team does strict 8 hours a day (including lunch), does NOT have better average productivity than ours, but gets very upset at the occasional expectation that they meet deadlines with similar 'vigor' as their SV counterparts. I'm sure the same people would complain about pay disparity between the bay area and Europe and find it unfair.

flubert 6y ago

I'm sure none of this applies to any of us here, but I've heard rumors that some people need deadlines to complete tasks. As in you set a deadline, and it doesn't really matter when, and check up with the employee on a regular basis. The interim feedback is always that things are coming along, but there is an awful lot of office chit-chat, browsing Facebook when I walk by, etc.. And then one week before the deadline all of a sudden there is griping and moaning about crunch time, but now there is sudden focus, and things get done. I'm a new manager, so I wish I had a better way to work with this dynamic. Smaller milestones? How small before it becomes micromanaging? But to the main point, if you are routinely working 70 hours a week that is a toxic work environment and you should leave.

dastx 6y ago

I'm only about 8 years into my career and if there is one thing I've come to realise, it's that a good chunk of deadlines are arbitrary dates plucked out of thin air. We as engineers are horrible at guessing how long something things. I've yet to meet anyone who has been able to accurately guess how long a certain task takes. Rightly so, because engineering wouldn't be engineering if all the problems were already solved. If you're in a workplace that imposes arbitrary dates on you, you should probably look elsewhere. There are better companies out there.

tanseydavid 6y ago

Thank you so much for this. I think you have managed to strike a perfect balance in tone -- no small task. You are quite direct in your message and do not sugar-coat any of your points but still avoid sounding 'bitter'. It has been my direct experience that the phenomenon you describe seems to be widely in practice at this point, across many organization of different size and disciplines.

awillen 6y ago

This is one of those times when you shouldn't attribute malice (or greed, I guess) to something that ought to be attributed to incompetence. I've been a PM for long enough to have dealt with lots of situations like this, and never once have I had the slightest inkling that there was any plan to overwork engineers in order to get them to work for free. The good companies I've dealt with understood that engineers are vital to their success and try to make them happy. The short term benefits of getting free work by bullying them with deadlines doesn't outweigh the downside of them leaving. The bad companies just don't think like this - they want cheap labor so they outsource engineering to the cheapest possible places. Based on this post, I would strongly recommend the author get a new job.

BMSmnqXAE4yfe1 6y ago

I have an impression that the article is about programmers, not engineers.

WrtCdEvrydy 6y ago

From a good manager of mine, "deadlines are cost control methods, unless we sent an email to a client or there's some pending legal requirement, those deadlines are to keep the costs of a project from skyrocketing". 2 years later, only two deadlines have ever been set in stone: the GDPR one and one we sent an email from Marketing about. I think he was right.

pkalinowski 6y ago

In Europe, giving employee less time than it's needed to complete a task is called mobbing.

dexterlagan 6y ago

IT director for a multinational here: I apologize if this has been said, but here are a few reasons why these deadlines are set to be broken from the start: 1) estimating dev time is a hard (as in NP-hard) problem. Nobody in the world can do it well. Ultimately, deadlines are meaningless in terms of actual dev time. 2) being an engineer myself, I know full well that if I'm given a fair or comfortable deadline, I'll code the thing quickly and enjoy some free time until the deadline. When the deadline comes, we'll find out there was lots of bugs. We're lazy/efficient animals. 3) if I'm given a short deadline, I'll complain but will work much harder under pressure. I'll still deliver something with bugs, but they will be fixed quickly, still under pressure. And so we give deadlines that are far off the mark, sometimes knowingly, in order to make sure the actual finished, *debugged* product is ready by the time we make the announcement/presentation/sale.

mbrodersen 6y ago

If you don't stand up for yourself, and accept whatever shit people throw at you, then you will get crushed.