There are a few big assumptions in here, that in less-than-optimal companies require time-eating validation:
* The source you have corresponds to whatever runs on production. No, you don't get access.
* The source code has a clear, unique home ('here is a stack of DVDs with the full content of the last person's hard disk. No idea if someone else touched it and dropped it in some repo')
* The source code compiles and runs locally. And doesn't damage production when you start it up because some monkey left a password in there. And doesn't shit all over your hard drive as said monkey expected a very specific folder structure on his personal laptop.
* There is basic test infrastructure. Adding a very first test to an untested code base can take forever
My experience is that most of this is OK when the software was developed internally. Internal people keep the nest clean enough, as they know they'll have to deal with the long-term consequences. When some random contractor or third party did a fly-by code drop('IT was too slow so business department X decided to hire someone themselves'), fear for your sanity.
Wherever I've worked there is no such thing as unowned code. We all know it exists in theory, but as soon as you can't find the owner it's automatically yours.
The perfect example for why tests are a professional courtesy. Code is never yours, it belongs to the person who will maintain it when you are gone. Not adding tests is making their task risky and painful, it's just disrespectful.
* The source you have corresponds to whatever runs on production. No, you don't get access.
* The source code has a clear, unique home ('here is a stack of DVDs with the full content of the last person's hard disk. No idea if someone else touched it and dropped it in some repo')
* The source code compiles and runs locally. And doesn't damage production when you start it up because some monkey left a password in there. And doesn't shit all over your hard drive as said monkey expected a very specific folder structure on his personal laptop.
* There is basic test infrastructure. Adding a very first test to an untested code base can take forever
My experience is that most of this is OK when the software was developed internally. Internal people keep the nest clean enough, as they know they'll have to deal with the long-term consequences. When some random contractor or third party did a fly-by code drop('IT was too slow so business department X decided to hire someone themselves'), fear for your sanity.