For further actions, you may consider blocking this person and/or reporting abuse
Read next
10 Must-Know Tips for New Web Developers Entering the Backend World
Ayush Kumar Vishwakarma -
Top 20+ Full-stack Projects For Beginners in C#, ASP.NET , .NET CORE
Sapana Pal -
Modify the local bolt.new interface to allow input of the API key
M Sea Bass -
Write a program to EMI calculator
Lakshmi Pritha Nadesan -
Top comments (60)
Probably a whole 9-hr work day and some change.
I was tasked with creating some Ansible configs for these build agents. The machines being spun up from them were identical, but spread across 3 different networks: A, B, and C. The big difference was one zip. A and B got it from shared drives, but C pulled it from our Artifactory. I was told that the one in Artifactory was the same from both A and B.
A and B were fine but machines on C were failing. I figured it was the zip, and it was...but it took the whole day and 2 30-minute Zoom meetings with different folks.
The problem? Well all 3 zips had the same name: Dir_X.Y.Z_14.0 but
A single-character typo brought me to my knees lol. Someone renamed the directory to have a hyphen, but the zip they created still had an underscore, lol. Ahh good times.
If I ever get to 3 hours staring at the same bug, I generally get up and go for a walk or get some other eyes on it, or try to tackle a different task and come back to the bug later.
Maybe not related, but definitely have had long stretches where a certain bug is 'fixed' only to pop up again a week down the line...
^this
The most I've worked uninterrupted on the same bug is probably around a week. It was one of the worst bug I'd faced too : Some of our clients data would get randomly deleted for no reason and noone had any idea what was happening. I spent days trying to debug every single API trying to determine what could do that...
I eventually ended up parsing the mysql binlog searching for every delete statement on that table, searching where it came from in our codebase, and rerunning them one by one...
Turns out someone had forgotten some parentheses in an 'OR' condition months before.
I spent several weeks trying to figure out why images from Windows Snipping Tool could not paste into Quill WYSIWYG and then a couple more weeks trying to fix it and work with other kinds of text and image pastes. I even wrote an issue for it that's still open! I've changed jobs 3 times since I wrote this and now I'm back to using it again in my current work project.
A paste event is detected, but the images never show when you try to copy and paste images from things Windows Snipping Tool. Copying and pasting images from Google, for example, has no issues.
It seems like there is a timing issue for reading files with a base64. I have not been able to reproduce a "fix" I discovered in CodePen, but in the actual project I'm using Quill for, extending the Clipboard module and lengthening the timeout duration at the end of the default
onPastefunction makes pasting from Snipping Tool work. The bigger the image that needs to be pasted, the larger the duration needs to be.Again, I am not able to reproduce a bug caused by my "fix", but in my project, lengthening the timeout duration causes two "regular" images to be pasted. I'm throwing this part out there in case it comes up for anyone else. It may be something in my project.
Steps for Reproduction
Expected behavior: All image pasting should behave consistently.
Actual behavior: Cannot paste images from snipping tools.
Platforms: Windows 10 (I have not tested this on others yet) Chrome 72
Version: My project uses 1.3.4, but the issue persists in 1.3.6. The CodePen is using 1.3.4.
3 months, not non-stop obviously, but I continuously went back and tried multiples things multiple times. Even did a 100% full on re-install of the operating system.
The issue? Bad vim-airline fonts on my Raspberry Pi.
The solution? Run a command to update the firmware of the Raspberry Pi.
Can't remember precicely how long but probably 1/2 month to one month, it was a dotnet "thread starvation" issue, where it was just running out of threads to run operations. Had a lot of false flags and a lot of debugging to find the actual issue. I hope to never see that error again vietnam flash back
It was very-very long time ago, in the late 90's.
I wrote a little game in Watcom C (somewhere between Wolfenstein and Doom, only walls and simple floor, but with not only perpendicular walls). Trigonometric functions were very expensive, so I used a generated sin table. I copy-pasted it into the source, but it looked ugly, so I lined it up with leading zeros. It was a mistake, because 0****** number are octal in C, so very strange things started to happen on the screen. It took a few hours to debug this and after that I was literally banging my head into the desk.
Unfortunately, I spend once, 3 months on a single bug. It was very long and I got desperate about it.
It was with a teleoperation application with a universal robot. The robot demo worked correctly in our office but not when the commercial did the demo at UR. For some reason, one demo was working, not the other we didn't seem to have any communication between the robots. Well, the second demo was working for 2 to 3 minutes and then both robots stopped, and stay blocked. It took a very long time to solve this, because we didn't have the setup to reproduce the bug in our office and I was not in a good health condition too.
Finally, the problem was from our robot dll library. They were an update, I was not aware of, between both demos. A colleague decided that a division by 2, which was not documented, was not "supposed" to be necessary. So he had removed it from the real-time library without further notice and pushed it in production. The result was that communication between both robots was not running at the correct speed. It was 2 times slower, therefore the teleoperation was not possible. Several months later, the bug is still in production, because "it was not the problem". Well it solves mine actually and I had figures to prove it.
This happened some time ago, I am not in this company anymore.
I tend to be the sort to leave something and come back to it in a week, especially for intermittent issues that are hard to reproduce.
Though I did get a fun text the other day "why does this test not work in IE?" from my last job's devs... 1. because I stopped trying to do a hack to fix it and 2. because <linked them to the IEDriver GitHub issue where Selenium said making IE work was so low priority that they didn't care typing was broken>
Technically I probably spent 4 years with those tests working in IE barely half the time because of timing around typing. I solved it by getting a new job :P
3 days. I neglected to filter NASA API results on the backend, so when Curiosity took 14,000 photos of Mars on one day it crashed my site lol. I was new to Python/Flask so it took me a while to figure out-- it was as simple as using a limit method!