This is about programming specifically, but I guess you can experience similar things with many other activities as well. So if you can even remotely relate your thoughts are very welcome.
Alright so, every time when I sit down to programme it tends to start out great, I feel relaxed and kind of looking forward to it. However, at some point there is going to be a bug in the code or some library does not work as I expect it to. I then start googling; try something out; doesn't work; google some more; try more stuff; still doesn't work. While this is of course just what coding is like, during these "google, test, repeat" sessions I tend to go faster with every iteration and at some point I am in such a rush that it feels like I hardly remember to breathe. Needless to say that this is freaking exhausting. After an hour of this my brain is just mush.
Of course, the obvious solution to this is to just take a break as soon as I notice me speeding up. I will try to do this more, but sometimes it feels like I can't. This unsolved bug will sit in my mind so that I can't stop thinking about it even if I'm not at the keyboard. "It must be solved. Now". Of course it doesn't, but that's what my mind is telling me.
In a few months I will probably be working as a full time dev again and until then I have to have solved this problem somehow if I want to do this any longer than a couple of years.
Ideally I want programming to be a meditative experience and feel refreshed afterwards instead of completely drained. This might be illusionary, but at least I would want it to be draining more like I've been on a good run, instead of feeling like being hit by a truck.
Anyways I'm wondering if any of you can relate to this and maybe has solved this in some way. Does this ever happen to you? What do you do to prevent this from happening? I appreciate any thoughts you have on this.
So, this may sound like a weird response, but:
I write Java for a paycheck and have been doing so continuously for the last... 12 or 13 years or so?
And, of course, the idiomatic way to do Java is to write your code atop a precipice of abstractions. A simple HTTP server library wasn't good enough, so they built Servlets. Servlets weren't good enough so they built Spring on top of Servlets. Spring wasn't good enough, so they heaped Spring Boot on top. I can't wait to see what they come up with next.
And these abstractions make everything so easy right? You just throw a little annotation here and it does all the magic behind-the-scenes and you don't have to think about it! ...until the moment something goes wrong. And if there's one thing that you can depend on going wrong, it's Spring/Spring-Boot stuff.
One thing you mentioned specifically was a lot of "Googling." And that's very reminiscent of a phenomenon I've seen repeatedly. All the Java people say you should be using Spring Boot because it makes things so easy, but the moment you actually go and try to use Spring Boot to do anything serious, you run into obstacles.
Not only does this lead to googling hell, but developers (particularly junior developers) tend to internalize that. "If I'm doing what folks are telling me will make things easier, but it's not working for me, then I must just not be a good programmer." But the truth of the matter is that these libraries often don't work as advertised. And nobody really knows how Spring Boot, so the top dozen answers about the problem on Stackoverflow are just straight up wrong. And so you throw shit at the wall until something eventually sticks, because you're not one of the Spring Boot core developers and you don't really want to delve into that madness. In short, the reason why it isn't working is Spring Boot's fault, not the developer's. (And I'm picking on Spring Boot in particular here, but it's far from the only good example.)
My team sees me as a "senior developer." The kind of developer to turn to after googling hell has lasted so long you've run out of leads. What that really means is that I'd rather spend hours delving into Spring/Spring-Boot source code than try to sift through a million wrong answers to find a code snippet to copy-paste in and hope it will work without having any understanding why it might work.
So, my recommendation to you is to stop using dependencies to the extent you can. Use what's in your language's standard library to the extent you can. Don't be so phobic to reinvent the wheel (and if you're phobic about reinventing the wheel, blame the propaganda you've been fed, not yourself!) that you pull in something that'll quadruple your project's and cognitive load. When you do need to use dependencies, use the most minimal ones you can. Also, don't be afraid to go "lower-level" with things. And never use any "frameworks" that try to do lots of unrelated things over libraries that implement a single narrow use case. And never use libraries whose only reason for existing is to "magically make things easier."
When you do things that way, you're just... writing code. Nothing's ever broken or misconfigured in a way that causes things not to work because... there's nothing there to be broken or misconfigured. There's fewer moving parts to contend with, so writing code is just... writing code. As fast as it pours out of your head and through your fingers into your text editor. (Oh, speaking of which IDE's are the devil too. They just muddle things. "Is it the build system that's broken, or is my IDE just giving me red squigglies because it's misconfigured?" Fuck that shit. Just run a build and if it says things are broken, then you don't have to choose between two different sources of truth to determine the state of the codebase.)
If you want to see some examples of what the results look like, a couple of projects I've written that are decent examples of this dependencies-avoidance approach are:
Other things to look into:
If you don't have enough autonomy over the project to make decisions about what libraries are used, spend less time googling and more time learning the internals of the dependency by pouring through the source code (or, if it's not Open Source, official low-level developer documentation -- JavaDocs or whatever) of the dependency that isn't behaving as it should. It's fine to spend a little bit of time searching Stackoverflow when you run into an issue, but set yourself a timebox after which you'll switch to source code and shut out the cacophany of wrong answers that Google is providing.
Good luck, and happy hacking!
I think you are making a good point. For private projects I do in fact programme a lot in go. Sometimes I even pull the plug on my router and use just devdocs.io to get things done. And this does make things at least a lot more bearable. Before I started the post graduate programme I'm currently in I did full stack development for a living in different projects. Usually Spring Boot + either vue, react or angular for frontend. And I 100% agree with you: Spring Boot is just madness. My personal arch enemy is Hibernate though. It's awesome when it works, but at some point it won't and then it is absolute hell. Problem is that where I live go jobs are scarce. Virtually everyone here is doing Spring Boot.
I've literally talked my team at work into writing an ORM rather than use Hibernate. (Ok, to be fair, the "ORM" in question doesn't do a few things that you might expect an ORM to do like creating tables and migration, and there are a few things that it does that you wouldn't expect an ORM to do, like support for data from more than just SQL databases, though we have yet to use that last feature. But it's much more "an ORM" than "not an ORM".) The in-house ORM has been in continuous use in production code working - I think - quite nicely for... jeez. Probably 7 or 8 years now?
To reinvent the wheel or search for a suitable premade wheel. It's never been a straightforward choice. On one hand, I might need functionality that the library actively inhibits. On the other hand, I could end up spending way longer than I can afford to replicate and adequately test everything myself.