Not every elliptic curve is the same: trough on ECC security (2010) - <AUTHOR> http://infosecurity.ch/20100926/not-every-elliptic-curve-is-the-same-trough-on-ecc-security/ <comment><USER2> This article is interesting, but it found it striking that it made absolutely no mention of Curve25519 [0], which has become quite popular today as an replacement for P-256 and co. Perhaps things would have been different had the article not been written 3 years before the Dual EC backdoor fiasco.

[0] [https://en.wikipedia.org/wiki/Curve25519](https://en.wikipedia.org/wiki/Curve25519)

<comment><USER3> Dual EC has nothing to do with the NIST curves.

<comment><USER4> I think what the root comment is referencing is that the dual EC standard being possibly compromised has made people take a closer look at NIST standards related to their curves.

</comment></comment></comment><comment><USER3> This is not an especially useful analysis. In particular, few specialists in 2016 would make decisions based on which standards bodies support a given curve.

</comment><comment><USER5> Anyone interested in using ECC should take a glance at SafeCurves: choosing safe curves for elliptic-curve cryptography [http://safecurves.cr.yp.to/](http://safecurves.cr.yp.to/)

There's a nice table showing which curves are safe and which curves are not.

</comment><comment><USER6> The author made no mention the more trusted curve25519 the web wants to move to.

Edit: Curve25519 may have been unheard of in 2010.

<comment><USER3> We don't want to move to it because it's "more trusted". We want it because it's a _better curve_. Most critically: for the most common applications, Curve25519 avoids the need for point validation, eliminating a class of vulnerabilities. It's also much easier to implement in constant time.</comment></comment>


Election hacking wider than previously known - <AUTHOR> https://www.nytimes.com/2017/09/01/us/politics/russia-election-hacking.html?_r=0 <comment><USER2> I thought we had already moved on to the next big scandal.</comment>


The Patent Troll: Making a fortune off other people's ideas - <AUTHOR> http://www.good.is/post/the-patent-troll/ <comment><USER2> Genius is 1% inspiration and 99% perspiration. A patent is a tool for doing 1% of the work and then waiting for someone else to do the other 99% so you can sue.

I'm being a bit extreme there... I think there should be something like a patent. But, it should be very hard to get. Maybe only 1% of current patents should have been allowed. It might be lower than that.

A patent should only be allowed on something fundamental, conceptual, highly novel, and unprecedented, and there should be a significant burden of proof on the patenter to prove all that.

<comment><USER3> _A patent should only be allowed on something fundamental, conceptual, highly novel, and unprecedented, and there should be a significant burden of proof on the patenter to prove all that._

Agreed, except I would substitute "tangible" for "conceptual," as the current laxness in the system could, arguably, be attributed to a departure from a tangibility requirement.

</comment></comment><comment><USER4> > Spangenberg argues that companies such as Microsoft and Ford know patent > negotiation is one of the costs of doing business.

I really, really hate this argument. "This negative thing is accepted as inevitable, so why is it bad that I am proactively part of that negative thing?". I don't know how to explain why, but I do know it screams complete and total lack of ethics, only justification.

I'm just waiting for another patent troll to troll one of his legitimate businesses.

<comment><USER5> It's rationalization: [http://en.wikipedia.org/wiki/Rationalization_%28making_excus...](http://en.wikipedia.org/wiki/Rationalization_%28making_excuses%29)

The statement is just as much a way of convincing himself that what he's doing is right as it is a way to convince anyone else. It's like a murderer who justifies murder by saying "They were going to die sometime anyway." People don't want to live with the knowledge that they're bad, so they come up with justifications for it.

</comment></comment><comment><USER6> When it comes down to it, patent trolls are only a symptom of the real problem - the fact that far too many obvious patents are granted. If the only patents granted were ones that companies would be unlikely to come up with of their own accord when they faced a given problem, patent trolls would be substantially less common, and more justifiable.

<comment><USER7> Exactly. If it makes business sense to wait for someone to accidentally infringe on your patent, you clearly shouldn't have that patent.

<comment><USER6> Very well put! I shall be snagging that line for future use, if you don't mind.

</comment></comment></comment><comment><USER8> This is an entertaining and timeless story. "Trolling" is, alas, inevitable due to the transferable nature of patent rights. (Troll-like cases are perhaps 1/20 of patent infringements filed.) But, the victims of trolling are not entirely without blame -- small inventors and start ups are frequently told to "scram" by large companies when they are informed of their potential infringement. Without a bankroll, contingency litigation is the only option for the small guy.

<comment><USER9> The problem surrounding the current patent regime is not that those being sued are blameless, it's that patents do not encourage innovation anymore. As you stated, companies that actually bring products to market are not ideally suited to launch patent lawsuits.

Only non-practicing entities (i.e. patent "trolls") can sue with great abandon because they don't sell anything that they could be counter-sued for.

</comment></comment><comment><USER10> They call it patent trolling; I call it poetic justice.

The companies that are extorted by patent trolls are the same group that agitated for today's over-broad patent system in the hope that they could wall out smaller competitors with thickets of mutually cross-licensed defensive patents. They created the conditions for parasites to thrive - now they have to live with the consequences.

...or they could support patent reform.

<comment><USER11> I disagree completely. The biggest patent bullies have a gigantic portfolio to kill or milk any possible competitor. In particular some of the big software houses. Patent trolls don't bite IBM/Microsoft/Oracle just like piranhas don't prey on each other. They go attack/bully weaker prey. Most patent trolls seem to rarely go against any corporation with a big legal team/budget.

IBM vs. Sun: <http://www.forbes.com/asap/2002/0624/044.html> (It's great this was published on Forbes, else I'd be dismissed as a waco lefty, just like their reporting on Enron at about the same time.)

<comment><USER10> Is that true? The troll in this article seemed to be going up against some major companies. I'm no lawyer, but it seems like if you're looking for 8-figure payoffs it would be better to hit up companies for whom that's a minor expense, not an existential threat.

</comment></comment></comment><comment><USER12> I would draw a distinction between patent trolls who target multi-million dollar companies, and patent trolls who target small independent entrepreneurs who are crushed by the litigation.

<comment><USER13> I'm going to guess that there are very few patent trolls that target small independent entrepreneurs. Not out of the goodness of their heart, but simply because that isn't where the money is.</comment></comment>


On why I co-founded 'Gauss - The People Magnet' - <AUTHOR> http://stopmebeforeiblogagain.com/on-why-i-co-founded-gauss-the-people-magnet/

<comment><USER2> Reading the entire post by Paul Graham about startup ideas (<http://www.paulgraham.com/startupideas.html>) I summarize his thoughts more as pointing to problems that many people have, where the problems of the founder should act just as the starting point! for ideation (to get to a startup idea) - not being the end goal of a startup.

Here are some quotes from Paul Graham: "When a startup launches, there have to be at least some users who really need what they're making—not just people who could see themselves using it one day, but who want it urgently."

"When you have an idea for a startup, ask yourself: who wants this right now [besides yourself]? Who wants this [besides yourself] so much that they'll use it even when it's a crappy version one made by a two-person startup they've never heard of? If you can't answer that, the idea is probably bad."

"When you find the right sort of problem, you should probably be able to describe it as obvious (...) Which means, strangely enough, that coming up with startup ideas is a question of seeing the obvious."

"If Mark Zuckerberg had built something that could only ever have appealed to Harvard students, it would not have been a good startup idea."

Paul Graham wrote even more in this direction in another post that was titled:

"Startup = Growth" <http://paulgraham.com/growth.html>

Here are some quotes:

"The growth of a successful startup usually has three phases: 1) There's an initial period of slow or no growth while the startup tries to figure out what it's doing. 2) As the startup figures out how to make something lots of people want and how to reach those people, there's a period of rapid growth. (...)" "During Y Combinator we measure growth rate per week (...) A good growth rate during YC is 5-7% a week. If you can hit 10% a week you're doing exceptionally well. If you can only manage 1%, it's a sign you haven't yet figured out what you're doing." "The best thing to measure the growth rate of is revenue. The next best, for startups that aren't charging initially, is active users."

"The fascinating thing about optimizing for growth is that it can actually discover startup ideas. You can use the need for growth as a form of evolutionary pressure. If you start out with some initial plan [solving your own problem] and modify it as necessary to keep hitting, say, 10% weekly growth, you may end up with a quite different company than you meant to start [that only solved your own problem]. But anything that grows consistently at 10% a week is almost certainly a better idea than you started with." "You'll generally do best to follow that constraint wherever it leads [solving a problem that some users really have] rather than being influenced by some initial vision [like solving only your own problem], just as a scientist is better off following the truth wherever it leads rather than being influenced by what he wishes were the case."

</comment><comment><AUTHOR> l33t h4xx0r. Server down. Sorry, guys. I'll go investigate what's wrong. Update: Server back up and running. Sorry for the momentary inconvenience.

</comment><comment><USER3> very nice! resembles a lot of my research intersts ;)

</comment><comment><USER4> Thx for sharing!

<comment><AUTHOR> No worries! I'd love to know more about the dangers of solving your own problem becoming an obsession, how to identify it and knowing when to quit or press on.</comment></comment>


Show HN: Latest Corona numbers per country and historical data [Desktop Only)] - <AUTHOR> https://neomjs.github.io/pages/node_modules/neo.mjs/dist/production/apps/covid/index.html#country=USA&mainview=helix <comment><AUTHOR> DESKTOP ONLY, support for mobile devices is not ready yet.

sorry for the repost, the api went down & this was intended to be a show hn.

this is a major update to the project (e.g. adding historical data).

ping me in case you are interested to jump in on the coding side (e.g. maps, charts, mobile support).

</comment><comment><AUTHOR> Ugh, the API is down again. Not a lucky day. [https://corona.lmao.ninja/all](https://corona.lmao.ninja/all)

Will ping you when it is back onine.

</comment><comment><AUTHOR> small demo video on how to use it: [https://www.youtube.com/watch?v=BhSZS6_UlO4&t=109s](https://www.youtube.com/watch?v=BhSZS6_UlO4&t=109s)

the source is MIT licensed: [https://github.com/neomjs/neo/tree/dev/apps/covid](https://github.com/neomjs/neo/tree/dev/apps/covid)

</comment><comment><AUTHOR> PING. back online now.

The API might switch to a more stable hosting env very soon (rumors 1 day).

</comment><comment><AUTHOR> if the api works & you got the app running, feedback would be greatly appreciated.

as mentioned below: contributors are welcome (for the app as well as for the multithreading JS framework).

best regards Tobias</comment>


Ask HN: If you don't permit telecommuting, why? - <AUTHOR> I'm writing a feature story tentatively titled, "Why the Company You Want to Work For Won't Hire Telecommuters." I'd like your input.
Plenty of businesses are interested in hiring only onsite staff. I want to explain the viewpoints behind such policies – and then, ideally, address what it would take for those organizations to hire telecommuters or remote workers.
So I'd like to hear from two types of respondents:
* Someone who has been in a hiring role at an organization where the job requisitions typically say, "Local candidates only, please." (Whether or not you're in agreement with the policy.)
* Someone who's applied to a job that says, "on site only" and gotten a remote job despite that requirement.
If you applied to an "on-site only" job ad and got the gig anyway, there's just one question: How'd you make that happen?
My questions are primarily for the people on the hiring side:
* Why does the person who does this job need to be on-site? Please be specific. Give me examples of things that can only be done if she were in the office.
* Have you been in a position where you personally would be okay with an employee being a telecommuter, but a decision-maker deemed otherwise? How did you handle it?
* How has the policy affected your company's ability to attract candidates?
* Have you hired someone for an in-the-office job, and later given permission for the individual to work from home? What happened to make the change okay?
* What would it take for the company to change the no-telecommuters policy, even if only for one specific position? For example, "If a rock star in my field applied for the job, we'd do anything to get him to say Yes – including letting him work remotely." But there can be many other answers, and I'd very much like to hear yours. <comment><USER2> I am a remote worker and if I ever ran a company I wouldn't allow telecommuting. Here is why:

When I was at the office for a decade, 90% of the insight and productivity came from informal conversations in the hallway, lunches and things I overheard in passing. As a remote worker, nearly all communication is very deliberate so I am not exposed to those ad-hoc conversations. Everything is very deliberate: I receive an email, a text or a meeting. The net result is my personal career becomes very confined and stunted... I become that guy who does that one thing rather than a team-member who has an awareness of everything and the ability to jump in as needed.

Being remote also limits my upward mobility. Most of my promotions and moves were because I would walk back from a meeting with an executive and talk about what was discussed and express interest in taking ownership. These walk-and- talks are the only availability in an execs schedule. I tried to get time with an exec remotely and it was a full two months before I could get any time-- and since it was scheduled it wasn't ad-hoc and overly formal ("What would you like to discuss?").

So, in my judgement, remote workers are fine for very defined single tasks. For dynamic workers that move about the company and immerse themselves in lots of projects and want upward mobility, I can't recommend it.

I feel like my experience of being in office and remote at the same company gives me some unique perspective versus the people who join a company remotely and never fully appreciate what they are missing.

<comment><USER3> >When I was at the office for a decade, 90% of the insight and productivity came from informal conversations in the hallway, lunches and things I overheard in passing

The issue is not remote working, the very thing you wrote is the issue.

Virtually every time, remote working doesn't create new issues but reveals and - embarassingly - exposes existing ones.

You can no longer take a chance by letting things such as hallway affairs become a norm and an invisible force. You need to plan everything(and know what to plan), track everything relevant (and know what's relevant), be in control of the conditions for career and team progression (and therefore know precisely what these conditions are), you need to know your stuff. You can no longer just wait for magic to happen, put people in rooms and cross your fingers. Or send them to restaurant and expect team communication to have improved to the benefit of your KPIs.

The truth is 60-80% of today's companies are terribly run. Management of these companies is playing games without realizing it.

Remote working simply requires real management for it. Real managers quickly love it as remote working basically is : output-as-a-service : no noise, just efficiency and result. But the manager more tham ever needs to know what he is doing, because remote working accelerate the consequences of managerial weaknesses. What would have tanked a company in 5 years can tank it in 5 weeks.

But the positive is that once a remote setup has been successfully established, there is an organization insanely streamlined, efficient and competitive.

<comment><AUTHOR> Okay: So how would you advise someone to create that "real management for it"? Any references or suggestions you would recommend a well-meaning manager to gain the wisdom and skills necessary? (Because I also will be writing, separately, about how to do remote work well, and this is exactly the kind of info I want to impart.)

<comment><USER4> I've both hired and advised people hiring.

This is beginning to look like the blind men and the elephant.

The inside joke on remote/distributed work is "You know, if we just had 1) better managers, 2) better specs, 3) better tools"

We have been trying all of this for 30 years or so. At some point a reasonable person would look around and see that most all startups are colocated, physically in the same room having to deal with each other all day long.

There are plenty of theories as to why this is true. Another observation: people not in the office do best at rote work: fix the bugs, align the images on the website, and so on.

If your job could be done by robots -- if it required minimal interaction over electronic tools to get specs and deliver on them in an over-the-wall manner -- it will be done by robots. Creating technology is about _people_ , not technology. You sitting in a room and getting into flow-state and cranking out code is nowhere near as important as you interacting minute-by-minute with messy humans and trying to determine the nature of the problem you're solving.

Best-case scenario: you work on a tightly-knit team for a few weeks/months on a fixed-length job. Everybody gets into sync on the customer, specs, terminology, and solution. The customer's problem is not changing that much. You deliver some stuff as a team that people like. At that point, and not before, who cares where people are? Just get the work done.

You can scale that out to working in BigCorp on a fixed domain, but only so much. And the scary thing is that there are no alarms that go off if you're doing it wrong.

It's not impossible, or bad. But it works under very limited conditions. Understanding that is critical. I know there are a ton of folks who want to work remotely. I am one of them. But wanting something and looking realistically at what works or not are two different things.

<comment><USER5> > You sitting in a room and getting into flow-state and cranking out code is > nowhere near as important as you interacting minute-by-minute with messy > humans and trying to determine the nature of the problem you're solving.

Are you implying that "interacting minute-by-minute with messy humans" requires physical presence?

<comment><USER6> It doesn't require it, but in my experience is vastly more effective; teleconferencing (even with all the wiz-bang tech aids available) is vastly lower bandwidth and reduced options for interaction, and a lot more opportunity for distraction/interruption, either physically at any of the involved locations or because of tech failures.

</comment></comment></comment></comment></comment></comment><comment><USER7> Throwaway account.

In order to stay price competitive in our industry, we need to use a mix of junior, intermediate, and senior talent.

We have never found a junior or newly-intermediate candidate successfully work remote. Part of the point in having senior people is for them to be available to guide the less learned staff, so it makes no sense for them to all be remote too.

To be fair, for the right senior staffer, we would be willing to consider 100% remote. For the right intermediate staffer, we would be similarly be willing to consider a split onsite and telecommute arrangement, or other flexible scheduling options.

<comment><USER8> Have you considered letting your senior people, whom you apparently trust to be remote, mentor your juniors _remotely_?

<comment><USER9> This is what we do, we have 3 senior developers, 2 intermediate level developers and 3 juniors on our team. Even before we hired the juniors we _ALWAYS_ had GoToMeeting up and conversed throughout the day and worked together on projects, it's more imperative with the Jr's so we'll usually pair someone up 1:1 with them on a separate call to mentor them on a project. We haven't felt a need for a physical office except as an occasional meeting space (which is why we are working on getting one built-out in the city where the majority of our remote team lives).

<comment><USER10> So you do remote pair programming?

I have found this to be quite productive.

Real-time communication with voice, but also the visually shared WIP.

Is this your experience?

<comment><USER9> Yes, everyone on our team has a GoToMeeting license, throughout the day most of our team is pair programming using the screen sharing functionality or talking with our users about issues or doing UAT before deploying a new build.

Personally I'm not a fan of pair programming, I don't like shoulder surfing, but it's an invaluable tool for mentoring the juniors so I still participate when I'm not working on one of my more niche responsibilities I don't share with the rest of the team as much (DevOps, Salesforce developer, DB developer, business analyst, etc.)

</comment></comment></comment></comment></comment><comment><USER11> How many decision makers are willing to admit that they are subconsciously using "chair time" as a measure of productivity?

<comment><USER12> hilariously, some companies with remote workers have "activity monitors" installed that tell coworkers you aren't doing anything if your mouse/keyboard goes inactive for a few minutes.

<comment><USER13> Is that for real?

<comment><AUTHOR> It was, at least.

About 15 years ago I got a demo at a Gartner conference from a company doing just that. The vendor's primary goal, they said, was to measure where the developer was spending his time (coding vs debugger vs editor... I think it was a Visual Studio add-in?). But they admitted employers could use it to track what the developer was/wasn't doing.

...and that was before Facebook.

<comment><USER13> I see. But it was not necessarily just to target remote people. My wife had to use a time tracker like that a while ago, supposedly for the same reason: understand where people spend their time.

<comment><AUTHOR> This is a tangent... but I haven't run across such tools recently. I wonder whether they weren't good at what they purported to do, or whether companies quit paying such careful attention to where workers spent their time.

</comment></comment></comment></comment></comment></comment><comment><USER14> I will make the opposite statement about telecommuting. I have a rule that my team must telecommute. Everyone on the team with few exceptions must telecommute at least one day a week. Here's why. We have the technology for people to be remote. We've had it for years. I used to do it at larger companies, and honestly it was a pain at times. This is exactly why I make people do it. I don't want to lose people or lose out on ones that would be great, because we don't know how to handle remote employees. I have remote workers now that are vital to the team, and we all need to know the pain points they suffer, so we can fix it. It didn't occur to me we had issues until he brought it up in a weekly meeting to me that he felt left out on side conversations. Now we all do it, so we all experience the problems and we can figure out how to fix it. Really this is our approach to everything. Anything we have issues with we practice until we get it right and anytime we see room for improvement we make it.

</comment><comment><USER15> Reasons against remote working: 1\. Timezone issues - this is, imo, the biggest one. Especially after working with people in China, India, Europe or even eastern USA (with me in SF bay area). People all over the world _usually_ start working around 9-10, and stop working around 6-7. Meetings, code/design discussions are very difficult on those schedules, especially when you want a decision on smaller issues where a quick back n forth would settle the matter in 30 min if everyone was in the same room. And there are plenty of such issues, where unavailability of your coworkers seriously affects the productivity.

2\. Rapport / Camaraderie: Knowing someone in-person, having lunch/dinner/coffee with them, having watercooler talks about casual stuff etc builds a rapport, which helps build closer work relationships. I don't think people in remote locations are any different than my colleagues here, but the rapport is simply not there if I am going to meet them on video conf or IM only a few times a week.

3\. Impromptu discussions: These are triggered by spontaneous ideas, and ideas do not come according to a fixed schedule of meetings. By not having remote workers in these discussions, both sides lose (by not having more brains, as well as by missing out).

<comment><USER16> 1\. is absolutely true. Real time communication has been crucial to my success as a remote developer. I'm in South America so it's easy for me to work at the same time as coworkers in the US. I worked for a some time for a British company and after a while I just decided to wake up 4 hours earlier so I could communicate with my coworkers.

2\. and 3. shows your organization has communication problems. One of my favorite ways to combat that is to do some pair programming. You'll get to know people quite rapidly if you are talking to one each other 8 hours a day.

<comment><USER17> #1 would be true if everyone HAD to be in the same timezone. Some companies specifically look for remote employees in different timezones to cover customer communication/support etc. So that's pretty company-specific.

</comment></comment></comment><comment><USER18> At a few companies I've worked at, remote wasn't viable due to hardware development. It was difficult and expensive to replicate test setups for remote employees when unit costs for some of these devices range from 10 to 100k USD (e.g., VNAs).

<comment><USER19> VNA=Vector Network Analyzer?

<comment><USER20> Given the price range, yes. Even though USD 10K sounds a bit too low for a VNA, even a simple one.

</comment></comment></comment><comment><USER21> I'm definitely not the person you're targetting, but I was interested in remote working for a long time- when I asked why I couldn't I was given a few reasons:

1) Spontaneous meetings become impossible, scribbling something on a whiteboard becomes much more difficult, the barrier to communication is too high.

2) We've had bad experiences with people who work in other studios/HQ. They tend to shirk responsibility, and it's very frustrating to get them to actually acknowledge your issue as high priority. Managers assume this would carry into remote work if it were offered.

3) We work in R&D, all internet access is monitored/blocked and we use internal systems for communications only, so while we can VPN in sometimes it's discouraged because I have liberties at home that I don't have in my offices internal network.

They do their best to make a good office environment, but it's still open plan (much to my dismay, I can't ever focus in that environment for some reason) but try to strongly discourage remote working.

<comment><USER22> I agree that 1) is a problem, although technical solutions are possible I find them awkward.

I think 2) has to do with people not feeling they are part of the team.

Our solution to 3) is a separate work machine (laptop) set up so that you can not access the internet in any other way than through the VPN to the office. So, to work remotly you need to bring your work computer with you. You can not connect using your private computer.

</comment></comment><comment><USER23> It is quite weird that we have all these up-votes (including my own) but no answers.

I think that the real answer might be something quite embarrassing, and politically incorrect.

<comment><USER20> I'm more prone to believe the answer is dull and not well-defined, on the likes of:

\- We really don't know how to deal with the differences, and it is scary to try;

\- There are some company process that we are afraid of changing to accommodate telecommuting;

\- The risks and costs outweigh the benefits, or the benefits are fuzzy while the risks and costs are clear;

\- etc

<comment><USER23> Those are the excuses. I think the actual reasons are much more sad, visceral and disgusting.

</comment></comment></comment><comment><USER24> I admit that I'm not a great manager and more of a technician. I just happen to have the authority to make hiring and firing decisions for my tiny engineering team.

I prefer on-site employees to remote for two reasons:

1 - I find that on-site employees are a bit easier to manage. The bar to communication is lower when they're so accessible. Also, I'm working with legacy hardware and software, and there is so much to understand in order to get started on many projects, and it can be a lot easier to sit side saddle with a junior engineer to help them through the first steps.

2 - I don't have a lot of great confidence in my hiring practices and the owners of the company are a little more conservative. As such, I make the safer choice to hire candidates willing to work on-site instead -- I can see when they come in, I can task and re-task on a whim, and I have a much better sense of when they begin down rabbit holes.

<comment><USER25> [note: I work at a company that allows telecommuting and I currently manage 5 engineers in two different locations]

I wanted to expound on "The bar to communication is lower when they're so accessible."

I think a lot of communication involves understanding the culture (and by this I mean 'the way someone views the world' and not a more the mainstream sort of 'they are asian' type of definition) of a person. The speed at which you are able to understand a person's culture (what technologies they like and don't like and why, what they're previous jobs were like, what type of family did they grow up in, what jokes do they like, etc, etc, etc) increases drastically when they are working on site, and it's usually small bits of downtime (lunch, coffee break, shooting the shit late night) when you learn a lot of this stuff. Not having this understanding comes with a communication cost, and it's not just for the managers, it's also for the engineers they work with (and it goes both ways, the telecommuter is going to have a tougher time understanding the culture of their coworkers/manger).

Which isn't to say this why my company doesn't allow telecommuting (on the contrary, we do), but I think this nuance is hard to put a tangible dollar amount on but is very real. Additionally this does happen eventually with remotes (I have two great ones that I really think I understand) and there are things you can do to facilitate it, but it is harder.

</comment></comment><comment><USER26> Are there any success stories of early stage high growth startups that were started by a remote team? At least in the startup world, most people are concerned that you will miss that zeal and watercooler chat magic that is critical to early stage companies. I don't think anybody cares too much about your 1000th engineer being remote, the organizational DNA has already been set a long time ago.

<comment><USER27> As someone who is remote about 90%, I contend the watercooler chat magic is overrated and a waste of time. I was previously in office full time. I was one of the first tech hires. I am mostly a programmer, with a good deal of overlapping ops and analysis thrown in. I'm part of a very small engineering staff (under 10) in an overall small company (under 30 people). My work output in our open office drops to around 10% of the output when I work from my house. This is code, documentation, and meetings attended. People spend more time at the office because they are constantly interrupted (both by off-topic conversations as well as for work-related things) and need to stay late (past 40 hours) to finish their tasks. From informal notes, conversations that occur via Skype or In Person are poorly documented and tend to be rehashed more often than written communications via Github or Slack. IMO, if the entire team was remote and utilized more written communications, we'd be spend less time rehashing old topics and more time delivering value. As to the spontaneity and ideation of face to face, I've observed this happening over video chat and slack just as often as in the office. If people are excited about their work, they will talk about it, in person or not.

<comment><USER28> I agree 100%, this matches my experiences pretty closely. I worked 80% remote for a six months a while back, and it was astonishing how much better productivity was, as well as the quality, if not necessarily the quantity of communication. Now I've basically flipped that ratio, and it is depressing how much of my time is wasted by low-quality communication, interruptions, as well as the low-grade stress and irritation of _having to be in the office_.

</comment></comment></comment><comment><USER29> The opposite of what you are asking: As someone who has worked remotely for 5 years, I can say that a big reason that it works for us is the willingness of everyone to make time for collaboration. For our team (mostly writers, consultants, analysts), this means picking up the phone and having conversations with each other constantly. For perspective, I use ~3000 minutes/month on the phone. This is largely made up of 15-30 minute calls.

If your work product doesn't lend itself to spoken discussion too well, or if that kind of collaboration doesn't suit the team, I can easily see why it would be very difficult to make it work. It is easy to collaborate remotely on ideas, but pretty difficult to collaborate on the final product.

If I worked in an field that required a lot of visual collaboration, like design, I don't think it would work nearly as well. The online, webex style tools are still too poor to support good collaboration on those kinds of tasks IMO.

</comment><comment><USER30> Not exactly what you are asking for, but I'll throw it in here:

I run a fully remote company, and most of the objections I've heard from others we've found workaround for.

The biggest unsolved problem is whiteboarding - there is no good collaborative online whiteboarding solution that doesn't require a lot of expensive equipment to be deployed to everyone.

<comment><USER31> > The biggest unsolved problem is whiteboarding - there is no good > collaborative online whiteboarding solution that doesn't require a lot of > expensive equipment to be deployed to everyone.

Maybe my company is just weird, but we don't use whiteboards all that much. At least for code our preferred collaboration method is pairing, which isn't as hard over a network.

We write NLP software, and most of our whiteboard usage is for drawing out linguistic constructs and often involves only one person doing the drawing, which seems like an easy subset of whiteboarding to handle remotely.

<comment><USER30> We don't either, but it comes up occasionally. Sometimes when figuring out a large architecture, it's just easier to be able to draw it out. So far we've solved the problem by waiting until we see each other in person every few months, so it hasn't been a huge issue, just the main issue we can't seem to solve well.

</comment></comment></comment><comment><USER32> I have worked for a 100% remote team for 4 years. Most of the concerns I see being posted here, I believe have more to do with the inability to hire well, the inability to efficiently communicate at the inter and intra team level, and the inability to operate as a remote-first company.

Below I document how to successfully run a remote company. I work for a successful startup receiving regular accolades for our product.

Hiring:

Never hire very junior unless the person shows extreme talent combined with superior communication skills. Generally you are looking for people that are: highly efficient, organized, responsible, disciplined and able to stay on task with limited oversight. They should be self-starters with numerous projects they can point to that they delivered on their own.

Product engineering:

Near all communication happens in Slack/Hipchat/etc. Group meetings, when including remote people, happen in skype / Hangouts. We use shared google docs to brainstorm product and document specs. We use Trello to translate those high level specs into actionable stories. Use github to organize code reviews. You need a results-driven mentality. What did a developer deliver this week? This month? Weekly standups on Google Hangouts + monthly 1-on-1's with each developer can give you a good sense of how well a person is performing.

Culture-building:

Have in-person meetups 2-4 x a year for beneficial face-time and for people to get to know each other better on a personal level. Have monthly video conf/hangouts on non-work technical topics where people rotate presenting. Have a separate monthly book club to discuss technical or nontechnical topics.

Onboarding new people:

First, never hire very junior people. When a new person is hired, have them do 20 min 1-on-1's with all team members to get to know each other and their job role. Pair them up with a another person to work on a shared project. Have them paired for several projects before releasing them on the own.

I am happy to answer any specific questions if you have any.

<comment><USER10> What is your team size?

<comment><USER32> 20 people, but the processes we have in place should be scalable to way higher.

<comment><USER10> I am not doubting that, I was unsure if this would be too "formal" for a small team of 5 or less.

<comment><USER32> In that case, I would slowing introduce pieces of this, see how it works etc. If you feel like you need more process or more ways to build team camaraderie act accordingly.

</comment></comment></comment></comment></comment><comment><USER33> I work at a company that is strict about not allowing developers to work remotely except in rare circumstances (i.e. an employee wanted to spend time in another state to be with their family for a few weeks, and they wanted to work during most of that time rather than take vacation).

For us, it's about keeping the barriers to communication as low as possible. We do pair programming, so we're already very much oriented to frequent communication. While tools like Slack and email get the job done if your team is working remotely, nothing beats being able to turn around in your chair and quickly engage another pair of developers (or the entire dev team if necessary) in a quick discussion about something. This extends to the rest of the team (designers, product managers, relevant business analysts, etc). At any point I can walk 30 steps or less and talk to anyone from the product or business teams about requirements.

Admittedly we keep strict working hours to maximize the amount of time the team is together (8am to 5pm, everyone takes the same lunch hour). The flip side of those strict hours is that we are never asked to work overtime or weekends. We come in, the entire team works for 8 hours together, and then we go home. People never believe me until they see it in person, but our office will be buzzing with work at 4:58, and then be a ghost town at 5:02... unless we decide to play some post-work ping pong or grab a beer!

I'm not saying that I don't think that remote work can be effective, because I've seen it work. But I think it's disingenuous to say that remote work is equivalent to colocation. The best argument I've seen for seeking remote workers is when a company is located in an undesirable city and struggles to attract talent (i.e. a company in Paducah, Kentucky will struggle to attract candidates in a way that a company in Denver, Colorado probably will not).

</comment><comment><USER34> Our management wants onsite for better control. I think it's all feelings based. We want to hire in Seattle. We had some remote not work out, therefore all remote is "bad".

I think BS. We just got a new remote QA team and they are doing great.

We have two remote devs also who are doing good work.

I interpret the evidence to show that remote does work.

I still get push back on it but the rationale is based on words like "better" and "easier" without quantifiers.

My feelings are that some managers like to interrupt frequently for "urgent fires" and that is easier when someone is a few metres away.

<comment><AUTHOR> In what way did the remote employees not work out?

(I'm looking for examples to include, so details are helpful!)

<comment><USER34> We called it a quality issue. IMO we didn't provide a good environment. One remote QA team promised things they didn't deliver. But we found out in two months

Edit: good environment means clear direction, open communication. Which is necessary onsite as well

</comment></comment></comment><comment><USER13> Answering for the hiring side at an organization where remote work is not allowed.

The reasons given by the founders to only allow local workers are: * we want everybody in the room to build the culture and for people to learn how to work together * whiteboard sessions/intense discussions are difficult to do remotely * for lead positions: face time is important to properly lead the team

I feel like it's a disastrous policy to find candidates. I'm in MA and we compete with _a lot_ of companies over a rather small pool of candidates. The worse is that the "local only" comes with a "please, go easy on the WFH" policy. Recruiters literally laugh at us, and tell us that we will never be able to compete if we don't allow flexible hours/locations.

We did manager to hire a couple developers, but we had to lower our standards (and one could question them, but it's not really the point here).

Interestingly, after a while the "limit the WFH" policy was relaxed. And now people are still local but can take a couple days to stay home every week. I think it's just because the team delivered, worked hard and built trust. It's just sad that it took a long time, and that still has not changed the no full- remote policy.

I think the candidate would have to be extraordinary and, more important, fill a position that had been open for a long time to allow remote workers. Enough time to convince upper management that we had to consider a wider pool or we would never find anybody.

</comment><comment><USER35> I have a remote member on my team who came to us as part of an acquisition. He travels to our London office once a fortnight. It works well, but I wouldn't hire remote workers for new roles.

The key reason for this is that our culture and processes within the company are not very well equipped to accommodate remote workers. We're spread across two sites (one of which is a factory), and communication is difficult enough as it is.

</comment><comment><USER36> I could be more productive remote, because it's less chair-time and more working when I'm really concentrated, 1.5h less commute, less distractions (i really love to block out the rest of the world with music and don't like headphones), real food and a bed for a quick nap at home. We are partly remote, but I'm sadly not.

What is nice about non remote though:

\- you can see if a college has time for your questions

\- you can scribble stuff easier while explaining complex things

\- less language barrier. I find it really hard to understand non-native speakers over a bad skype connection (high quality headsets would fix this I believe)

\- you can sense how the other feels and act accordingly

\- It's easier to guide inexperienced people when they feel more free to ask questions. Probably fixable through good culture, but an effort to be made. It's also easier to see when they really got what you mean. (had trouble with the remote people here, though being forced to write even tighter specifications or more making more detailed mockups is not necessarily bad)

<comment><USER37> The language barrier thin is very real. I'm not a native English speaker and have very hard time understanding people with heavier accents. It's especially bad over phone/web conference.

Also it's really amazing how crappy many companies' web conferencing setup is. They break down regularly, have poor sound quality and are generally really flaky. I know this is getting better with Hangouts and alike, but still, they are occasionally going to crap out and always, it seems, at the most inopportune time.

<comment><USER16> > \- less language barrier. I find it really hard to understand non-native > speakers over a bad skype connection (high quality headsets would fix this I > believe)

> The language barrier thin is very real. I'm not a native English speaker and > have very hard time understanding people with heavier accents. It's > especially bad over phone/web conference.

Solution: Hire only people who speak good English (yes, you should test them / interview them before hiring them!)

<comment><USER36> Fine english, just with a foreign accent. No problem face to face.

</comment></comment></comment></comment><comment><USER38> Currently we are an "on-site only" workplace.

There are two reasons for this, firstly and most importantly our primary founder has a law, not a technical, background.

This means he often has to just trust that myself and the other core team member are doing sensible things. With a large chunk of savings invested and the project running late (prototype and limited release 1 done, but 'core' functionality and UI still very much in progress) bums in seats is a very real metric.

Secondly is a combination of bad experience, low funds, and not the right time.

The company has had several other in office developers who were supremely sub par. A lot of my rapid acceptance into the company and (currently thrahing out the details of) gaining equity came from the removal of predecessors crap and providing simple and solid guarantees. This makes us edgey about trusting people to get on and do things without serious oversight.

Its obvious that this can be remedied in two ways- with more funds for the right developers and spending more time managing them. The funds are being remedied with our growing sales (yay!) and the time... well I'm primary developer and learning a hell of a lot about managing people.

Not the right time is a case of everytime we bring someone new in it will distract me for a fortnight or so... especially considering the current compensation we can offer. As we are near a wider release it does seem more sensible just to get on with it and hire with the money and time a wider release brings (or takes away, as I suspect will be the case with time).

Finally we should note I fully intend to bring remote working into the company. At first for new hires then a few years in for myself and the other two (likely rota'ish). This looks like an uphill battle with the founders but I'm sure when their stress can be lowered it will be a lot easier.

Regardless, life ahead shall be good.

</comment><comment><USER16> As someone who has worked 10+ years remotely (based in South America) I think it's a combination of factors:

Supply and demand. Why hire remote when there's plenty of warm bodies locally? Most companies do not need, and cannot afford, top-tier talent. Labor shortages are a myth.

Managerial incompetence. How many of the managers have any experience managing a remote team? Do they know what to do and what not to do?

Remote is frequently seen as synonym with "cheap, sub-par foreign developer" and there are many good reasons companies avoid that.

IMHO, remote-friendly organizations will prevail. The ability to hire from a much larger pool of talent and save on office costs gives them the upper hand.

<comment><AUTHOR> > Managerial incompetence. How many of the managers have any experience > managing a remote team? Do they know what to do and what not to do?

What are the skills that someone needs to manage a remote team? How could someone measure whether he has them?

<comment><USER16> Ability to communicate properly and proficiency with collaboration tools rank high on the list. It's also crucial to be able to properly identify and evaluate the contributions of any team member.

Remote is also largely incompatible with micromanaging. If you don't trust the ability of your remote developers to take decisions on their own the team is likely to underperform and fall apart. This is one of the main reasons remote works much better with senior developers.

</comment></comment></comment><comment><USER39> Broadly, remote workers are only going to be successful in two situations:

1\. Remote workers are task-oriented or don't require collaboration. 2\. The company is set up to make remote workers equal citizens. ("Remote First")

#1 tend to be the cost play, and leads to outsourcing or offshoring. (Or are things like in-territory sales managers or something.)

#2 is _hard_ unless you're starting from scratch. On top of implementing collaborative technology, improving processes, focusing management practices, and restructuring your organization, you need to change your _culture_. Employees who sit right next to each other should be chatting in the Slack channel, not face-to-face.

Most companies have other priorities than to tackle this kind of change, and quite frankly, don't _need_ to look outside a 30-mile radius to find qualified candidates.

Hiring remote employees without the organizational foundation to support them is a recipe for disaster.

Having an existing employee "go remote" is easier because they're already ingrained in the culture, and "alternate work schedules" (e.g., not 100% remote) are good in-transition approaches.

</comment><comment><USER40> Our last hiring round was for a senior system administrator. We currently have 10 student workers "underneath" this position, and something like 30 percent of the employees time is spent mentoring students to do the work. We're okay with occasional work from home days, but a 100 percent remote person is basically a non-starter.

There's a number of tasks that cannot easily be done remotely:

1\. Recruiting and Interviewing students. 2\. Installing equipment into datacenters. 3\. Letting customers into the datacenter after hours. 4\. Face- to-face student mentoring.

Hiring a 100% remote employee essentially means a substantial shift in in the other employee's (ie me) duties.

We recruited for this position globally, but a number of prospects were only interested in working remotely. It makes sense for the prospects -- remote work frees up a family to follow one spouse's career. It makes filling positions harder obviously. But the only way we'd be able to accommodate that equitably is by dropping the focus on student employees, and we'd need a lot more cash flow to make that happen.

</comment><comment><USER41> I live in a rural area in upstate NY. I can't relocate because I live close to my wife's family and she teaches kids to ride horses.

A while back I was in a dead end job and working on a side project that was an image search engine that had nearly perfect relevance in a time when both Google Image Search and Bing Image Search were both embarrassingly bad -- at least at the time I started.

It took about a year to get the product really ready populate the database, and by that time the big guys had come a long way.

This got the attention of a company in LA that had ambitious ideas for an intelligent social media aggregator and they had explored several dead ends in terms of building the brains of the product so they brought me in. They were hoping I would relocate but they had to start getting traction.

It lasted about a year. A prototype of what I built was picked up by the team and developed into a "MVP" that didn't really get product market fit.

I moved on to another company that was based in Rochester, NY that hired remotes, but that is another story.

<comment><AUTHOR> I want to hear the other story, too! :-)

</comment></comment><comment><USER22> I find remote collaboration with shared screens and headsets much more productive than sitting next to each other. You can quickly jump back and forth between the shared screen and other activities while collaborating.

We also do this even when being in the same room, just because the screen sharing is so powerful compared to physically sharing a display and a keyboard.

Also, you can quickly and easily call in any number of people and everyone can easily read everything on the screen.

I find this perfect for mentoring, pair programming, demonstrations, meetings, etc.

You don't have to go fetch your coworkers and drag them to your desk to show them something.

Also, you can quickly see if the coworker is busy in another session, or set your own status to busy if you need to work uninterrupted for a while. This is not possible when physically in the same location (unless you have a door you can close). People will still come up to you and interrupt you with a "quick" question, derailing your thoughts. A virtual call can simply be ignored.

</comment><comment><USER42> for a purely software based company I think the main reason to require on-site employees is lack of trust. management really wants to see the people they pay walk in in the morning and sit at their desks.

personally I am more productive working remotely. I used to work for many years on-site at the same company and the distractions were unbearable, phones ringing, people walking by who always felt the need to interrupt me about anything (work related or not). and many phone calls about unrelated projects which resulted in context switching.

it turns out working remotely is more efficient because you avoid the random chit-chat, and unrelated calls transformed themselves into emails which I can open and respond to at a more convenient time.

</comment><comment><USER43> I know this isn't exactly what the OP is asking for, but I'd like to share my experiences working remotely for 8 of the last 10 years.

* It's not for everyone. You have to be pretty motivated and driven, and also a good communicator. You additionally need some good non-work relationships. (Although, that's probably true regardless...)

* It's a lot easier when everyone uses phones/email/slack/etc. Being the 1 guy on the phone during a 30-person meeting sucks.

* Those little "water cooler chats" can and do happen on slack and phone calls. It's helped by having met the people in person before, but even that isn't a requirement. I was talking to a co-worker that I've never met in person about pokemon just yesterday...

* I usually shoot for about 10% of my time being spent on-site in 1-2 week chunks, perhaps a little more right after joining a new team. I try to go out for dinner & drinks and whatnot with team members for at least one night on a visit. This can help with those virtual "water cooler chats" later on.

* Mentoring can happen remotely as well. Mentoring and guidance is a large part of my current role, and I've never met the majority of the folks I help out.

* I do occasionally take time out of work for family things. But I also occasionally cut out family time to deal with pressing matters at work. So I think it works out in the company's favor overall.

* I've been told by more than one manager/CTO/CEO that I was fit for a leadership role but wouldn't get it because I worked remote :(

* I joined IBM a year and a half ago partially because of this: I believed that being remote wouldn't hold me back from promotion here but...

* A few months back, the Watson division got a new guy in charge. Everyone was told to either move on-site or find a new job. I managed to get a temporary exception until the end of the year but I'm still not sure which one I'm going to choose when the time comes. Maybe both (I've always wanted to see Europe... ;)

</comment><comment><USER44> I have worked on remote-only teams which were great because everything was set up for that workflow. In companies where you have a lot of on-site people the remote guys add a lot of overhead because now you need processes for on-site and offsite people.

I am fine if a guy shows up two times a week or so but I am wary of full-time remote workers unless I know I can trust them to not waste time on irrelevant tangents. There needs to be some level of maturity.

Time zones are also an issue.I would not work with somebody 12 hours away.

</comment><comment><USER8> I once got a remote job with a startup in Dallas, but it was a bit of an unusual circumstance where I had all the bargaining power. A friend was going in as the director of engineering and really wanted me, and I basically made being 80% remote a condition of my employment. It wound up not working out in the end largely because of that (not because of my friend, but because of executives who didn't feel like they were obligated to honor their agreement with me).

</comment><comment><USER45> Easy - my ex-employer's HR department has an explicit policy of promoting when your staff grows. Part of it is a spreadsheet exercise at the end of the year and part of it is optics. The greater the staff I can show the higher the change of promotion. That was the deciding factor. Period.

I left that place because it was non-sensical, but it was a major employer in Connecticut, so i wonder how many other major employers have a similar policy.

</comment><comment><USER46> On my team we work from home roughly once a week, but don't hire anyone who's remote full-time. Honestly, I don't have super strong reasons for or against remote. It does seem like your culture needs to be either fully remote or fully colocated (to avoid the informal communication problem) but there's no major reason to pick one or the other. So I go with fully colocated, because it's the default.

</comment><comment><USER10> In some instances I really believe it to be an ego or optics thing.

I have noticed some business owners emphasize how many people they employ, how they are "job creators".

On the opposite end, I have seen entrepreneurs who strive to be as lean as possible (automate everything), with employing another person seen as a last resort.

Do you think it depends if the org./dept. is results focused versus process focused?

</comment><comment><USER22> What about open source projects where people mostly collaborate remotely?

Are they harder to manage, or less efficient?

</comment><comment><USER47> My company generally doesn't hire telecommuters. There are exceptions though.

* Why does the person who does this job need to be on-site? Please be specific. Give me examples of things that can only be done if she were in the office.

Ad hoc meetings are 1000 times easier when everybody is in the office. Standup and other meetings are hindered by teleconferencing at best. Even with high quality video and audio, it is often much harder to hear the remote person, harder to collaborate (I can't just walk to a whiteboard and draw something up quickly and have them _easily_ see it.)

Having them train a new hire or an intern is much harder. Furthermore, interns and new hires much prefer somebody being able to sit with them and collaborate. Sure, you can do screen sharing, but it's not the same at all.

One thing that makes our team 'special' is the culture of the team. We often do team building exercises (paintballing, curling, etc.), have optional happy hours, etc. and all of that is physically impossible without flying somebody out.

It is much harder for the remote person to get support from help-desk. If you are onsite, you walk down to one of a few different help desks and get help right away. If your hardware is faulty, you get a new laptop and are up and running within a few hours. This is not possible with somebody remote, and we've had major headaches dealing with this.

* Have you been in a position where you personally would be okay with an employee being a telecommuter, but a decision-maker deemed otherwise? How did you handle it?

No.

* How has the policy affected your company's ability to attract candidates?

I think this one is pretty hard to answer. I'd assume many potential employees pass on even applying since we don't really support remote work. I don't think I can give a proper answer here, unfortunately. I can say that we're fine with this tradeoff. We haven't had any problem attracting talent in the past (paying boatloads of money helps.)

* Have you hired someone for an in-the-office job, and later given permission for the individual to work from home? What happened to make the change okay?

Yes, we allow this with extenuating circumstances. We've had team/org members get sick and prefer to work from home for a few months while they recover. We've had employees leave the country to be with their parents due to illness. Employees who wanted to work from home a majority of the time while their child is young, etc. Generally we're pretty okay with short term telecommuting, but we don't really offer full time (forever) telecommuting.

Note that team members regularly WFH for a week or two while visiting home (if they don't want to take vacation), and nobody cares if you WFH once a week or two.

* What would it take for the company to change the no-telecommuters policy, even if only for one specific position? For example, "If a rock star in my field applied for the job, we'd do anything to get him to say Yes – including letting him work remotely." But there can be many other answers, and I'd very much like to hear yours.

If a known rock-star (guaranteed) applied, we'd let them work remotely. If we had trouble attracting the talent we needed, we'd let them work remotely.

</comment><comment><USER48> I am someone who got an "on-site only" job and now work full time remote in the same position on the other side of the country (and sometimes the world).

This happened because I worked on-site for a year and I wasn't happy with the lifestyle the city I lived in provided (specifically SF/the bay-area, spent 5mo in SF then 5mo in SJ, still wasn't happy, so I moved to VN for 6 weeks).

I told my boss I needed a change of scene-ary and I really enjoyed working for and doing the things that I do at work, but I really did not like the bay and I wanted to live other places. He agreed to let me work remotely from Vietnam for 6 weeks, then Florida indefinitely. I think a few things that drove that decision were:

1\. After working with me for a year, I am a known quantity that they like. With every new hire, there is risk and some people think more risk, since people won't be there.

2\. The company is very small (10 people) and I play an important role in our platform. It would be expensive to replace me and they don't really want to, because of 1.

* Why does the person who does this job need to be on-site? Please be specific. Give me examples of things that can only be done if she were in the office.

Having been on site and remote, a couple of things that I feel that I am missing out are:

1\. I feel like I have less klout in the office. When it comes to product design and company policy decisions, I am often left sitting on my hands while everyone else chats about it in the office.

2\. Sometimes I miss spontaneous product discussions that happen within the office and am not typically told about that. This should be fixable, but it is about building good habits and keeping the team informed.

* Have you been in a position where you personally would be okay with an employee being a telecommuter, but a decision-maker deemed otherwise? How did you handle it?

No.

* How has the policy affected your company's ability to attract candidates?

Since the office is in the bay, people fly from all over the world to work in our office. Has not been an issue.

* Have you hired someone for an in-the-office job, and later given permission for the individual to work from home? What happened to make the change okay?

me! see above.

* What would it take for the company to change the no-telecommuters policy, even if only for one specific position? When I got hired, there was a no-telecommuters policy and they were letting go both of our remote workers. I think I have been able to work remotely because of the points mentioned above.

</comment><comment><USER10> It seems in most reason given here, it is because the onus is on the junior developer to seek out the senior developer's help on-site, but it is not encouraged for a senior developer to reach out to a remote junior dev.

</comment><comment><USER49> I'm not allowed to work offsite, but then again I work in defense, so you can probably put two and two together...

<comment><USER8> I used to work defense, and with a few exceptions, I always thought most people who worked at the company could have been remote without much problem. It's really not that hard to deal with classified information remotely, and most things aren't classified (yet).

</comment></comment><comment><USER50> I'd like to know how many people here who refuse to hire remotely are willing and can provide a proper working environment to their engineers: ie-> single, private offices, 4k monitors, adjustable desks chairs, etc. Or are these people forcing people to work onsite in substandard conditions simply so that there can be "spontaneous" conversations, aka pointless distractions like I read in most of the comments?

<comment><USER51> How can such conditions be 'substandard' if they are the norm, and thus, presumably, 'standard'?

</comment></comment><comment><USER52> I think its also a lack of examples of companies that managed to scale up a remote dev team.

</comment><comment><USER53> I've argued both sides of this issue (both for and against) and generally they come down to situational communication.

Before jumping in though I'd like to create some definitions that I use in my mind to keep things differentiated. There are three configurations of remote work that have been called at one time or another, telecommuting.

1) Working from home. This is perhaps the most interesting one and it is specifically an employee in their own home using their own or company equipment to connect back to "the office". They participate in teleconference calls when invited and generally have a VPN type connection to the company network.

2) Working at a 'commuter' desk. These are people who are working away from where they normally would and sitting at a desk in a company owned facility that is not specifically assigned to them but hosted in a company facility.

3) Working at a 'remote site'. These are members of the group who are working at a company facility that is distant from the primary facility that is hosting the group they are associated with. It may or may not include other "remote" members of the group but it is a permanent arrangement unlike #2 above.

I don't think there is a lot of controversy or question around #2. People are traveling, they can stop in a local office and get some work done and have access to things like printers and conference rooms. So for those workers it is a way to work effectively while travelling.

Option 3 (a "local" office for a member of a "remote" group) is generally well supported by most organizations, especially ones with extended sales presence in multiple markets. This arrangement benefits the company by allowing them to hire in places where people don't want to move away, and in my experience, it makes the sales team (if there is one) at that facility more effective as it can cut down on communication time between corporate and sales.

So lets agree when we're talking about "telecommuting" as something which can be argued for or against, we're talking about allowing full time staff to work out of their homes.

There is lots of material on this with many different angles from team building to team communication to legal liability.

Most people don't think about the legal question, just like they don't think about collecting sales tax from people at their garage or yard sale. However, in some jurisdictions it is illegal to work full time out of your home without a business license, fire department inspection, and ADA compliant facilities (for example). In some places you need a zoning allowance. There is a question about injuries you sustain while at home but "working", is that covered by workman's compensation? homeowners insurance? (likely both will refuse to cover it). To the extent that working at home becomes more popular, you will see municipalities crack down on this just like they do on lemonade stands[1] from time to time.

Then there are the team dynamics. If you have an office which some people hate (say a noisy open office plan) but they can't work from home (maybe they are renting one room out of a 3 bedroom apartment which has two families living in the other two rooms). They will have negative feelings about the company and their fellow employees who have the luxury of working from home. If you have a lot of spontaneous brainstorming sessions, few will remember to "dial in" someone who is not in the office. This will make the person off site feel "out of touch" (which can lead to them feeling anger and distrust for the rest of the team).

But lets answer the 'hiring side' questions, that is easy.

\-- They have to be on site to avoid negative team dynamics and legal liability.

\-- Yes, and I told the employee they had to work on site at least 4 days a week.

\-- No.

\-- I've seen that happen (I wasn't personally involved in the decision). The change was okay because the person's job was essentially a group of 1 (they had few external dependencies) and they were reliable at meeting the schedule. They essentially became a "remote office with 1 employee" in it.

\-- I have been in companies where it was pretty absolute (everyone comes into the office) and companies where it was more flexible. In my experience, groups within the company without work-at-home people had better group dynamics and higher productivity. But to really understand why that was you needed to understand how the company got things done and how groups negotiated deliverables.

[1] From 2011 -- [http://www.forbes.com/sites/erikkain/2011/08/03/the- inexplic...](http://www.forbes.com/sites/erikkain/2011/08/03/the-inexplicable- war-on-lemonade-stands/#476741982264)</comment>


Towards a Global Brain / Tim Oreilly - <AUTHOR> http://www.slideshare.net/timoreilly/long-now

<comment><USER2> It's hard to see how the threads come together but there is definitely something there: faster and faster flow of information allows humans to produce, refactor and combine ideas much more quickly than one mind could.

On the other hand you need some people who don't immerse themselves in the stream too much so they can actually drill down on hard problems.</comment>


Show HN: Twitch Plays Tinder - <AUTHOR> https://github.com/xasos/twitch-plays-tinder

<comment><USER2> FYI, this is completely against the Twitch ToS (for non-gaming content) if it was actually implemented.

<comment><AUTHOR> Yeah, was kinda just a hack to see the power of Tinder data</comment></comment>


Get Ready For the Memristor Revolution - <AUTHOR> http://blogs.zdnet.com/Foremski/?p=1309

<comment><USER2> Much better article: <http://news.ycombinator.com/item?id=397335>

I really hope these make the hard-disk and RAM obsolote. The hard-disk of course is the current bottle neck, so removing it entirely from the picture with potentially smaller, and cheaper devices alone will lead to an insane amount of innovation.

For example, the idea that we can move away from the von Neumann model and have in-memory processing (so-to-speak) could lead to a revolution in computer vision and other highly parallel, compute-intensive, pattern matching applications.

For now, HP will begin to deploy these things in tiny, very sensitive sensors that will lead to, potentially, more efficient discovery of oil: <http://www.hpl.hp.com/news/2009/oct-dec/cense.html>

<comment><USER3> I guess clunky hard-disks with all their moving parts will be around for some time to come. Just because they have already been around for so long and survived several other up-and-coming technologies.

</comment></comment><comment><USER4> Important subject, but this article sucks.

 _Instead of just two states, on or off, as with transistors, memristors can represent many states. This means we can create new types of computing models, we can also create analog computers, which you don't program, but you let them learn. You can then replicate the learning to other memristor analog computers.

\- We might be able to use memristors in a similar way to synapses in the human brain._

_snort_

<comment><USER5> What is wrong with the article?

<comment><USER6> This bit is rather silly:

"This means we can create new types of computing models, we can also create analog computers, which you don't program, but you let them learn."

Analog computation is nothing new and has pretty much been superseded by stored program digital computers - for very good reasons.

I used to knew am engineer who had used a hydraulic analog computer to solve systems of differential equations that modeled fluid flow... :-)

<comment><USER7> I'm not claiming to be knowledgeable, but isn't it true, that analog computers are easy and fast to use for computations (sliding logarithmic ruler, self regulating hydraulic systems,...). But notoriously hard to construct IF you're looking for something multipurpose and programmable.

<comment><USER8> It's mostly the "you don't program, but you let them learn" part that's a bit weird/inaccurate. You have to program analog computers, and don't get any automatic learning built in. It's just a different kind of programming. Some things, from a digital-programming perspective, are amazing freebies that would require difficult programming on a digital computer. Other things, that on a digital computer would be trivial, are frustratingly difficult to implement. But it's still programming of a sort either way.

And it doesn't make a ton of difference these days anyway, because "continuous" vs. "discrete, but with trillions of gradations" are indistinguishable for a lot of problems, so you can simulate an analog computer on a digital one, or vice versa, with reasonable accuracy.</comment></comment></comment></comment></comment>


Evolving to Enterprise-Grade Permissions - <AUTHOR> https://benchling.engineering/evolving-to-enterprise-grade-permissions-493eac166449 <comment><USER2> At the risk of making sweeping generalizations, the people who build permission systems tend to be very different from the people who sit at a desk and set permissions for people.

Those who build permission systems commonly think very deeply about the process and can hold tremendously complex permission systems in their head. The people who are tasked with setting permissions in the real world tend to view anything else as a more important part of their job to think about and tend to default to either granting permissions broadly so they aren't bothered again or granting permissions minimally so they aren't blamed for things.

A small number of well designed and well named roles is unfortunately commonly better in practice than a highly powerful and flexible fully configurable turing complete granular permissions management system.

<comment><USER3> (Benchling PM here)

As far as sweeping generalizations go, I think that's a pretty reasonable one :). I'd imagine that almost all of our users (including most lab admins who assign permissions) don't want to keep a complex permission system in their head.

What we've seen is that this system ends up leading to a small number of well- designed and well-named roles. Most users see the roles themselves ("DNA Designer"), but don't need to worry about exactly what the configuration behind it is.

 _Somebody_ needs to be aware of the powerful (although not quite turing- complete) configuration system, but what we've seen in practice is that it's usually one or two technical admins whose job it is to gather requirements from the different teams and figure out how to translate those into a few digestible policies that everybody else can assign.

We certainly didn't invent this model (it's basically RBAC), but we've found it's a good way to address the often-complex demands of a big pharma (where IP is crazy regulated from like, 3-4 angles) without taxing the individual scientists too much.

</comment></comment><comment><USER4> The reasoning about only allowing additive permission is something I've had pretty strong opinions, and it's nice to see that other people agree with this. Permissions gets incredibly complicated very fast even in the best case, and any additional complexity can easily confuse users.

Their use case feels a bit too micro-managed for my taste, but that is certainly a matter of opinion. And if their customers demand this, it's hard to convince them otherwise. My preference is to handle certain more subtle cases like their "only DNA design team can edit sequences, but Research team can edit metadata" as a convention, not a hard rule enforced by the application. And if you have a good history of changes, it still allows for transparency about who edited what.

</comment><comment><USER5> Interesting article and really close to what we'll need to do at my company soon!

I wonder if there are any open-source projects that operate in this realm and provide an off the shelf solution to this.

I'm thinking that it could be something like a small server to store the policies and a few libs in various languages to interpret them.

This could or could not be tied to a user management system.

<comment><USER6> Gluu is possibly an off-the-shelf solution: [https://www.gluu.org](https://www.gluu.org) (I'm not deeply familiar with its authorization capabilities)

<comment><USER5> Awesomeness @adamfeldman, thanks for the pointers!</comment></comment></comment>


How Long it Takes to Learn a Dvorak Keyboard - <AUTHOR> http://lifebyexperimentation.com/2013/08/learn-dvorak/#.UgEo-2T71Uv

<comment><USER2> I used [http://www.keybr.com](http://www.keybr.com) to help me learn the Dvorak keyboard, after a couple days I couldn't stand not knowing where my hotkeys were. This article has inspired me to try again, maybe this time I'll use the Dvorak-Qwerty layout on Windows. Does anyone have any experience using the Dvorak-Qwerty ([https://code.google.com/p/dvorak- qwerty/](https://code.google.com/p/dvorak-qwerty/)) layout linked to in the article on Windows 7/8?

<comment><USER3> Thanks for the link, definitely something I'll be making use of. I just started the switch over to colemak ([http://colemak.com/](http://colemak.com/)) yesterday, and these kinds of tools will definitely be helpful in gaining the muscle memory for the layout.

</comment></comment><comment><USER4> every time I am about to try something like this, I realize that I use VIM.

<comment><USER5> Vim is a blocker for me too..</comment></comment>


Ask HN: Is tradepub.com in anyway connected to HN? - <AUTHOR> Is tradepub.com in anyway connected to HN?  The reason I ask is that I stumbled upon this page:
http://thehackernews.tradepub.com/free-offer/2016-top-trending-government-technology-resources/w_bund15?sr=hicat&_t=hicat:1204
Which in turn brought me to this page:
https://thehackernews.com/ <comment><USER2> The "thehackernews.com" domain is a spam site. If you have "show dead" enabled in your HN user profile, you can see that just about everything submitted to HN from that domain is '[dead]'.

[https://news.ycombinator.com/from?site=thehackernews.com](https://news.ycombinator.com/from?site=thehackernews.com)

<comment><AUTHOR> Thank you. I suspected it was but I wanted to verify.</comment></comment>


We need to kill off the localStorage API - <AUTHOR> http://paul.kinlan.me/we-need-to-kill-off-the-localstorage-api

<comment><USER3> Whenever someone says "We need technology X to go forward. It is our only choice." I see it as a warning. Is there really no other way forward, even if localStorage _is_ broken? Maybe IndexDB is awesome (I have no idea), but perhaps it's not the holy grail.

One example of this is CSS. CSS is leaps and bounds better than, for example, GTK's layout and styling system. It is a huge improvement over spacer images and tables. However, it is far (far, very far) from perfect. Having umpteen different ways to position elements, inconsistent layout/display models, inconsistent implementations, no nesting and even lack of arguable features like constants (why can't I define color _main_color_ = #cc0000; and use that everywhere, so I don't violate DRY principle?). It is important to recognize both the benefits and flaws of all technology we use.

Now, it sounds like a lot of the OT's gripe has to do with inconsistent implementations, which are always a huge pain when it comes to web development. However, as some comments suggest, it's at least possible that the spec itself is not broken. Issues like "it's slow" or "it's too small" seem like implementation details. That's like saying "JavaScript is slow" before/after Chrome came around. Right tool for the right job, etc.

<comment><USER4> Exactly

localStorage wasnt build as a replacement for your dataStore, its just a convenient place to put some of your data, things like preferences, keep ui state across pages etc, its a perfect replacement for cookies without the HTTP overhead, turning it into a more sane localJSON api is like 10 lines of code.

I do agree that we should be making sure we move to more robust solutions that were designed for large amounts of data and queries etc when there is a requirement for them, but that doesnt mean localstorage is bad or evil

<comment><USER5> > its a perfect replacement for cookies without the HTTP overhead

Or for a big global object (to reload on each arrival/page)

</comment></comment></comment><comment><USER6> Kill it off? I don't think so. Avoid using it if it's not the right tool for the job? Certainly. As a simple cross-browser key-value storage mechanism it beats cookies hands down in my experience, but obviously doesn't compare to database-style alternatives.

<comment><USER5> > Kill it off? I don't think so. Avoid using it if it's not the right tool for > the job? Certainly. As a simple cross-browser key-value storage mechanism it > beats cookies hands down in my experience

Exactly. localStorage is not a _database_ , hence not having "database" in its name as opposed to "Indexed Database" or "Web SQL Database". It's a persistent key/value store, aka a big hashmap/dictionary which survives restarts.

If you need a database, it's _not_ the right tool for the job, and if you want to store tens of megabytes of shit in the browser it's _not_ the right tool for the job either.

If you need to store a bunch of site-wide configuration items or to cache some basic information, it's quite good enough, and at the same time safer, easier to use and providing far more storage space than cookies (which are the actual alternative).

The big issue is that we _do not_ have a stable cross-browser client-side database interface (some browsers implement IndexedDB, others implement WebSQL), so people try to jump the gun and coerce localStorage into a DB role... which unsurprisingly breaks.

</comment></comment><comment><USER7> I too miss WebSQL. Every time I have to spend time changing my code to simulate what would be a simple SQL join, I wonder if we didn't adhere a bit too much to dogma.

The complaints about WebSQL being tied to a a specific library remind me of the "Linux shall really be GNU OS with a kernel and user-installed non-OSS stuff, and we're happy that non-techies will have to compile their own multimedia tools" or "Thunderbird will always put -- as a sig separator, b/c that's the way it has always been" arguments.

Perhaps if we make the standard we want, and let implementation rest in the hands of implementors, then we can get the KV store AND a SQL store, since they solve different problems in different ways.

This does remind me of the recently posted Marco Arment post, <http://www.marco.org/2012/02/25/right-vs-pragmatic>, of doing what your users want instead of what you want in some cases. Some devs really liked what WebSQL offered, or could use a good KV store... but due to purist principles, we are stuck with where we are.

<comment><USER8> I really never understood the WebSQL single-implementation problem. It doesn't have to be - SQLite is _public domain_. Fork it. Maybe even change it so it fits a bit more smoothly with JS. But instead we invent something new, with new optimization problems, new usage annoyances, new inconsistencies between browsers...?

<comment><USER9> Yeah, plus there's already a "single implementation" thing with HTML5, since most of the browsers have moved to use a common parser based off Java code (in some cases, translated automatically to C++).

<comment><USER10> _since most of the browsers have moved to use a common parser based off Java code_

err, say what?

</comment></comment></comment></comment><comment><USER11> The spec isn't broken; the browser implementations are broken. Even then, it's incredibly useful as is (although I haven't run into the locking issues described).

That said, we also need a client-side storage mechanism that supports queries, so I'm all for pushing toward IndexDB (or bringing back WebSQL).

<comment><AUTHOR> I think our context of use for localStorage is at fault too, it is insanely simple to use for small key value pairs.

<comment><USER11> Yeah, that's exactly what it's perfect for; like cookies, but without the 4K limit and the HTTP overhead.

</comment></comment></comment><comment><USER12> The problem with the localStorage API is that it blocks on IO: [https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local- stor...](https://blog.mozilla.com/tglek/2012/02/22/psa-dom-local-storage- considered-harmful/)

<comment><USER13> The problems listed in the linked page have little to nothing to do with localstorage, but rather are implementation problems. Localstorage is scoped, so if an implementation is blocked on irrelevant meebo data, the implementer needs to fault themselves.

<comment><USER12> > Webpage completely freezes for a few seconds while the browser populates > Local Storage key/value store.

The synchronousness means the whole DOM will block; blocking anything else would be an implementation bug, however that is not what Taras's post describes.

Blocking the DOM is bad. JS is designed as an evented language (the insight that led to node.js), which means it can't accept primitives that stall its main loop; breaking that assumption would add a lot of complexity to code that never uses localStorage.

<comment><USER13> _JS is designed as an evented language (the insight that led to node.js)_

It was? How do you explain alert and confirm, two of the first uses of JS? I don't think we need to add religion to JS. Node.js is evented because that works best for it. In my JavaScript thread if I want to wait for the localstorage get, so be it. This is isolated to my thread, breaking nothing.

However my point was that the claim of the scope of the problem are overblown. If a given implementation loads one massive store for localStorage, that's a problem with the implementation, not localStorage. The linked article worst cases on the back of a bad, lazy implementation decision.

<comment><USER14> Dont forget document.write, or the blocking behavior of script tags themselves.

</comment></comment></comment></comment></comment><comment><USER15> Regardless of whether localstorage is the right tool I think people felt/feel no choice but to advocate it based on one all-important issue (saving grace?) "Browser Support". It would be nice to educate people and explain to them, don't try to use localstorage for any serious stuff, no querying, slow performance, etc. But what would you answer when they ask what's an alternative that I can use today? Based on <http://caniuse.com/indexeddb> it's not looking too good. I would suggest we continue to advocate its use, and at the same time add in a "but.. in the really near future" you should be switching. Is it great, no; But good enough for many use cases- I think so.

</comment><comment><USER16> I can't say that I agree. For certain use cases, the localStorage API is great. For example, I have built an online Text Editor (<http://wrrrite.com>) and I don't see any real alternatives to storing the text locally.

<comment><AUTHOR> Nice app but I quickly got to a point where the UI became unresponsive and digging into the CPU profiler it was all in storeValue and setItem, granted some of it can also be the issue of reading the data from the DOM, but I the point stands, localStorage's synchronous API causes issues.

It all depends on the app, but we seem to be using localStorage for all our storage and bolting complex querying on to it etc and this is a huge recipe for disaster.

</comment></comment><comment><USER17> If anyone stopped and looked at his 'simple' IndexDB version of the backbone local storage you will see the issue right there. There is nothing simple about that...

<comment><AUTHOR> Granted IndexedDB is not simple, and that pains me, but the migration was very simple with the library (that was the point).

<comment><USER18> Which library?

<comment><USER19> <https://github.com/superfeedr/indexeddb-backbonejs-adapter>

</comment></comment></comment></comment><comment><USER20> One unfortunate thing about localStorage is that if you start using it, and then decide to move instead to IndexDB (or WebSQL, or the Filesystem API), you need to jump the chasm from synchronous to asynchronous.

Which in Javascript always means a hefty rewrite, since there's no way to abstract out async vs sync.

It makes me long for call-with-current-continuation.

<comment><USER21> It's not Javascript proper, but take a look at tame.js. Would make switching between sync and async very easy. Also, IcedCoffeeScript for the CS-ers.

</comment></comment><comment><USER22> I would like to see more tools to see what is stored inside localStorage. Right now, afaik, there is not easy way to inspect.

<comment><AUTHOR> Chrome DevTools and Safari (and I am sure FF) have had tools for a long time to see inside localStorage. It is inspection tools for IndexedDB we haven't got.

<comment><AUTHOR> Actually according to [http://peter.sh/2012/02/scoped-styles-deflated- websockets-an...](http://peter.sh/2012/02/scoped-styles-deflated-websockets- and-the-vibration-api/) we now have IndexedDB inspection in the latest Chromium (behind a flag).

</comment></comment></comment><comment><USER23> We need an async KV store:

1\. Embedding of LevelDB or Kyoto. BitCask is terrific but has too slow a startup time for large data sets.

2\. No range support.

3\. No IndexedDB-style gargantuan-spec and setVersion versioning complexity. No versioning at all.

4\. Just humble powerful KV.

5\. Node-style callbacks.

6\. Get/set/unset.

7\. UTF8 keys.

8\. ArrayBuffer byte-array values only - developers can layer any slow serialization/deserialization abstraction else on top.

9\. Unlimited storage quota when requested by the app.

10\. An option for the user to see how much storage the app is using so they can uninstall if it uses too much for their liking.

11\. Fast.

12\. True MVCC auto-completing read/write transactions (readers block writers in most IDB implementations, not MVCC) or cross-tab in-memory lock api.

After that we need an async BTree api.

<comment><USER24> So you're basically asking for something like jQuery for IndexedDB (which could probably be written on top in a few 10s of lines of JavaScript). Baking a barebones API into the browser when a more powerful one has already been implemented doesn't make sense.

Similarly for the WebSQL apologists, there's no reason <50kb of JavaScript couldn't provide a fully featured SQL engine on top of IndexedDB - <USER2> implements most of the hard work (indexes, transactions, the container itself) already.

<comment><USER23> "So you're basically asking for something like jQuery for IndexedDB"

No. To use your terminolgy, IndexedDB is like jQuery on top of LevelDB. We need just LevelDB without the IndexedDB overhead. Surprisingly, there are things you can do with LevelDB that you can't do with IndexedDB. It's too high a level of abstraction.

</comment></comment></comment><comment><USER25> localStorage ins't for heavy tasks? It is not meant to replace databases, it is more for a robust capable cookie system.. So your argument doesn't make much sense

<comment><AUTHOR> yes it does, it is being pushed as _the_ cross platform datastorage solution.

<comment><USER14> Who is pushing this cross platform datastorage solution you speak of?

<comment><USER23> In discussion at Public Web Apps, someone from Mozilla suggested LocalStorage as a suitable alternative to those who preferred WebSQL over IndexedDB.

<comment><USER26> Figures it had to be someone at Mozilla. If I prefer WebSQL, I'll use WebSQL.

</comment></comment></comment></comment></comment><comment><USER27> This API is as simple, as it gets, and it's working OK for me (saving/loading game state), and I think for many other purposes also.

Why can't we have simple API AND second, async API with bells and whistles for people who need that?

<comment><AUTHOR> The async api with bells and whistles is supposed to be indexedDB.

It would have been nicer to have an async mode for localStorage, but even then I don't think it covers it. I really worry that developers are starting to try and build serious apps on it and it just won't work..

Question: what happens if your gamestate gets over 5Mb?

<comment><USER27> > Question: what happens if your gamestate gets over 5Mb?

I hope it won't, because I only save stuff that changes. I can compress biggest data, if it becomes a problem, to get more space, but I don't think I'll have to.

Anyway - it's not a problem of API, but of constraints of browser implementations. There's nothing preventing browsers from implementing configuration option that allows users to assign available space in localStorage to domains.

</comment></comment></comment><comment><USER26> I think the author is comparing apples and oranges. If you need large-scale data storage, then go with WebSQL or IndexedDB. If you just want to store data you normally used cookies to store, then use localStorage. This approach hasn't done me wrong yet.</comment>


Pgbench results: PostgreSQL on AWS RDS is 2+ times faster than Aurora - <AUTHOR> https://www.chooseacloud.com/postgresql <comment><USER2> Would be interesting to see Azure in this table now that their managed postgres is GA. I've had a "mixed experience" using it during preview, both from performance and troubleshooting perspectives.

<comment><USER3> If you enjoy Microsoft lock-in, sure.

</comment></comment><comment><USER3> They are using postgres 10.1 for RDS so weird comparison, isn't it?

<comment><AUTHOR> Currently only RDS support 10.1. But benchmarks were all under 9.6.</comment></comment>