We all know about DSA—Data Structures and Algorithms. But that's not all there is to programming, no matter the field. I emphasize this especially in software engineering: DSA is almost never the fix on its own.
Today marks over a week and a half on my lexer since the beginning of May 2026, when I decided to build a compiler. I've gone through different choices, code patterns, rewrites. But you know what? I didn't read a single compiler book. No Compiler Dragon Book—the bible of the field. No PDF, no 2,000 pages just to experience someone else's experience into yours.
This article isn't saying you shouldn't read books. But if you're a systems engineer like me—and my experience is pretty low, roughly 2.5 years in C++ and years in programming—we know tools aren't always the answer. In fact, DSA isn't either. This isn't about toy projects. We're talking about real production-grade projects where every performance detail and line of code must be understood perfectly, not just written pretty.
While writing the lexer in C++, coming from Rust after ditching C++ for a while, I hated my comeback. Rust's ownership model and the compiler fighting me on every borrow? I ran from it. Went back to C++ where debugging a struct—which was my token object—meant just printing fields and moving on. No lifetime elision wars, no fighting the borrow checker because my token held a reference to source text that might outlive the lexer stream. In C++, I own my memory, I leak it, I fix it. The cost is visible immediately. In Rust, the cost was hidden behind compiler errors that were technically correct but solved someone else's problem, not mine. I didn't need zero-cost abstractions. I needed to see my token struct in a debugger without wrestling with the language first.
