6 ms·

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

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.

ocdtrekkie 8y ago
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".
- eckza 8y ago
  Full-time remote worker. We solve work-life and burnout problems at my organization by having set hours and hard stops at the end of the day. What you lose in having a fairly rigid schedule, you more than gain back by not having to carry around that “always on” feeling.
  - deleted 8y ago
    [deleted]
  - bmelton 8y ago
    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.
- jfaat 8y ago
  I guess, but even as an on-site employee if production breaks because of me and I’m not in the office, I’ll still get pinged 10/10 times
latchkey 8y ago
I used to work with a guy named Noah. The ongoing joke was... "Where is Noah? I don't Noah."
iandanforth 8y ago
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.
- itake 8y ago
  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. [0] - https://news.ycombinator.com/item?id=17252798 https://news.ycombinator.com/item?id=17252798
bmelton 8y ago
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. The team broke the site.
- gitgud 8y ago
  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.
- mfonda 8y ago
  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.
  - megaman22 8y ago
    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.
    - nounaut 8y ago
      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.
k__ 8y ago
That's why I don't do operations. Remote is only fun if you aren't "on-call"
- reilly3000 8y ago
  Amen. Especially with Slack in your pocket.
  - deleted 8y ago
    [deleted]
toomanybeersies 8y ago
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.
IOT_Apprentice 8y ago
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?
meiraleal 8y ago
This premise I guess is exactly for you to not have any part of your project strictly subject to only one cowboy coding.
UlisesAC4 8y ago
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.
billysielu 8y ago
Pick up the telephone and ask him.
lagadu 8y ago
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.
yosito 8y ago
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.
toasterlovin 8y ago
This is easy: you call Will on the phone. You should have the personal contact information of anybody who is a single point of failure.
e12e 8y ago
> Yo, you gotta tell me when you’re working. Sure, have core hours, and make them known. 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.

ocdtrekkie 8y ago

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".

eckza 8y ago
Full-time remote worker. We solve work-life and burnout problems at my organization by having set hours and hard stops at the end of the day. What you lose in having a fairly rigid schedule, you more than gain back by not having to carry around that “always on” feeling.
- deleted 8y ago
  [deleted]
- bmelton 8y ago
  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.
jfaat 8y ago
I guess, but even as an on-site employee if production breaks because of me and I’m not in the office, I’ll still get pinged 10/10 times

latchkey 8y ago

I used to work with a guy named Noah. The ongoing joke was... "Where is Noah? I don't Noah."

iandanforth 8y ago

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.

itake 8y ago
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. [0] - https://news.ycombinator.com/item?id=17252798 https://news.ycombinator.com/item?id=17252798

bmelton 8y ago

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. The team broke the site.

gitgud 8y ago
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.
mfonda 8y ago
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.
- megaman22 8y ago
  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.
  - nounaut 8y ago
    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.

k__ 8y ago

That's why I don't do operations. Remote is only fun if you aren't "on-call"

reilly3000 8y ago
Amen. Especially with Slack in your pocket.
- deleted 8y ago
  [deleted]

toomanybeersies 8y ago

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.

IOT_Apprentice 8y ago

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?

meiraleal 8y ago

This premise I guess is exactly for you to not have any part of your project strictly subject to only one cowboy coding.

UlisesAC4 8y ago

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.

billysielu 8y ago

Pick up the telephone and ask him.

lagadu 8y ago

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.

yosito 8y ago

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.

toasterlovin 8y ago

This is easy: you call Will on the phone. You should have the personal contact information of anybody who is a single point of failure.

e12e 8y ago

> Yo, you gotta tell me when you’re working. Sure, have core hours, and make them known. 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.