In typical HN fashion, this just sounds like an excuse to jaw about your resume projects.
How would these clearly niche projects be something "every programmer" should try? When in enterprise engineering is 2MB a normal amount of memory for something to need? I'ved worked in videogames, fintech, e-commerce and worked on many kinds of systems and not run into anything with such requirements.
Not to mention, the sorts of "lessons learned" on such projects could actually hurt an engineer when working on more realistic enterprise systems. At my current job (where I manage many teams of engineers), if I saw engineers micro-optimizing to save 2 MB of memory instead of getting features shipped I would ask their tech-lead wtf was going on.
I've seen far more damage done by premature optimization in my career than I've seen it actually help matters. Engineers trying to be "extra smart" and show of their extreme memory/cpu optimization skills so often leads to wasted time, hard to debug code, or worse, annoying bugs which are much more difficult to diagnose later.
You miss the whole point of the list. The idea is that experience of working on variety of projects makes you better developer in whatever field you are in.
This assumes you will understand where to use and when not to use those techniques.
The list gives examples of projects each with unique requirements. Each requiring you to think about the problem in a different way.
I just gave two more examples that I personally found very illuminating, that also have unique requirements, different from other projects on the list.
I may be working on some more mundane software atm but, for example, I know how specifying size of every buffer or any data structure is important for reliability of the service I am working on.
In fact, the service had bad track record of reliability which was quickly fixed by specifying what it means to do stream processing (no unbound data structures in memory, etc.) and quickly verifying each component against this spec.
I learned this and many others from MISRA which is standard to help write reliable software for automotive industry. I adopted it for my embedded app to help me work on complex app that had to be very reliable.
How would these clearly niche projects be something "every programmer" should try? When in enterprise engineering is 2MB a normal amount of memory for something to need? I'ved worked in videogames, fintech, e-commerce and worked on many kinds of systems and not run into anything with such requirements.
Not to mention, the sorts of "lessons learned" on such projects could actually hurt an engineer when working on more realistic enterprise systems. At my current job (where I manage many teams of engineers), if I saw engineers micro-optimizing to save 2 MB of memory instead of getting features shipped I would ask their tech-lead wtf was going on.
I've seen far more damage done by premature optimization in my career than I've seen it actually help matters. Engineers trying to be "extra smart" and show of their extreme memory/cpu optimization skills so often leads to wasted time, hard to debug code, or worse, annoying bugs which are much more difficult to diagnose later.