4 ms·

I didn't quite understand why they had to debug on the spot, thus working like 36 hours uninterrupted or so. A sane working environment would file a priority 0

I didn't quite understand why they had to debug on the spot, thus working like 36 hours uninterrupted or so. A sane working environment would file a priority 0 bug and address it during working hours. I'm not throwing a rock but oftentimes this sort of heroic behavior is self-inflected. Also why is heroic debugging required on something that is not production? The article mentions it was a "quick demo". Then who gives a shit? There's time to investigate. And this would/should NEVER happen to production. The whole point of testing and staging/UAT environment is to catch this sort of problems. Again, a normal day at work in software engineering and not something to kill yourself living on amphetamine like a commando behind enemy lines in WW2.

peschu 3y ago
it‘s called „motivation“
- atoav 3y ago
  Jup, and if your employer doesn't stop you or even expects such behavior that is called a bad work culture. Sure, I would also do long programming sessions on my own things every now and then, but those happen because I am in the flow and it feels like more work to come back into it the other day. But those are my own projects. I don't owe this to my employer. If they want that they could offer me double my current salary and even then I would insist on only doing it when it makes sense to me.
  - number6 3y ago
    How would the employer know?
    - atoav 3y ago
      In my case my superior comes by in my office or sees I made a commit and tells me I should stop working (I tend to forget to look at the time if I am in a flow). But I also live in Europe and my superiors want me to come in with a fresh mind, instead of burning myself for things that should be normal work.
rezonant 3y ago
When you are not experienced on the platform you are building on, all debugging is heroic. It's really strange that they would invest all this time as if they are keen to understand the cause of why it happened, but then be satisfied when jiggling the handle solved it. The real cause ultimately is a process one (developer discipline) or a pipeline one (bad build/test/deployment processes). They got close to realizing it and then blamed the language instead of what appears to be bad practices happening on their dev team.
warkanlock 3y ago
OP here; thanks for reading everyone! While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things and then try to prove those, but it's just too hard to keep track of everything. In addition, we are using lock files and good practices but it's just too much to handle for our small team (small startup) so we will plan to migrate onto a more stable platform. It's really funny the heated arguments this post generated but I have been using Javascript for 12 years to these days, still this looks as a nightmare to me. Tsdoing has a good video trying to install React from scratch, that's exactly how I felt during this debugging process Another random story from this week: we have been using `nanoid` to generate IDs internally for an internal tool. Apparently, they did a breaking change release, and now you cannot use it anymore on commonJS env. See my point? where's the hypothesis we can make? It's hours and hours spent tinkering with code and other people's dependencies, and if, as you said, put a theory that theory won't match if you think how real systems work (the networking section on the blog post)
- MichaelRo 3y ago
  Well your reply still doesn't explain the administrative (not technical) reason why you had to spend some 36 hours uninterrupted hunting for this bug. Particularly since it was 'a demo' and what broke was 'PDF export', while other exports still worked. Hardly the end of the world if you ask me. Technically though, I have hardly met this dependency update problem with C++ simply because dependencies are rarely if ever updated. Android on the other hand was a nightmare. I had colleagues quitting in a rage and swearing to never again touch Android in their life. Probably half the effort was spent fixing crap that was broken by updated dependencies. Luckily I'm back to C++ now and hope never again will I have to touch such a crazy system. The whole 'update for the sake of update' seems to be a grave problem of the Android / Kotlin / Javascript universe. The mentality is like 'bread won't be sliced anymore, eggs won't hatch, sun won't rise if we don't absolutely have the latest bleeding edge alpha version of all libraries'.
- rezonant 3y ago

peschu 3y ago

it‘s called „motivation“

atoav 3y ago
Jup, and if your employer doesn't stop you or even expects such behavior that is called a bad work culture. Sure, I would also do long programming sessions on my own things every now and then, but those happen because I am in the flow and it feels like more work to come back into it the other day. But those are my own projects. I don't owe this to my employer. If they want that they could offer me double my current salary and even then I would insist on only doing it when it makes sense to me.
- number6 3y ago
  How would the employer know?
  - atoav 3y ago
    In my case my superior comes by in my office or sees I made a commit and tells me I should stop working (I tend to forget to look at the time if I am in a flow). But I also live in Europe and my superiors want me to come in with a fresh mind, instead of burning myself for things that should be normal work.

rezonant 3y ago

When you are not experienced on the platform you are building on, all debugging is heroic. It's really strange that they would invest all this time as if they are keen to understand the cause of why it happened, but then be satisfied when jiggling the handle solved it. The real cause ultimately is a process one (developer discipline) or a pipeline one (bad build/test/deployment processes). They got close to realizing it and then blamed the language instead of what appears to be bad practices happening on their dev team.

warkanlock 3y ago

OP here; thanks for reading everyone! While I agree with everything you have said, and it's been my motto since I read, "I'm sure you're joking, Mr. Feynman." The point of the post was to point out (maybe I did it wrongly) that those things you have described are pretty impossible given the ecosystem we have nowadays in Javascript (as a whole!). Of course, you can try to theorize and try to get a hypothesis on things and then try to prove those, but it's just too hard to keep track of everything. In addition, we are using lock files and good practices but it's just too much to handle for our small team (small startup) so we will plan to migrate onto a more stable platform. It's really funny the heated arguments this post generated but I have been using Javascript for 12 years to these days, still this looks as a nightmare to me. Tsdoing has a good video trying to install React from scratch, that's exactly how I felt during this debugging process Another random story from this week: we have been using `nanoid` to generate IDs internally for an internal tool. Apparently, they did a breaking change release, and now you cannot use it anymore on commonJS env. See my point? where's the hypothesis we can make? It's hours and hours spent tinkering with code and other people's dependencies, and if, as you said, put a theory that theory won't match if you think how real systems work (the networking section on the blog post)

MichaelRo 3y ago
Well your reply still doesn't explain the administrative (not technical) reason why you had to spend some 36 hours uninterrupted hunting for this bug. Particularly since it was 'a demo' and what broke was 'PDF export', while other exports still worked. Hardly the end of the world if you ask me. Technically though, I have hardly met this dependency update problem with C++ simply because dependencies are rarely if ever updated. Android on the other hand was a nightmare. I had colleagues quitting in a rage and swearing to never again touch Android in their life. Probably half the effort was spent fixing crap that was broken by updated dependencies. Luckily I'm back to C++ now and hope never again will I have to touch such a crazy system. The whole 'update for the sake of update' seems to be a grave problem of the Android / Kotlin / Javascript universe. The mentality is like 'bread won't be sliced anymore, eggs won't hatch, sun won't rise if we don't absolutely have the latest bleeding edge alpha version of all libraries'.
rezonant 3y ago