Live data from Hacker News

Remote Only

remoteonly.org

191–200 of 374 posts

Re: Remote Only

#191
post #148
post #91

Earlier quoted context omitted.

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 s…

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 kno…

If your process cannot revert a breaking change with a figurative snap of fingers, the process is broken. It is like driving a car with no brakes.

About the only time where I've seen this fail is if it was a publicised feature launch that was way premature.

Re: Remote Only

#192
post #91
post #11

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 s…

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.

Re: Remote Only

#193
post #143

Observation: This almost completely conflicts with the agile manifesto. Opinion: As an architect I feel that f2f whiteboard and brainstorming sessions are invaluable. But for a dev working on a feature, it might be better to seclude. This is just an example to say that we will never find a policy that works for everyone company-wide and world-wide. The company should do it's best to accommodate it's employees' work s…

Oddly enough, I've worked with people who are agile/scrum fanatics and remote work fanatics at the same time. Good times... no, I seriously take that back, it was terrible.

Re: Remote Only

#194
post #183

Earlier quoted context omitted.

> If all information is visible and everything is well documented, it should be rare to have the situation where one person is the only one that can answer that question. This will totally still happen for remote teams, but I think it happens more in other organizations that rely on face time and verbal information exchange. I worked at my last job for just over 2 1/2 years and, while we had an actual office, for the…

> - Legacy code. Bob was the only one around when this code was written and it hasn't been touched in years, now it's breaking and no one understands why. (In an ideal world, there wouldn't be knowledge silos like this, but there always are) Not sure if valid, if some legacy code was written a few years before, probably even author will have no clue what's wrong.

The author might have a higher chance of figuring it out. This is playing the likelihood game though. In perfect world, the code would be tight and small enough that you wouldn't take long to understand it, and then the complex components (there are always a bunch of these) are well tested and documented. Especially rationale for design decisions or implementation quirks.

Old code does not necessarily mean legacy code.

Re: Remote Only

#195
post #18

> Save on compensation due to hiring in lower cost regions Pay people what they're worth regardless of where they live. If you have a developer in Nigeria or Ukraine or Vietnam that is as equally capable as a developer in the Bay Area, they should be paid the same. Doing otherwise, at best, perpetuates Western hegemony, and at worst is simply racism.

This is a bit ridiculous. It's not hegemony or racism. It's how markets work. People in those markets have fewer opportunities for highly paid employment. As a result, employers have more leverage in negotiations. It's as simple as that.

What if you are a nomad, changing locations month after month? What is your employment market? Is getting hired while in a high income place then moving to a low income place immediately after regarded as a good move in this game?

A remote only company playing the local income game is a major red flag for me. It's basically an employee caste system at that point, with second class employees based solely on their physical location.

Re: Remote Only

#196
post #64

Earlier quoted context omitted.

This is a bit ridiculous. It's not hegemony or racism. It's how markets work. People in those markets have fewer opportunities for highly paid employment. As a result, employers have more leverage in negotiations. It's as simple as that.

People in those markets usually aren't comparing their offer with local competition, the job market for remote workers is worldwide. Many companies do pay remote employees based on the value they bring to the company regardless of where they live so they are the competition.

The problem with this is that a remote worker will have problems finding opportunities or getting found, especially because the competition is so huge. It is like the problems contractors face taken to some non small power.

Re: Remote Only

#197

Earlier quoted context omitted.

This is a bit ridiculous. It's not hegemony or racism. It's how markets work. People in those markets have fewer opportunities for highly paid employment. As a result, employers have more leverage in negotiations. It's as simple as that.

It's how markets work. Markets work by paying for value created. I’ve tested extensively, and found that I’m equally capable of writing code on a beach in Thailand as in a felt cube in California. I’ll grant that there is a Cost of Living difference between those places, but I would prefer that difference to be captured by me rather than somebody else’s company. It’s me doing the work and creating the value, so that…

Unfortunately, you will get outpriced by people doing "the same" work for less. Since you cannot know the global prices, you cannot even meet them, much less compete. Lowest bidder often wins.

Re: Remote Only

#198

Earlier quoted context omitted.

I guess we'll have to throw purchasing power out the window to discuss this one. So pay the developer $20k per year or pay them $100k? If the former, I guess those US developers are just screwed and will probably make more money flipping burgers. If the latter, or anywhere between, then we'll just see developers move to the cheapest, lowest tax countries to arbitrage the artificial market inefficiency. Or are you sug…

> So pay the developer $20k per year or pay them $100k? If they bring you $20k worth of value, pay them $20k. If they bring you $100k worth of value, pay them $100k. Would it suck to be a developer in San Francisco on the same salary as your colleague in India? Sure, but nobody forces you to live in San Francisco. > If the latter, or anywhere between, then we'll just see developers move to the cheapest, lowest tax co…

> Nobody forces you to live in San Francisco

Spoken like a person without a family or property who is fine with moving to India in a heartbeat.

Do you even know Indian culture? Languages? How to actually acquire a decent living place in there?

It is an existential risk. A pretty big one. You could end up on street or worse. Alleviating this risk takes negligible resources and quite a lot of time.

Re: Remote Only

#199
post #37

I'd be interested to know some long term remote workers experiences with regards to interruptions. It's one of the things that I believe would be better. In many places I've worked I tend to become a "go to" person which results in many many interruptions, it doesn't make too much difference how much you write down, it's usually always quicker to just ask someone who you know knows the answer to whatever question you…

If I may play devil's advocate for a minute, I would say that just because you felt like were not productive doesn't mean that you weren't being productive for your team/company. Those people interrupting you with questions are often stuck or could use the extra input to do their own work better.

Re: Remote Only

#200
The usual skepticism from HN comes up whenever telecommuting is brought up. However, it was tech's promise. I think people should be asking how to fix its problems rather than nagging that it "doesn't work for me". But maybe i'm biased as an indie dev.
Post reply on HN