Earlier quoted context omitted.
Fun fact: the "compilation" step in my company's React project is the biggest consumer of CI minutes by far across our entire organization, beating out every one of the Maven compile and test loops But, since the devs don't care, there's only so much finger wagging I can do
Over the course of a month or two the time taken to compile a single .ts file in our codebase climbed from 'too small to measure' up to '7 seconds'. It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow. Getting timing data out of build tools like rollup was brutal, and editors with tsc integration like vs code/sublime text would just lag and misbehave…
I don’t know why. Perhaps it’s because it’s something you and your peers use constantly so when it speeds up the quality of life for all in the shop improves. I mean, it’s not often you get to make an improvement to your project that directly affects everybody working on it.
Perhaps it’s because of the challenge and that most developers absolutely hate fucking around with the build system. Example: the parent poster. Build systems are can be pretty archaic but have a ton of features that most people don’t exploit.
Perhaps it’s because it is easy to timebox and has a readily apparent set of diminishing returns. You can generally make a single change, push it to production and if that is the only change you made you’ve still added value.
Perhaps it is because almost all of the changes you make don’t alter how the end user (other devs) use the build system. Short of swapping the build system entirely most of the time everything you do changes nothing for the developer.
Perhaps it is because it is a good distraction from whatever it is you should be working on. You can squeeze it into spaces where you don’t have much in the pipeline or need to think something through.
Whatever it is, I love fucking around with build systems.