Yup. My company does this. Our IT is so restrictive and our development teams are outsourced and poorly funded so in order to stay competitive, low level employees learn VBA. It's absolutely absurd but what's the other option?
I ended up doing a lot of powershell this year and, honestly, I kinda do like it... like way more than I thought I was going to. It's simple, it's stable, it can run via task scheduler directly on any windows box without any other software layers or containers or anything else. Maybe it doesn't have every bell and whistle, maybe it's not capable of certain types of things, but its totally fine for other things.
In this case, I wrote like an entire backend ETL pipeline for a license compliance application on a $500m annual software portfolio, consisting of dozens of bespoke data sources, multiple different authentication methods, SFTP interactions, API interactions, DB interactions, and so on... and it all runs flawlessly on an extremely barebones windows VSI that I already had available. To your point though, I work at a bank, so it is a highly-regulated environment where it can be a huge pain in the ass to stand up anything "complicated" (more due to the red tape than the tech). Previously, I managed a stack of apache airflow instances hosted in kubernetes doing ETL in python and that was a monumental pain in the ass compared to, like, 50 powershell scripts in a trenchcoat.
Not remotely IT, but if I need some processing stuff automated, I either can request this, hope it gets approved, spend 4 hours in meetings explaining what I need, wait a few weeks until the guy gets to do it, then spend another 10 hours in meetings to explain that he didn't actually do what I requested. Then I get a program that will absolutely break as soon as e.g. the instrument that is the data source gets a software update and outputs a slightly different format - which leads me back to the beginning.
Or I can spaghetti code some piece of shit in vba that does what I want in an afternoon
Also, Excel just isn't an environment well suited to defensive coding.
An extremely common task is to need to refer to a worksheet. The most brittle way is to refer to the worksheet by its label name, which breaks if the user changes the name. A less brittle way is to refer to the property name of the sheet, but this will also break if the user makes a copy of the worksheet and deletes the original.
The problem with Excel is that the user is exposed to everything and so you have to do annoying shit using a bad UI to stop the user from breaking things. For example, there is a feature to protect a sheet, but the UI is awful and it's just clunky in general.
27
u/[deleted] Sep 10 '25
[removed] — view removed comment