31–40 of 78 posts
I currently work a 4 day week with Wednesdays off and it's like magic
This was the topic of a video [0] posted by CGP Grey on the 25th August. Not mainstream, but I think the idea has been popular for a while [1]. >6.4 >A manager went to his programmers and told them: "As regards to your work hours: you are going to have to come in at nine in the morning and leave at five in the afternoon." At this, all of them became angry and several resigned on the spot. >So the manager said: "All r…
Of course people want flexibility, but there are cons- >Much more difficult for collaboration especially for small questions >Bad workers exploring nice policies Pros- >I can sleep/think about code without being paid. Making my solutions lower cost and higher quality >Happier employees >Potentially less micro management needed
- the company restaurant closes at the normal time (or all good stuff is taken)
- you still get that condescending look from early-birds
Earlier quoted context omitted.
And to show how much of this is personal, during normal times, I'd consider a singleton day in the middle of the week an incredible waste relative to 3-day weekend (or even better a 4-day weekend once every two weeks) so that I could travel places.
The Wednesday off is not so bad for this; 2 vacation days and you're looking at a 5 day holiday
Only if you have Tuesdays and Thursdays off you won't be able to get a contiguous five day holiday with only two days extra off that can include any weekday (e.g., with a fixed Thursday off, you can't include Tuesday in your five day block without taking a third extra day off).
My wife and I both work four days a week and have Fridays off. It makes it much easier to get into the weekend mindset.
Earlier quoted context omitted.
Of course people want flexibility, but there are cons- >Much more difficult for collaboration especially for small questions >Bad workers exploring nice policies Pros- >I can sleep/think about code without being paid. Making my solutions lower cost and higher quality >Happier employees >Potentially less micro management needed
More cons: - the company restaurant closes at the normal time (or all good stuff is taken) - you still get that condescending look from early-birds
Earlier quoted context omitted.
Especially since it's observably true that for knowledge workers, almost nobody actually spends even close to a full percentage of their work hours doing the work in their job description. The productivity loss from requiring say 30 hours a week a week instead of 40 would be significantly less than a 25% decrease. In fact I wouldn't bet against a gain in total productivity.
I've been furloughed down to 32 hours a week for 5 months (mostly taking 3 day weekends). It has had a noticeable (downward) impact on tempo, but we aren't necessary looking for ways to make it the permanent way to organize the week either. It would be hard to sell me on taking Wednesday off, but I can see where people with more obligations would get a lot out of an arrangement like that.
Absolutely agree but it would be darn hard to manage with kids. I might be more productive on a Saturday than on a Tuesday, but hard to explain to the kids that you'll miss half the weekend because I wrote better on Saturdays than on Tuesdays.
Also, huge numbers of people have to work at the weekends. From highly-paid doctors to fast-food employees. Presumably their kids understand.
Earlier quoted context omitted.
More cons: - the company restaurant closes at the normal time (or all good stuff is taken) - you still get that condescending look from early-birds
In tech, it is people who work late who act superior. Early birds have it rather harder as they are seen as leaving early even if they objectively done more work.
In contrast, early-birds act superior while you are there.
Earlier quoted context omitted.
Of course people want flexibility, but there are cons- >Much more difficult for collaboration especially for small questions >Bad workers exploring nice policies Pros- >I can sleep/think about code without being paid. Making my solutions lower cost and higher quality >Happier employees >Potentially less micro management needed
You can make 1pm to 5pm as mandatory, so both the 9-5 folks and 1pm to 9pm folks have some overlap for synchronization, meetings and such. As for people exploiting it, you should measure relative performance and not but time One of my first startups I worked had a noon-4pm core hours. You had to be in by noon, and should stay until 4pm, the rest was flexible. I thought it worked really well for both early risers and…
This is also easier said than done. How do you measure programmer performance? LOC is obviously not a reasonable metric. Closed tickets isn't either. It takes an experienced manager who understands code to understand what work is actually being done, and managers like that are rare and valuable.
This was the topic of a video [0] posted by CGP Grey on the 25th August. Not mainstream, but I think the idea has been popular for a while [1]. >6.4 >A manager went to his programmers and told them: "As regards to your work hours: you are going to have to come in at nine in the morning and leave at five in the afternoon." At this, all of them became angry and several resigned on the spot. >So the manager said: "All r…
I worked for a startup that had an internal "story point meter" that would go up as you closed your tickets. The goal was to pressure employees into completing a certain number of story points per week the CEO considered a good number for a productive employee. Needless to say, this didn't work as intended, and the workforce was split between those who didn't care about it (higher ups) and those who maxed up their me…
As a software engineering manager, I put a story-point-based method of task size estimation and team velocity measurement in place about two years ago. A stipulation of this was that at no time would any one developer have their story point velocity assessed. The purpose of this system is to provide the team with a powerful tool that it needs in order to set a realistic timeline on team deliverables, such as a launch…
1/ the team’s composition at a point in time (and all the variability that comes with this)
2/ the team’s dependencies (a kind of exponential effect is at work here: the team’s dependencies also have all these issues in variability and so do their dependencies)
3/ the type of work being estimated in the context of the product (even “basic” things like “CRUD” can be quite intricate in some cases)
Basically unless the estimation is literally for a known change (e.g. modify source code files X, Y and Z with code changes A, B, and C) its predictive power diminishes substantially.
It’s not a powerful tool, it’s a micromanagement technique disguised as a tool to empower ICs.