This article resonated with me a lot. On Tuesday I wrote a custom build app for my games, something that'll take my game dir filled with crap, preprocess the source code to create multiple versions, filter out unnecessary files, auto generate an inno setup install script and spit out setup files (or run the game in auto play test mode, etc).

Back in high school I wrote a similar thing in C#. I wrote custom code for every window and literally every control - lots of redundant code there. It was a big horrible mess and took two months to develop. For various reasons (cross platform high on that list, but also lack of flexibility and a horrible source base) I decided to rewrite it. I used to think I was a pretty good programmer (Dunning Kruger effect?).

This time around, I instead built a system which automatically generated a GUI around RTTI and handled loading and saving - very similar to Rails' Scaffholding. A day instead of months, because I chose to build a domain specific library with which to construct my application out of.

It's not exactly compiler writing (a parser wasn't needed thanks to RTTI, but if it was I would have written it) but I think it's very analogous to what he's talking about - problems that appear big and nasty can be abstracted down and become trivial by solving one hard problem instead of a larger amount of slightly smaller ones. This is true of compiler writing, frameworks like RoR, layers like HTTP/TCP/IP. It's the very reason why the spread in programmer productivity is so high. Better programmers don't attack problems faster, they attack them from a position of higher leverage.