It goes like this: You read a function and understand what it does. You scream at the original programmer (who was probably yourself) for being an utter idiot and doing it badly. Then you rewrite it better.
Then you go to the next function, and realize it doesn't even need the previous function at all, so you get mad at yourself and delete all that wonderful code you just wrote.
Then you try a new way: instead of inside out (start at the internal functions) you start at the top - you find where the code handles some particular task, and you drill down deep into it, throwing away useless code left and right and rewrite the thing better. (Your advantage being you know exactly what it needs to do, unlike your previous self who did not know that since he was still developing it.)
You also use a tool that finds dead code - in particular functions that are never called by anything.
Breaking big problems down into small ones is part of the process, yes, but only once you are well-versed in the problem space. The guy who rewrote this:
1. Is proficient in C.
2. Understands Playstation architecture and development better than the original programmers of the game. (Although Psygnosis had far less time and hindsight on their side.)
3. Is apparently quite familiar with 3D game programming and techniques in general, and how/when to use them.
4. Already had experience reverse-engineering parts of the game previously.
5. Had the free time to undertake a project of this scale.
So it's not something any random dev can just snap their fingers and decide to do. It's a case study on the intersection of experience, preparation, and luck.
On the other hand I think ars's point is good advice: The way you do the work is, by doing the work.
So many people I work with these days are constantly looking for tricks, or secrets, magic tools, or whatever they seem to think I'm doing to consistently outpace them, just to avoid writing code (/ reading code / thinking through code). They take 2-10x longer and their result is invariably worse. When you ask why they do it, they answer "you'd have to do so much refactoring", "the algorithm would be hard to implement", "I'd have to replace dependency X", and so on as a list of things that actually aren't so hard or time-consuming if you sit down and just do the work. But my only "trick" is that I write the code.
Just sit down and do it! I'm reminded of Harlan Ellison, commenting on why he wrote in public,
I do it because I think particularly in this country people are so distanced from literature, the way it’s taught in schools, that they think that people who write are magicians on a mountaintop somewhere. And I think that’s one of the reasons why there’s so much illiteracy in this country. So by doing it in public, I show people it’s a job.
Wipeout was asses in chairs writing code. This cleanup is an ass in a chair writing code. Yes soft skills are important blah blah. But if you want to be good, to learn to do this stuff, there's no way around putting your ass in the chair and writing code.
Shipping bad code fast and with little understanding isn't really what I'm talking about. I would say the kind of frontend developers you're describing lack hubris; the ones I'm talking about (which are all over the stack but I would say somewhat concentrated in the middleware-to-commodity-backend, Spring Boot, etc. area) lack laziness.
This specific case is just a grift. The usage of is-odd isn't as legitimate as people think.
If you look through the dependents, there are other packages by the same author that are "semi-useful" and depend on it. The author got some important packages to use those.
The author could just inline is-odd, it's a single line after all, but then he would lose the bragging rights of having a package with 500k weekly downloads.
This is how left-pad got included into create-react-app (or something like that) in the past. It was a 3rd or 4th level dependency of something that was actually useful.
The problem here is people and packages not really vetting their 3rd-4th level dependencies. And you'll see a lot of people here in HN defending the practice of not caring.
Then you go to the next function, and realize it doesn't even need the previous function at all, so you get mad at yourself and delete all that wonderful code you just wrote.
Then you try a new way: instead of inside out (start at the internal functions) you start at the top - you find where the code handles some particular task, and you drill down deep into it, throwing away useless code left and right and rewrite the thing better. (Your advantage being you know exactly what it needs to do, unlike your previous self who did not know that since he was still developing it.)
You also use a tool that finds dead code - in particular functions that are never called by anything.