> Complexity-related Learned Helplessness
I've gotten used to just accepting that every job I have will involve a code base that uses up way too much memory to run in a debugger and doesn't have (or allow for) unit tests.
I've gotten used to just accepting that every job I have will involve a code base that uses up way too much memory to run in a debugger and doesn't have (or allow for) unit tests.
But when I'm called upon to work entirely without tests, or with inadequate backups, or otherwise in ways that create a scenario where every keystroke I make holds imminent potential for disaster, I quit. I can do trapeze acrobatics if you let me use a net. If you insist that I must not use a net, I'm not willing to live with that constant stress.
Most of the projects/companies/teams I've worked on didn't have tests, adequate backups or had scenarios where errant keystrokes blow up production but it's nothing that has been world-stopping and these jobs rarely involved anything were downtime equated to real harm (outside of the economics of the companies themselves, but usually nobody necessarily cared as long as things got fixed).
Companies that subscribe to YOLO-level development usually already _know_ that and with it, comes a certain understanding that shit will break, it's just minimizing the blast radius by learning/knowing the code bases and leaning on those with more experience.
Well then you're talking about a completely different scenario than I am.
To maybe put it into examples:
World stopping: Traffic collision avoidance system (TCAS) has a bug that lets planes crash into each other.
Don't care: Not enough vegetarian meals made it onto the plane because of a bug in the meal reservation software.
In between: Thousands upon thousands of people get stranded in some airport for 3 days because of a bug in the route planning software.
most of healthcare software (that i have worked with) is really, really bad.
The fact that it mostly has no tests, or if it has tests they mainly test just the happy route.
They usually have lots of documentation, but it's not comprehensive and mostly just describes the happy paths, so when thing break you are out of luck. Also can't google anything since this are all closed source enterprise type software, so you are at the mercy of their support, that often also sucks.
And if you have to integrate with it, you often can't get the documentation, or tools to do it unless you are working for one of their VARs. And the VAR's are often even worse.
If you pick random 10 high school kids, get them into some code academy for a 6 months, and then have them develop an application, the ones that finish will probably be better than majority of health care software out there (for simple reason that they won't know enough to really screw up as bad.).
The only saving grace is, that its often written in Java so you can find workarounds in runtime (or inject stuff) if you really need to.
(I'm also against this "YOLO because it's fun" attitude, though.)
Oh yeah, we had unit tests all right, fragility didn't prevent that since you couldn't commit otherwise.
So there was no safety net. Just a constant dread of customers actually using the feature. So "fast-and-fragile development" resulted in a worst-case scenario as far as engineers were concerned.
The author says : "Their reports won’t tell the manager that they are having a terrible on-call experience". This was exactly what happened to me. And I quit one day, this was a big factor, two weeks out of a month (in my rotation) I'd be on the hook for supporting this morass of problems.
Moving safer takes up a lot of, imo, unnecessary time with dubious payoffs. I'd personally rather live on the side of YOLO and ship a lot then hem/haw over getting certain % unit test coverage (and the maintenance costs that come with that in the face of uncertain requirements).
I did that early on. Then again, because the next place was the same. Then again, because the next place was the same. 10 places later, I finally realized they're all the same.