Two thoughts came to mind when reading this. First, remember trust is normally earned, rather than assumed. There is a careful balancing act between getting to

Two thoughts came to mind when reading this. First, remember trust is normally earned, rather than assumed. There is a careful balancing act between getting to know the code base, the culture and the team vs being proactive from day 1. If they're completely lacking tests, write tests for the sections of code you're working on; the sections you fully understand. There's a few books on the subject, but they all boil down to don't try and tackle everything at once. Build an understanding and ensure new code is well tested. Furthermore, make sure you understand the background. Is this a prototype that has been deployed to production? Is your colleague a "starter"; great at shipping new ideas, but stability and maintenance are not their strong points? Do they simply know no better? Why are things the way they are? The solution varies a lot. Lastly, age, experience and knowledge are often confused in this industry; try to keep them separate. I manage a team of 6 and I'm the second youngest member (late twenties), but the most experienced in my product. It takes a mix of everything to make a good team.