The thing that wasn't working was something the previous junior programmer made just before leaving the company, and it never really worked right. The junior programmer in the picture was trying to fix it without understanding how it worked and broke 3 other things, so he's been urgently trying to get all the things working together. The senior programmer doesn't care if it was fixed the best way because he knows the whole system should be redone but he'll be retiring before that happens.
Funny Comics
A space for sharing funny comics and cartoons.
Now we need to figure out how and why
You're missing the part where you try over and over again to replicate the result and it keep failing. Looks like the first time was the only time, too bad. Then, as you clean out the freezer six months later, you find a leftover vial from the experiment in the back that randomly formed perfect single crystals that you excitedly diffract only to be disappointed because despite everything it's somehow triphenylphosphine oxide because it's always triphenylphosphine oxide. Even though there was supposedly no phosphorus of any kind in the original experiment. Turns out, the undergrad intern has been double-dipping pipettes in your special personal cache of NaK-dried THF and cross-contaminated it, and that contaminant TPP stabilized your experiment---phosphine stabilization is well known, after all, which is why you were trying something new and different without phosphine to begin with. Oh well, sucks to be you, the undergrad graduated already and is gone.
And then you're a programmer who's also a scientist.
No, generally speaking. But sometimes yes.
I would say that myself and most programmers appreciate there is always some logical root cause for why things work or don't, and its very unsatisfying to have thigs work without knowing why. It's also problematic, because if you don't know why then it might break again in future and you can't fix it.
That said, programming is different from pure science. The explicit point of science is to uncover the truth and understand and make it replicable. The point of programming is to have a software product that functions.
So realistically we may as programmers occasionally let something slide without knowing the full detail, because we are working to different goals.
This is especially true based on the category/criticality.
Something "magically" starts working in the core backend payments API code? Not good enough, we need to know exactly what the cause was and cover it in tests.
Something "magically" fixes the UI bug that caused a weird but inconsequential margin padding that affected Samsung Galaxy S21 devices ONLY and no other phone? Hallelujah, it's a miracle.
Yup, I have two examples of "magical" fixes:
- removing a comment broke the build - probably not a thing anymore since compilers have improved
- manually creating components from a static list vs iterating fixed a render bug
I don't know why those work, and they're no longer necessary since their respective bugs have been resolved, but we absolutely didn't bother looking into them at the time.
Thanks for that detailed reply 😊😊.
I don't know how to make the best use of a GitHub account although l've created one. Can you please tell me how to use it for creating interesting projects ?
For example, for some reason Da Vinci studio doesn't work on Mx Linux. How to make this particular distro fit my requirement might be found in GitHub. But I don't know how to make the best use of the knowledge that is shared in this website.
The scary one is where you complete your code and give the test suite it's first full run.
...and it passes...
[Cue scary dramatic music]
Damn. Must have missed a test case, there's no way that was correct first time...
I can't find a source for this now, but this is the last part of the intro sequence of Doom 2016 (NSFW due to a dead guy, some blood, and earlier in the clip a lot more gore). After they got the sequence audio perfectly synced up for the console platforms and (I believe) the more popular graphics configurations at the time, the director said no one was to touch that part of the code at all, under any circumstances. It's not that they didn't have version control, it was just that it was so finicky that they didn't want to have to go through that trouble again. For reference, this is what it's like off-sync, with the shotgun lagging a bit behind the end.
Oh that shotgun timing. That is absolutely bliss, and it's so nice to have it sync like that
Don't you guys have version control systems?
This comic seems to be about bad programmers, so maybe they don't have version control 😬 When I'm working on something especially fiddly and I finally get the tests passing, I immediately make a git commit before even trying to clean it up. That way, I have a checkpoint I can return to if I accidentally break anything.
Instead of commit, i just stage them while I do clean ups. So that if I'm successful I stage the cleanup, else I remove the unstaged changes.
Through if you do local commit and amend it later it's not that different.
What is version control ?
coconut.jpg
I remember a while back seeing some commented segments of code from TF2 and one was about:
"I have no fucking idea who put this here, but when I deleted it the game wouldn't start. Words cannot describe my fucking confusion."
Referring to an image in the game files of just a coconut.
"Praise The Omnissiah!"
yes, absolutely