Earlier quoted context omitted.
ok, let's go back to 2014. I was working on a project, a web front end. The ticket was "change color of button". This sounded easy, modify the CSS. However, the CSS was generated. From YAML. The YAML was generated from JSON. the JSON was pulled from mongo. The Mongo was updated through a strictly validated XSLT that had an enumeration of colors. Those colors did not include the button color we needed. Don't worry! Th…
That sounds complicated. Though I'm not sure if this is a valid example to counter my view. I can't comment on the exact situation you went through. It could be that that complexity was a side effect of having to solve far more complex and frequent issues more easily as opposed to doing simpler and rarer things more easily (unless of course changing button colours is a frequent modification). It's also possible that…
That's the whole point. What some people consider to be "good engineering" is a different set of standards, a different set of qualifiers.
Let's go back to 2012. I was yet again doing web stuff.
We had this hodgepodge of jasmine, junit, eslint and selenium and couldn't commit unless it all passed
But the tests broke more then the code itself, because it was . So more time was spent on fixing and babysitting the tests then writing the damn software.
Alas, we finally released and it totally completely bombed. Why?
Because those test suites don't care if something "feels" clunky or "looks" wrong ...The machine responded to the interface in machine time, it didn't actually test human time, which was the only thing that mattered. We should have relied on human dogfooding, like the business books say to do. I got arrogantly laughed at for suggesting it, multiple times; that simply wasn't "engineering" to this team.
Now of course tests are valuable, sometimes. But "sometimes", that's the important thing. Understanding when to make that call is actually important. When, where, what, why, and how - not just important for journalists.
But instead, like some 18th century royal court disconnected from reality, we did ceremony. So we wrote tests, most of them bullshit. One of the tests was essentially: "Does this image on the page load from s3?"
At least that one usually passed.
Except when AWS was down or our internet went out: "I guess we can't work today, the does_image_load_from_s3 test is preventing the commit." They were a waste of time and got in the way of actual work. But we HAD to have them, we MUST, right? Nonsense.
I'm convinced the tests were there because "doing it right" was about virtue signaling. So we built a salary defending potempkin village composed of pure thought stuff.
I imagine it all like a catholic mass: Men in robes walk around, ring bells, and use special boxes to wash their hands with special cloths; it's all very important if you go to church, but that's the point, it's praxis and faith: we were coding from plato's cave, creating intricate shadows of reality representing actual work.
Symbols passing as tools: like Dumbo fetishizing the feather and being oh so worried when it falls, everything passed the most sophisticated testing I had ever seen yet the program still crashed in the user's hands almost every time. All that work was mere ceremony.
Understanding how modern computing speeds and vc capital has allowed people to be wrapped up in their own bullshit, call it programming and get away with it, is a major insight into why technology sucks today.
It's not just you, everyone agrees. It's lame now.