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.
You might want to find something that helps you temporarily switch off or redirect that part of your brain. Drugs can be habit-forming, but video games or going for a run might help clear your head. Even making yourself stand up and stretch for a few minutes every half-hour or so can help.
You can also try to work on more systematic approaches to solving your problems, rather than throwing random snippets from the Internet at the wall. Come up with a plan to collect data, structure experiments, analyze results. Rubber-ducking also helps, explaining your problem to someone real or imaginary; this can help you reframe the problem in your mind and lead to a Eureka! moment.
Finally, programming might never be a meditative exercise. At its heart it’s simultaneously highly creative and technical, using a lot of brainpower. In order to feel less drained, you need to stop before you hit the point of exhaustion - at the very least take that break, grab that drink, eat that snack, whatever helps you recharge.
Don’t let yourself get bottlenecked. The debug cycle can spiral out of control when you too fixated on one element.
When you feel that happen, take a five minute break and figure out some other part of the project you can spend time on that you know will work. Wasting hours on a stuck pig is frustrating, spending those hours instead making other progress let’s you simmer on the issue.
Come back to it later with fresh eyes, and maybe it will be easier. If you hit the same wall after many attempts, maybe you have to find a different solution, and at least you got a ton of other stuff done.
The sunk cost fallacy is a lot worse when you’ve spend multiple sessions on the same issue.
It also helps when you can identify these problems early in the project cycle. Knowing what parts will work because you’ve done it before, versus new modules you haven’t worked with, helps to plan testing of the unknowns early, even if they are used later in the project.
On large scale projects, I make sure to prototype the unknowns right at the beginning, and when I get stuck, I do easy work till I feel relaxed again. If I don’t solve the first one, move on to the next, and next, unknown till I’ve been through each at least oonce. Then you’ll have a road map of what works, and what’s going to take the hard, head down, jam music on, I’m not stopping to piss till this works or I abandon it, sessions.
Then I know there are X number of those sessions in the project, and when I’m in that kind of mood, I tackle one. Some days you just want to bang out easy UI and functions, others you’re ready to beat your head on the keyboard till that one thing works.
Other than that, I write a lot of test code around the problem so I can isolate exactly what where is. Then once it’s fixed, I go back and strip it all out. Don’t be afraid of spending time really understanding the issue before just doing brute force. In your example, if a module doesn’t do what is expected, are you sure your connected to the module? Are the commands formatted correctly? Do you get any response from it or is it just dead or not loading? Can you write around it? Are there other modules available? Can you write your own code instead of using the module?
At the end of the day, what you said is right, step away and clear your head. I can’t count the number of times I’ve come back to something I strained at for hours or days, only to solve it in 15 minutes a week later.
Diet, exercise, plenty of sleep (what’s that, lol), and just keep at it when you are tired. It’s not meditative, it’s work though it can be exciting. I guess if you haven’t been at it for very long, it will get easier as you become more fluent. The code will flow off your fingertips (some of the time) without your having to think as hard. Of course that is also the part that AI might already be automating.
