I worked at Bell Labs Holmdel for precisely 10 days. It's a memory I am glad I have, because it was what persuaded me to never, ever work for a large corporation ever again, and very specifically, to never ever work in an interior, windowless office.
My assigned task: there was a constant in the C code that ran their telephone exchange hardware which controlled how many forwarding hops were allowed. I was taked with changing it from 32 to 64. The allotted time for this task was 1 week.
While I appreciate the committment to quality assurance/testing, the idea that I could have spent my life working in such an environment fills me with shudders.
My brief time there was ended when I rolled my then-wife's car 3 times on the way down to the Outer Banks (NC), broke my arm and could no longer commute between Phila. and Holmdel. Lessons learned, for sure, and appreciated, but not necessarily in a good way.
1 week is fascinating. Was it like – the missing piece was modern version control/CD? What kind of testing would need that? (We have configs at work where the system interactions are so unknowable and the financial implications of reduced efficiency so profound that we have to run multi-week A/B tests to change values) Was it some kind of pathological documentation culture?
https://medium.com/better-programming/software-component-nam...
Small summary: external identifiers are hard to change, so projects will evolve such that they are not accurately descriptive after time.
(Less discussed there, but: In a complex or decentralized ecosystem, it's also the case that you come across many "X Manager"/"X Service"/"X State Manager"/"X Workflow Service" simultaneously, and then have to rely on a lot of thick context to know what the distinctions are)