Tesla uses the standard Type2 plug in Europe. You can also charge any Type2 equipped car with the Tesla home charger (EU model). Most Tesla owners I know have the CHAdeMO adapter as well, so can pretty much charge from every fast charger available.
I don't really disagree with your notion. However, as someone noted above, Sweden already has these laws in place, all the data from Finland currently (before the sea cable to Germany is ready) goes through Sweden, and their laws didn't prevent Facebook from building a huge datacenter in Luleå. But yeah, they probably would have _some_ effect.
@raggi Thanks for chiming in with your POW. You certainly went into much more detail than I was comfortable going.
I completely agree with you (although wasn't of course even aware of all the details, the company grew so fast during the last years). It's all about ownership and communication, which are somewhat easier with someone next to you (with obvious caveats as well), but it's far from black and white. Actually, remote in some ways makes it more explicit: you have to write stuff down, and thus, when you hire new people (or people leave) it's more than tacit knowledge.
But yeah, it boils down to individual in the vast majority of cases, much more than whether the individual sits next to you or not.
“did you forget our Kiwi friend, our first FTE? he's still here, rocking it.” Of course not, but he was a remote contractor as well through the early years :-)
Maybe that was one of the things that helped us to begin with: since all of the developers were remote originally, you just had to have the communication in place. I would imagine it's trickier if there is an in-house team originally and then remote devs added to that.
There are so many anecdotal examples of bad experiences in this thread that I have to chime in with a counterexample.
I used to contract for a startup that was sold to Google a couple years ago for $350 million dollars.
In the beginning, it was just the two co-founders in the Valley and us developers, spread around the world. Later, when the company took VC funding, we helped to expand the engineering team with in-house developers as well (at the time of acquisition the total eng headcount was ~50 IIRC).
The product both took off like wildfire, grew, staid stable, and weathered some serious beatings on AWS just driven by the contractors. Even when there were several in-house teams, the remote ones were by far the most productive and e.g. drove 90 % of all the ops side of the service.
So, a couple of points:
* Retention/ownership: This has nothing to do with whether someone is an employee or a contractor. It's true that most outsourcing companies try to sell you just hired hands, but that's not all that's out there. You can find superb small developer houses that take more ownership in your product and code than any developer you can get in the Valley ever would. They're not 10x cheaper, but they're probably much better than any developer you can reasonably hire in the Valley at the moment, period.
We staid at the startup we contracted for from 2008 to 2013 and only left because Google doesn't do contractors, period. (This is a story of its own but I'm not comfortable telling it until a few more years have passed.) There were not a single employee that staid at the company for longer than us.
Employer shopping is much less pervasive outside US, so considering an employee a more long-term investment than a contractor is an illusion. Besides, you have the exact same means to keep a remote contractor happy as you have with an employee.
* Quality of code: This is a red herring IMO. You can choose whom you hire, even if they're remote. You have the same opportunities to check their level and productivity, and it's even easier to fire them if things don't work.
* "knowing what to build, not just how to build." Most of this isn't really related to remote vs in-house either. If the product is online, much of its clients are as well. I used to spend a shitload of time in the early days helping clients solve their issues from 10 timezones away. And often the clients were in the EU, when in-house people wouldn't have been available to help them.
* "you're still over there because you're not good enough for anyone to sponsor you for an H1B". Sorry, but I rather stay here with pure nature right off the door, 4 real seasons, and no rush, and produce the same (or probably more) output and value as a remote contractor. I might not make the same salary I would in the Valley, but it's not that far off if I contract for an American company. I also have much more flexibility to choose where I am at any given moment and how I structure my workdays. Plus, not all people hold money in quite as high a regard as people in the US do.
So, long story short: it's much more about who you get to work for you than employee vs. contractor. If you go for the cheapest code farm option, of course you're getting cheap quality. But you can also hire expert-level individual contractors or small teams where you know exactly what you're getting. They are not cheap, of course, but still less expensive than senior level employees in the Valley if you consider you can skip all the benefits and overhead.
And of course, at the moment they're probably better than what you can find in the Valley for any amount of money.
You can't imagine how many times that crossed my mind before and while writing the article. FWIW, much of it is not Rails-specific by any means, and we'll always have a new crop of developers asking these questions.
I don't think we really disagree there. I might not have made it clear enough, but I mentioned that there are obvious things that need more consideration, like Kissmetric's or Skylight's data aggregation and massaging.
That said, for many (most?) that culprit is not easy to identify in the early stages and many apps are still basically glorified CRUD apps where that is a non-issue to begin with.
For example, a few years back we ran a much publicized vote for an unidentified social network with more than a billion users. It ran on a run-off-the-mill Monorails[1] app and MySQL, without any hitches. If anything, we vastly overestimated the number of app servers needed (a couple dozen IIRC).
Of course it was a fairly simple use case, just an example that high load by itself doesn't mean much.
[1] A term commonly used for a web app that is a single Rails application, as opposed to a more SOA-style app split in smaller pieces.