5 ms·

Why is there a belief in this industry that working more hours == productivity? Arguably a more experienced developer could do the same work (if not better) in

Why is there a belief in this industry that working more hours == productivity? Arguably a more experienced developer could do the same work (if not better) in less hours. The right to not work 12 hours a Day shouldnt be something that is earned with age. If a team is consistently required to put in unreasonably long hours it’s either due to being understaffed or poor planning. Both are a recipe for disaster...

PurpleBoxDragon 8y ago
>Why is there a belief in this industry that working more hours == productivity? Lack of manager ability to measure productivity based on anything else. Between POs, BAs, business representatives, and IT managers there are a lot of people who don't seem to be able to grasp why two relatively simple to describe tasks can require such vast differences in time. So it becomes hard for them to judge if their developer is wasting their time or not (and let's not even begin on overall lack of trust to begin with), so the only fall back measure is if they have their butt in the seat and appear to be working. And even if you are lucky enough that everyone you directly deal with either understands the basics on why sizing varies so greatly or able to accept it without question, you still have to deal with middle managers walking the floor who measure productivity the same as they would in a factory. And if you are lucky enough to not even have this problems, you still have to deal with cultural norms set in party by all the jobs which aren't as lucky.
philipov 8y ago
Because managers can measure hours, but they can't measure effectiveness.
- cannonedhamster 8y ago
  Good managers can measure effectiveness. The problem is it's hard to quantify to higher ups, and even when you do quantify the data, it never beats the sales guy drinking with the boss and knowing the boss's taste in wo/men.
  - philipov 8y ago
    I think that measurement implies a quantity being measured, so it sounds like we agree on the main point. Managers can form opinions about who is effective, but the silly quantities they come up with don't end up being useful, because "mistakes avoided" isn't an observable[0]. You can't count events that didn't happen, yet such hypothetical suppositions are crucial to appreciating the benefits of experience. 0: https://en.wikipedia.org/wiki/Observable https://en.wikipedia.org/wiki/Observable
    - mgkimsal 8y ago
      Thanks - I've had that notion for a long time, but could never put it as succinctly. "You can't count events that didn't happen." Had a lowball offer from a company once - had some friends working there. I could see from some earlier code that some really basic web knowledge was being overlooked. I won't go in to details, but... this was something I'd pointed out to one of the managers there (met at a local meetup). Fixing it then would have taken about 2-3 hours, scanning all the code to ensure it was in sync. Instead, the problem spread as they grew, and it's harder to fix when there are dozens of staff and thousands of files in use vs 5 staff and a dozen files. It became a 'this has to be fixed in order to close mega-deal X integration with company Y', and it took multiple devs several weeks of full-on effort to rectify everything. How do you quantify that? "Please, take my advice, doing this 4 hours of work now now will save you >$50k and weeks of opportunity cost in 4 years". Generally people don't seem to care.
bpyne 8y ago
My guess is that it's a myth that developed from the industrial era when more widgets could be produced in 12 hours than 8. The fact that developers don't do specialized line work doesn't seem to register. As people are noting on this thread, startups are their own thing. During my startup days, we were always the next sale or funding round away from going belly up. We pulled late hours to get in the latest features for our president to "sell" to investors.
ams6110 8y ago
Well in the case of consulting it's more billable hours, thus more profit. The clients should be the ones asking "why do you need 20 developers working 60 hours a week on this inventory system" but they seemed to accept it as normal.

PurpleBoxDragon 8y ago

>Why is there a belief in this industry that working more hours == productivity? Lack of manager ability to measure productivity based on anything else. Between POs, BAs, business representatives, and IT managers there are a lot of people who don't seem to be able to grasp why two relatively simple to describe tasks can require such vast differences in time. So it becomes hard for them to judge if their developer is wasting their time or not (and let's not even begin on overall lack of trust to begin with), so the only fall back measure is if they have their butt in the seat and appear to be working. And even if you are lucky enough that everyone you directly deal with either understands the basics on why sizing varies so greatly or able to accept it without question, you still have to deal with middle managers walking the floor who measure productivity the same as they would in a factory. And if you are lucky enough to not even have this problems, you still have to deal with cultural norms set in party by all the jobs which aren't as lucky.

philipov 8y ago

Because managers can measure hours, but they can't measure effectiveness.

cannonedhamster 8y ago
Good managers can measure effectiveness. The problem is it's hard to quantify to higher ups, and even when you do quantify the data, it never beats the sales guy drinking with the boss and knowing the boss's taste in wo/men.
- philipov 8y ago
  I think that measurement implies a quantity being measured, so it sounds like we agree on the main point. Managers can form opinions about who is effective, but the silly quantities they come up with don't end up being useful, because "mistakes avoided" isn't an observable[0]. You can't count events that didn't happen, yet such hypothetical suppositions are crucial to appreciating the benefits of experience. 0: https://en.wikipedia.org/wiki/Observable https://en.wikipedia.org/wiki/Observable
  - mgkimsal 8y ago
    Thanks - I've had that notion for a long time, but could never put it as succinctly. "You can't count events that didn't happen." Had a lowball offer from a company once - had some friends working there. I could see from some earlier code that some really basic web knowledge was being overlooked. I won't go in to details, but... this was something I'd pointed out to one of the managers there (met at a local meetup). Fixing it then would have taken about 2-3 hours, scanning all the code to ensure it was in sync. Instead, the problem spread as they grew, and it's harder to fix when there are dozens of staff and thousands of files in use vs 5 staff and a dozen files. It became a 'this has to be fixed in order to close mega-deal X integration with company Y', and it took multiple devs several weeks of full-on effort to rectify everything. How do you quantify that? "Please, take my advice, doing this 4 hours of work now now will save you >$50k and weeks of opportunity cost in 4 years". Generally people don't seem to care.

bpyne 8y ago

My guess is that it's a myth that developed from the industrial era when more widgets could be produced in 12 hours than 8. The fact that developers don't do specialized line work doesn't seem to register. As people are noting on this thread, startups are their own thing. During my startup days, we were always the next sale or funding round away from going belly up. We pulled late hours to get in the latest features for our president to "sell" to investors.

ams6110 8y ago

Well in the case of consulting it's more billable hours, thus more profit. The clients should be the ones asking "why do you need 20 developers working 60 hours a week on this inventory system" but they seemed to accept it as normal.