99% of the time you are right.To me that sounds like an absolutely useless manager
1% of the time you need to unfuck 40 years of bullshit impacting a multibillion dollar enterprise then you need this person.
I keep trying to poorly communicate how batshit database development was in the past. Let me try to frame it a little better.
- Source systems deposit data in a file format to tons of SFTP that's been around since the 80s.
- This SFTP is consumed by an in house application that extracts data from these very specific files with what you would today consider VERY BIZARRE formatting. A lot of them are not CSV, but |||| SV and so on. Layer 0
- You have now entered the first layer of databases existing in a datacenter this company owns. All of this runs on SQL Server. Layer 1.
- You have another in house application that is not really an application. But a simple task runner that runs hundreds and hundreds of stored procedures in sequence. This generates several thousand tables, databases, and other objects periodically. Layer 2.
- Nested in the above hundreds of stored procedures are other stored procedures that produce more database shit. Layer 3.
- The above nested stored procedures update and generate tons of more stuff that is then used by the next layer of views, tables, databases, SSIS jobs, etc etc.
- ... Another layer of Stored procedures and triggers and shit.
- ...
- ...
- ...
- ...
No comments, no source control, no logging, no documentation, no real way to diagnose problems unless you're a wizard with old SQL tuning and generally know where to start looking.
- 2