[HN Gopher] I suspect many task deadlines are designed to force ...
___________________________________________________________________
I suspect many task deadlines are designed to force engineers to
work for free
Author : sT370ma2
Score : 222 points
Date : 2020-09-16 19:05 UTC (3 hours ago)
(HTM) web link (misc-stuff.terraaeon.com)
(TXT) w3m dump (misc-stuff.terraaeon.com)
| lisper wrote:
| 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.
| ineedasername wrote:
| 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.
| stefs wrote:
| >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.
| duxup wrote:
| 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.
| [deleted]
| kache_ wrote:
| 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 wrote:
| We as laborers have cognitive bias towards the commodity we
| sell: our time.
| ChrisMarshallNY wrote:
| 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
| hevelvarik wrote:
| 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.
| supernova87a wrote:
| 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.
| fishtoaster wrote:
| 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 wrote:
| _> 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.
| gnusty_gnurc wrote:
| I get frustrated when it seems like _no one_ is maintaining
| requirements (or aware of them) and I 'm just expected to
| make something work, as though I can read minds about what's
| expected.
|
| I have no problem with developing solutions on my own with
| the right accommodations and compensation - but stop handing
| me sprints based on things where the greatest extent of
| planning is a single sentence fragment of a Jira issue title.
| pdonis wrote:
| _> I get frustrated when it seems like no one is
| maintaining requirements (or aware of them) and I 'm just
| expected to make something work, as though I can read minds
| about what's expected._
|
| Yes, another (often frustrating) part of the engineer's job
| is to try to get the client (or a manager or someone else
| who is supposed to be communicating the client's
| requirements to you) to understand what "requirements"
| actually means and what does and doesn't count as actually
| specifying a requirement so it can be met, or at least so
| that a reasonable estimate of the time and resources
| required can be given.
|
| As others in this thread have said, sometimes the only real
| cure for this problem is to find a new job where you have
| different, and more reasonable, clients and/or managers.
| TeMPOraL wrote:
| > _If you delivered a result that the stakeholders are happy
| with, that 's a good outcome as an engineer. If you want to
| overengineer something, consider either doing it on your own
| time or switching to a job where, for example, more
| scalability, is actually a requirement._
|
| On the flip side, that sounds like a fast track to making
| shitty products that cause financial losses to the users (or,
| depending on industry, loss of life and limb). There are always
| implicit requirements to balance that stakeholders don't think
| of (or sometimes can't even conceptualize). Like, "satisfy the
| obvious safety constraints despite them not being mentioned in
| the spec", or "don't ship kludges that will slow everyone else
| down later on". Sometimes, part of being an engineer is saving
| stakeholders from themselves.
|
| Might depend on the company culture, but personally I do not
| want to work in the place where the engineering culture is
| "ours not to reason why, ours but to do and die".
| fizixer wrote:
| 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.
| gwbas1c wrote:
| I figured this out shortly before I started my career and screen
| out these kinds of employers.
| forgotmypw17 wrote:
| 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.
| OldHand2018 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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).
| blnqr wrote:
| 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.
| darekkay wrote:
| > 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.
| diogenescynic wrote:
| 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.
| mostlyghostly wrote:
| 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.
| skwirl wrote:
| 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.
| Animats wrote:
| 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/
| riazrizvi wrote:
| 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'.
| zwieback wrote:
| 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 wrote:
| 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.
| [deleted]
| curiousllama wrote:
| 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.
| JJMcJ wrote:
| 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]
| [deleted]
| umvi wrote:
| 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
| ghaff wrote:
| 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 wrote:
| 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.
| matheusmoreira wrote:
| > 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?
| iamkroot wrote:
| More like the managers make promises they don't understand.
| matheusmoreira wrote:
| Isn't understanding the capabilities of the people they
| manage the job of the manager? I always thought that was
| the whole point. If they don't know this, then maybe they
| shouldn't be making any promises at all.
| watwut wrote:
| Making correct estimate on how much time feature will
| take is something different then just understanding the
| capabilities of the people.
|
| Even developers themselves are often unable to produce
| good estimates. In fact, most developers tend to
| systematically underestimate how much time they will need
| for this or that task.
|
| I have seen management to even add padding to estimate
| and it is still not enough in the end.
| thelean12 wrote:
| Isn't that up to the developers to provide reasonable
| estimates? I regularly tell the higher ups estimates that are
| 3x what I actually think because I know I suck at estimates.
|
| If the problem is that your manager isn't listening to your
| estimates, then find a new manager. Plenty of fish in the
| sea.
| matheusmoreira wrote:
| Can software development jobs actually be reliably
| estimated though? It's not like other jobs where you can
| statistically analyze the performance of workers and
| estimate how long they take to perform tasks. There are too
| many factors at work here, no doubt there's going to be
| high variance from developer to developer, from project to
| project, from team to team, from feature to feature. The
| work isn't an uniform task.
| Jiocus wrote:
| Some say people from Sales are involved as well. "Follow the
| money" :)
| Clubber wrote:
| "Never attribute to malice that which is adequately explained
| by stupidity"
|
| -Hanlon's razor
| liability wrote:
| Advanced malicious actors often feign incompetence when
| caught, to take advantage of the naive and forgiving.
| lotsofpulp wrote:
| Maybe one should assume the people who say the hanlon razor
| saying are advanced malicious actors.
| quickthrower2 wrote:
| 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.
| wdb wrote:
| 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.
| [deleted]
| GoToRO wrote:
| 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.
| Justsignedup wrote:
| 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.
| maxharris wrote:
| At a well-managed company that's growing properly, such as Apple
| was from 1998-2012, this effect is employed in a way that
| compensates engineers very well via the gains in stock price.
|
| If you're a great engineer, it behooves you to see yourself as an
| investor in the company you end up choosing to work for.
|
| This means learning about things like the disruptive growth era
| we're in, how monetary policy affects growth, etc. You should
| know what an inverted yield curve is, and where to look to keep
| up with those charts (https://fred.stlouisfed.org/series/T10Y2Y).
|
| It's important to read Clayton Christensen "The Innovator's
| Dilemma". I also highly recommend reading ARK Invest's research
| reports. They cost nothing but an email address, and I have found
| these all to be enormously valuable in my own research on this.
| If you just want to sit and watch some stuff on YouTube that can
| help, give "Chicken Genius Singapore", "Dave Lee on Investing",
| and "Solving the Money Problem" a whirl.
|
| Great management is incredibly rare. But it's on _you_ to learn
| how to identify it. If you want to be paid the most, you have to
| know more than just the field you specialize in! There is little
| value in putting your head in the sand.
| TuringNYC wrote:
| Thanks for "Chicken Genius Singapore", "Dave Lee on Investing",
| and "Solving the Money Problem" -- these look great! Do you
| have any other recommendations?
| maxharris wrote:
| Cathie D. Wood, founder and CEO of ARK Invest, also does
| periodic YouTube videos. I love her!
| gowld wrote:
| That seems not true. The slacker / incompetent gets the same
| stock growth as the overworking genius.
| bird_monster wrote:
| 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
| [deleted]
| htrp wrote:
| > 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 wrote:
| > 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 wrote:
| they should realize their company business model sucks and
| bail
| rabidrat wrote:
| 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 wrote:
| 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=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.
| cryptica wrote:
| >> 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
|
| The good news is that this is likely a sign that the system is on
| the brink of failure.
| jchook wrote:
| 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.
| reillyse wrote:
| Is this article set in the late 90's. Times have changed, get a
| new job.
| dorkwood wrote:
| "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.
| cortesoft wrote:
| This seems to be describing a particular problem of working at an
| engineering consulting company. I have never had this experience
| in my career.
| jimbob45 wrote:
| It goes both ways. Many weak deadlines allow engineers to slack
| off when they otherwise might not have.
| stephenboyd wrote:
| 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?
| orf wrote:
| If this is you, then quit. You're not cattle, and there are
| better environments to spend your time in.
| dboreham wrote:
| Penny dropping..
|
| Now to figure out how to set boundaries in the abusive
| relationship.
| TuringNYC wrote:
| >>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.
| KKKKkkkk1 wrote:
| > _If neither of the above happen, you should trade absurdity
| for more salary /growth. I've seen this at places such as hedge
| funds and consultancies and they compensate and "pay" for it
| with better comp and growth._
|
| I traded stupidity for money. Don't do it.
| TuringNYC wrote:
| Highly recommended read:
| https://www.joelonsoftware.com/2000/08/09/the-joel-
| test-12-s...
|
| My recommendation: try to evaluate your employer on the
| above.
|
| I've traded stupidity for money for money earlier in my life,
| and it made sense. But people underestimate the break-even.
| You deserve a lot of money (50% or 75% premium) for some of
| the stupidity I've seen.
|
| On the flip side, i've also traded a salary discount for a
| well-run org -- a job where i have 90min max meetings a day
| with lots of good _ASYNC_ communications, good project
| planning, estimation, and good sprint cadences. I work a lot,
| but only when I want to (often late nights), bike outside
| when I want to, work heads-down w /o disturbances, etc.
|
| Just be careful when headhunters come offering a 10 or 15%
| increase in comp except w/ a very different culture. You have
| to compare like to like.
| jnwatson wrote:
| I think the Joel test is table stakes now. I simple cannot
| imagine working in a situation where they are not true.
| kelnos wrote:
| 1 through 4 and 11 are table stakes, but I think most
| orgs are missing various bits from the other 7.
| hobofan wrote:
| > My recommendation: try to evaluate your employer on the
| above.
|
| And better do it in a nuanced way, not the yes/no
| checkmarks that Stackoverflow Jobs is using for those
| points. I've worked for companies that were a mess and
| would get 11/12, as they _technically_ were using source
| control and tracking bugs etc., just in the most
| unproductive/useless way.
| WrtCdEvrydy wrote:
| > I've worked for companies that were a mess and would
| get 11/12, as they _technically_ were using source
| control and tracking bugs etc., just in the most
| unproductive/useless way.
|
| ie: Security Auditing Style...
| Igelau wrote:
| You didn't trade high enough!
| binarytox1n wrote:
| I agree with this wholeheartedly. The article seems to be
| written by someone who has not yet learned the life lesson that
| "everything is a negotiation".
|
| There's no such thing as a hard deadline. Everything is made
| up. What your manager is saying is: "To be successful in the
| market, I think I need to have X thing in Y days."
|
| It's the engineer's responsibility to provide information and
| estimates that will shape the business's direction. If you
| don't clarify or negotiate requirements based on your technical
| knowledge and experience and just take requirements as law
| written in stone you are not providing the true value of an
| engineer.
|
| If you are doing that - pushing back and grounding requirements
| in reality - and the business plows ahead with unrealistic
| goals anyway, then that simply means the people you work with
| are unreasonable and you should seek employment elsewhere. If
| they're not even willing to listen to people they're paying to
| have expertise then they're probably reading the market wrong
| too and I wouldn't trust them to be around long anyway.
| ip26 wrote:
| _There 's no such thing as a hard deadline. Everything is
| made up._
|
| "This video processing software needs to be ready by the
| Superbowl" or "This electronic voting software needs to be
| done by election day" don't strike you as hard deadlines?
| Igelau wrote:
| When we can't change the deadline, it's obvious that we
| should shift the scope. If that breaks down, the problem
| becomes not losing your entire engineering team while the
| deadline looms.
| robocat wrote:
| Often this video processing software wasn't ready by the
| Superbowl, and this electronic voting software wasn't
| completed by election day.
|
| You don't get sacked, you just get to work on the next
| death-march project. And for your two examples, it might be
| punted to the next Superbowl or election.
|
| Hard deadlines are not often deadly.
| ip26 wrote:
| So, what, it's only a _true_ Scottsman hard deadline if
| missing it means the guillotine?
| bradlys wrote:
| > So, what, it's only a true Scottsman hard deadline if
| missing it means the guillotine?
|
| I mean, honestly, yes. That's kinda the point of
| "dead"lines, isn't it?
| binarytox1n wrote:
| I guess that depends on your definition of "hard". Will the
| world end if you don't meet that regulatory deadline? No.
| Will the company survive? Maybe. Will you lose your job?
| Maybe. Are there other jobs for you? Yes.
| m463 wrote:
| 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 wrote:
| For those interested in the quiz: https://books.google.ca/boo
| ks?id=U5VCAwAAQBAJ&lpg=PP1&pg=PT5...
| Zippogriff wrote:
| 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?
| jpeloquin wrote:
| The quiz asks for a range that will include the correct
| answer 9/10 times. Not a point estimate. If you don't
| have the relevant trivia in your head, broaden the range
| proportionally. I think the intended point is that we're
| bad at judging probabilities. Getting 100% right (within
| range) is probably supposed to be as concerning as
| getting 0% right.
| depressedpanda wrote:
| Continue reading, especially the part titled 'How
| representative is this quiz of real software estimates?',
| and you'll get to the author's point.
| Zippogriff wrote:
| Ah, right, I've always taken that effect in software
| estimation to be a result of business people hating how
| wide an actual "90% accurate" estimate is. Not many
| managers will accept "8 to 30 months" as a 90% estimate
| at the start of a project with a fairly typical set of
| unknowns. Especially they seem to really hate ranges that
| aren't quite a lot narrower than the size of the lower
| bound. But maybe it's actually driven by the people doing
| the estimating.
|
| For my part I definitely tend to squeeze my "90%"s down
| to more like "30-40%" when asked for a "90%", for that
| reason. I might try out an honest and accurate estimate
| on someone I kinda know, and suspect won't quietly re-
| evaluate me as a useless moron or "one of those asshole
| 'programmer' types who doesn't get business" in response,
| though.
| kelnos wrote:
| You're supposed to put down ranges such that you have a
| 90% confidence that the correct answer is in that range,
| and then can expect to get roughly 9 of them "correct"
| (that is, the actual correct answer is included in your
| range).
|
| The point of the test -- as shown by the response graph
| after it -- is to show that when someone asks us for a
| 90%-confidence estimate, we don't really understand what
| that means, and end up giving 30%-confidence estimates.
| The point is that people need to understand what they do
| and don't know, and reflect their level of uncertainty
| with the width of the range.
|
| If I have a trivial task that I've done a hundred times
| before, I might say that it'll take me 45-60 minutes to
| complete, and 90% of the time I'd be right. But if it's
| something I've never done before, and I don't understand
| the steps or complexity, I might say that it'll take me
| between 30 minutes and 8 hours.
|
| This scales up, too. For a larger project that I
| understand well, I might say 6-8 weeks, while for
| something I don't understand, I might say 4-12 weeks.
|
| Over time, I can determine if I make good-enough
| estimates by checking to see if 90% of the time the
| actual time to delivery fell within the stated range. It
| doesn't matter if it's at the beginning of the range, end
| of the range, or right in the middle. I just need to hit
| somewhere in the range, 90% of the time.
|
| For example, for the Alexander the Great question, I
| don't have a clue. Your mention that he was a
| contemporary of Aristotle actually made me realize I
| believed he was much more modern-day than he is. So I
| might give a range of like 1000BC to 0AD, because I
| recall that Aristotle was definitely BC, but I don't
| really have much confidence as to when. Looks like the
| right answer is 356BC. So my estimate was correct, even
| though it had a wide range. Giving people (like your
| manager) a wider range also communicates your
| uncertainty, which is a useful piece of information for
| them to have. The issue is that I think many engineering
| managers simply won't accept a true 90% estimate if it's
| wider than they know what to do with from a planning
| perspective.
| tootie wrote:
| I'm a manager who has to speak directly to paying customers
| about how long they have to wait to get what they paid for and
| even I will never give a deadline or date. Most customers are
| actually pretty reasonable and know you can't predict
| everything. Most are thoroughly aware of how terrible they are
| at giving clear direction. It's important as a leader to
| exactly why things take time or why timing is unclear. Risks,
| uncertainty, quality takes time. There's also plenty of things
| you can do as a manager to de-risk a delivery and avoid being
| bottlenecked by risky tasks. It's also much easier (not easy,
| but easier) to estimate larger buckets of tasks than individual
| ones knowing that some will be harder than expected and some
| will be faster.
| chromedev wrote:
| I feel like large companies see developers/engineers like a
| commodity, give them a spoon and tell them to move a mound of
| sand. As soon as you tell them you have a shovel, they'll
| say... well we have spoons, we've always used spoons and you
| need to continue to use a spoon. We have managers and vendors
| that take them out golfing that we pay millions of dollars to
| and we signed a 5 year contract to use spoons, so use a spoon.
| temp667 wrote:
| I traded absurdity for salary.
|
| I just said, I'll need to work Saturdays to make this happen,
| and will need at least 2 others in on Saturdays (in office -
| full day work). I asked for +50% and got it.
|
| It helped I'd been clear that my schedule was 8:30-5:00 M-F to
| start and was younger at the time.
|
| Ironically - these days I just wish I had free time and curse
| myself fairly often for being over-committed. So rarely worth
| it even for more $ especially if you have kids and are a
| stranger to them. While I'm paid extremely well QOL is WAY down
| and stress is very high.
| hkmurakami wrote:
| This reads more like the"engineering manager" has had a sales
| role for too long. I think most frequently this is at the VP
| level.
|
| The direct eng manager (or PM sometimes) should be in a
| position to fight against this sort of absurdity, give the IC a
| few days to scope the project, etc. One of the eng managers at
| a previous employer wasnt a great technical mind but was
| stellar at playing defense against managament. We all had great
| respect for him repeatedly taking it on the chin for his team.
| babesh wrote:
| Most tech companies are set up such that managers are not
| incentivized to play defense for their team. Managers switch
| teams too often (usually on an annual cycle). Teams get
| reorganized almost as often. Managers have to please their
| boss or someone higher up.
|
| The power the engineers have is to exit. In some
| organizations, the engineers can exit to another part of the
| organization. In others, they exit the organization entirely.
| This does actually work in aggregate if you just look at it
| on a longer timescale.
| majormajor wrote:
| Yeah, anyone who knows about a deadline for a project for a
| month and hasn't bothered scoping it or estimating with their
| team is massively failing at their job.
| taigeair wrote:
| do you have any career development book recommendations?
| klmadfejno wrote:
| Number 2 is very important and not obvious. Give your manager
| options to choose from. It makes you a cooperative problem
| solver rather than someone who is pessimistic and can't manage
| deadlines. Shrugging and saying that scope management is the
| manager's job is equally as bad as the manager shrugging and
| saying implementation is the dev's job.
|
| Applies to non-dev work as well.
| sidlls wrote:
| And what happens when your manager's response is "you're the
| expert, I expect you to decide these things?"
|
| This industry is like any (every?) other: a minefield of
| incompetence and laziness interwoven with an unhealthy dose
| of unjustifiable arrogance.
| TuringNYC wrote:
| In some ways, that might be a good situation -- it means
| they are leaving all the trade-off decisions to you. If
| they are only specifying time and resources, you can trade
| scope, quality, debt.
|
| If they are freezing time and resources and scope, and you
| dont have much room to move except with quality and debt.
| But those catch up. If that is the consistent trade-off,
| i'd go with my original recommendations: trade this
| stupidity for more salary or find a new employer with
| better management. Or seek the managerial position yourself
| and do a better job at it.
| nthj wrote:
| Always provide options and a recommendation.
| matheusmoreira wrote:
| Why can't engineers simply tell managers that it can't be done
| by the specified deadline? Why do managers even ask this
| question if they're gonna ignore the answer and impose an
| impossible deadline anyway?
|
| It looks like they're assuming we're all lazy. They think the
| job isn't that hard. A fundamental lack of respect.
| drdeadringer wrote:
| Perhaps some managers think they are a clever Cpt Kirk who's
| gotten wise to their Scotty's miracle-worker tactics, even
| though they're a manager with an honest Geordi La Forge.
|
| No offence to Geordi La Forge.
| blibble wrote:
| mandatory clip: https://youtu.be/8xRqXYsksFg?t=9
| TeMPOraL wrote:
| Related, from the newest member of Star Trek family:
|
| https://youtu.be/latWmQtm8fw?t=22
|
| In your estimating, remember to always add _buffer time_.
| PragmaticPulp wrote:
| Managers don't operate like this at well-run companies.
|
| Any remotely healthy team will perform estimation and scoping
| as a discussion with the developers involved. The author of
| this post sounds like he has worked at an extremely
| dysfunctional company, not a company that understands how to
| develop software.
|
| This idea that managers are universally incompetent just
| isn't true. The best thing you can do is refuse to support
| incompetent managers. Change teams or change jobs if you
| must. There are many, many great managers out there who won't
| try to pull nonsense like this.
| lhorie wrote:
| > Why can't engineers simply tell managers that it can't be
| done by the specified deadline
|
| They can. I've had a time where a project manager came by no
| less than 3 times asking me to re-estimate the same project,
| tweaked ever so slightly each time. Turned out that they had
| made an impossible promise to the client. Upon learning that,
| I just said, listen that can't be done within that budget,
| end of story. You have to go reduce the scope. In the end,
| they had to go back, loop in the account manager and have the
| awkward conversation with the client.
| watwut wrote:
| Because in majority of the case engineers after manage to hit
| the deadline. That is managerial experience. What management
| learns over time is that engineers say it is impossible but
| if you insist they will then do it.
|
| It is by trading quality pretty often, but that often is
| exactly trade off managers want. It is often by trading
| future productivity - engineers burning out or at least
| having drop after deadline.
| matheusmoreira wrote:
| > It is often by trading future productivity - engineers
| burning out or at least having drop after deadline.
|
| Future productivity? If engineers are burning out in an
| attempt to meet otherwise impossible deadlines, it means
| they're being placed under enough stress that it's
| _threatening their mental and possibly physical health_. Is
| employee health really something that can be traded away?
| NortySpock wrote:
| Yeah, you just hire a new employee.
| matheusmoreira wrote:
| This _is_ sarcasm, right?
| TeMPOraL wrote:
| > _Is employee health really something that can be traded
| away?_
|
| In theory? No. In practice? Very much yes.
|
| Health (particularly mental well-being) isn't readily and
| reliably quantifiable. As a manager, you may think your
| subordinate is happy and productive all the way up to the
| point they hand you their resignation letter. Meanwhile,
| employees have every reason to pretend everything is OK
| up to the very moment they secure a new job elsewhere.
| And to the extent they're becoming less productive due to
| burnout, most software jobs has a lot of slack in it -
| between high variance in problem solving and plenty of
| bullshit tasks to juggle, someone working at 10% of their
| normal capacity can stay unnoticed for a while.
|
| With no good feedback being available, it's hard to see
| you're putting too much pressure on your employees,
| particularly if you don't look for it (whether because
| you're too busy or just don't care).
| matheusmoreira wrote:
| > Health (particularly mental well-being) isn't readily
| and reliably quantifiable.
|
| There are resources which may help. Here's an article
| that's specific to stress:
|
| https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6345505/
|
| > As a manager, you may think your subordinate is happy
| and productive all the way up to the point they hand you
| their resignation letter.
|
| This is the same problem we have with depression and
| suicide. The answer is to actively look for it.
|
| > Meanwhile, employees have every reason to pretend
| everything is OK up to the very moment they secure a new
| job elsewhere.
|
| An evaluation of a person's mental health produces
| medical information which should of course be
| confidential. People will not open up if they think this
| information will be shared with others, especially their
| bosses or colleagues.
|
| > And to the extent they're becoming less productive due
| to burnout, most software jobs has a lot of slack in it -
| between high variance in problem solving and plenty of
| bullshit tasks to juggle, someone working at 10% of their
| normal capacity can stay unnoticed for a while.
|
| Many diseases also have a subclinical phase where they
| show few or no symptoms. This is actually a good thing
| since it allows you to intervene _before_ a complication
| manifests itself. The answer is to actively look for
| them.
|
| > it's hard to see you're putting too much pressure on
| your employees, particularly if you don't look for it
| (whether because you're too busy or just don't care).
|
| Hard, but not impossible. The answers won't be found if
| the people responsible aren't looking for them. If
| managers are too busy, maybe they should make the time.
| If they don't care, they should straight up be fired for
| gross negligence.
| kelnos wrote:
| > _An evaluation of a person 's mental health produces
| medical information which should of course be
| confidential. People will not open up if they think this
| information will be shared with others, especially their
| bosses or colleagues._
|
| How would this information be useful if it's _not_ shared
| with the boss?
|
| Regardless, I don't think the biggest issue is people are
| afraid that the information will be shared, but that
| there's a stigma around being associated with a mental
| health issue that causes lower productivity in the
| workplace. Employees are more likely to keep that kind of
| thing a secret because they likely believe knowledge of
| it will make it harder to get raises and promotions.
| gorzynsk wrote:
| Hanlon's razor is an aphorism, "Never attribute to malice that
| which is adequately explained by stupidity"
| pera wrote:
| "Never attribute to stupidity that which is adequately
| explained by greed" - an alternative formulation of the law of
| parsimony (aka Occam's razor)
| ouid wrote:
| Hanlon's razor is a boundary condition. Over time strategies
| improve, including malicious ones.
| bravura wrote:
| "Any sufficiently advanced incompetence is indistinguishable
| from malice." - Grey's law
| RankingMember wrote:
| 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!)
| TeMPOraL wrote:
| "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
| AnimalMuppet wrote:
| I've quoted that before, but never heard it called "Grey's
| law". Who is Grey?
| ardit33 wrote:
| 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
| jopsen wrote:
| 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 wrote:
| 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?
| golemiprague wrote:
| 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 wrote:
| 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.
| snarkypixel wrote:
| 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
| crazygringo wrote:
| 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.
| PragmaticPulp wrote:
| Agreed. I feel for the author of this blog post, who apparently
| has worked underneath some terrible managers.
|
| > Deadlines exist because people need to make plans and be able
| to rely on them, which is how our entire society and economy
| function.
|
| This is the core of it. When we're heads down working through
| code, it's easy to forget that the end product is part of a
| much bigger business. In most companies, operating without
| deadlines or target dates is equivalent to expecting the rest
| of the business to revolve around you. Doesn't work.
|
| That's not to say that deadlines can or should be arbitrary.
| Healthy teams will sit down and discuss realistic deadlines
| with engineers, not hide the tasks from engineers and give them
| unreasonable deadlines without a hint of communication like
| this blog post suggests.
|
| If you find yourself working for a manager or company that
| resembles this blog post in any way: Get out! There are many
| great companies and managers out there who would be more than
| happy to add good talent to their teams. Mutual respect is the
| norm at any halfway functional company.
|
| Any company operating like this is doomed to suffer massive
| turnover, exodus of good employees, and slow descent into
| failure. Don't let bad managers like this drag you down with
| them, and don't let bad experiences make you permanently
| cynical of the industry as a whole.
| mekoka wrote:
| > Software doesn't exist in a vacuum.
|
| Strip down everything to its bare essentials (i.e. just beyond
| the vacuum) and you have: a Programmer, a Software and (maybe)
| a User. The sentence above is a common trope that people
| believe justifies all the friction added between the Programmer
| and the Software, while attempting to optimize the process of
| putting it in the hand of the User. But I contend that
| deadlines are an unfortunate and provably unnecessary byproduct
| (see many open source projects) of that often wasteful process.
|
| > Deadlines exist because people need to make plans and be able
| to rely on them
|
| To make a plan you need a list of priorities and some time
| _estimates_. Some people just have a knack for turning these
| into artificial emergencies. The decision to build a new
| software feature can be taken in an organization by
| establishing how needed it is and vaguely describing the time
| it would take to build in terms of days, weeks, months or
| years. It 's enough to know whether you want to spend some
| resources on it or not. Regardless of deadlines, people will
| work toward those time frames.
|
| > which is how our entire society and economy function.
|
| Only the parts of our society where such engagements actually
| matter function like this. In many other parts it's useless to
| follow such a model. Unfortunately some people observe it in
| one context and believe that it's a driver that can be blindly
| transposed onto another. So they start fabricating urgency
| where it doesn't belong. Meanwhile, _it 'll be ready when it's
| ready_ remains a successful model for many, even in our society
| and economy.
| marcinzm wrote:
| >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 wrote:
| 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.
| ThePadawan wrote:
| 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 wrote:
| Then why do so many engineers come to work in the US?
| irrational wrote:
| Is this still the case?
| MiroF wrote:
| Yes? As long as the pay differences are what they are, why
| wouldn't it be?
| irrational wrote:
| I thought the Trump administration was working overtime
| to limit HB1, immigration,etc.
| jamiequint wrote:
| Then again, maybe the lack of insane regulations on labor
| (amongst other things) is why the US has managed to produce
| new, highly-valuable companies at a much higher clip than
| Europe has, and is also the reason why software engineers in
| Europe get paid far less than their counterparts in America.
| kryptiskt wrote:
| Maybe because we European software developers earn a small
| fraction of what US ones do?
| metacritic12 wrote:
| Right -- in those "civilized" countries (you probably mean the
| higher income European countries?) the total pay is just 20
| Euros an hour net of taxes, so software engineers' salaries
| even with overtime don't match the US. But at least your boss
| can't play these games.
| orf wrote:
| You're only fooling yourself if you look at the raw values
| rather than quality of life and relative cost of living.
| est31 wrote:
| You could live in the US for a few years, and then come
| back to Germany so that you can e.g. buy a house without
| having to pay for it for decades.
| fxtentacle wrote:
| For skilled programmers, pay in Germany tends to be $5k to
| $6k per month after all taxes and the highest level of health
| insurance and a generous retirement insurance and disability
| and private unemployment insurance (additional to the
| government one).
|
| That is enough for an entire family to rent a house and live
| a very comfortable life pretty much everywhere in Germany,
| except maybe Munich city center.
|
| There are strong overtime protections, I've heard from people
| who were paid 4x their regular salary because they were
| called in on a Sunday.
|
| I'm sure the FAANG pay better, but maybe house + family +
| free time is nicer than high numbers in your online banking?
| lotsofpulp wrote:
| The US is pretty awesome if you're in the top 10%. Of
| course, more than 10% of the US population likes to believe
| they are in the top 10% or have a chance at being in the
| top 10% in the future.
| est31 wrote:
| Switzerland is kind of an exception to that, but their market
| is pretty small.
| onion2k wrote:
| It happens in the UK. I know plenty of devs here who complain
| about the "crunch" on projects that really don't need it.
|
| Mind you, I also think there's an element of developers
| lowballing estimates and then putting in extra time to make
| themselves much more productive than they actually are. I've
| worked with a few people who management believed were fantastic
| but who actually just worked 50% longer hours. I fight hard
| against those kinds of people being on my team because it
| destroys morale and absolutely ruins my burndown charts any
| time they're not available.
| m0zg wrote:
| 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.
___________________________________________________________________
(page generated 2020-09-16 23:01 UTC)