How do you not get so exhausted while programming?

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.

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.

https://youtu.be/OGKPmBtBpBo

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!

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.

I have a tea addiction which ensures that at least once an hour I stand up and leave the keyboard for 10 mins. Pee, collect tea, back to work.

Sometimes however, when I'm stuck on a bug I have no idea how to solve I can sometimes lose track of time and maybe don't take a break when I should...but never for longer than 2hrs.

If I've been working on a problem for 8hrs I go to sleep. Invariably I solve it quite quickly the following day.

Obviously the thing to learn here is: stop working on it before 8hrs hits....but I'm a simple man who apparently can't see this at the time.

Not a programmer, but I do understand the basic principle you're discussing and have experienced it with other things.

First off, your mental endurance will grow stronger with exercise. It's important to make sure you're taking care of your biological necessities, it's extremely easy for me to forget to eat, for instance. But so long as you're giving yourself the calories, water and oxygen necessary, you should be able to strengthen your ability to operate in that crunch mode. The key here is to absolutely force yourself to handle those biological necessities. If you find yourself holding your breath, exercise your full willpower to make yourself stop, lean back, and resume breathing normally. Get some calories and fluids as necessary. This can eventually be made a habit, but you absolutely have to brute force that habit into being.

Second, when that exhaustion is beginning to look more likely, you have to similarly force a break. In my case it's important to physically remove myself from the stimulus, I can't just sit at the same desk. I have to get up and walk away. My brain will still churn on the problem for a bit, but it eventually slides it to more of a back burner position since it can only get so far without actually trying things out, and this "giving up" is exactly what I'm looking for. Once on that back burner, you can give some time to let your forebrain "cool off" a little bit. Going for a brisk walk would be a good way to go about this. Music could work. Some short videos could work. A quick chat with someone could work. Lots of possibilities. None of it will be pleasant until the brain gives up, though, and in my case that just requires enough time to pass that it runs out of ways to advance without me returning to my desk and testing something.

You may note, the key thread between the two is willpower. There is no way I know of around having to simply brute force the decision with my own conscious mind sometimes, because I won't want to stop. But I do other things I don't want to do too, so this is no different. Sub-brain will obey forebrain, I am not offering any choices or debate on the issue. We are standing up now and the feet are walking, the decision is final, now stfu. lol

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.

i think i agree with everyone here

i would go further and when you're tackling a problem that is not making progress, leave it until the next day and work on something else. let your brain release and feel some progress and come back to it with full energy (and most likely a totally new perspective) the next day

I'm not a programmer but I've done QA professionally so I'm kind of on the other side where my main focus has been in finding the bugs

Maybe I'm focusing in a little too much on the particulars of your description of googling, trying something, googling more, trying something else? But it kind of sounds to me like you could benefit from digging into the issue more methodically.

Usually when something doesn't work as expected, it means one of our assumptions is wrong. So other than documentation I would say resist the urge to go to Google at first. Walk yourself through the relevant code and methodically figure out what assumptions you're making about it. And then cross-check with the documentation to see whether there are any special cases where those assumptions are wrong, or maybe you just subtly misunderstand something and don't know about it yet. I would guess that if you primarily work in only one or two languages, that doing this will help strengthen your fundamentals in that language.

Hope this helps

I don’t really program anymore but I do manage a group that includes programmers. In college, my professor said the gig is 99% pulling out your hair but living for that 1% when you solve it.

I find myself bored and paranoid when things are going smooth so I don’t think I ever felt bored when debugging.

There are times when I’ve focused on something for too long and go without eating or drinking so I had to pull myself away.

The only advice I can give is just the general good life advice of eat well, sleep well, and stay active.

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.

For me remembering myself to take a step back often helps. Most of the time I am too focused on the problem at hand and overlook something I would recognize with some distance.

Try to view the problem from another angle. If you can, try to observe how your colleagues tackle these kind of problems. For me it helped to expand my "toolbox". Having options makes me feel more in control, reducing stress and tunnel vision.

Of course this does not always work. Take your time to improve, allow yourself making mistakes and, most importantly, be nice to yourself.

I have a rule regarding what packages I allow myself to use. I must be able to re-write whatever functionality I’m using in the package. That way when it doesn’t work as expected, I either write my own, or debug their code.

I've experienced that nagging feeling of needing to fix that issue and endlessly searching for an answer. And you've answered your own question: taking a break might be the best solution. But obviously it is frustrating to stop yourself once you're "down the rabbit hole". I've never worked in dev team but this might be your answer when you start working professionally. Asking help from your colleagues might be less frustrating than pacing yourself on your own.

Been at this a while and have plenty of scars. Some tips:

• Start every day with 2-3 goals. Like, implementing a feature, or knocking off the top 3 bugs off your list. They should be reasonable goals that can be finished in one day.

• Resist feature-creep. No 'one more thing.' Write down the idea and 'backlog' it. There's a good chance it's a great idea, but will never be built. Move on.

• Think of a day as a 'runway.' The fewer meetings and distractions, the longer the runway where you can concentrate. Turn off notifications and social media. Move all meetings to specific days. Those are productivity sinks. If absolutely required, push meetings to the extreme ends of the day. Or just do triage and say no to bullshit 'status checks.' Send an email. The longer the runways, the more ambitious things you can try that day to feel good about.

• At the end of the day, go back and revisit the goals. Did you get them done? Mark them off your list. Instant dopamine hit.

• On days when things are going great, finish what you were doing. Take a break, then see if there's something simple you can tackle.

• Important: end EVERY day at a good stopping point, then stop thinking about it all. Go do something to disengage.

• Some days, you can't get everything done. Be nice to yourself and tick off what has been done. Anything left goes into tomorrow's bin.

• If easily distracted, use a Pomodoro 'egg' timer (physical or digital) to work in bursts. Use breaks for stretches, bathroom breaks, hydrating, meals, exercise, etc.

• Some days, the juice doesn't flow. These are good days for doing easy stuff, like tweaking layout, graphics, updating tooling, or writing docs. Things that don't require active problem-solving.

• Other days, even THAT doesn't feel good. It took me years to be able to tell. I'd try to push through, and the output was always crap. These are 'mental health' days. Just stop torturing yourself. Avoid meetings. Take time off and go for a walk, bike, or drive. Get shopping done. Go see a movie. My favorite is to go to a museum or tackle a home repair project. Give your brain a day off.

• If working with a team or on a deadline, plan ahead on having one of these every two weeks or so. Best way to avoid burnout and have something to look forward to.

• If you hit an intractable bug, don't be afraid to step back and do 'mini' tests to isolate the problem. I once lost 5 whole days on something that had been working fine for months. Then one day, it just stopped working. By Day 4, I was miserable and ready to change careers. Day 5, I restarted with a minimal version from scratch. Made sure it worked. Built confidence. Then slowly added back features one at a time. Finally, had an 'aha!' moment. The next day felt amazing! Zoomed ahead and made up for all the lost time.

• Revisit your list once a week, and make up what you want to get done by end of following week. Break it up into mini-tasks and leave them for yourself to pick up Monday morning. Think back to what worked for you and what didn't.

• If working with a team, also a good time to do 'show-n-tells.' Focus on positive feedback.

• Rinse. Repeat.

• Lastly: when you hit a major milestone or release something, remember to celebrate. Go to a favorite restaurant, sip a glass of expensive whiskey (if into that sort of thing), or do a special dance. Take a victory lap and treat yourself. If working in a group, make sure you do it all together. Then take a day off and come back refreshed, ready to kick ass.