It's true, you can't discourage it too much in people's free time, because a lot of them seem to love tinkering and that's the whole reason they started, but we

It's true, you can't discourage it too much in people's free time, because a lot of them seem to love tinkering and that's the whole reason they started, but we also don't need to make it an industry standard expectation that everyone writes a parser generator at some point. Innovation beyond the random toys level is really hard. At best most things can become a proof of concept that inspires some corporate dev. Unless you really enjoy that kind of random garage project, it seems reasonable to just leave it to the people who do. There's a lot to learn in the world of boring unoriginal software. You learn how to take a task and do it with high level building blocks, and the minimum possible custom code. You're essentially designing a "Plugin" for a system made of the entire current software ecosystem, treating dozens of unrelated apps in a workflow as if they were a suite, taking into account the fact that you know people will want to look at data in Excel or control your thing with a MIDI keyboard. I've done lots of random side projects, but I'm not sure I learned all that much, other than to really appreciate the value of the off the shelf thing I later replaced them with. It's hard to objectively measure that kind of general learning, so maybe I am better off for them, but I also think I picked up some bad NIH type habits that I later had to unlearn, and caused some of my biggest tech related regrets. Then again, if I was in a field where we actually did real "Paradigm shift" type stuff, I'd probably feel differently. But even then I'd imagine learning Haskell and linear algebra might be a better use of time, rather than implementing a window manager.