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.
Personally the bug fixing part of it is the most enjoyable to me, so if I end up programming and there is no bugs, that’s when programming becomes a pain for me. Trick to fix it for me is to have my wife give it a test, bam, bugs to be fixed. Never fails.
I think sometimes I do enjoy bug hunting as well, but only if I didn’t write the bug myself and only if there is no research outside the editor involved. Fixing my own bugs feels like “not progressing” to me. So tell us your secret.
The issue is your mindset.
You write bugs because you have something to learn. You’re so focussed on what you’re making, that when a learning opportunity arises, you are not open to it. You’re just looking to speedrun/hack it.
You need to drop the delivery pressure and enjoy the journey. When a bug comes up, celebrate it “ah, you got me here. Interesting. What am I missing?”. Then you slow down, focus not on solving it, but understanding it. If you understand it, the solving is easy.
If you consider learning “not progressing”, then you need to reflect on what benefit the pressure and delivery focus is.
Especially as one potential “solution” to creating complex bugs in programming is to be less ambitious with the projects you choose. A friend suggested this to me once, when I was getting frustrated with how many bugs I was running into in a new problem domain. They knew better than I did at that point that the reason I kept diving into silly projects was because I did enjoy the challenge and the feeling of my capabilities expanding. That had gotten a little lost along the way.
Have you tried ‘rubber ducky programming’? I’m not a programmer but the trick has helped me with other things when I hit a wall like your talking about. Basically you have a rubber duck with you and when you have a bug or issue, you back up and explain each peice and what it’s supposed to do to the duck. The duck doesn’t know programming so you have to explain it like it’s, well, a duck. This helps slow down your thoughts and focus more on what each line does individually. As an electrican it helps me trouble shoot problems without opening up everything.
Hopefully this helps but I know each of us are different and what helps me may not help you. I know how hard it is to set a problem down when your in the thick of it. As a perfectionist I have to tell myself, it’s good enough, constantly or I’ll spend 3 days on something that should take 1.
There are programs to force yourself to take a break on a schedule, locks the screen for a few minutes, if you know about how long it takes to happen.
Music can help a bit.
Digestion when stuck is good, too. I go do something else and let the unconscious part of my brain work on the problem. Aha is like a cat, it will come but not if you force it.
You might want to try a Pomodoro timer. Work for 25 minutes, then a mandatory 5 minute break. Even if your brain doesn’t stop thinking about the bug, over time, you may find yourself better able to separate yourself from the work when you want to.
I made one you can try.
So, this may sound like a weird response, but:
- What language are you writing in?
- What sort of projet are you working on? (A scratch-your-own itch project? Contributing to something Open Source? Something to eventually make money off of? A game?)
- How much autonomy do you have over this project?
- What kind of libraries are you using?
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:
- GoVTT - A web-based “virtual tabletop” for playing tabletop roleplaying games remotely. 13,000 lines of Go and JS code. Exactly three dependencies: a Sqlite3 client library, an HTML/CSS/JS minifier library, a transitive dependency pulled in by the minifier library. (Zero JS dependencies.)
- CodeComic - A domain-specific language for making web comics. 4,000 lines of Go. Three dependencies: two having to do with image generation/processing and a transitive one having to do with font rendering.
- Hydrogen Proxy - I haven’t touched this one in a good while, but it’s a scriptable HTTP proxy. 7,000 lines of Python. Three dependencies: an SSL library, a standalone templating engine, and a library that implements the Socks protocol that I also wrote myself.
Other things to look into:
- suckless.org - These folks know how to minimalism in programming. The coding philosophy of these folks is elegant and beautiful.
- cat-v.org - The person who wrote this site was heavily involved with suckless.org before his tragic passing, so largely it’ll be more of the same, but much more humorous and enjoyable to read.
- Rob Pike’s Mastodon account - Rob Pike’s awesome. Top architect of of the Go programming language. Has unusually level-headed views on coding.
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.
