If the Programmer Won't Go To Silicon Valley, Should SV Go To the Programmer?

theodp writes: "If 95% of great programmers aren't in the U.S.," Matt Mullenweg advises in How Paul Graham Is Wrong (a rejoinder to Graham's Let the Other 95% of Great Programmers In), "and an even higher percentage not in the Bay Area, set up your company to take advantage of that fact as a strength, not a weakness. Use WordPress and P2, use Slack, use G+ Hangouts, use Skype, use any of the amazing technology that allows us to collaborate as effectively online as previous generations of company did offline. Let people live someplace remarkable instead of paying $2,800 a month for a mediocre one bedroom rental in San Francisco. Or don't, and let companies like Automattic and Github hire the best and brightest and let them live and work wherever they like." Microsoft and Google — which hawk the very tools to facilitate remote work that Mullenweg cites — have shuttered remote offices filled with top talent even as they cry the talent sky is falling. So, is "being stubborn on keeping a company culture that requires people to be physically co-located," as Mullenweg puts it, a big part of tech's 'talent shortage' problem?" Chris Pepper also recently posted another reasoned rebuttal to Graham's post.

Comments

Exactly this.

[fyngyrz]

Also, stop being anal about degrees, credit scores, old convictions, age, and health.

There's no programmer shortage. That's utter BS.

There's just a hiring pathology.

Re: Exactly this.

[Anonymous Coward]

If these companies were hiring a cook they would require 3 years experience working on an Ace cooktop, 5-years experience with Acme Food Supply, and be able to demonstrate the restaurant's recipe for their signature meat dish before being considered.

Companies didn't come into existence with their particular toolsets: they learned them, and quickly. Then they refuse to consider hiring anyone who doesn't already know them in depth.

Re:Exactly this.

[AK Marc]

There is a shortage of programmers in the US. There aren't enough of them, in my locality, that will work for what I'm willing to pay. That's a national emergency.

Re: Exactly this.

[Stewie241]

I assume he wasn't being us specific as the article sure wasn't. I work on a remote team that spanned, at one point six timezones - a guy in Australia, a team in China, a team in SV and a few others scattered among the other three north american timezones. It certainly had its challenges.

I think it is especially difficult for a preexisting company to start thinking remote, and that is probably the real problem. The org is very head office centric and so many meetings start in a room and remote people get added in either part way through or after the pleasantries have taken place. They don't think to introduce people in the room so on the remote end all you hear is voices going back and forth at varying volumes depending on how far away the person is from the mic. If a couple of people in the room start having a person to person chat amongst themselves (not private but where the in room attendees are spectators and can listen in) then you are almost guaranteed to be SOL because they end up speaking quickly and don't enunciate as much and they don't speak as loud. If you are in the room you can jump in if you have something to add (probably using body language to indicate you want to add something) but you're lost very quickly if you are in the phone.

Re: Exactly this.

[Shados]

Because it doesn't take very long, and the chef is likely to still be working there in 2 years.

In software engineering, the average time you can reasonably expect someone to stay working for you, regardless of salary or conditions/perks, is about 2~ years. Much less in startup hotbeds like SF.

Now, let say you have some reasonably complex stuff, not too crazy, but not trivial either...maybe you use slightly less common languages (let say Scala over Java...not obscure, but not everyone learns Scala in school), and it takes 4 months for someone to be able to be left alone and do their thing (I'm making numbers up) They still won't be amazingly familiar with your particular business/domain and the ins and outs for a year, and because humans generally always improve with time, they'll be at their peek at the end of the 2 year.

If you hire someone who already knows your technologies, you might be able to reduce that 4 months to 2 months instead. That's 2 more months of peek productivity at the tail end when your engineer is at their best. That could translate in hundreds of thousands, of even millions of dollars depending on the size of your business.

And that is why everyone's hunting down pre-trained people. Of course, then you have to weight that with the cost of not hiring anyone at all, and decide whats best.

Re: Exactly this.

[ATMAvatar]

Because it doesn't take very long, and the chef is likely to still be working there in 2 years.

In software engineering, the average time you can reasonably expect someone to stay working for you, regardless of salary or conditions/perks, is about 2~ years. Much less in startup hotbeds like SF.

...

And that is why everyone's hunting down pre-trained people. Of course, then you have to weight that with the cost of not hiring anyone at all, and decide whats best.

That's largely of the tech industry's own doing.

It is well-known amongst programmers (and anyone else who cares) that the only way to be paid the prevailing wage is to job hop. Employers refuse to give regular raises to keep their coders in step with market salaries. Furthermore, employers do not invest in their employees - training must be done on a person's own dime and their own time. In a worst case, the tools and technologies used in a workplace will stagnate, causing people to leave just so they're not left behind in the industry as a whole.

This would quickly change if the tech industry executives put more effort into retaining good people and less time into screwing them.

Re: Exactly this.

[melchoir55]

This is the point of view of PHBs who don't understand human behavior at even basic levels. Humans have things like trust, loyalty, nesting instincts, and all the other things that make staying at a company for many years a reasonable expectation. There are software development shops *in the bay area* which have low turnover rates for their staff. Of course, in order to take advantage of those characteristics, you need to the prime them.

You cannot treat people like cogs in a machine and expect them to treat your organization like anything but a machine to draw resources out of until they can find something better. There is a prevailing attitude among people who run software shops that their people are there to be abused and taken advantage of as much as possible. I left one of those organizations early in my career for something much better, and the difference in my own sustained productivity levels really astonished me. I didn't realize how hard I was dragging my feet out of spite, apathy, and god knows what other negative emotions fostered by maximizing the alienation of your workforce.

PHBs think they're killin' it when they hire someone they know is worth 90k and pay them 60k. In fact, that person is probably hanging out until they can find a better job, and because they know they are doing that, they are contributing at the bare minimum level they think is necessary. Since it is impossible to quantify the productivity of an engineer (no matter how much you try to micromanage), this is NEVER a win for the company. And, no, seeing them in their chair for 50 hours a week doesn't mean they're doing more than 20 minutes of work.

Re:They want you there...

[wierd_w]

The problem with the latter approach, is that programmers spend time when they arent working, thinking about the problem they are being paid to work on when they are working.

EG, they may have the sudden epiphany while playing super mario brothers, that they have failed to have while sititng in their cublcle, trying so very hard to push that solution out under great duress from their manager.

Or, as archimedes had his epiphanies-- In the tub.

This is not a new thing, and creative problem solving REQUIRES downtime to be effective. The people that insist "You arent applying yourself all the way, therefor I will ding you on your reviews!" are a problem, not a solution.

Physical security as information security layer

[tepples]

I can think of a few reasons why some software development companies oppose telecommuting.

Sometimes, an air gap can be the most effective form of information security. By 1985, Atari was already adding electronically locked doors; see posts about "building access" in Jed Margolin's inter-office memos from 1985. And for years, Nintendo required that authorized game developers operate out of a "secure office facility", explicitly excluding a home office. (Source: WarioWorld.com, the home of Nintendo's software development support group) This caused a bit of drama when Nintendo refused to sell a DS devkit to Robert Pelloni's home-based studio and Pelloni ran to the news media. (Nintendo relaxed this a bit in 2011, possibly to meet a threat of competition from iOS, Android, and OUYA.)

In addition, a lot of people still live in areas where affordable, reliable, high-speed, low-latency Internet access needed for telecommuting is unavailable.

Finally, the dynamics of interrupting another team member for a quick answer to a quick question differ between working in person and working remotely.

No. Reciprocal loyalty is dead.

[tlambert]

No. Reciprocal loyalty is dead.

If you work in SV, you can likely walk away from a tech job you can't stand and have another tech job inside a week. Some people can do it the same day.

If you work in Omaha Nebraska, you can walk away from a tech job you can't stand and have another job inside a week. At Pizza Hut.

There's a huge benefit to the worker to being able to switch loyalties quickly in an industry which is notoriously disloyal to their workers; some people's notification comes in the form of them coming back from a trip and finding that their badge no longer opens the door.

There are also economic factors. First, it's very east to relocate from San Francisco to Omaha, because it's an economic downslope. It's very hard to migrate from Omaha to ... well, anywhere ... because it's an economic upslope. The equity in your house or condo will convert out nicely, going one direction, and will end very poorly going in the other.

Finally, there are the social aspects; I'm not just talking about nightlife, or the bar scene, or sexuality issues, I'm talking about having a group of friends and acquaintances with whom you can maintain face to face contact, who are able to help you out in a job search, which simply doesn't exist, if you're looking for a tech job, but don't live in a tech Mecca. It's just not going to happen. So when your company is disloyal to you (read: let go, RIF'ed, laid off, temporarily cut back, or any of the other euphemisms), there's no reciprocity.

Gone are the days you could move to Southern Utah, go to work for Browning Arms, and write IBM 360 assembly code happily until you hit retirement age, and then collect your pension for the remainder of your life, in happy retirement. Even IBM has moved to a cash-balance pension plan, instead of a fully funded pension plan. Jobs for life are a thing of the past. And relocation, when it happens, is generally a long term thing. IF jobs don't last as long as the relocation does, and there are no alternatives: no thank you.

The problems of distance

[Marginal Coward]

I've had experience working with people remotely, and my experience has been that the problems scale with distance. Specifically, it's easiest to work with someone in your own office, a little harder to work with someone across the hall, harder still to work with someone across the country, and *quite* hard to work with someone across the ocean. By the time you get that far away, timezones become a major problem, and IT systems don't always work well.

From a business point of view, you have to look at the cost versus the benefits. I once worked with a group of people from India who reportedly cost 1/4 of what we cost. But we did some metrics that showed we were 6x as productive, so we actually cost less overall than them. The main reason we were more productive was that our local group was highly experienced in the specialized technology we were developing, whereas the folks in India were brand new to it. Also, the folks in India ran into numerous network and server problems that slowed them down. Evidently, nobody in The Big Corporation realized that they needed to spend money on IT, since this experiment was supposed to be about "cost savings".

Given time, the IT problems might have gotten ironed out, and the Indians might have developed the necessary experience. However, the India group had so much turnover that they never became experienced in that technology as a group. In contrast, we had some Indian folks who worked with us locally, stuck around (at least until they got their Green Cards), and were ultimately as productive as the rest of us.

Re:The problems of distance

[melchoir55]

My best frontend developer is in Germany (I'm in the bay area). I spend about 2 hours a week interacting with him on a really busy week. 30 minutes to an hour normally. At the beginning of a project, I hand him a wireframe and we go over requirements. He asks me questions if anything is unclear. As the project continues, I check on how he's doing once a week. Sometimes I find he is mildly off course and I set him straight, but it is an uncommon occurrence. The stuff he delivers is mostly great, with a few bugs that usually end up getting ironed out the week after the turn in date.

How do I achieve success with a worker on the other side of the planet?
- I pay him very well. His wage ends up being about $65 usd per hour (which is high for a frontend developer).
- I maintain a professional, but friendly relationship with him. He's a person, not my underling, and not a mere resource.
- I made sure I know what he is good at and interested in. I give him tasks he is either good at or can/wants-to adapt to.
- I don't engage him in communication unless doing so would be productive, though I do respond quickly if he wishes to initiate communication for any reason.

This list should seem blindingly obvious to everyone reading this. "OF COURSE you do these things", you folks are saying. Well, I've found that although everyone agrees on the best methods to engage employees, very few people actually follow that course. Many corporations large and small appear to think there are shortcuts around building a strong employee. There are not. If you think there are, you're a bad manager.

Re:No. Reciprocal loyalty is dead.

[phantomfive]

No. Reciprocal loyalty is dead.

Exactly. Be loyal to people but never to corporations. The corporation will never be loyal back: it will lay you off as soon as it benefits the bottom line.

Re:They want you there...

[jmcvetta]

While ago I worked for a venture-backed company. The code was an awful steaming pile of dog shit. But a few modules were much higher quality than the rest. Logical design, solid implementation, good comments, full test coverage, etc. The programmer who wrote them had only worked for the company a few months before he was canned - apparently management thought he sucked balls.