The Eureka moment for me was learning that a parser isn't a single entity. It's reading tokens, making an abstract syntax tree, etc. One I learned how to break the problems down I found writing parsers very easy.

As for it only being a small part of making your own language, that is so true too. However I do think it's a rewarding project to tackle.

The ability to parse is one of the things that differentiates "power programmers" from people just hooking things together. If you wish to be one of the former, it is on the Must Study list.

It is true that many, perhaps even most programmers can go their entire career without having to face the problem of writing their own code to take a text file and view it as a tree of tokens. This is even more true than ever with so many off-the-shelf serialization options, meaning that creating your own new one had better have a really, really darned good justification to it. But if you conceptualize a parser as "a thing that receives a stream of low level, primitive inputs and needs to extract sensible state information and know when constraints have been violated"... ah, now that sounds pretty useful, right? And very modern as we continue our inevitable marches towards viewing the world in terms of event streams rather than blobs of completed input that we can take in all at once. The generalized parsing problem of taking a stream of primitives and extracting higher level meaning from them is as relevant as ever, if not more relevant.