Yo, you gotta tell me when you’re working. You must. You’re on a team that is depending on you and somebody has to know where the fuck your are and when you’re going to fix whatever is broken today.
“Where’s will?”
“I don’t know, our manifesto says nobody gets to know when he’s working.”
“Well he broke the site.”
“That’s his right as a sovereign citizen.”
The end.
If Kevin broke the site, it's a process problem. Kevin didn't break the site, he introduced code that might have broken the site, and the lack of tests to have detected the it broke the site. Jane then peer reviewed the code that might have broken the site and approved it. Bob then failed to notice that the site was broken during QA. The QA environment was apparently configured differently enough by Taylor that the site could appear working in dev and QA, and pass unit and functional tests without exploding until it hit production.
As true as this is, unexpected problems happen. Kevin may be the only one that can fix it, or at least be able to fix it a lot more effectively than others. The issue might not be Kevin's fault (i.e it's really a process problem), but being able to talk to him immediately (or at least know his schedule) will go a long ways in getting the issue resolved in an acceptable time frame.
Nothing against remote work, but knowing everyone's typical working hours makes things run a lot more smoothly.
And when it's the build server itself that's broken? No process can account for every possible edge case, and you need to have flexibility to handle the unexpected.
At some point problems reach the "Call Kevin now, I don't care what time it is" level. Your processes should enable anyone to handle problems that are not at this level.
if the build system is broken, then no new code gets built to roll to production. Your build system has no resiliency in terms of having more than one, or ability to roll back? Do you even have version control implemented along with a mature change control process, with automation and monitoring in place?
Kevin's available hours should be common knowledge, or easily findable in a system of some sort, ranging from text file to excel sheet to Exchange to massively overpriced time-tracking software.
Doesn't really help to know peoples hours. If they're not overlapping with yours then you have a potentially crazy overhead on time it takes to get responses to issues that could hold up your work completely.
That's a fundamental problem of teamwork. This also happens when the coworker sitting right next to you, working the same hours, has a higher-priority task than the one you're waiting for.
It absolutely does, although in my personal experience far, far more rarely. And even if that person was sitting remotely at their own hours you’ld then have to wait for them to get ”to work” and then do that higher-priority task and then get to your request so the overhead is still waaaaay bigger.
This was in response to Practical Tip #1: "People don't have to say when they are working."
I'm arguing that this tip is harmful. I should know he was on vacation, and thus have a plan in place to handle anything that might come up while he's on vacation. If I'm completely in the dark about when he's working, things are going to be a lot more difficult.
Vacation / Sick time is a bit different than needing to run errands till 10am, either shifting the working day round a bit or spreading the time out over the next days or week etc.
Doesn't hurt to check in when you're available again as a courtesy but the benefit is NOT having to get permission to do something like this up front.
If you're remote as an employee then presumably the company has process around holidays and stuff that would be followed. If you're a freelancer then part of what stops you, and your client, from being fined by HMRC (in Britain) is setting your own working hours and days.
The main bit of process missing here seems to be the requirement that the developer of a given feature is at work (or at least on call) when it's deployed and has it's first full day of usage (or whatever makes sense for the particular type of application). Don't deploy on Friday afternoon, it's better for everyone to wait until Monday morning. Certainly don't deploy major feature work just before going on holiday, etc.
Additionally, if Jim had configured the backups properly the site could be reverted to a stable build. A lot of measures could prevent these situations.
There's nothing more annoying than asking a question, and not knowing if you're going to get a response in 5 minutes, in which case you stretch your legs and grab a water; or a couple of hours, in which case you move onto another task while you wait for a response.
"Oh, but if you ask in a public Slack channel, someone else will answer!", is the inevitable response from someone here on HN. Unfortunately, that is not always the case for a multitude of reasons.
Whenever I've worked remotely, I've always clocked in and out on slack, either through posting in a channel or sending a DM, or by using statuses. That way people can know that I've gone for lunch and will be incommunicado for the next hour.
It's the same as working in a physical office, if you're out of office, your colleagues should know how long for.
That point is a little bit bad worded. It is more pointed to old school managers who think that by controlling working hours they are controlling productivity.
After all in remote work productivity is measured about communication, issues , commits and pull requests done.
The corollary here is that if nobody knows when you're working, people will always expect you to work. That whole work/life balance thing depends on having clearly denoted "working time" and "not working time".
Also full-time remote worker. We solve the problem by letting people know when you will and won't be available. It can be super informal (e.g. "Hey guys, gonna be out of pocket this afternoon") or entered into a shared calendar.
I agree with you (and OP) that there has to be some visibility into what work is going to be done when, and there are lots of ways to solve it, that said, I'm sympathetic to the notion that "I don't care how or when you work, as long as the work gets done." I'm a big fan of measuring developers more by the velocity of their Jira queues and commit history than how often they're available to be bothered with non-coding stuff.
If I know someone won't be "at" work for the next 20 hours (part time, different timezone) I can factor that into how the teamwork will... Work.
Is something on fire, and only a single person can put it out? A) that's sad B) sometimes happens anyway (and then you can try and fix A after the fire is out) C) depending on what's on fire, contracts etc - you can always call and wake someone up.
But mostly it's just nice to know people's schedules - so one can plan work.
Maybe there's some pair programming to be done (via shared screen session or whatever) - obviously try and schedule that when both parties are available...
It's really not that different to chasing after a manager that's busy with meetings or a co-worker who's part time out of the office doing on-site consulting work.
Even in a shared office, developers need to plan "deep" time when they have time to focus - or nothing will get done due interruptions.
Just because someone is sitting right there does not mean they're "free" for a chat. They could be deep in the debugger chasing a bug.
So you're saying that "Will" is your organization's single point of failure? So, when he goes on vacation or when he's sick or quits the whole thing comes crashing down?
If that's the case, I hope I don't own any stock of it, as you're a single injury away from disaster.
Having worked on a team that was responsible for uptime of some high traffic web apps, there's a difference between when you're working and when you're on call. We had an on call schedule for emergencies and down time, but we rarely had actual emergencies to respond to. The rest of our work was done in two week sprints. No one cared when we did the work, as long as we stayed on track with those two week sprints and got everything done most of the time.
I think this is a valid and important point, especially as this is aimed at #1 on their list of 'practical tips.' The item in question isn't even really a practical tip. You should submit an issue that suggests a real practical tip for how people can be both flexible with their time and available in urgent situations.
I have been working remotely for about 2 years and the last 5 months completely out of cycle with the rest of the company.
This comment hits the nail on the head [0]. Everyone's butt is on the line. It should never be one person's fault that the website was taken down. If one person has the power to damage your business and only they can repair the error, then you have a process problem.
Yo, why isn't the site monitored with alerting that tells Will the site is broken? Why isn't the site set up so that if a change is deployed and breaks it, the site can be rolled back to the last working state? Yo, why don't you have change control and a roll back process?
“Where’s will?” “I don’t know, our manifesto says nobody gets to know when he’s working.” “Well he broke the site.” “That’s his right as a sovereign citizen.” The end.