Force Multipliers and Japanese Programmers

Having worked with a lot of Japanese programmers, this rings true, but I think it says more about how Japanese companies are run than anything else. There are a couple of interrelated factors that come together here. Typical Japanese companies tend to be very conservative in regard to established technologies. Also, lack of timely Japanese-language materials only makes the problem worse. Even if there is official documentation or an O'Reilly book in Japanese, not having the surrounding ecosystem of blogs and tutorials makes it pretty hard to get familiar with a new technology. Even for mature technologies, the documentation for the newest release or the newest editions of books may not be translated for a while, which further slows things down. Of course, this problem isn't limited to Japanese.<p>At the small Japanese company where I worked there was a pretty stiff resistance to using full-blown web frameworks. The main argument was that it would take too much time to train people to use the framework, and that open-source frameworks were somehow unreliable. So they ended up poorly re-inventing several wheels (like using plain text files and locking for storing data, or a crude templating system) without first checking out the available open-source alternatives. It often felt like we were working at the wrong level of abstraction. On a more practical note, most of our clients used shared hosting with such draconian limitations and ancient server software that it would have been pretty difficult to use some of the modern frameworks even if we'd wanted to. (Think servers with PHP 4 and FTP access only.) I don't think everywhere is as bad as that was, but in my experience not-invented-here syndrome seems to be pretty common here in Japan.

I'm not sure if this is related but...<p>I remember when the PS3 was first shown at E3 many years ago, one of the big selling points that Sony was advertising was how difficult it was to program for it. They happily extolled the fact that it would be a 10 year platform because that's how long it would take programmers to learn how to program for it.<p>Meanwhile, some big 3D devs like John Carmack were talking about how nice it was to develop for the XBox 360 because everything felt so familiar and MS already had a mature toolset available for people to use.<p>I don't know if this dichotomy is a reflection of the blog post or more a reflection of the games industry at that time.

It's a much deeper social problem. You'd be surprised at the number of potential programmers that went to study law or economics because of the sheer career opportunities you get with this background. You see a lot of engineers that took a roundabout course into the field after wasting years pursuing a different major or regular desk jobs, etc. People with a good engineering background might be educated in FORTRAN (for hard engineering) by a professor that hasn't programmed in decades. Hardcore departments (really depends on professor) might give you a good background in C. In general, it seems the computer science departments are really geared towards creating coding robots more than the big dreamer, tech entrepreneur. If you miss your chance to get a good job out of college, you'll never catch up to your peers and will more or less be relegated to the "loser" group and be lucky to either be job hopping in small venture companies or worse be one of the IT temp workers living in internet cafes (this is less hyperbole than it sounds).<p>Also, while I agree that there are lots of competent coders, engineers just aren't as ruthless about personal productivity. They'd rather not rock the boat instead of getting into an argument. There's also the social tendency to take any form of argument personally. Combined with age-based seniority in programming teams, this kills innovation quick. A younger engineer with a pulse on the latest cutting edge technology isn't going to be heard at all. A crusty veteran, will just overrule them and say, "follow tradition". After decades of soul-crushing guess what these once brilliant engineers will say to fresh meat?<p>It would take a lot of courage for a younger, capable engineer to go and rewrite the code of a senior engineer even if it's mediocre, he'd have to be careful even in wording the commit message. Performance on the job is not rewarded as much as "competence (meaning just enough to get by but not so much as to make others look stupid)" and at most you'll rarely get promoted over older employees, you'll just be first among equals in your age group and so will your salary (almost negligible in terms of monetary differentiation, people will just treat you better because you're on the "fast" track). If your body and mental health manages to survive the hours you might get rewarded in a management position by your 40s and join the ranks of "young guns" where you get to try your luck in Japanese corporate politics where deals are cut in dirty drinking shacks over yakitori and beer.<p>Breakdown of academic background for elite companies: <a href="http://news.livedoor.com/article/detail/5873497/" rel="nofollow">http://news.livedoor.com/article/detail/5873497/</a>

I've worked in Japan for 5 years at one of the major companies, and I think there's a bit more to it than the facts mentioned in the article. At my company we were developing embedded software, yet only a very small subset of the people working there were educated programmers, and only a very small subset of those people were actually good, productive programmers. And of those good, productive programmers, quite a lot of them were forced to do tedious repetitive tasks by the higher-ups.<p>I think the reason this happens is because people are rewarded differently. For example, if there's a crunch session and you manage to solve your bit of the problem with a fancy algorithm that means you get to go home early, while all the others work the 'less smart' way and spend overtime in the company, then the company will look favorably on those who worked longer, not those who worked in less time.<p>Since the culture expects you to work overtime anyway some people will believe that there's no point in working smart but less, since you'll only be working smart but the equal amount of hours anyway if you want to be respected. I've seen plenty of my colleagues following this routine and I've seen some foreigners fall for this trap too. It's a kind of culture that does not reward change.<p>As for me, I couldn't care less about how people perceived me so I just went on designing things the 'right' way (and going home in time for dinner). It worked out very well for me, but I doubt that a Japanese person could pull it off as easily, since they have to worry about their reputation a lot more than foreigners.

About languange barrier: I was shocked when I found that all the Sun's official JVM documentation is available in Japanese.<p>This showed the amount of dedication and respect to Japanese market and companies (many of which invested heavily in Java, I know), but I understand how it can go both ways: When some programming languages and tools are translated to your language and some aren't, you might become stuck with those which are, and they are perhaps older, limited and less experimental. Limiting your toolset based on the human language is surely a problem. When you have to use tool A and not B and C because B and C aren't and won't be translated to your language (and then you have peer and management pressure).<p>I also remember a few years ago on NH a comment by Dutch developer who claimed that very few books about software development tools are published in Dutch, so they use original English sources and whatever tools are good, but when they come to Germany they see full bookshelves on programming topics in German - so people are reading those instead of original docs and limit their toolset.<p>But there is another thing, maybe Japanese see programming as Engineering. A respected craft, but you don't reuse much of electrical engineering output between projects, neither expect youe engineers to take care of the product side of the product. They usually do what they are told or don't when it's too expensive or would not work that way. Programmers are pretty distinct: they can reuse, they have to face the product side and they're much less constrained by a physical media so they can go a long way towards a wrong path.<p>Which would probably make Japanese system programming thrive but Japanese customer- or developer-faced software suffer.

I don't buy the language barrier argument. So what if there's little documentation in japanese, I don't see why these developers couldn't just learn the languages and frameworks by reading the documentation in english. Unless they don't speak english, and in that case, I'd say it's their own fault. I may come off as being arrogant now, but let's be honest here, english is the <i>lingua franca</i> of our profession and any self-respecting developer will have at least a basic grasp of the language. You really don't need to speak a language perfectly to be able to read the documentation and learn some new technology. Also, english is quite easy to learn compared to other languages (much simpler grammar than most of the other languages I know or know about) and with all the US/Brittish shows, sitcoms and movies around you almost cannot help but to practice it regularly. Unless they synchronize them in your country, in which case you're out of luck there, but still...<p>Btw, if anyone is wondering, I am not a native english speaker. But I did learn how to program by reading the books and documentation that were available in english. If I had waited for somebody to translate these to my language, I probably wouldn't know a thing about programming to this day.

I think this has more to do with how anyone competent or socially adept is promoted out of engineering/development roles, joins a multinat or goes abroad. Very few East Asian companies have the concept of a senior engineer, let alone anyone actually employed as one. Institutional knowledge, and the lack thereof, is the main reason for so much reinvention. Usually, at the coalface, there is no one with significant project experience and those with experience will not help rookies (because they are management now and the questions are below them or they struggle with any form of human interaction).

Nice post. My time at Panasonic &#38; then later selling software tools to the Symbian OS developers was eye opening to say the least. The Japanese corporate mentality was, in many ways, still feudal. Fujitsu's Symbian OS team was given a lot of support by NTT Docomo but also a crushing amount of responsibility -- they were developing something like 30 baseports a year, 15 each for the Spring and Fall seasons, for all their handsets <i>and</i> acting as lead Symbian developer for the entire NTT Docomo group with little to show for it. Talk about churn &#38; burn.<p>When I spoke to the management about this, they said that they were in a position where they couldn't say no to Docomo and likewise they didn't see anyway of <i>not</i> continuing to do their development. And yet, and no offense to the folks grinding this stuff out, there was little real differentiation in the <i>software,</i> the OEM's were all focusing on the hardware feature differentiation and the software was really just a "necessary evil."<p>So I'm not convinced that it's simply a case of needing a "force multiplier" framework, the Japanese companies need to see that there's value in cultivating better, highly differentiated software.<p>DeNA, GREE, and the other Japanese social startups seem to have found this whereas the larger vertically integrated semi manufacturers are basically stuck writing drivers for their whizzbang hardware.

It's cultural -- there is excessive NIH in Japanese corporate culture. They see using a framework as showing some sort of weakness. Managers are rewarded for reinventing the wheel.

FWIW here's a story about the scene, by a native Japanese.<p>It was more than 10 years ago when I joined Fujitsu's 3G cellular network project as a subcontractor. It was a huge complex project and I believe was one of the first 3G networks deployed in the world. So I expected I would work with teams of descent engineers.<p>Except most of them were not.<p>The subproject had dozens of 'engineers', but many of them had just finished vocational schools that didn't teach them even programming in C. To make it worse, the existing code base was the exemplar of bad code, e.g. each function had more than 3000 lines, function names were a letter and some digits and we had to consult some other documents to find out what they were expected to do, etc as well as more architectural design problems. In fact there I was able to find every horror story about software development.<p>Why did such a mess happen? One of the reasons was that the contractor company (who then outsourced some senior positions to subcontractors like me) were paid by the headcount of engineers it offered to the project. No kidding. So, in order to maximize the profit, the contractor made up a legion of those incapables who were paid less. Expectedly that made things worse, and Fujitsu thought it needed more engineers to solve the problems. Vicious circle.<p>I had tried to make the situation better, but the root cause was not in the technical side and I had no clue. The only nice thing for me was that during the personal research to improve the project I got to know Erlang, which was of course never ever used in the project because of the similar reasons mentioned in the article.

Repeating what I commented on the post itself, but this is a really interesting observation.<p>I can confirm from limited experience that this is happening. But the problem is that “giving Japanese programmers good frameworks and libraries” is not as easy as just handing them a package and being done with it. The pace of modern frameworks like Rails etc. is so fast that there is a big learning curve just getting used to staying in the loop.<p>We lost at least a week on a project I’m working on catching up when Rails 3.1 hit, because all these useful things (asset pipeline, etc.) require effort to tie into existing practices. Imagine the Japanese developer with limited English skill, trying to navigate the discussion threads like this one ( <a href="https://github.com/chriseppstein/compass/issues/337" rel="nofollow">https://github.com/chriseppstein/compass/issues/337</a> ) (just as an example). It’s a lot of work.<p>So I think what happens is that, although re-inventing the wheel is a hell of a job, at least it means that the basic groundwork is constant and designed internally, whereas using frameworks means that you’re building on someone else’s work — usually non-Japanese, so not well documented in Japanese.

I automatically discount anybody who believes that people are "too old to be familiar with current programming technologies and shortcuts." Aren't we supposed to be a meritocracy and judge on nothing but talent?

Does this mean there's a business opportunity waiting for someone to make Rails friendly to Japan's programmers?

<p><pre><code> &#62; "what about Ruby!" </code></pre> Arguably one of the most powerful force multipliers inherent in ruby is the object order, which is definatively derived from the Japanese language subject-object-verb syntax (<a href="http://en.wikipedia.org/wiki/Subject%E2%80%93object%E2%80%93verb#Japanese" rel="nofollow">http://en.wikipedia.org/wiki/Subject%E2%80%93object%E2%80%93...</a>).

Perhaps a simple layer between English "force multipliers" and Japanese speakers would prove to be a good solution?<p>Ideally, you would probably want the Japanese programmers using the exact same frameworks as the rest of the world- reinventing Python in Japanese would boil down to duplicated and thus most likely wasted effort.

I'll just add, because it wasn't in the article: Japanese higher education (and, increasingly, secondary education) is pretty bad. It's bad in completely different ways from US schools which is why it often gets a pass or is thought of as good in the West, but it doesn't produce good programmers.<p>Lots of focus on certificates and standards and consensus and other proof of 'merit', and not a lot of focus on getting shit done and programming, motherfucker.