Then there's the feeling you get after you have done a dozen of fixes to your code and none of them fixed the problem which got you started until you realize that you were debugging the wrong file. There was so much room for improvement.
I can only expend so much energy learning a problem domain so many times a day, sometimes, using instinct and learned heuristics to find a fix without building a mental model of the wider picture is good enough.
I should also add it depends greatly on your codebase. Some code bases are so rotten your heuristics won't work but if you have clean abstractions or even just code that generally limits the amount of weird and unexpected shit it does you should be fine brute forcing a few things saving brain power for later in the day.
This problem can be solved by increasing compile time.
But that sort of dumb deployment thing is what gets me when I am tired, more often than something really complicated.
I eventually realized I was running into a bug in my build environment. It wasn’t detecting the library had any code changes so it was “optimizing” my build by skipping that library. It was one of a dozen or so dependencies so it wasn’t immediately obvious. Eventually, I set a breakpoint somewhere else in the library code and realized it wasn’t being hit because the source code didn’t match the symbols!
I felt pretty dumb once so figured this out even though rationally I know it wasn’t my fault.
My code is targeted to experienced functional programmers, and others of the same skill level seem to have no trouble with it, but the less experienced will bounce off it. My thinking is that those people should get more experience and come back instead of optimizing my codebase to a lower common denominator for ease of hiring. This has made hiring difficult as anyone who can work on my code base can probably get a high paying job at a FANG. But as a solo dev the productivity gain is enough that I still have no trouble competing in my niche.
Doesn't work with clients who aren't quite sure what their own requirements are, of course. Then it's more of a few days at most, so revisions can be done early.
If I'm interfacing with a library that I'm not familiar with, I'll usually do trial and error in a blank project, separate from the actual project, first. Then write cleanly in the real project. Iteration times on the learning process are faster that way.
Sometimes I'll just write long drafts or snippets in notepad at first, just to stay clear of IDE distractions. It's a fast way of figuring out the structure of things without the need for everything to compile at all times.