No, not even that “deep”.
Like, they literally had ZERO data validation. The database was one of customer records, which they were in the process of amalgamating from 40+ separate DBs. The minimum required data (as per the job spec, none of it enforced by the software) was entity name, entity type, business address, contact address. You could literally hit “create new record” and immediately hit “save” without entering anything and the record would be saved. I mean actually no fucking data validation whatsoever. And this was a MAJOR bank here in the UK.
Because of this, when the new records from the old system would be migrated - unless the person was sharp enough to spot it (which pretty much none of them were due to a lack of training/motivation) - a new record would be created. So lets say it’s a UK Ltd company, registered in Scotland. That would mean the company number should be “SC”, followed by 6 numbers. People would enter “SC012894”, “12894”, “sc012894”, “012894”, “00012894” etc. When I first joined the department, I did a search on the DB and found 12 entities for the same company. You could, of course, also enter “SC012894” for 100,000 companies and the error would never be caught.
By the time I had pointed this out to them, they already had around 750,000 records in the DB. So if you want to apply validation at the database level such as “VARCHAR NOT NULL” or a composite index then the the shit hits the fan due to non-confirming data.
No user-level access control. I mean NONE. The department employed a lot of students on summer breaks from the local universities as temp staff. They had the same level of access as everyone else had. And they also didn’t give a fuck because the work was repetitive and extremely dull and they were going to be gone in a couple months anyway. People would delete records or merge records (which could not be undone as there was no “soft delete”) due to complacency or thinking they were cleaning things up by doing so. These would often be records that had months of work on them by relationship managers.
Then there was the ratings team who fed data about the bank’s customer into a model and the results of the model would decide whether or not to lend the customer often millions of £ (retail parks etc). I saw one of their requests for data from my team that made no sense (they were rating tenants in a retail park from a backlog of work from 6 months prior but the company who was the tenant had only been registered as an Ltd in the past week). I asked to look through their work and I calculated that about 30-40% of everything they were entering into the model was wrong (not the same entity at all, nothing to do with the customer).
When @The_Adversary posted above a while back with his initial research into what to learn and how to learn it, I replied saying that if would be a success if he was as diligent with learning as he was with his planning (or words to that effect). That is because we are systems engineers and that requires understanding of the moving parks and the schema. Being able to write “hello-world.js” doesn’t mean anything. As I said about Mr Musk above, it’s the ability to innately understand how the system functions that is important, such as the questions like “Why are we pulling 90% of this shit when it’s not needed, costs us money on infrastructure, complexifies the code and slows the performance of the site/app?” and “Why are we paying people to sit in safe spaces and drink soy caramel lattes and they haven’t even committed any code in 6 months?”.
You don’t start painting the walls then think about moving the furniture and covering the carpets - you move the furniture, cover the carpets then start painting. You don’t make yourself the richest man in the world without being organised and understanding the simplification is the key to keeping mega-systems manageable.