To me, this model absolutely applies: Writing code is little-picture, detail work. So is typing, so is debugging, so is deployment. So you can bury yourself in detail work as a coder.
And, I'm not a little-picture person. If I'm doing detail work, it's generally got to be really interesting to me, or otherwise highly relevant to my personal values, or I'm going to burn out pretty fast.
In that way, it's a very good fit as a hobby. Nothing super-important, but also really fun? Sure, I'll dive into those details for a while, and then get back to work.
In my work-coding then, the risk is that I overkill on detail that's not interesting to me. So I keep things as high-level and reasonably scope-defined as possible in order to avoid the downsides of this.
For example, I use big-picture plan to build the rationale for the work, then I schedule the work to happen in comfortable phases that jive with my overall schedule (avoiding a detail-crunch), I framework my entire coding practice from beginning to end, I reuse code when applicable, and so on. I always watch for ways to make it easier next time.
But going beyond that: I have something fun or interesting planned for afterward, I have interesting things going on during (music, movies I like, snacks I like, etc.) and I package my work for later in case I need to do the same thing again in some way.
I had to discover this pretty early on in my career but it's been helpful since that time.
As a subjective hobby, I find that programming is metaphorically the same as scheduling for objectivity (get with the program, theatre programs, object-oriented programming, and so on).
So at those times, programming as an interest that "strikes me in the moment" helps me to remember to carefully, patiently stay on track and accountable on objective passion projects that I suck at, and that I want to do anyway.
Bravo on the career reflection btw. If you're not enjoying your career, changes have just got to be made.