Naming variables descriptively? Build for current requirements, not future ones?
You do not have to look far to find these qualities and practices basically anywhere software is made. I am not especially inclined to see the author as an authority after reading this.
I have also worked with Japanese developers and found them resistant to new ideas because seniority often trumps knowledge in Japanese work culture. But I did not assume that meant that all Japanese developers are stuck in the past because that would be silly.
The observations reflect the deeper cultural differences. Japanese corporate goal is to build a company that lasts 500+ years. In the West the corporate goal is to maximize this quarter's numbers, deliver profits for the shareholders, maximize the executive suite's gains.
> Western developers are obsessing over the latest JavaScript framework or arguing about tabs vs. spaces
Most "Western developers" are not doing that; this is a minority.
I don't really know anything about Japanese software development, but I'm reasonably sure there are some Japanese developers doing unreasonable things too.
e.g. was that Toyota firmware that caused acceleration developed in Japan? An audit revealed it was absolutely horrible.
I’m not creating a medium account to read the entire article, but I read plenty of bad code while living in Japan — as a full-time employee, a contractor, and open source projects. I would take this article with a grain of salt.
Don't get me wrong, my career has been enormously helped by Japanese developers. (Thanks Matz)
But "works better" is a hard claim when there are very few pure software tech firm in Japan that are also globally dominant (would love to hear of them if they exist).
I have never in my entire career at startups, consultancies, BigTech, or Fortune50s heard _anyone_ ever care about tabs/spaces or JS frameworks beyond "oh this approach is interesting, lets try it"
Additionally I don't think "The secret? They treat code like a Toyota Camry, not a Tesla." is the flex the author thinks it is.
Finally, development speed is incredibly important. Napoleon is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own".
As long as its not complete slop and has some safe guards, consistently moving very quickly fixes almost every other deficiency.
- It makes engineering mistakes cheaper (just fix them fast)
- It make product experimentation easy (we can test this fast and rever if needed)
- It makes developers ramp up quickly (shipping code increases confidence and knowledge)
- It even makes rigor more feasible as the most effective rigorous processes have to be light weight and built-in or they go unused.
Code shouldn't be built to last decades, it should be built to be changed quickly and easily.
Every line of code is a liability, the system that enables it to change rapidly is the asset.
11 comments
[ 3.0 ms ] story [ 46.8 ms ] threadYou do not have to look far to find these qualities and practices basically anywhere software is made. I am not especially inclined to see the author as an authority after reading this.
I have also worked with Japanese developers and found them resistant to new ideas because seniority often trumps knowledge in Japanese work culture. But I did not assume that meant that all Japanese developers are stuck in the past because that would be silly.
Most "Western developers" are not doing that; this is a minority.
I don't really know anything about Japanese software development, but I'm reasonably sure there are some Japanese developers doing unreasonable things too.
e.g. was that Toyota firmware that caused acceleration developed in Japan? An audit revealed it was absolutely horrible.
This reads somewhere between ChatGPT sycophancy and LinkedIn cringe from someone with a Japan fetish.
tldr: According to the previous thread, Germans are terrible at software.
Don't get me wrong, my career has been enormously helped by Japanese developers. (Thanks Matz)
But "works better" is a hard claim when there are very few pure software tech firm in Japan that are also globally dominant (would love to hear of them if they exist).
I have never in my entire career at startups, consultancies, BigTech, or Fortune50s heard _anyone_ ever care about tabs/spaces or JS frameworks beyond "oh this approach is interesting, lets try it"
Additionally I don't think "The secret? They treat code like a Toyota Camry, not a Tesla." is the flex the author thinks it is.
Finally, development speed is incredibly important. Napoleon is credited with saying "quantity has a quality all its own", in software it is "velocity has a quality all its own".
As long as its not complete slop and has some safe guards, consistently moving very quickly fixes almost every other deficiency.
- It makes engineering mistakes cheaper (just fix them fast)
- It make product experimentation easy (we can test this fast and rever if needed)
- It makes developers ramp up quickly (shipping code increases confidence and knowledge)
- It even makes rigor more feasible as the most effective rigorous processes have to be light weight and built-in or they go unused.
Code shouldn't be built to last decades, it should be built to be changed quickly and easily.
Every line of code is a liability, the system that enables it to change rapidly is the asset.