- cross-posted to:
- programmerhumor@lemmy.ml
- cross-posted to:
- programmerhumor@lemmy.ml
More like:
11:00 in the evening: it’s a simple bug, I can fix it in a few minutes
9:00 in the morning:
After 5PM stop looking for a fix, start looking for a stopping point and write up some notes to review when you’re fresh again.
No. I’ve almost got it.
Just one more line bro. One more line will fix it.
Line of code… right?
Is that what we’re calling coke these days?
After 5PM stop looking for a fix, start looking for a stopping point and write up some notes to review when you’re fresh again.
Hot Take Incomming…
No. My best successes were when I stayed on point and pushed through the fatigue and solved the problem. Taking a ‘go to bed and come back to the office fresh’ type of break would inevitably set me back, as I would have to pick up my train of thought again, to get back “into the zone” of the problem and solving it. Its another form of an interruption while you are trying to concentrate, and can interrupt an ‘Eureka!’ moment in problem solving.
It truly sucks having to work the extra hours, and if the project management is so bad that you’re doing it all the time, then you need to find other work, but sometimes, ‘sticking it out’ is the solution to the problem, finishing what you started.
Having said that, if I’ve pushed through the fatigue multiple times in multiple hours, so that its super hard to push again, THEN that would be the point where I walk away from the problem for the evening. Its not an either/or thing, but its definately stick around and try to solve longer than the advice I’m replying to would suggest.
One last thing. The above advice was given by someone who spent most of their career self-employeed and working an hourly rate. You’re expected to solve the problems others can’t because you’re getting paid more, and your time is compensated accordingly to the amount of work you are putting in. If you are a salaried employee, especially one who is low paid, I would then advise you to consider other things than strict professionalism, like QoL issues vs compensation gained, etc.
Not sure why this is being downvoted. My main takeaway is just that while taking a break works for a lot of people a lot of the time, for this person sometimes it doesn’t.
People are different and sometimes if you are new to something, it’s helpful to see both the popular advice (take a break) and that it might not always work for some people (this poster).
I don’t code, but I do work with a lot of really shitty proprietary software. The amount of time vendors haven’t been able to fix their own shit is so high. Spent 6 hours on the phone once. Work 2.5 hours overtime for that call.
In that case though, the person helping you doesn’t have the ability to solve the problem by changing code. They have to work around the bug to try to make it work for you in its broken state and report the problem to developers to fix in the next release. It’s a more difficult problem to solve
The fun part about this is that every time I’ve had to call a vendor about proprietary software, the techs helping me ARE the devs. 💀
17:30 - This is a tomorrow/next week problem
The rules to remember when this is happening but before it gets that bad:
- remember your own advice
- have you tried turning it off and on again?
- have you explained the issue to the ducky?
- have you eaten?
Rule 1 is the hardest tho
And the official solution to this problem in the documentation is a library deprecated four versions of the framework and/or programming language ago.
Ahhh just entering the phase where the bug is fixed, but everything else is broken.
Usually it’s just one character that’s wrong
Bonus points if it’s failing because you spelled it right and the preexisting is misspelled.