This leaves out a pretty important part of work: you work on a team. Increasingly it’s acceptable for people to work hours that suit them, and for many people that means coming in at 10 or 11. That means they are staying later and they are probably most productive around 3 or 4 or 5. That means they’ll be dropping the most PRs on you then or asking the most questions.
That isn’t to say that this suggestion won’t work, but you probably can’t just institute it and call it a day. The post doesn’t even mention colleagues or teams.
This leaves out a pretty important part of work: you work on a team.
I don’t think it matters whether you work 9-5 or 11-7. If other people on the team are working within a certain time period (such as 11-7), then by all means try to accommodate them by adjusting your hours to overlap with theirs to the extent that doing so doesn’t impact your productivity or get in the way of the rest of your life.
The fundamental principle is to do a solid day’s work in eight hours or less because unpaid overtime is for suckers. Not only are you not getting paid for the extra hours when you draw a salary, but working more than 40 hours a week reduces the amount of money you earn per hour.
It’s not only stupid, but unethical too. If somebody works overtime without pay, it creates pressure for other workers to do it as well. If you do it regularly, your output gets worse, which means that your employer benefits nothing either. It’s just loss/loss.
I know that. You know that. Managers refuse to know it. They’d rather make wild promises, letting their egos cut checks that their own asses won’t be called upon to cash.
I would agree if the workday were actually one solid block of nothing but writing code or thinking about writing code. However in the real world (or at least MY real world) the workday consists of that plus a whole host of scheduled and unscheduled interruptions like meetings, chats with manager and coworkers, etc.
When you add in those things, a 4-6 hour workday starts to look kinda sketchy :)
I don’t think it’s sketchy. I think it’s something we should have forced down management’s throat in the 1960s. In the meantime, when you add in the bullshit that comes with a coding job, you end up with an eight hour workday.
For teams, I think it’s fundamental to estabilish a common ground from the get go. I feel that team members should (ideally) agree on a (flexible as much as possible) schedule that accomodates everyone needs, instead of just individually decide which work hours suite them. Personally, I think that, when other team members depends on some measure of your availability, showing up “whenever you feel like it” is a sign of lack of respect for your peers (and I won’t allow it on my team).
My team is doing mostly 10-8 (so working more than the 8h/d).
Now I usually do 8-4/5 (depending on the work pressure, my commitments, if I took an additional personal time at lunch break …) if a team member throws a PR when I have to leave, I have absolutely no scruples to let it for tomorrow. Once or twice some asked for a review when I was leaving. To that you just have to answer that you’re leaving because you called it a day and that except if it’s critical to have it reviewed it today, it can probably wait for tomorrow.
To me the teams are not an issue as long as you communicate.
In my experience it’s better to let important reviews wait for the morning, when my judgement is clear, rather than wave them through at when I’m tired.
I really enjoy reading write-ups like this where people have made the effort to mechanize solutions to “wetware problems” like this one.
This particular trap is SO easy to fall into. I particularly like the idea of snapshotting to create context bridges from one day to the next for a particular task.
The modern mindset I see adopted increasingly in the past few companies I’ve worked for is to focus more on output and less on an arbitrary number_of_hours variable.
One tactic I’ve adopted is to ask myself at the end of every day a simple question:
“Am I happy with the work I’ve done today, and does that feel like a good day’s work?”
If the answer is no, then I reflect on how to correct that so I don’t get a negative the next day, and so on.
I always leave at 5; I try to avoid ‘being in the middle of solving something’ and working with such small increments that I can stop and continue at any time. Because during the day, there will always be people, meetings, even walking to get water. In my opinion is better to avoid being in ‘the zone’ so I don’t feel any type of pain being interrupted.
This is interesting to me. I hear a lot about “flow” and “zone” lately and I find that I would rather have many small periods of decent productivity (interspersed by unavoidable context switching) than get upset at inevitably having my flow broken.
I suggest finding a way to get back in the zone. It’s productivity benefits are incredible. It feels great, too, with who knows what positive benefits in your mind. Maybe find a way in your practices or talking to management to reduce interruptions or make them happen outside of zone time.
Alternatively, consider finding a better job where you can be in zone. This could be worth talking to their employees about, too, when checking on the company before applying.
This leaves out a pretty important part of work: you work on a team. Increasingly it’s acceptable for people to work hours that suit them, and for many people that means coming in at 10 or 11. That means they are staying later and they are probably most productive around 3 or 4 or 5. That means they’ll be dropping the most PRs on you then or asking the most questions.
That isn’t to say that this suggestion won’t work, but you probably can’t just institute it and call it a day. The post doesn’t even mention colleagues or teams.
I don’t think it matters whether you work 9-5 or 11-7. If other people on the team are working within a certain time period (such as 11-7), then by all means try to accommodate them by adjusting your hours to overlap with theirs to the extent that doing so doesn’t impact your productivity or get in the way of the rest of your life.
The fundamental principle is to do a solid day’s work in eight hours or less because unpaid overtime is for suckers. Not only are you not getting paid for the extra hours when you draw a salary, but working more than 40 hours a week reduces the amount of money you earn per hour.
It’s not only stupid, but unethical too. If somebody works overtime without pay, it creates pressure for other workers to do it as well. If you do it regularly, your output gets worse, which means that your employer benefits nothing either. It’s just loss/loss.
I know that. You know that. Managers refuse to know it. They’d rather make wild promises, letting their egos cut checks that their own asses won’t be called upon to cash.
This was my take too. 9 and 5 are arbitrary fence posts. The key here is working an 8ish hour day and not a 10ish or 12ish hour day.
4-6 hours would be better, IMO, but I find myself turning into some kind of dirty long-haired pinko as I approach middle age.
I would agree if the workday were actually one solid block of nothing but writing code or thinking about writing code. However in the real world (or at least MY real world) the workday consists of that plus a whole host of scheduled and unscheduled interruptions like meetings, chats with manager and coworkers, etc.
When you add in those things, a 4-6 hour workday starts to look kinda sketchy :)
I don’t think it’s sketchy. I think it’s something we should have forced down management’s throat in the 1960s. In the meantime, when you add in the bullshit that comes with a coding job, you end up with an eight hour workday.
For teams, I think it’s fundamental to estabilish a common ground from the get go. I feel that team members should (ideally) agree on a (flexible as much as possible) schedule that accomodates everyone needs, instead of just individually decide which work hours suite them. Personally, I think that, when other team members depends on some measure of your availability, showing up “whenever you feel like it” is a sign of lack of respect for your peers (and I won’t allow it on my team).
My team is doing mostly 10-8 (so working more than the 8h/d). Now I usually do 8-4/5 (depending on the work pressure, my commitments, if I took an additional personal time at lunch break …) if a team member throws a PR when I have to leave, I have absolutely no scruples to let it for tomorrow. Once or twice some asked for a review when I was leaving. To that you just have to answer that you’re leaving because you called it a day and that except if it’s critical to have it reviewed it today, it can probably wait for tomorrow.
To me the teams are not an issue as long as you communicate.
In my experience it’s better to let important reviews wait for the morning, when my judgement is clear, rather than wave them through at when I’m tired.
I really enjoy reading write-ups like this where people have made the effort to mechanize solutions to “wetware problems” like this one.
This particular trap is SO easy to fall into. I particularly like the idea of snapshotting to create context bridges from one day to the next for a particular task.
The modern mindset I see adopted increasingly in the past few companies I’ve worked for is to focus more on output and less on an arbitrary number_of_hours variable.
One tactic I’ve adopted is to ask myself at the end of every day a simple question:
“Am I happy with the work I’ve done today, and does that feel like a good day’s work?”
If the answer is no, then I reflect on how to correct that so I don’t get a negative the next day, and so on.
I always leave at 5; I try to avoid ‘being in the middle of solving something’ and working with such small increments that I can stop and continue at any time. Because during the day, there will always be people, meetings, even walking to get water. In my opinion is better to avoid being in ‘the zone’ so I don’t feel any type of pain being interrupted.
This is interesting to me. I hear a lot about “flow” and “zone” lately and I find that I would rather have many small periods of decent productivity (interspersed by unavoidable context switching) than get upset at inevitably having my flow broken.
I suggest finding a way to get back in the zone. It’s productivity benefits are incredible. It feels great, too, with who knows what positive benefits in your mind. Maybe find a way in your practices or talking to management to reduce interruptions or make them happen outside of zone time.
Alternatively, consider finding a better job where you can be in zone. This could be worth talking to their employees about, too, when checking on the company before applying.