Finally, the last bit of this sorry tale.
Part III:

The single "IT" guy didn't put UPS on anything so when the power failed all the servers just carried on running until they died. Bye bye Dell servers.

The computers were locked down because one user ran an EXE and it encrypted everything on his machine. All network activity was logged. All work was recorded on an internally written "log" system that also monitored mailboxes so any email sent that included a log number ended up automatically on the internal log system. This meant a few occasions of people complaining about others ending up on a log. Any work you did involved "clicking onto a log" but then if you didn't do this you'd get a Skype message from a "manager" asking why you weren't "clicked onto a log". The internal log system was written in ASP and used SQL Server but used a lot of SQL functions and was next to impossible to debug because it was hosted on an IIS server that was in use. There was no test server. The main database was 200 GB or something like that so you just had to work against this live database.

All of the software was 32 bit and had about 150 DLLs along with some OCX. The use of COM and ActiveX everywhere by junior developers meant they got the AddRef/ReleaseRef stuff wrong and you'd get leaks everywhere. Installation of the software (it was just a desktop app that talked directly via ODBC to a database) involved about 30 manual steps - there was no installer. It put some of the DLLs into the System32 directory and installed CPL applets for Control Panel so was very firmly stuck in 1996. Customers actually had to pay for the single "IT" guy to install the software.

The build ran daily (and/or whenever anyone checked in code using TeamSource in Visual Studio) and they pushed out software to users using an appalling C# web service / utility system one guy had written. It was spaghetti and objects made calls into other classes and changed their members. The guy eventually faked his own car crash and just disappeared from work, never to return. The code of his that I inherited was appalling.

The build ran an ANSI and a Unicode build, even though they actually were still just distributing the ANSI build.... You had to wrap all of your strings in _T wrappers and make sure you used the appropriate typedef for wide or narrow characters. You didn't have time to build the entire thing to test it worked in both, so tested in one and checked in and then got berated when you "broke the build" that automatically ran in Unicode/ANSI when you checked in. It sent out an email to everyone detailing the last check in and who it was.

The web service that served the data relied on a secondary document service that silently failed for years when serving documents to customers, but nobody noticed. Not even the customers. They wouldn't be receiving files and nobody had noticed for about a decade. I once fixed this but it meant the secondary distribution service now got an exception when it asked for something that didn't exist, so was told I couldn't go home until it was fixed.

They employed a team of people to help "manage" (I guess?) whose sole job was to pester you on Skype and add events to your calendar for when you'd have a meeting with your boss (the senior developer). You would have a meeting with the developer and this other person would be on the call but would say and do NOTHING. They wouldn't even make notes. I honestly have no idea what their job was.

The software was also incredibly incredibly ugly. It also used Crystal Reports for its "report" system which was a steaming pile of buggy C# that threw exceptions in its own libraries all of the time, and would take 30 seconds per report to interrogate the database to see what format the fields were. You could have written your own PDF-writing report system in a month (since most reports only used 1 or 2 queries), and wrapped it in a PDF.js web view and that would have performed 10000% better than the absolute crud Crystal Reports but no, that wasn't important. The guy that wrapped the Crystal Reports library in a "viewer" window was also the same guy that faked his own car crash... He would run a background thread and then update the UI from the background thread and say that it sometimes seemed very slow or would appear to hang.... you think so?!?! Duh!

It was a horrendous job. I enjoyed the C++ side of it but not the 20 years worth of overly-complicated code (loading/saving from/to a database doesn't need such complexity) and obsession with COM and MFC was horrible. I didn't like the toxic culture (witch hunt people when they get it wrong rather than train them) nor the obsessive micromanaging. The company was a great study into fomenting a bonkers environment where people worshipped "the build", feared the bosses, and had become so used to the ridiculous software that they didn't even see how stupid typing numbers into a grid to change behaviour was in 2017 or whenever it was.

I didn't enjoy getting shouted and sworn at. I left and worked fewer days elsewhere. I believe the company is still doing well (they made enough money from licences and writing custom extensions that everybody inherited, so all customers got a really really really complicated piece of software that did way more than they needed, and slowly at that) but I believe it's circling the drain because of the baggage of its design and COM architecture. C++ good, COM bad.