This is actually an explicit decision, designed to maintain consistency of the user experience across GOV.UK services in terms of information architecture and content design. It's not something that departments choose to do (or not), and is codified in the GOV.UK Service Manual: https://www.gov.uk/service-manual/technology/get-a-domain-na...
An employee's use of a company-provided communication channel like Slack isn't covered by GDPR, but the company is liable for the content that's stored in their Slack account. Under GDPR, I, as a customer of Company X, have a right to know about and request a copy of any data stored about me by that company, which includes Slack conversations, in both open and "private" channels. GDPR also applies retroactively, so the old compliance export process wouldn't cover it.
Vaguely related: there's a great episode of the 99% Invisible podcast [1] about how two specific ice cream truck jingles are used to help deal with Taipei dealing with trash disposal.
I don't agree with working like this, but I'd expect that you're generally going to get marginal gains from each extra hour worked (up to a point of exhaustion or burnout), especially in the short term, so it might make sense to have people work in this way _occasionally_. I know I've been on "work all the hours available" projects in the past, and I definitely got a lot more done than I would have just working a 40hr week, even if I did feel like cr*p at the end of it.
It makes sense when all your employees are singles without a family or any other obligations outside work. You might want to take into account that your employees who are not, may have to pick up their kids from kindergarten/school, etc. They may not be able to work long hours without letting down their children or damaging their marriage.
You could make crunch optional, but there is some peer pressure ('Look, Johnny is not committed to our project').
These are waters to thread carefully if you want to have healthy/happy employees. Make clear rules ahead of times of what is expected, pay extra compensation for overtime.
Too bad I can only vote once UP for this comment. I fully agree; I have a family, my wife is a doctor and she works on shifts, so I often have to pickup kids and so on.
A huge cost that is often misunderstood is the cost of replacing an employee who leaves because the working conditions (endless hours, regular extra time, bully environment) are not compatible with his/her work/life balance.
My previous workplace was founded upon extra time (I remember our CTO and CEO clearly saying that he expected people to work 50-60 hours per week. The CEO literally said multiple times "these people are young, I expect them to work 120%").
We constantly were fixing issues and problems, we never had time to properly plan and design. Once the CTO told me that he expected our SW to have problems, but since we had no time to fix them or to build better software, he also expected the programmers to be available so fixing production issues when they happened no matter if it was night or weekend. Once he told us that he expected senior developers to check email once a day while on holiday to check if there were no problems.
No wonder that in a few month 3 out of 4 of the senior engineers left the company.
Peopleware talks about this. There is a cost to overtime in terms of lost productivity afterwards and in terms of developer happiness. When developers are unhappy, their work quality drops and eventually they leave. Cost of employee turnover is mentioned as a cost that is actually quite high, but rarely factored in.
They also say that overtime can make sense if its short and a rare occurrence.
An employee who leaves is a tragedy, especially in smaller companies. His work has to be shared among the other (implying even more extra time). Then you have to start a new acquisition process to hire someone new, train him, fit him into the existing group and so on. And if someone leaves because of the company culture, there is the possibility that other will follow, making the cost even higher.
I found a good way to curb crunch is to pay extra for it: Every mandated hour that exceeds the regular work time gets paid 25% - 50% on top, preferably in time off (that is for 8 hours extra a week you get 10-12 hours off the next). This allows for crunch time when needed but provides a strong financial incentive to avoid it. A lot of things suddenly drop in priority from "absolutely crucial" to "can be done next week" when you respond with "I hear you, are you willing to pay a 50% premium for that?".
Also offering help with child-care makes things easier for employees with families. Those are solvable problems if crunch-time is limited to short stints and if both sides are willing to work together.
I fail to understand your post: it's neither a novel idea to compensate extra for overtime nor did I claim it was. I just said that I found this to work well.
I see unpaid overtime as one of the primary drivers of extreme crunch abuse. It aligns incentives in the worst possible way: More work gets done per week (though only marginally at best), project management gets to claim "we're doing all we can" and then, on top it's actually free time donated by the employees at no immediately obvious costs. Not surprising that this sounds attractive.
I've struggled for years trying to get my headspace into the right place to deal with salaried work. I've got a very blue-collar background, and my first few jobs were in those kind of hard-hat & steel-toe boot industries, where you literally punch in and out, and your compensation is directly tied to the number of hours worked. In those situations, the calculus you're describing about "does this need to be done now, or can it be done tomorrow?" already takes place, since unpaid overtime is illegal, and if you need more than 40 hours in a week from an employee, you have to pay the premium for it.
It's less of a salaried work issue, it's more one of people not knowing or not caring about their rights. I can't talk about the US landscape but in germany unlimited unpaid overtime is not legal, still you see that often in work contracts, especially in contracts in startups and web/multimedia agencies. Its especially common where unions and other organizations that could enforce legal limits are weak. I've for example never seen such a clause (and unpaid overtime) in organizations where a strong worker rights position existed.
No to overtime being paid in time off. Many times, they'll gladly let you do that, only to not let you ever use it, assuming they actually remember that they promised it to you.
That's the point of "short-term" - that's weeks at the very most. Of course, a PHB will take this to mean "until the next release, half a year away, that's not too long, no?"
I think you're confusing the who the "user" is in this case. It's not Joe Bloggs out on the internet who wants to see fresh content on your site; it's you, the web developer, working on your local machine, building a web site or application.
The live-reload functionality is there as a development workflow tool, to automatically reload the page to see the results of the latest code change, rather than manually switching to the browser and hitting ⌘R/F5.
Regarding (Slack/4)... I believe that toomuchtodo is talking about the following features within Slack:
* Stars: the ability to privately star individual messages (so you can easily find them again)
* Pinning: the ability to publicly highlight specific messages within a channel, much like pinned posts in a forum (effectively channel-wide starring)
* History links: click on the timestamp next to any Slack message and it'll open a canonical URL for that message, allowing you to drop these links to specific messages or points in a conversation into other chats, GH issues or anywhere else you fancy.
i see. History links does seem like a useful feature (I've pasted links to SO answers in slack, so same could be applied to when someone answers a q on slack)
Stars also seems like a useful feature, but I'm so used to pasting useful stuff in a google doc, never even thought of it
I can see this being a really nice idea to use across a team, if such a thing was offered. A few use-cases / benefits:
* An agile team could use this as part of their retrospectives, and could track the data points across multiple sprints to see trends, as well as "scoring" the latest sprint.
* Sometimes an individual in a team can be quite quiet and reserved, and won't physically speak up if something's not going so well. Moving to a system like this may give them a voice.
* The levels can be tracked both by the team and by an individual's line manager to keep an eye on those people who are consistently (or increasingly) bored, frustrated, not learning, or generally unhappy.
* If this were completed every day, then it would effectively become a Niko-niko calendar[1] (although you might want to fill out just a single data point if you're doing it every day).
* Having a daily version would also work as an early-warning indicator of trouble brewing within a team or project.
JSON API [1] is an attempt to standardise the request and response formats for JSON APIs, and it supports an extension which permits multiple operations in a single request [2].
Facebook have their own, similar method of supporting batched calls through the Graph API [3], and this even permits you to specify dependencies between operations in a single request using JSONPath [4].
I took the article as to be more a case of using Redis as an example of a system which is reaching the limits of performance _given the current state of the kernel it's running on_, rather than a direct comment on the performance of Redis itself.
Also, saying that using Redis is slower than using a local hash table is a truism. There are myriad reasons why using a local, in-memory data structure is not viable: scalability and persistence, for example. It's like saying "I don't need a database, I can store everything in a local variable."
