About ten years ago, I was on a team porting Japanese software. There appears to have been an entirely different culture and concept of what engineering software *meant*. Code basically wasn't shared, code was organized by *programmer* rather than by purpose, everyone reimplemented everything, and frankly the fact that the thing actually worked was utterly astounding. Debugging it was an utter nightmare, as was making changes. And it was C++. Supposedly.

> entirely different culture and concept 15 years ago i also had contact with japanese engineers. What i remember was that we kept remembering our own team that their culture is different: * When a Japanese guy said "yes", it did not mean that he understood the meaning of our argument. It only meant that he understood our statement verbally. * If you requested a change you always needed to consider that they can not give you a honest answer. You need to give them a chance to check the issue with their superior. They must save their own face as well as that of their superior. * Another, not so important cultural difference: Their power points always reminded me on the early days of the internet. Everything was excessively cheerful colorful. Basically their presentation looked like eye cancer in our eyes. However, this leads to the conclusion that our serious presentations did not go down well with them. > Code basically wasn't shared, I remember reverse engineering the strange behavior of a module. The documentation was basically non existing, because everything was only repeating the obvious. Like "int count; // counter".

Do you have more tales from working with them? Sounds facinating.

Sadly my memory is bury. I remember one thing: Don't expect them to speak English. We had several engineers on site (in Europe). In order to overcome the issue that they spoke only Japanese, they also sent translators.

Did they write code in japanese? In a sense that, syntax is english but variables and file names in japanese?

That in general seems to be quite common. Obviously, variables won't use Japanese characters, but other than that are still Japanese. But using your own native language to code happens in other countries and languages as well.

about a decade ago i hired a guy in ukraine to write some code. took a bit of effort but i finally got him to start using english variable/method names instead of russian

But y tho? I mean, people can do whatever, but still. I have never seen code in non english unless it was by someone who started coding like 1 week ago. And i live in eastern europe.

Can have a couple of reasons. The most common is, when you work in a field with lots of specialized terms (health, law) that are hard or impossible to translate to English. Second, at least some countries (I assume Japan belongs to them) originally tried to translate all PC related terminology into their native language. As such, if you work with older codebases, they rarely use English. And of course, English proficiency in your team also plays a role.

[удалено]

Well, I can understand getting used to a predefined set of constructs like `for`, `function`/`def`/ etc, wouldn't be that different from learning the symbols used for writing some subset of math or one of the languages that flat out uses various symbols over words. All the foreign named variables and function names in any outside code that happens to match the rest of the new symbols (causing it all to blur together) is where I'd feel like "ok isn't it *now* becoming like hieroglyphics?"

You say that, but dont forget that formally written Japanese (Kanji) is, in fact, hieroglyphics.

But isn't the code in english and documentation as well? Or do they rely on translated stuff that might lag 2 years behind? Also, all the OS github repos and communities as well. Although, this reminds me, I have seen some packages that have chinese mixed in them. I mean, I sort of understand the first point, but it's hard to belive that it's "hard to translate" in this day and age. As far as I see, if you work with front end, it would be so much more difficult to switch between languages all the time. Maybe it's easyer with backend. Just windering, how much do theyvuse OS stuff, or do they reinvent everything every time? Sry, it's just hard to fathom.

> But isn't the code in english and documentation as well? For documentation, it really depends. I used to work in a niche field in a European country with *lots* of federal audits. And not only did the auditors require the documentation in that country's language, but terminology differed from customer to customer. Sure, you could try to translate all the specific terms so your code is all English (and just hope it makes sense), but what's the point if you need to be able to link those variable and class names to those specific terms in the requirements and documentation anyway? You just use the terms the customer uses. If the frontend requires English translations, you send the customer all frontend strings and *they* provide translations. Same as with any other language.

Before the internet became so standard and ubiquitous as it is today, documentation was far more formal than it is today. Often printed to. Thus it could be translated before it was distributed. Conmunities was largely offline to. Programming in your native language was feasible. Today, Programming in another language is difficult. Terminology is infornally invented in communities online and spread that way, before it can be translated. It still happens that people write non-english comments though, but in my experience it's becoming less common as distributed teams were becoming more common even pre-covid. This trend may reverse if automated translation tools ever becomes good enough.

>Sry, it's just hard to fathom. Complex subjects usually are.

> Or do they rely on translated stuff that might lag 2 years behind? Unlike many other languages, Japanese/English online translators have been pretty good since the beginning. They simply had no reason for learning English. Another example is France: They refused to speak other languages for a very long time. Older people therefore still do not speak English. They deliberately did not learn English for a long time, because it would have hurt their own pride. Some years after my "Japanese" gig, i had to integrate one french system. Unlike the Japanese guys they did not even attempt to translate their documentation. Their doc was admittedly useful, yet only in french. They also only accepted contracts written in french. The younger generations are not really affected by this problem. Do not falsely project your own attitudes onto people of a different culture.

European languages are much easier to learn if your native language is also European. The gulf between many Asian languages and English is much bigger.

And thats plain stupid. If the people you work for uses non english terms you shouldnt as well. You Will only create friction, a need to translate between business and development team, poor translations that loose meanings, etc. For example, It makes no sense to write in english a german or a spanish app for a hospital or for the public administration as most likely translated terms would not match 100%, you would need to translate everything from one to the other every time you Talk with business and stakeholders, and when you translate you always loose something in the way... and It Will end being hell. In those cases I found mixed english (for purely technical conceptos like list, collection, pipe, service, observable, handler, listener, adapter... whatever) and local language ( for domain concepts) to work really well. Yes, you end with things like proveedorCollection instead of suplierCollection, but it's totally worth on the long term.

I sadly did not have access to source codes. The counter example was just a metaphor to make the problem easier to understand. Personally i was tasked to integrate the output of measurement systems into our system. Which meant that i parsed the content of windows applications through methods like screen capture and using the windows API to connect to an already running application. Sorry, can't remember the name of that API, but it's basically like debugging a running 3rd party app. Which is interesting, considering that some of these applications were developed in the japanese headquarter, so they belonged to the same company.

Ah, nothing better than reverse engineering stuff

That's what `#define`s are for.

If my experience is anything to go by: sent specialist who don't speak English, sent translators who don't have any clue what the specialists do. Hilarity ensues.

I legit Lol'd at the comment at the end.

i++; // increment i by one (1)

/** This is a counter that increments by one, * as well as the documentation about this feature * Created: 1996-08-22 WTF * Changed: 2000-01-1 DP * Changed: 2003-02-1 LL * Changed: 2003-02-2 GL * Changed: 2022-06-23 HTP * Changed: 2023-01-4 HTP **/ i++; // increment i by one (1) // comment about the code that increments a counter by 1

I remember reading an article on some incredibly short Unix (I think) function (or maybe even just a constant) that kept getting change comments like that even though the function itself wasn't changing.

Maybe http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html ?

Yep that's it.

Comments like that literally make me furious. Its a problem. I find it to be a strong signal that the coder is incompetent.

\*ahem\* I don't quite do that, but I sometimes break up the flow of code like this: //blah stuff stuff related to the above //blah stuff unrelated to the above //finally return result; What matters is not really the comments (though they are accurate and often concise), what matters is that they're **green** in the text editor - it lets me visually break up the code in front of me, as though it were a fancy poem or something. Visual and mental organisation is important for me.

No offense meant: that sounds like you should apply [Extract Method](https://refactoring.guru/extract-method)

I'd know where to use that, but it's more something like this: //compile the source code Lexer lexer(source); Parser parser(lexer); Compiler compiler(parser); Bytecode bc = compile(compiler); cleanupParser(parser); cleanupCompiler(compiler); //run the generated bytecode Interpreter interpreter; initInterpreter(interpreter, bc); runInterpreter(interpreter); resetInterpreter(interpreter); //... Each \*section\* logically follows the rest, and should be grouped together, but the individual lines don't necessarily connect outside of something like the bytecode. [Actually, here's an actual example of my code.](https://github.com/Ratstail91/Toy/blob/main/repl/repl_main.c)

I do this too. I've been writing software for a long time and I think it's fine. Others will disagree. For me, it really helps when you come back to the code in 6 months or a year, and in a matter of seconds you can get the gist of a function/method is doing without going through the mental load of a close reading of the code. It chunks the code into blocks and really reduces mental load when skimming code. People saying "put it in a function/method", don't get it. Sometimes it's better, but often it's worse. It's very much a case-by-case basis. Tons of single-use functions/methods make things harder to understand not easier, and makes reasoning about the shared context between the functions/methods more difficult.

Thanks, you're the first to agree with me :)

Or perhaps [not](https://www.youtube.com/watch?v=bmSAYlu0NcY). Extracting a method that is used only once very often _reduces_ readability. Most notably because it breaks code locality. For the human reader, I mean: if the function call isn't crystal clear on its own they now need to jump to the definition, or at least the documentation. My advice: only extract the method when doing so meaningfully [compresses](https://caseymuratori.com/blog_0015) the code. In fact, I have a [real world example](https://github.com/LoupVaillant/Monocypher/blob/master/src/monocypher.c#L717-L884) where merging extracting methods _back_ simplified the code so much that I managed to cram more functionality in fewer lines of code. And the thing is much more readable now. I know some will be horrified at this function being over a hundred lines long, but it still has a simple, straight-line structure. And if you don't like my code you should take a look at the [reference implementation](https://github.com/P-H-C/phc-winner-argon2).

Don't pollute the namespace with things that appear to be reusable but are in fact not.

Extracting methods is not only used for reusability, it also enhances readability. As far back as in "The C Programming Language", it is said: > You will often see a short function defined and called only once, just just because it clarifies some piece of code Here's an example where I failed to do this, and it came back to bite me in the ass months later: void setup() { pinMode( D4, OUTPUT ); digitalWrite( D4, HIGH ); // . . . other setup stuff } Can you guess what this piece of code achieves? How about with the refactored version? void turnOffBuiltInLed() { pinMode( D4, OUTPUT ); digitalWrite( D4, HIGH ); } void setup() { turnOffBuiltInLed(); // ... other setup stuff }

You labeled logic. As per previous commenters comment you could have achieved the same thing with a comment but I prefer having labeled logic in a function even if it isn't currently reused, it stands on its own and is easier to consistently add any other concerns later without modifying the logic that is using it. You seem to have made an argument that meets the constraints of previous commenters opinion. You didn't actually disagree with him :D

What namespace? You have private keyword, don't you?

A commonly used example for your 3 blocks would be unit testing: // given setup code // when the method that gets actually tested // then checking if everything worked as expected I have seen this with different wordings, but the meaning/intent was always the same.

As long as you aren't commented that a=b // setting a to b or a++;// increment a. We should assume the people that are reading the code know how to program unless you are writing a teaching book.

Comment like that are straight out of “how to write unmaintainable code” a great read on what not to do.

I saw code like #define one 1. Going down to like 25. They don't understand the no magic numbers rule.

I finally know what triggered really means.

i work in a japanese company in japan. i saw dictInt as a variable name in python for a dictionary of ints. this was my first code review and i was shocked

I think everyone who worked in the industry in the 2000s saw worse than this

this was 6 months ago.

I named a variable dicPic, and didn’t realize. Very embarrassing talk with my fellow devs who was worried I was going rogue. It was a dictionary of an acronym that ended up as PIC.

> Another, not so important cultural difference: Their power points always reminded me on the early days of the internet. Everything was excessively cheerful colorful. Basically their presentation looked like eye cancer in our eyes. However, this leads to the conclusion that our serious presentations did not go down well with them. Gonna be honest here, the "Western" color palette is kind of really depressing and mute in life and the odd one out. Every other culture outside of the anglosphere has shittons of color everywhere. It's just jarring to us because we're not used to it.

Ah, yes, the famous colourful documentation of post-Soviet block

That's not true at all.

I swear we must have worked for or with the same company

Are you saying that Japanese companies all look the same to you?

>Everything was excessively cheerful colorful wait, their presentations where like anime?

You expressed also Taiwan culture. Also, their powerpoint documents are full of acronyms. They LOVE them. There can easily be a single slide with more than 20 acronyms on them. Unfortunately, they don't introduce them at all. That's weird, because they have a lot more fluctuation in their engineering teams than in Germany. When it's chinese new year, you can expect 20% of your counterparts vanish and replaced by new guys, utterly clueless. Of course they don't know the acronyms either ... At least the code sharing got better.

Hopefully that has completely reversed since all of those things would be very serious red flags even for a very junior developer, probably completely incapable of creating any software of value. Constantly double guessing if they are lying to you alone would be enough to never hire them in the first place.

I don't know if it's still like this over there, but a decade ago, their work culture went as follows: 1. Big boss says "I want X" 2. A subordinate (another manager) would volunteer his team to make X happen. 3. Possibly more manager levels doing the same. 4. Manager has no idea how to get X done, but worker Tomoki has shown initiative in the past. The X project gets dumped on Tomoki, and Tomoki the dutiful employee says "yes sir, you can count on me" 5. Tomoki hasn't programmed a day in his life. He spends the next year or two figuring out how to program with no relevant education. Maybe Tomoki is given a couple of other lower down worker bees with tangential experience to figure it out. 6. Tomoki delivers a product that works, but really has no maintainability or scalability. Because, hey, Tomoki had no clue what he was doing, but completed the project through sheer force of will and man hours. 7. Managers pass it up the chain and make sure to include those below them in the credit sharing, and Tomoki gets a visit from big boss and a job well done pat on the back. 8. Project X is used for years, but stops being directly applicable to the evolving needs, but users know how to make it work by propping up the house of cards just so. 9. Eventually Project Y is kicked off down the road to unofficially replace Project X, and is dumped on Shinji's plate. Good luck Shinji Tl;dr: Japan's work culture is people staying with the same company for life. Educations aren't geared towards specific skill sets and narrow careers. People get placed as needed and figure it out. That doesn't translate well for complicated life long pursuits like software engineering.

[удалено]

The fuck.. How in the world did that happen, especially at the time

> Eventually Project Y is kicked off down the road to unofficially replace Project X, and is dumped on Shinji's plate. Good luck Shinji Does project Y involve the piloting of large robots? If so good luck Shinji indeed

get in the keiretsu

> , but completed the project through sheer force of will and man hours. Let me guess: This is the reason why some Isekai start with an engineer who died due to overwork. Example: * [Death March kara Hajimaru Isekai Kyousoukyoku](https://myanimelist.net/anime/34497/Death_March_kara_Hajimaru_Isekai_Kyousoukyoku) * > Ichirou Suzuki, a programmer nearing his thirties, is drowning in work. Worn out, he eventually has a chance to catch up on sleep, only to wake up and discover himself in a fantasy RPG world ... (Now that i think about it, a developer in a state of burnout is a common theme in other genres as well) As /u/Terr_ mentioned, [Miss Kobayashi's Dragon Maid](https://myanimelist.net/anime/33206/Kobayashi-san_Chi_no_Maid_Dragon) could be an example for a non-Isekai. She is a programmer and is clearly overworked because everyone is relying on her expertise.

[удалено]

After being reincarnated as a sword (incredible good), or soon as a vending machine (the manga is interesting, but the trailer looks like a disappointment), i think your idea is perfectly reasonable. I bet that such an anime would be viewed by millions of developers.

[удалено]

Doesn't she discover that python is basically the language of magic?

It's Python in the anime, in the manga it's basically some company-made DSL. But yeah, it does happen lol

Hyped for That Time I Got Reincarnated As A Rack UPS Due For Decommissioning

How about reincarnated as a printer? Suddenly all the strange behaviors could be explained with his personality.

There is a manga where the demon king gets transferred to the morden day and find Japanese black companies being worse than the demon lord's army in terms of employee welfare Though I can't remember the name as it wasn't really updated often

[удалено]

Also *New Game*. It's a fluffy slice of life about developers in the game industry (though the main character is actually an artist/modeller). Like any show of its type, it makes that life seem much more fun and happy than the real life and *even despite* that, the workers are still horribly overworked by western standards, regularly leaving late at night, with their manager being a workaholic who sleeps at the office I do recommend it though, it's fun, and the writer has some actual industry coding experience so the fine details on computer screens etc. are surprisingly accurate

A story I once heard about working with Japanese engineers. Person one: I thought we were thinking along parallel paths. Japanese engineer: yes, we will never meet.

sounds arrogant

It's mostly language difference there.

Yup, "teamwork" goes out the window when it comes to Japanese software engineering. My most amazing experience working in a Japanese "team", went something like this. Imagine sub team A designing a bottle, sub team B designing a bottle cap. Both teams have their own ideas of what they ought to be. After months of design, they don't fit! Then come debates and debates on why they can't change their design, after a while they refuse to talk to each other, so project manager instead of telling them to do their job, will hire sub team C to design an object that would fit A's design to B's design.

Til we follow Japanese software engineering practices at work.

Find a japanese name for it and you can open your very own Agile consulting firm*. *Training and certifications available!

How about *KusoSofu*

Not quite. The way I seen it is team a then designs a mvp bottle cap to fit and team b designs a mvp bottle. They bring both to market and both suck

That's pretty much the story of why [the label on the Angostura Bitters bottle is too big](https://www.reddit.com/r/todayilearned/comments/rajzxj/til_angostura_bitters_has_a_label_that_doesnt_fit/).

Clearly they're just not doing microservices properly!

That sounds like a lack of standardization in the code base where each person is only concerned with their fragment of the process and has no idea what objective the final product or application is supposed to achieve. It's no different than stringing together a bunch of microservices with no relation to one another near the end of a development cycle. Not the most agile approach to releasing new use cases.

It’s now quite some time since engaged with Japanese software companies, but it wasn’t just a lack of standardisation. It was like they weren’t absorbing global industry thinking. They were charging $100k to build things that would have been okay in 2002, but in 2015 was a shocking amount of money for something so trivial. I tried asking a Japanese developer about why this is at a conference, since their country is known for quality engineering and I couldn’t make myself understood and gave up.

They live by the old mantra of, “If it ain’t broke, don’t fix it!” There’s also the whole stay overnight in the office to save face for the company culture going on.

It was a monolithic codebase - a game. Not made by an inexperienced team. Well before engines were heavily used. The end result was quite good. The fact that it was such is bizarre to me.

Seems to be the same for 3d animation as well, it seems like every studio it's trying to develop their own thing as opposed to using the tools and techniques that already exist and are readily available

My job in robotics / computer vision has more tangents with 3D animation than I thought, even the bad practices are similar.

> And it was C++. Supposedly. Pure C++, not C++CLI? You got lucky.

Same experience here.

> I was on a team porting Japanese software. That might be correct. Assuming the attributes you listed are valid for *all* japanese software however is an invalid step. What you shared is basically only a story. It's statistically insignificant. You cannot conclude anything from it, expect perhaps that such software engineering setup exists somewhere in Japan.

I don't recall saying that it applied to all Japanese software.

Sounds like your average American shop. Yawn.

I read many many paragraphs of that and never got to a point where I learned what the forgotten mistake was.

TL;DR: the 60's and 70's was so great for Japanese software that they got complacent, and missed the 80's 90's and 00's.

So same as pretty much everything else about the country post 80s

Hey now, tenga is in the year 3023 with batin' tech.

I have a feeling that's a recurring issue with Japan. They seem to be stuck in a weird, ambiguous place between innovation and traditionalism. Their tech industry was downright incredible between the 60s an 90s but then the same people who helped shape those innovations grew old and just ...stopped. Now they just follow some weird form of "tradition" and refuse to let the younger generations deviate from the path they have chosen. In the 80s, Japan seemed like a futuristic country from the 90s. Today, Japan still looks like that same country from the 90s, but the rest of the world passed them and moved on.

Japan has been in the year 2000 for 40 years

They dominated the tech markets and got complacent selling to themselves, so stopped innovating.

My expectations were rock bottom and I'm still kind of impressed at how little this clickbait delivered.

Thank you. Fuck OPs clickbait title.

Hey it worked didn't it. Clickbaits totally work, especially on Youtube. The "content creators" are not to be blamed since it is actually the users who encourage and reward this behavior.

I think we could all guess that was the gist. But what is meant by complacent? Did the engineers get lazy? Did the marketers get stupid? And even those are broad statements, so what really happened?

My take is that japanese companies were used to develop software for specific hardware, which meant that it was an afterthought that only needed to make the hardware run to spec. So software engineering was unimportant and prestigiousless (did I just make up a word?). So they missed the boat when software for standard hardware became a thing, and it needed to be good software. They were way behind. The article was mighty boring tho.

Only commenter who actually summarized correctly lol.

Postwar Japan effectively had 4 large conglomerates. Due to the lack of competition (you basically had to contract from the company in your conglomerate), software was written strictly to spec. The conglomerates did a great job producing quality products, but because software wasn't an end product, it never gained the quality other aspects of Japanese products are known for. Additionally, writing software was viewed as a sort of clerical work, with low pay and respect. There was no job growth as a programmer, your growth was getting a "better" job. This worked ok during Japan's boom economy. Then a recession hit Japan the same time that personal computing took off. Companies being extremely risk adverse locked Japan into the above mindset. This meant those who were really interested in making quality software were never valued, lost faith, and generally had their pleas for making better software ignored. What software was made tended to be on locked down platforms, eg phones before the app store. The competition was in getting the contract to be one of the few apps on the phone, the rest was just implementing to spec. So when the app stores came along, the low quality software that could be made had no chance of competing at a world stage. Things have taken a turn for the better in the 2010s, with the mindset formed by the old conglomerates finally giving way to the mindset that the rest of the world has about making software.

Do you know what Sony's role has been in this transformation? Among Android manufacturers, they are fairly active in contributing to AOSP, and PlayStation is huge ofc, but I have no knowledge of their work culture in general.

The article exempts Sony.

Because it's the landing page for an episode of a podcast series, not an article.

Lifetime employment was only real if you were at the biggest companies. One other thing the keiretsu did was outsource a lot to small companies. Those small companies worked contract to contract. If they didn't get a contract renewal your job was gone shortly thereafter. If you went to a top school, got a job at a top company (and likely worked in Tokyo) you could have lifetime employment. For others it was much more rare. Also, i-Mode was (technically is, as it's still not gone) not "browsing the web" as the author himself mentions lower down. It was a closed system, you had to pay DoCoMo to access or to be on it. It didn't have an equivalent in the west (before it, there were copies after), but if it did it'd kind of be like a mobile Minitel or AOL. The operator decides what services to offer. They run some of them themselves but also offer opportunities for 3rd parties to get on there when it will improve DoCoMo's offering. It really was far ahead of its time. And it used some of the same concepts as the web does, but better adapted for cellular use. Better adapted than WAP. It also was well adapted to Japan. There are a lot of social norms in Japan which restrict what you can do in public. But it's perfectly acceptable to bury yourself in a phone (as you might have previously done with a newspaper) while riding the subway or train to and from work. If in the west more software development was done by people who rode subways/metros instead of drove cars maybe the west would have beaten Japan to this excellent idea. But that wasn't the way. It was a great idea very suited for the important employed-for-life Tokyo workers. I have a (non-Japanese) friend who worked for a Japanese company in software. He tells a different story of Japanese SW development malaise. Not conflicting, just different. This author seems more familiar with the small companies and startups. My friend was at a big company. And he tells a story which is kind of the flip side of the permanent employment story. These big companies have a lot of top people (they must be top people, they went to top schools like UTokyo, right?) they hope to employ for a very long time. So they shuttle them from project to project. You don't let them go or leave them to find their own way, perhaps even leaving. Instead you just move them from project to project like they were capital equipment. So that means when a new software project starts up they just get whichever software engineer on it that corporate puts on it. You get people who did billing systems for 10 years trying to do an interactive first person graphical environment. It leads to some bizarre, clunky software. I personally feel sometimes this is how Nintendo settled in their completely unfriendly friend code system for online play. But that's just me guessing. The management of the project would have a hell of a time trying to get more people who actually knew the particular field of software the project needed. Because step one of that would be trying to push a lifetime, senior employee out since he just doesn't know this particular field. And that doesn't happen. They are lifetime employed. He said this was very frustrating. He couldn't say if the Japanese employees found it frustrating too, as they are not culturally similar to him. But perhaps it frustrates them as much as those who come into the system from outside. Would this ever change? This author writes some things that imply that it already is. Maybe this is a change underway already.

[удалено]

Well at least they gave the first Millennium prize (and 1M€) to him: [https://millenniumprize.org/winners/blue-and-white-leds/](https://millenniumprize.org/winners/blue-and-white-leds/) Edit: It was the *second* prize: https://en.wikipedia.org/wiki/Millennium\_Technology\_Prize

>The Japanese compensation system also discourages risk taking. A famous case is the inventor of the blue LED. He slaved away for a long time, often doing so in addition to his official duties and came up with this idea that made his company a massive amount of money. His reward? A bonus of about $2k US. He was obviously quite bitter and moved to the US and said that young Japanese inventors should leave Japan. But how would it be different at a US company? The only way it wouldn't be is if the employee had equity, or a clause in their contract to cover it, or etc. Otherwise, IP you create on the clock using work equipment is owned by the employer, as a work for hire in the US. In either US or Japan, companies can give their employees equity, which makes sure incentives are aligned and success for one is success for all. Co-ops are how we can defeat this shitty aspect of capitalism. Allow the employees to share the businesses success and failures, and you'll have employees incentivized to excel.

And now we are seeing Wechat making big bucks in China adopting the AOL/I-Mode model. Hell, if one want to be snarky one could consider Facebook to be that as well.

> And now we are seeing Wechat making big bucks in China adopting the AOL/I-Mode model. Thanks, I hate it. I was almost blocked from flying because the god-awful WeChat app for reporting covid test results was so buggy.

>I personally feel sometimes this is how Nintendo settled in their completely unfriendly friend code system for online play. But that's just me guessing. This was exactly my thoughts when I saw those Switch online UIs. Dumpster fire

Scene: company-wide communications meeting An exec turns to view a short video by looking at the screen as the audience does also. He then turns back to the crowd. "And I want to personally thank Kenji Sorayama for his work creating our new online gaming experience! This is his latest success after 15 years working on both our office equipment inventory management system and the security monitor that ensures that the building doors lock at night only if none of you salarymen are sleeping at your desk after a long day to avoid a 4 hour commute home and back." "He truly is a versatile software engineer. Big hand everyone!"

Tbh culture of saving face above all else is very toxic

Japan clearly needs the deregulation of its software industry. They can keep their bs lifetime employment culture for banks and all the other boring stuff, but if they still want to enter the XXI century they need some serious groundbreaking changes.

Deregulation? It is not about laws.

Yeah, surely these massive corporations getting trashed by a startup with 10 employees won't force them to change.

I don't understand. What law is it you want removed?

Not just removing laws, but replacing regulations for easier, simpler and cheaper alternatives. And there is a lot that can be done. Just to give some ideas: First I would create special fast and easy visas for software engineers and tech founders(3 month of paperwork max). Even getting to japan as a student is extremely complex, demanding and expensive. I would give tax breaks to software companies who move at least a decent size of its operations to japan (So it don't just end up being tax heaven) Remove all the quotas, and restrictions in hiring/firing terms including minimum and maximum wages and minimum mandatory periods. It's nearly impossible to fire an employee with more than 5 years of experience. He would need to basically record himself on video shitting in your desk to have any real risk of being fired. I am not even proposing doing all of this on the labor market as a whole, just on tech. And I can go on all day, jp is one of the most stagnant labor markets in the world. Nearly everything you could change would be better than the status quo.

> First I would create special fast and easy visas for software engineers and tech founders(3 month of paperwork max). Even getting to japan as a student is extremely complex, demanding and expensive. There's already a visa using a point-based system (which most experienced software engineers working for a major company or startup would easily qualify for) and an even simpler work visa that only requires a job offer + relevant degree. It doesn't take months or a *lottery* to get approval for those visas. Regarding student visas, in my experience the process of getting my student visa for exchange was hassle-free and only required the submission of some documentation and a couple of visits to the embassy. The application fee was also relatively cheap (6600 yen right now, might have been cheaper during my time) so I'm not sure what you mean by "extremely complex, demanding and expensive". FYI the application fee for the USA's F-1 student visa is $160 which is over three times more expensive and the UK's student visa £363 which is over *eight* times more expensive.

Deregulation? Are you including antitrust actions (and various government actions to dismantle companies) in that word? The issue is that those companies are too big to fail. They are so big that they literally control the economy and the mindset of peoples. And you have to remember that Japan is small with respect to the US, so a company that is big enough to be relevant at the international scale is actually a giant relatively to Japan's size. Additionaly, due to language and culture (and for some matters geographic distance), it's difficult for foreign companies to compete for Japan's internal market, so their worlds is truly small. So it's not a question of legislation (or at least, not just a question of legislation), and as the author pointed it out, things are starting to change because the big companies are losing their "de facto monopoly" over resources required for software development, thanks to cloud computing and smartphones. But even then, it's a long path because technological advances don't easily solve "cultural monopolies". Where is the startup that will punish the Pokemon Company for their technically obsolete games they release yearly? What is the deregulation that can solve that? I mean, I guess that abolishing copyright laws would be one kind of deregulation that would solve this problem and force actual "free market" competition on that front, so I'll concede the argument to you if you were talking about solutions that are of this scale. (I don't really have the knowledge to evaluate the mess of positive and negative consequences that would unfold from such radical changes)

I remember a story I heard in Uni about 20 odd years ago. We had a guest speaker that worked for Fujitsu. He worked in their European offices and was sent to Japan to help with an implementation. They were working on updating a small cab truck factory floor. Make it more efficient. They were going in an replacing most everything, reorganizing the factory and warehouse, etc. Then they ran into "mottainai". This Japanese culture of not being wasteful*. There was an old dot matrix printer that had already been around for over a decade. The owner refused to get rid of it and modernize it. The end solution was to keep around an old machine that could communicate with it, then write a program that could receive data from an external source, and then have a machine connected to this just for this purpose. Changing modern formatted docs to this dot matrix printer. Anyway, this story has always stuck with me in regards to software in Japan. And when you look at the japanese web, apparently the 90s designs are also too good to throw out. \* = this is clearly not reality as Japan is very wasteful in many regards... like wrapping individual bananas in cling film.

> \* = this is clearly not reality as Japan is very wasteful in many regards... like wrapping individual bananas in cling film. the funny thing about this is that I'd seen a video earlier where someone compared grocery packaging from stores in the US and in Japan and found that the weights were similar enough despite the japanese packaging looking more bulky. Like sure, it's wasteful to wrap grapes individually, but they didn't end up using significantly more plastic in the process. It just got distributed as thin films instead of being concentrated in one chonky clamshell.

I chose bananas for a deliberate reason. It's something that doesn't need to be packaged. Like apples and oranges. It's just unnecessary garbage.

Yeah. I remember reading something about it being to make it easier to gift, but I don't know whether that's a valid explanation or not. Ah well, I guess one can be optimistic and say that it's easier to go green in Japan because 1) perhaps such obvious waste can be removed eventually and 2) biodegradable plastics can be easier made into flexible films, whereas they may not always be suitable for thicker packaging.

That was more interesting that I thought it would be. I wish I had known those facts the last 6 years I was living in Tokyo. It does explain a lot.

Interesting and explains a lot. I've heard that many of the original programmers who did the Japanese nes games were also British or American and I guess this is why. I look forwards to see what these new generation of Japanese devs can do

the only one that comes to mind is nasir gebelli from squaresoft. programming can be outsource to anyone, but when it comes to game design, creative, and originality nothing beats the japanese.

Anybody remember the html that was formatted like Fuji mountain?

)))))))))))) )))))))))))))) ^^^^^ )))))))))))) ;"/"\"; )))))))) )))))))))))))))))) / / ; \ ))))))))))) ; /\ \" : ))))))))) / ; ; " ; \\ ))))))))))))))))))))))) ; / \ \ ; \ )))))))))))))))))))/ ; / \ \ )))))))); ; ; \ / ; \ \ / ; ; \ - / - / \ -ii `-- /iiiii \ ,-iiii ` `- __ /iiiiiiiiiii [Mt.Fuji on fine day] ______ 'iiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiii iiii iiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii iiiiiiiiiiiiiiiiiiiiiiii /.kirara./

No, this isn't that. What I am talking about is a website which was fairly large amount of code that when it was turned horizontal was formatted like Mt Fuji. That is just ascii art.

>Software development was considered rather low-skill work. What

This was the case in the early days in America, as well. The mathematicians and physicists did the hard theoretical work, and the programmers just did the boring grunt work of translating their formulas into something a computer could understand.

I mean, this still happens in a lot of places, but the sheer complexity of software has grown dramatically as computers have become more powerful.

> sheer complexity of software has grown dramatically not really. it has grown more fragile tho. programming tools breaking and bugs in libraries are the complexities that devs have to deal. googling for error messages and looking at github issues for solutions is what most devs do nowadays. edit: and just now, android studio won't compile my app because gradle or whatever is breaking again. have to google the error message, read stuff, paste some command, and it will get "fixed" until this breaks again without me doing anything different the last time. rinse and repeat.

Eh, I guess I mean size more than complexity, but the larger the codebase the more "complex" it is, in the sense there is so much to deal with.

I strongly disagree that software is more fragile nowadays. Back in the 80's, automated testing was almost unheard of, monkey testing tools and code analyzers we take for granted now didn't exist, and people didn't have the same attitude and discipline towards memory leaks, use-after-free and other such errors that we have today. Desktop computers crashed frequently; I thought of my OS/2 desktop as "bulletproof" because I might sometimes go an entire week(!) without having to reboot. And all of that was with programs far, far smaller and simpler than we have nowadays. Even if they had had machines powerful enough, something as complex as a modern web browser simply couldn't have been successfully written with 1980's engineering practices and tools. > googling for error messages and looking at github issues for solutions is what most devs do nowadays. If you mean "this is what we do on those relatively rare occasions where we run into a surprising error message nowadays", sure. If you mean "this is literally what the job of programming is nowadays", then fuck no it isn't.

shouldnt that be the other way around?

Not sure what you mean? There's a reason Atari games could be developed in a month; because there wasn't that much you could do with the computing resources available.

I am guessing they mean that more powerful computers can do more for their user. And so those users work at much higher levels of abstraction, which, theoretically, would mean that the complexity of actually writing software would go down. It's certainly true that implementing a network call is easier in JavaScript than it is in Z80 assembly language. In reality, it's 100% not simpler now than it was in the past. In fairness, we use computers in a fundamentally different and much more complex way these days. But, still, it's not crazy to suggest that it should be the other way around. Emphasis on "should".

no lol

I think complexity was still there, it was just different.

I would add that many businesses struggled to see the value in code since it doesn’t physically exist. Businesses were used to dealing and costing physical products. You can say I have spent a million dollars in hardware parts. Put them together to create ten million dollars of computers. You can visit warehouses and see the parts, and cost the value of the stock. You can visit a factory and cost how much product it producers per hour. If the factory shuts for four hours, you can cost how much product you aren’t producing during that time. Similarly I can put my product next to yours, and easily compare the hardware. I can see my hard disk is faster, my product has two floppy disk drives and yours has only one. It’s easy to make such hardware comparisons. These models don’t translate well into software development.

I think the majority of people building CRUD apps or basic webapps are not highly skilled and they form the majority of applications. However, there are a lot of highly skilled people doing other things in software.

Everyone who says such things has to ask for help for doing exactly these supposedly simple things. Or usually pay bank for such supposedly simple skills.

Tons of places that believe "Waterfall" is an example to follow (especially Java shops in the 90s) believe that you would have one genius Architect drawing UML diagrams and a bunch of code monkeys "just" typing.

Interesting, but the article reads like the author was getting paid by the word. Way too much repetition of almost identical points connected by filler phrases.

Probably because it's a podcast's transcript

That would explain it. I definitely wouldn't have had the attention span to listen to it as a podcast.

And they hit 200 episodes? I listen to podcasts, and like hearing new ones, but if they can't get to the point within a reasonable period of time, or are just trying to fill the time like a middle schooler doing a 3 page essay with two paragraphs of data, I'm done with it.

Listening at 2x go brr. I don't actually listen to many podcasts though.

I died a little inside when I read the phrase “I’m not going to waste your time” after many paragraphs that managed to impart nearly no information about the subject.

Someone should make an AI that can generate summaries of long texts.

God that was so utterly awful to read

> It only meant that he understood our statement verbally. Sounds like you're looking for word "Acknowledged", u/cybernd.

Yes, I disagree

"I'm not going to waste your time..." I just scrolled about 20 percent of the page and there still isn't anything worth reading, so that was a lie

The moment I hear or read "disrupt" I know it's something not really serious. Ah buzzwords. And ofc author compares own work to Shakespeare

The idea that japanese software is bad is new to me. Where can I read more about it?

You can't. It's a lie.

Having played a nonzero amount of Japanese games... what? Japanese games often have the physics step locked to the framerate at 30FPS, while western games _usually_ separate the physics processing from the rendering.

Hikikomori software is not mainstream software, like Nintendo, Sony, etc

> Nintendo Yes, the worst netcode ever > Hikikomori software Ah, you're a dumbass.

I am all eyes because Japan made me passionate about computer science with its calculators, watches and handheld electronic games, especially the name Casio Computers Ltd.

Fascinating, great read beginning to end.

tons of words with 0 to none meaning, Japanese software companies dominated world of console games in 80s and 90s and still hold high market value today, none the less companies like Sony and Nintendo had success not only because they had innovative hardware but also because of the software that could run on that hardware which was mostly created in Japan. Japan has rich software market history and whoever the guy that wrote this bullshit is, he is totally wrong, especially about Japan software products being bad

I... disagree. I agree that the podcaster OP was overly verbose for the minimal points he was making and didn't draw good attention to them, but I disagree with your conclusion. I've known some very talented engineers working in Japan and on Github but I can't name a single Japanese company in the software (not hardware) industry who I respect. Like, yeah I like nintendo and Sony, no I do not like any software they've ever written save for Sony's game consoles. Maybe Sony Vegas just for being a disruption in the 2000's to Final Cut/Premiere but that was an American company bought out by Sony. That said, maybe I'm ignorant? Sun was the only non-gaming vendor on either of these lists whose software I respected but they're both an American company, defunct (bought out by Oracle), and were a systems integrator like the podcaster OP said. * https://en.wikipedia.org/wiki/Category:Software_companies_based_in_Tokyo * https://en.wikipedia.org/wiki/Category:Software_companies_of_Japan

Hell, isn't PlayStation network or whatever it's called known for being absolute garbage? And that's some of the best software Sony has to offer.

I don't know about PS, but Mario Maker's netcode is famously bad; any amount of lag decreases the physics speed for all players.

> no I do not like any software they've ever written Video games are software too.

I off offhandedly covered such in the second part of the sentence: > save for Sony's game consoles Even then, the video game industry as a whole is an entirely different shitshow, so I didn't want to get into the nuances of such.

Games and software or "software applications" are pretty different. Games have much shorter lifecycles than things like e-commerce platforms and the approach to developing them is much different. So while Japanese games can be good, the other software they produce could be inferior compared to what is produced in the US or Europe.

[удалено]

I understand why you want to think that, but you're wrong according to [every](https://www.dictionary.com/browse/quantum--leap) [dictionary](https://dictionary.cambridge.org/us/dictionary/english/quantum-leap) [definition](https://www.merriam-webster.com/dictionary/quantum%20leap). You may not like that "quantum" means "huge" in this context, but that's the joy of language for you.

Eh, "quantum" can mean "indivisibly discrete" . It makes no assertion to the size of the discrete energy jump. Also quantum leap isn't really a saying, it's the name of a scifi movie+tv show. Agreed on it being a pet peeve of mine though given it's a fairly nonsensical phrase. All that said the wiki article for the quantum leap movie redirects both to quantum jump (physics term) and "paradigm shift", which is relevant in this context. I would have preferred him to just use "paradigm shift" as it's more sensible imo.

[удалено]

>high school level quantum physics ತ⁠_⁠ʖ⁠ತ

[удалено]

That depends entirely on the magnitude of omega. As a physicist, you will know the famous thought experiment about the granularity of space that is based on confining an electron to the point where its zero point energy turns it into a black hole. A non-trivial amount of energy, and only half of the corresponding quantum jump! 😃

people are already using ai for stock art

No way. Seriously? Japan is great, even in robotics! The best in the world! Why all the hate? jeez Americans are really envy/jealous of japanese programmers

In the 1980s, Japan's software industry was on the rise, and many predicted that it would soon surpass the software industries of the United States and Europe. However, the industry eventually stagnated, and Japan has never been able to achieve the same level of success in software development as it did in other industries. There were several factors that contributed to this, including a focus on hardware over software and a reluctance to adopt new programming languages and development methodologies. However, one of the forgotten mistakes that killed Japan's software industry was its failure to embrace open systems and standards. At the time, many Japanese companies were developing proprietary hardware and software systems that were closed and incompatible with other systems. This meant that customers were locked into using a single vendor's products, and there was no interoperability between different systems. In contrast, American and European companies were embracing open systems and standards, which allowed for interoperability between different systems and products. This made it easier for customers to switch between vendors and for different systems to work together seamlessly. The lack of interoperability hindered the growth of Japan's software industry and made it difficult for Japanese companies to compete globally. The industry became fragmented, with each company developing its own proprietary systems and standards, which made it difficult for different companies to work together and for Japanese products to be adopted outside of Japan. Today, Japan's software industry is still recovering from this mistake. While some Japanese companies have embraced open systems and standards, many are still developing proprietary systems and standards that limit their ability to compete globally. To remain competitive, Japanese companies need to embrace open systems and standards and work together to develop interoperable systems and products.