When I started at my first company, they had a very complex VB application running on dozens of …

This is amazing. I can so well imagine a bright young hire joining that team, helpfully offering to "setup this thing called git" only to be laughed out of the meeting by all the "senior" staff.

> There was a LOT of global variables (seemingly random 4 uppercase letters) controlling everything. I once ran across a (c) program that had 26 variables, each one letter long, one for each letter of the alphabet. They were all global variables. And many of them were re-used for completely unrelated things.

This is nightmare-fuel. How does this happen? As a glib answer, can I suggest, that without proper training, there were a lot of developers who had never trained under anyone or any company with proper practices?? Honest question. How does our profession root out intrinsically obvious bad practices?

My first role was with a company who had hit a limit for VB6 variable names iirc. So they'd all been renamed to shorter names. This may be the same issue. They were in the process of rewriting in VB.net.

> with some still having bugs fixed years before for others Hopefully they won't discover at some point that customers were in fact depending on those bugs. That's poison for the programmer's soul.

There is "do things that don't scale" and the there is bending over backward to do things in the dumbest possible way. Not sure where this lands.

> At some point, the application had some bugs which were not appearing when the application was run in debug mode in Visual Studio. The solution was obvious: installing Visual Studio for each customer on site and teaching the users to run the app in debug mode from Visual Studio. Holy smoke! That's actually the most creative solution (horrible, but creative) I've ever heard to fix a Heisenbug: https://en.wikipedia.org/wiki/Heisenbug

As much as this stuff is nuts to think of today and there's tons to hate, I am kinda nostalgic for some aspects of my experience of working at a place where software is maybe needed and/or valued but isn't a core competency. Or maybe a time when software was a new fangled thing that hadn't fully been integrated into corporate structure yet: - No one having any preconception of how you're /supposed to/ do things or whether you'd even be the type of person to know, so you just kinda figure it out yourself. You spend a lot of time on reading and learning skills. Version control? Wow, cool, what's git, let's try that! A new graphing library? Let's give that a shot, maybe it'll make things easier! You want XYZ? Let me go read about that for a day. - No one having any idea what's even possible: being treated like a wizard for introducing the tiniest piece of automation or improvement that make…