The video is meant to be in the same vein as the You Suck at Photoshop videos. https://www.youtube.com/watch?v=0nbkaYsR94c
being handed someone else's excel sheet is an infuriating experience because they're also handing you whatever convoluted mental model they used
The guy who took over for me had a nervous breakdown.
So if someone is good at exce you can easily understand what they're doing and why they did it
It can absolutely be said for Software Engineers. It just can't be said of every Software Engineering Org.
A lot of it is just high level stylistic suggestions, sort of like the Python style guide, though some are more specific
The strangest one I remember is: when you are summing a column, put one row in between the cell with the sum and the bottom-most number to be summed. Change the row height to something like 10% of normal cell height and in the cell in the new row, right above the cell with the sum, add a set of dashes (-------).
I don't remember why we were told to do this but definitely remember doing it, and in my next job people laughing at that habit. I think that it ensures that, when you add a new row to the column to be summed, that your sum formula automatically picks up the new row
You definitely have a lot of moments similar to reviewing others' code where you go "Hmmm, this doesn't seem to make sense. Am I missing something? Or did they just do this flat out wrong?" Often the answer was "yes."
There's also a radical spectrum of Excel skills (much like coding). I took a 50MB Excel report that took hours to update manually and brought it down to <1MB that refreshed when you clicked a button via web queries. There were significant savings for the agency as a result as that had to be updated weekly, simply from cleaning up a spreadsheet.
Whenever possible now, if I suspect a spreadsheet tool or report I've built is too complex to grok just by quick perusal of some formulas and clear naming conventions, I document the hell out of it in a separate sheet or our knowledgebase. The pain of deciphering those things is real, and I would never wish it on anyone.
Just like Zed Shaw's LPTHW tells you to type in the code from the book, and not copy-paste.
Some of them would use our software to print various reports and then manually enter those printed values in to excel.
Even worse, the software could export to a format excel could process so it wasn't necessary in the first place.
Don't expect to be disrupting banking anytime soon though. Banks are incredibly risk averse, especially when it comes to messing with expensive legacy software that has been working for decades.
At one point, one of the company's customers did an investigation to see how much it would cost to replace the software, and it was close to 9 figures, and so they decided it was more cost effective just to continue paying the multi-million dollar yearly licenses.
A bank I've worked at had a project to replace lots of bank's legacy (Mainframes and Cobol) with Java on Linux. The project's budget was over 1 billion dollars and it was estimated to take 5 years.
Both attempts cost millions, both were abandoned.
The lessons (and pain) from the first attempt were ignored because not enough of the upper management were still around, and the only people who remembered the pain were the rank and file, who were ignored by the new upper management types looking to leave their mark on the product.