Ask HN: Whats the worst job you've ever had?

Working at a company with 6 million+ lines of C++ COM code with an old UI (still in use) that was written in Delphi but was migrating to a new system (written using MFC....) with zero documentation other than a Wiki nobody updated, and 2 senior developers who weren't overly communicative and would be lumbered with fixing others' code because they didn't tell them how anything worked. Then the "junior" developers would leave because they kept getting berated for doing stuff wrong, and the cycle would start again with another developer who got the job. An eternal cycle of stressed, frustrated, bored (because they wouldn't be given interesting code to work on because they weren't trusted/"good" enough) developers, but 2 very busy senior developers.

The newer C++ code had a good idea in a function-based system for the UI but the functions were too generic and would accept parameters of any type, so a lot of the runtime code was working out if the object you were passed was of the right type. It was too flexible, and also meant the implementation team who would design the software for the users hadn't a clue what the parameters were meant to be.

The schema for the database was generated from their own textual file format that let you specify soft relationships instead of hard FK relationships. XML was nowhere to be seen. The parser for this format was convoluted and also very picky about the format of the schema file.

The schema would be translated into header files so that you could refer to fields in the database by an enum value, and then pass off reading/writing that field to the underlying database code so that developers (ideally) didn't have to write SQL. It was their own ORM system but it was quite simplistic and to do anything worthwhile you had to write your own SQL. The schema for the database was not published, nor did it use sensible names, so you'd have to learn this baffling schema and hope for the best. All transactions pending for the database were put into an object that transacted them in one, and they were under the illusion that this was their sole invention in the entire universe. Whilst a good idea, the singular nature of these transaction objects and self-contained business logic meant that when object A hit the database, it might load object B, C, D and E. Each of these might load F, G, H, I and J and so on, so you ended up with a colossal tree of SQL hitting the database. It was incredibly slow.

The database also used magic numbers to change the behaviour of the software. Even in the user interface that the customers used, they taught on training courses that to make it do X Y or Z, simply open the config editor (an Excel-like grid) and the number 5 into grid B25...! As if this was perfectly understandable or usable? It never ever struck them that it might be a good idea to put English words next to settings.

At runtime, the software loaded its schema in a C++ object that it had serialized to the database when the database was upgraded. Since the pointers inside this object had now changed, at runtime on loading it would hook up the pointers to point to the correct parts of this object. If the schema upgrade failed when running its SQL, the schema object might still get saved I think so you could end up with the physical database schema being X whilst the serialized object was Z, so at runtime it was haywire.

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.