現在のブログ
ゲーム開発ブログ (2025年~) Gamedev Blog (2025~)
レガシーブログ
テクノロジーブログ (2018~2024年) リリースノート (2023~2025年) MeatBSD (2024年)

【Development】"Don't Reinvent the Wheel" is Terribly Destructive Advice
In the field of software development, especially web development, the advice "don't reinvent the wheel" is often heard.
The short-term goal is to complete tasks and make money quickly.
However, in the long term, this advice is extremely destructive.
Why is "Don't Reinvent the Wheel" Destructive?
The biggest reason is that this mindset encourages developers to remain indifferent to the code's foundation, the systems being executed, and even high-level code.
As a result, when a project breaks, they don't know how to fix it and can only hope that the person who invented the wheel will fix it for them—if that person still cares.
Another issue I've been warning about for over a decade is the growing danger of supply chain attacks, which is becoming increasingly evident today.
These attacks allow malicious actors to destroy your project without even knowing your source code.
This is because all the dependencies used in web, mobile, or desktop development are open-source, and the remaining 5% of your project's code is likely copied from StackOverflow, Qiita, or ChatGPT.
The "don't reinvent the wheel" mentality is also demoralizing.
It psychologically suppresses you, hinders the growth of your knowledge and skills, and makes you a worse programmer overall.
This is because you constantly think, "Someone better than me has already made it" or "I can't make it as good as others".
The Importance of Self-Respect
This may be a controversial opinion in Japanese culture, often considered a Western mindset, but the key to becoming an excellent programmer is having self-respect and taking pride in your work.
This applies not only to programming but to all skill-based fields like digital art, design, music, sports, engineering, and literature.
Regardless of country or culture, you always have the choice to step out of your comfort zone and take pride in your work or stay in your comfort zone and rely on others without thinking.
A recent example I can share is my collection of PHP libraries.
Each library already has available dependencies, PHP extensions like php-curl or php-mysqli, or, to put it dramatically, dependencies that are merely OOP layers for PHP extensions.
Still, I built everything from scratch, deeply learning how each component works in the process.
Don't make excuses like "it's too hard".
I'm currently learning the Nintendo Switch SDK, its tools, the NVN API, and possibly other things I can't mention under NDA.
I can't rely on online communities, documentation, or AI, yet I learn something new every day and make progress on my game without external help.
How to Do It?
All it takes to achieve this is deciding to do it properly right now.
Yes, to learn programming, you just have to do it.
This might seem unbelievable to modern coders, but it's common sense to veteran programmers.
It's truly a shame I even have to point this out.
Last weekend, I struggled to get model-based collision detection working.
Then, looking at basic shapes, I realized the issue was treating the entire stage as a single model.
If I had separated it into components, collision calculations would have been much simpler.
For example, in a 3D model of a room with a PC, monitor, and cat tower, you only need to set box colliders for the floor, walls, desk, and cat tower.
There's no need to calculate AABB collisions for each item on the desk because you won't walk there.
The same goes for the ceiling—you don't need to set collisions there because you're not supposed to collide with it.
If you treat everything as a single model, you'd apply AABB collisions to the entire room, causing the player character to stand on the ceiling and be unable to descend to the floor.
That's all