programming under stress
This is what happens when programming under stress... I pulled an all-nighter to force a major change and simplification of my code. The next day I got an assertion pop in my code. It took me 8 hours to find the bug:
I had:
instead of:
The static members actually initialize the first time, so my code passed my initial unit tests, and popped in an unknown place in the middle of nowhere.
This is what happens when you program under stress or great desire to do something quickly. I was so irritated when looking for this bug that I was hitting the wall and shouting at my computer.
The moral of the story, I guess, is that the frustration with one's too slow progress leads to stress. Stress leads to coding with not fully clear head (and in my case not sleeping enough). This leads in turn to bugs, which increase stress and cause one to stay even later, and look for the errors. This creates an evil cycle of frustration and lack of productivity.
Anyone had similar experience?
I had:
|
|
instead of:
|
|
The static members actually initialize the first time, so my code passed my initial unit tests, and popped in an unknown place in the middle of nowhere.
This is what happens when you program under stress or great desire to do something quickly. I was so irritated when looking for this bug that I was hitting the wall and shouting at my computer.
The moral of the story, I guess, is that the frustration with one's too slow progress leads to stress. Stress leads to coding with not fully clear head (and in my case not sleeping enough). This leads in turn to bugs, which increase stress and cause one to stay even later, and look for the errors. This creates an evil cycle of frustration and lack of productivity.
Anyone had similar experience?
Under those circumstances, the only thing you can do is pump yourself full of caffeine and hope for the best.
This isn't directly related to coding, but it's pretty close. I had already spent two days trying to fix a goddamn automated build process that was supposed to build my own program plus all of its dependencies (for a ~20k LOCs project, it has a shitload of dependencies, by the way). For no discernible reason, the same process I had already used for and tested on Linux stopped fully working. libjpeg would build and it would link to the rest, and one dependency would report using it. And yet, the jpeg just wasn't displaying. What was even more annoying was that the process did work on BSD.
For two days, I tried every possible combination of static and dynamic linking, which involved remaking the same 7z, burning it to an ISO image because I had no other way of passing files to the BSD VM, and building the project and its dependencies. Over and over and over again. On both Linux and BSD. Every iteration never took less than 20-30 minutes.
Nothing worked on both systems. As one example, statically linking everything worked on Linux, but broke on BSD. Statically linking some things worked on BSD, but put me back on square one because again libjpeg didn't work on Linux. At one point I even managed to break libpng and libtiff on BSD.
Today, I finally decided to test my initial configuration on a native Linux. And for fuck's sake, now DirectFB is giving me shit! I was starting to get a splitting headache after two hours or trying different configurations and linking to anything other than DirectFB before I realized I was logged in that particular shell as root from when I installed a library to try some unrelated thing out, and that was causing DirectFB to fail. I imagine I has something to do with a user not being able to send graphical output to a different user's screen. I wasn't even copying the binaries to the directory I had all my testing data because I left root where it was after I installed the library. I didn't notice all this partly because I had gotten used to building the project in session 1 and testing the build in session 2, on the virtual machines; and partly because of my ever-growing frustration.
Ugh. The headache is back.
This isn't directly related to coding, but it's pretty close. I had already spent two days trying to fix a goddamn automated build process that was supposed to build my own program plus all of its dependencies (for a ~20k LOCs project, it has a shitload of dependencies, by the way). For no discernible reason, the same process I had already used for and tested on Linux stopped fully working. libjpeg would build and it would link to the rest, and one dependency would report using it. And yet, the jpeg just wasn't displaying. What was even more annoying was that the process did work on BSD.
For two days, I tried every possible combination of static and dynamic linking, which involved remaking the same 7z, burning it to an ISO image because I had no other way of passing files to the BSD VM, and building the project and its dependencies. Over and over and over again. On both Linux and BSD. Every iteration never took less than 20-30 minutes.
Nothing worked on both systems. As one example, statically linking everything worked on Linux, but broke on BSD. Statically linking some things worked on BSD, but put me back on square one because again libjpeg didn't work on Linux. At one point I even managed to break libpng and libtiff on BSD.
Today, I finally decided to test my initial configuration on a native Linux. And for fuck's sake, now DirectFB is giving me shit! I was starting to get a splitting headache after two hours or trying different configurations and linking to anything other than DirectFB before I realized I was logged in that particular shell as root from when I installed a library to try some unrelated thing out, and that was causing DirectFB to fail. I imagine I has something to do with a user not being able to send graphical output to a different user's screen. I wasn't even copying the binaries to the directory I had all my testing data because I left root where it was after I installed the library. I didn't notice all this partly because I had gotten used to building the project in session 1 and testing the build in session 2, on the virtual machines; and partly because of my ever-growing frustration.
Ugh. The headache is back.
I once had to fix some fundamental flaws in the "client" side line discipline for a
serial-port based protocol. I decided that the best approach was to re-implement
the line discipline by copying a previous line discipline I had written years before and
making modifications as necessary. The other line discipline had survived the test of
time well and had a lot of debugging facilities, whereas I had just spent a week trying
to figure out what the current problem was (because there was no debugging facility).
The biggest difference between this new protocol and the previous one is that this
new one used parity errors as part of the client-side transmission (don't ask).
I spent all night trying to figure out why my line discipline would completely stop
working after reception of one command and transmission of one response. It didn't
make sense -- that code was completely unchanged from the previous line discipline.
Eventually, deadline approaching, I gave up and made a kludge in the old one to
work around the problem.
And then -- within a hour or so of the deadline -- it dawned on me. I was flipping
the parity to transmit the first response, but I was never flipping it back when the
transmission was complete. The parity affects the data being received, so I was
receiving what appeared to be data in which every byte had a parity error, and I
was thus discarding the data as bad.
Perhaps had I not stayed up all night, I would have gotten a good night's sleep and
still had time to discover and make the one line fix in my new line discipline the
following morning before the deadline...
serial-port based protocol. I decided that the best approach was to re-implement
the line discipline by copying a previous line discipline I had written years before and
making modifications as necessary. The other line discipline had survived the test of
time well and had a lot of debugging facilities, whereas I had just spent a week trying
to figure out what the current problem was (because there was no debugging facility).
The biggest difference between this new protocol and the previous one is that this
new one used parity errors as part of the client-side transmission (don't ask).
I spent all night trying to figure out why my line discipline would completely stop
working after reception of one command and transmission of one response. It didn't
make sense -- that code was completely unchanged from the previous line discipline.
Eventually, deadline approaching, I gave up and made a kludge in the old one to
work around the problem.
And then -- within a hour or so of the deadline -- it dawned on me. I was flipping
the parity to transmit the first response, but I was never flipping it back when the
transmission was complete. The parity affects the data being received, so I was
receiving what appeared to be data in which every byte had a parity error, and I
was thus discarding the data as bad.
Perhaps had I not stayed up all night, I would have gotten a good night's sleep and
still had time to discover and make the one line fix in my new line discipline the
following morning before the deadline...
@jsmith - That really would of sucked :( - I've kicked myself many of times over small things before a deadline. And as soon as you hand it in, you just go oh... thats what I did wrong.
This is what helios also does:
| helios wrote: |
|---|
| My job is so fucking unbelievable. I'll try to sum it up by first telling you about the folks I work with: First, there is this supermodel wanna-be chick. Yeah, okay, she is pretty hot, but damn is she completely useless. The girl is constantly fixing her hair or putting on makeup. She is extremely self-centered and has never once considered the needs or wants of anyone but herself. She is as dumb as a box of rocks, and I still find it surprising that she has enough brain power to continue to breathe. The next chick is completely the opposite. She might even be one of the smartest people on the planet. Her career opportunities are endless, and yet she is here with us. She is a zero on a scale of 1 to 10. I'm not sure she even showers, much less shaves her "womanly" parts. I think she might be a lesbian, because every time we drive by the hardware store, she moans like a cat in heat. But the jewel of the crowd has got to be the fucking stoner. And this guy is more than just your average pothead. In fact, he is baked before he comes to work, during work, and I'm sure after work. He probably hasn't been sober anytime in the last ten years, and he's only 22. He dresses like a beatnik throwback from the 1960's, and to make things worse, he brings his big fucking dog to work. Every fucking day I have to look at this huge Great Dane walk around half-stoned from the second-hand smoke. Hell, sometimes I even think it's trying to talk with its constant bellowing. Also, both of them are constantly hungry, requiring multiple stops to McDonald's and Burger King, every single fucking day. Anyway, I drive these fucktards around in my van and we solve mysteries and shit. |
AHAHAHAHHAAHAHAHAHHAAHAHAHAHHAAHAHAHAHHAAHAHAHAHHAAHAHAHAHHAAHAHAHAHHAAH
Woah didn't look how it spread it out like that. Sorry :D
Woah didn't look how it spread it out like that. Sorry :D
Last edited on
Topic archived. No new replies allowed.