1,997 karma · joined July 18, 2008
Me: http://njclarke.com
My code: http://github.com/norman
My blatherings: http://twitter.com/compay
[ my public key: https://keybase.io/compay; my proof: https://keybase.io/compay/sigs/5ghM6xDeYY3U9odHk-2BOd7DxA9AIP5-QcWBkrTOgSQ ]
I'm happy to help them come up with the spec. But if the client can't give you an elevator pitch for what you're going to build for them, run for the door.
The crux of the problem is that working with a remote team is a very different proposition than working with people onsite - a fact that is obvious but that people generally fail to act on.
Quite often at my company we're contacted by clients want to hire folks in a foreign country and expect them to work like remote employees, but cheaper, and with fewer legal responsibilities. They think that through the wonders of Skype and email, people in India (or South America) can work just like on-site employees.
The reality is that outsourced development to remote teams only works when the client is willing to adapt their own work patterns to it. As a client, you need to:
* Have a crystal clear idea of what you want built. The less communication overhead you have with the remote team, the easier your life will be, and the more likely it will be that stuff gets implemented the way you want to.
* Have frequent and early deliverable dates. Don't start a project that will take 6 months to get a first release out with a remote team. Shoot for as early a release as possible, followed by frequent small releases. This lets you pull out almost whenever you want and also reduces the likelihood of burning out the developers on the other side.
* If you already have a company with a bunch of people, have the remote developers work outside your regular dev cycle. Don't expect to plug in a couple of guys located 5 times zones away into your regular team, unless your regular team is already distributed.
* Be linguistically very compatible with the folks you're outsourcing to. If you have any difficulties understanding or being understood by the folks you're hiring, then you're significantly increasing your risk.
The well known Ruby consultancies like Pivotal, Thoughtbot and Hashrocket will all tell you, that outsourcing to foreign countries is a mistake, and that developers need to be on-site. This, of course, while basing a huge amount of their business on Rails and a bunch of other open source libraries and frameworks which are developed almost entirely by distributed teams. These companies have an economic incentive to lead people away from outsourcing to cheaper countries, so follow the money.
It just also happens to be the case that since many clients don't understand how much their own workflow needs to change, many outsourced projects fail and reinforce the idea that outsourcing doesn't work.
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
Have you generally been a hard working person your whole life but are now going through a tough spell where it's hard to find motivation? If that's the case you may be burnt out, or perhaps you are working on something that deep down inside you don't really believe in. Maybe you need to listen to that intuition, rather than beat yourself up and think "I'm the problem because I'm lazy."
I went through a pretty major burnout cycle in my career a few years back and was lucky enough to be able to afford to take a lot of time off - nearly two years - and dedicate it to just working on open source. Nearly 3 years later I suspect that financially it was a poor decision: I'm still majorly suffering the consequences of that lack of income for 2 years. But I was able to recover my passion for work and now have a job that I'm enthusiastic about, and willing to work my ass off for, even though it pays less than I had been making before.
At the time I quit my job I wrote a short post on it, take a peek and see if it resonates at all. If it does, you're most certainly not lazy.
http://njclarke.com/posts/why-i-quit-my-job-to-work-on-open-...
Luckily since our initial terrible experience, we've had nothing but good ones with the US Consulate in Buenos Aires. So I'm hopeful that if we ever decide to move back to the USA, being married for 5 years and having a child will count in our favor and make the process much easier like it was for you.
As it is though, I've grown pretty comfortable here and don't know if we'll ever move back. All's well that ends well, I suppose. :)
Her fiancee visa was in fact quickly approved, pending an interview at the US consulate in Buenos Aires. We waited and waited, called, had our lawyers call, and the response was always "when the consulate is ready to make an appointment, they will call you." They never called, leaving us in limbo for over a year and saddled with thousands of dollars in legal fees.
Eventually we grew tired of the uncertainty. I moved to Argentina, we got married, and we've lived here ever since.
Argentina is not perfect. But the legal status of foreign residents here is much clearer than in the USA. As the husband of a citizen, permanent residency was automatic provided I didn't have a criminal record in my home country (I don't). I am allowed to vote in municipal elections. And, now as the father of an Argentine citizen, citizenship is also automatic if I want it.
You might think that Argentina can afford to be generous with immigrants because it has nowhere near the load of foreign residents that the USA does, and to an extent that's certainly true. But on the other hand, Argentina has fairly large immigrant communities (from Peru, Paraguay, Bolivia and China), more social welfare services (basic healthcare is free here), and a lot less financial resources than the USA.
Having now lived somewhere else and been on the "other side" of the immigration issue, I feel indignant and outraged when I read about how my country treats non-citizen residents.
* No GIL
* JIT
* Better garbage collector
* Better debugging tools
Unfortunately, Rubinius is not yet complete, so it's not a suitable MRI replacement for now.
I understand there are good reasons to keep MRI around, but the idea of making Rubinius the future of core Ruby development is not an outlandish idea.
If it's "just a dream," it's largely for human reasons rather than technical ones.
> Maybe I've been spoiled by Python, Perl, Java, C++, C, and other languages
Probably. :)
One of Lua's main goals is to provide a language easy for beginners to use for small tasks. This affects its design in some other rather annoying ways (like for example, variables being global by default rather than local) but they were pretty carefully made decisions.
The context of this thread is, "what could be a good replacement for PHP?" I think because Lua aims to be easy for inexperienced programmers, it's a rather good choice, even if some of its characteristics can be surprising or annoying to established developers experienced with other languages.
It's trivial to write, there are lots of libraries that do this. I've worked on a lot of string processing code in Lua. It's not as easy as Perl or Ruby but it's not by any means hard.
> One-based indices instead of zero-based.
Other than violating the expectations of people used to other C-like languages, this is not in any way even remotely a problem. I don't know anybody who's spent any significant time with Lua who regards this as more than a minor detail.
Also, if you've followed Kaplan since his (awesome) "Fucked Company" website you'll know that the man is no babe in the woods. IMO he has too good a grasp on the nature and consequences of risk to be "not sure" what the lesson is here.