|
Yup. No matter how much information you think is available in your native language, you will have more and higher quality in English, the vast majority of the time. I've worked at a Japanese company and seen people who were ostensibly good at English gloss over the right result in a Google search because they didn't quite have the fluency to pick up on it immediately. People who aren't comfortable with English at all often get lost in native language articles that are just outright wrong or misleading, because when there's a vacuum of information to begin with it's very easy to write a bad article and still end up the top result for that topic in that language. That's not to say most non-English content is bad - most content overall is bad or mediocre (or just obsolete), in any language, English included. Thus, the lower the density of content in any given language, the more likely that good content for any given search doesn't exist, and you're left with the poor stuff. The exception is when you're looking for information on an insular tool or community that is primarily developed and used by speakers of a given language. There's a whole world of "Galapagos tech" in Japan that nobody uses elsewhere, and you won't find any English resources on it, and it might even be pretty good. But in today's globalized society, cooperation across borders ends up producing higher quality results (especially in open source) most of the time, so these kinds of insular projects are rarely the best option, unless it's a very niche thing or support and documentation in a non-English language is a primary concern. Quick example of this kind of bizarre situation: I recently took a peek at reverse engineering a certain Japanese product that uses Android tablets and involves keeping a database on them and synchronizing it from a base station. Database updates are hilariously slow, taking hours to catch up on just a few thousand mutations. Turns out they were using an extremely niche database engine by Hitachi (if I remember correctly), in an embedded version; the only reference to this engine I could find was in the context of a full blown enterprise offering by them (think Oracle competitor). I bet it was configured to flush to disk after every mutation, for data durability in an enterprise setting. Had they used SQLite - which comes with Android, is free, and would've saved them a license fee - everything would be much simpler and DB updates would be orders of magnitude faster, since you can trivially configure it not to flush or just put the whole update in a transaction. They also could've just had the base station maintain the SQlite DB file and bulk transfer that, since it's not that large and it'd probably end up being faster and more reliable than the delta update mechanism with CSV mutation logs they were using. (I'm a native Spanish speaker and my Japanese is good enough to understand technical content with occasional use of a dictionary, so I have a bit of experience with two non-English ecosystems) |
So, while I agree with your point, at least 15 years ago, there were a lot of resources for Japanese programers to read in their native language. Of course, another problem was the terrible, terrible state of education in Japan and the fact that good students would study Electonic engineering and that Software engineering was seen as being an unattractive choice.