This is very common, and it can ruin a new hire for no reason (as well as lead to problems later, when it turns out everyone is doing various cargo cult ways of running the code). Almost everywhere I've worked, if there was existing code, there was key undocumented info that was necessary to get the code, build, and run it.
It's become the norm for me, when starting at a new place, to grab someone who knows how to get and run the code, and have them walk me through it while I take step-by-step notes, then I turn that into the start of the official development docs. (I'll also start capturing other org process information, usually starting with things like what comms are used for what, who to talk to about common things, how to use a wiki effectively, etc.)
Comments
This is very common, and it can ruin a new hire for no reason (as well as lead to problems later, when it turns out everyone is doing various cargo cult ways of running the code). Almost everywhere I've worked, if there was existing code, there was key undocumented info that was necessary to get the code, build, and run it.
It's become the norm for me, when starting at a new place, to grab someone who knows how to get and run the code, and have them walk me through it while I take step-by-step notes, then I turn that into the start of the official development docs. (I'll also start capturing other org process information, usually starting with things like what comms are used for what, who to talk to about common things, how to use a wiki effectively, etc.)
This is exactly the way to go. It will unblock yourself, and improve things for future team members.