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.
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.
@Jarkko: thank you for the great insights.
How many hours typical developer on your remote team work on?
What is the typical hourly (or daily or weekly) rate for senior developer who is working on the same project full time for months or years?
Hey Jarkko, been a while, I hope you and the other guys are very well!
A few things from my view, not to take away from anything you said, just to drop in some thoughts from my angle:
* If I was forced to pick favorites, the most productive SWEs we had were actually in-house. This is no reflection on anyone, and also isn't directly related to being in-house. It's down to individuals, and most significantly how they communicate around requirements. It's a bit more tricky to do this remotely, but you guys also did this very well. I completely agree that you guys were among our top performers; you were absolutely essential to many stages of our growth, and I would hire you all again in a heartbeat. I love you guys, and I miss working with you.
* Our eng headcount was actually about 50% larger, the extra gap was more contractors. With so many contracting teams, I gained quite a bit of experience with a wide spread. You guys were great, Wyeworks were also absolutely fantastic. I won't mention the others, as they were not so strong, and one contractor in particular did a fair bit of damage as a result of isolated work that was largely overengineered (work that subsequently landed in a book, that's still popularized to this day, and is a total anti-pattern that I had to rip out of our code base myself in a mad hurry to fix the critical outages it's piss poor performance resulted in). The point is, overall, we had a couple of great contracting teams, you guys included, and a couple of not so good. I don't really see much direct correlation with "contractor or not" here, it's more about work ethics and processes. The contractors that did worse worked in isolation, the contractors that did better worked in collaboration. The best contractors always kept their cool as they retained the concept of "you're a customer". This advice extends to satellite teams too, where we had one that could have benefited from a more consulting approach to their integration. We all live and learn.
* Retention and ownership take a lot of work on all sides. We had a very different relationship with you guys to what we had with Wyeworks. Neither was bad, but Wyeworks was more like a company, and you guys were more like individuals. Of course this is a big product of history, you actually were individuals until after the close, and Wyeworks was obviously bigger than you guys by then too. Both great, both would be hired again in a second. You all demonstrated ownership and stuck with us through good and harder times. Thanks for being awesome! As far as the big G and contractors goes, well, we can't open this wound for all to see here, but Wyeworks got through the paperwork and continued with us for a while longer than you guys were able to. This isn't a comment about you guys, and as you say, we shouldn't bare all here right now, but it's just to say that large organizations have complex legal requirements that can be difficult to overcome - this is something that contractors need to understand, and companies relying on them that might be acquired should also take into account - it could affect your valuation in extreme cases. As far as "not a single employee", you're mostly right, maybe you are right, but did you forget our Kiwi friend, our first FTE? he's still here, rocking it. I agree with you that the typical churn rate in the valley is all manner of crazy. I have friends who've moved upwards of 4 times in a year. I'm glad to say that we had far better retention than that.
* Code quality. Well, I told a story about this above, so I won't repeat it all here, or risk damaging the guilty with more details, but it's really important to remember the core point: the gap was in work approach. We got crap code from people who worked in isolation. They were slower, their code was overengineered, underspecified, buggy, and unsustainable - but most critically - largely unnecessary - most of it could be elided with a quick conversation with the PO. It was replaced, and in the case I described above, it was replaced by me, which, given my position was an expensive call. This doesn't have anything direct to do with contractors though, it's just slightly easier to work in isolation over the wire than it is in person - though we had plenty who did that in person too, with similar but less extreme results. More importantly, it's easier to train this stuff out, to help individuals develop their skills and measure their effectiveness when they're local. That's a long winded way of saying that it is easier to manage your "average" employee in person than it is remotely. Strong employees, like you guys, this is less of an issue. You self manage, give and take feedback, and we all get better together.
* knowing what to build. Yep, as you say, this has nothing to do with location. It does have to do with communication, so a contractor needs to be extra effective at communication to make this excellent. Some can, some can't - same as any FTE's. Again the difference is, as a manager / leader, you can more easily draw people below this line up if they're within earshot. A contractor below this line you often end up needing to drop.
* H1B and "you're not good enough". I don't think we ever uttered such horrific words, but I'm sure they've been said somewhere. The degree requirements for the H1B can be a sticking point, and that impacted a few of our folks over the years. I think these rules are dangerous for the country, especially with the STEM numbers being what they are. Sure you can pile more people into universities here, but what are you going to do about post academic training (which is extremely important, see all the points above none of which are ever taught in a CS/IT degree). We also opened a satellite team as a tactical move to increase headcount without being stuck in the US/valley hiring market, and it was a good move. The team busted the ceiling on their hiring goals, and even though that rapid growth came with the usual growth pains, it was overall a very successful move and many great additions to our team(s). If we'd have been able to find other strong contractors we may have considered doing that too.
I completely agree with your conclusion that it's all about who you get. I hope that the above also speaks to this fairly clearly. I've had a wide range of strong and weaker FTE's and contractors. I don't divide them in that way. There are genuinely other business reasons to prefer one over the other, but a lot of the commonly stated crap isn't it - given the right people and the right attitude. As far as expense goes, it's all much of a muchness. If a company is that concerned about the cost difference of contractors vs. FTEs they're not hiring at the right level and may very well have some management and/or financial problems. From when I've done contract/consulting/WFH work, I'd avoid such companies.
I have recently recommended a bootstrapping company to use some contractors for some of their work, as they're situated in the valley and don't have the ability to effectively judge incoming talent. They can very effectively get up and running with some contractors, and take their time to find a really strong first local team. I could see them maintaining a mix long term, much like we did, and to great success.
I wish you guys all the best, and miss you.
disclaimer: I was the first Eng Director, and later CTO at said company. Nonetheless, comments are exclusively my own, and not representative of any organization.
@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.
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.
