3 ms·

Productivity matters, both to the companies that pay these workers, and to people's wellbeing and mental health. I don't know the numbers today but in the 2000s

Productivity matters, both to the companies that pay these workers, and to people's wellbeing and mental health. I don't know the numbers today but in the 2000s, on average, corporate engineers had 35 hours a week of meetings. At 40 hours, this left 5 hours a week for coding. If you were willing to work 60 hours a week, then voila - you would be a 5x coder! Not to mention most coders get into it for the coding, not the meeting. This math isn't just arbitrary - it's embedded deeply in how organizations function, how people work, get promoted, deliver, all that. in a vacuum, a 32 hour workweek might push meeting times lower and leave the same or more engineering productivity time. It might also stress the system so hard that non-meeting work grinds to a halt, unfortunately just at a time when there's less time to notice it.

alephnerd 1y ago
> I don't know the numbers today but in the 2000s, on average, corporate engineers had 35 hours a week of meetings Do you have the dataset for that? I'd be surprised by that number, unless it was all "engineers" irrespective of software taken into account.
- vessenes 1y ago
  okay digging in to my vague memories - it was claimed as 25 hours, and posted by a charismatic-ish internet gadfly in the early 2000s, Philip Greenspun: here's a slashdot link about the story: https://developers.slashdot.org/story/00/11/06/1448235/greenspun-on-managing-software-engineers https://developers.slashdot.org/story/00/11/06/1448235/green... but I didn't dig up the original. I have no idea if Philg referenced data in his essay, but I kind of bet he did, it was his style. Not that his style was to fairly reference data mind you.
  - alephnerd 1y ago
    Thanks for the context! 20-25 hours makes more sense - especially in an era before a lot of productivity tooling like Slack, Git, Zoom, Notion/Confluence, and Asana/Jira was created or normalized, and development processes were way less nimble and iterative than they are today. I'd be curious to see similar data today - my gut is saying that the hours spent in meetings for IC engineers (Staff and below) is probably lower today than it was 25 years ago because of the productivity gains and changes in management culture, but I'd need data to make such a qualification. It is also interesting to go thru that slashdot thread and see how similar the conversations were back then to those we still see today.
    - vessenes 1y ago
      For sure - same topics! Slack definitely changed things. I'd guess largely for the worse when it comes to knowledge work. But it definitely everted meeting time into all the time, which means there's less scheduled meetings. Closing the door to work uninterrupted is harder now though
philipallstar 1y ago
I was in software in from mid-2000s onwards and never experienced anything like 35 hours of meetings a week.
skeeter2020 1y ago
even as a full-time manager I have never had anything like 35 hours of meetings a week. No developer has that either. IME a developer who says "I have a lot of meetings!" is at < 10 hr/ week. Something like standup (1hr) planning (1hr) refinment/definition (2hr) 1:1 (1hr) staff/all-hands (1hr) practice groups (2hr) adhoc (3hr) is what I might see on their calendar and that's a heavy - not regular - week.

alephnerd 1y ago

> I don't know the numbers today but in the 2000s, on average, corporate engineers had 35 hours a week of meetings Do you have the dataset for that? I'd be surprised by that number, unless it was all "engineers" irrespective of software taken into account.

vessenes 1y ago
okay digging in to my vague memories - it was claimed as 25 hours, and posted by a charismatic-ish internet gadfly in the early 2000s, Philip Greenspun: here's a slashdot link about the story: https://developers.slashdot.org/story/00/11/06/1448235/greenspun-on-managing-software-engineers https://developers.slashdot.org/story/00/11/06/1448235/green... but I didn't dig up the original. I have no idea if Philg referenced data in his essay, but I kind of bet he did, it was his style. Not that his style was to fairly reference data mind you.
- alephnerd 1y ago
  Thanks for the context! 20-25 hours makes more sense - especially in an era before a lot of productivity tooling like Slack, Git, Zoom, Notion/Confluence, and Asana/Jira was created or normalized, and development processes were way less nimble and iterative than they are today. I'd be curious to see similar data today - my gut is saying that the hours spent in meetings for IC engineers (Staff and below) is probably lower today than it was 25 years ago because of the productivity gains and changes in management culture, but I'd need data to make such a qualification. It is also interesting to go thru that slashdot thread and see how similar the conversations were back then to those we still see today.
  - vessenes 1y ago
    For sure - same topics! Slack definitely changed things. I'd guess largely for the worse when it comes to knowledge work. But it definitely everted meeting time into all the time, which means there's less scheduled meetings. Closing the door to work uninterrupted is harder now though

philipallstar 1y ago

I was in software in from mid-2000s onwards and never experienced anything like 35 hours of meetings a week.

skeeter2020 1y ago

even as a full-time manager I have never had anything like 35 hours of meetings a week. No developer has that either. IME a developer who says "I have a lot of meetings!" is at < 10 hr/ week. Something like standup (1hr) planning (1hr) refinment/definition (2hr) 1:1 (1hr) staff/all-hands (1hr) practice groups (2hr) adhoc (3hr) is what I might see on their calendar and that's a heavy - not regular - week.