3 ms·

Sure, that's understandable. My perspective is that those agreements should be changed from "X hours per week" to just "accomplish tasks by their deadlines". I

Sure, that's understandable. My perspective is that those agreements should be changed from "X hours per week" to just "accomplish tasks by their deadlines". If no tasks are assigned then how does blocking those hours benefit anyone? And if tasks are assigned, then what does it matter beyond the deadline being met?

vertis 5y ago
Okay, I want the whole project by the end of the day. /s It just doesn't work. Complexity of tasks, scope, resources all make for something that is very hard to measure. I agree with your sentiment, but it's hard to execute. However, the high-functioning teams I've been part of are certainly not checking if you're sitting in your seat at 9/5. They're not even worried if you take a long lunch, because they know that you can't cram every second of the day with programming work, but doing so 'in secret' is not okay.
- manigandham 5y ago
  I agree with you on the "in secret" part, but where we differ is that I see that as a symptom of micromanagement by the company. It's not isolated to remote work either, there are plenty of people just sitting on social media at work until it's time to leave, and usually being overall less productive because of these forced hours. Whether there's trust (on both sides) to effectively make progress is an entirely different issue. Remote work just makes it more explicit.
hermitcrab 5y ago
Software engineering is a process of design/discovery. So it is often very hard to say how long something is going to take. For example a 'simple' change could unearth a bug in a third party library that ends up taking days to work around.
- manigandham 5y ago
  I know. So what? People weren't actually productive for 40 hours in the office either, it was still based on timelines. Nothing has really changed here, other than trust actually being tested to a much larger degree. And perhaps people on both sides are finding out just how much trust there is.

vertis 5y ago

Okay, I want the whole project by the end of the day. /s It just doesn't work. Complexity of tasks, scope, resources all make for something that is very hard to measure. I agree with your sentiment, but it's hard to execute. However, the high-functioning teams I've been part of are certainly not checking if you're sitting in your seat at 9/5. They're not even worried if you take a long lunch, because they know that you can't cram every second of the day with programming work, but doing so 'in secret' is not okay.

manigandham 5y ago
I agree with you on the "in secret" part, but where we differ is that I see that as a symptom of micromanagement by the company. It's not isolated to remote work either, there are plenty of people just sitting on social media at work until it's time to leave, and usually being overall less productive because of these forced hours. Whether there's trust (on both sides) to effectively make progress is an entirely different issue. Remote work just makes it more explicit.

hermitcrab 5y ago

Software engineering is a process of design/discovery. So it is often very hard to say how long something is going to take. For example a 'simple' change could unearth a bug in a third party library that ends up taking days to work around.

manigandham 5y ago
I know. So what? People weren't actually productive for 40 hours in the office either, it was still based on timelines. Nothing has really changed here, other than trust actually being tested to a much larger degree. And perhaps people on both sides are finding out just how much trust there is.