A healthy repository allows you to make a trivial patch without fear. The surprises will all be documented in an obvious place. All of it (at least the important parts) will be tested one way or another. "How do I know if my patch worked" will be automated somehow so you don't even need to talk to them about how they broke things. It will either be obvious or clearly documented how to step through the code while it runs on a real-enough set of data, so that people can watch it work and learn about it that way.

> In another thread, a Google employee said the manager didn't expect them to make a real contribution in the first six months. Is that unreasonable?

I can't comment without more details. In particular "real contribution" can mean a lot of things. I think a trivial bug patch (forgot to validate an input) or implementing an already designed feature (we have five of these, implement the sixth) should be possible in the first couple weeks.

I am surprised that Google has code bases like that. I was under the impression that Google has engineers from completely different parts of the company transforming each others' code all the time so they can make breaking changes to libraries.

I was actually overstating the case :) the quote is "My manager has told me that I should not feel pressured to contribute at all for my first 6 months and I should feel free to just focus on learning as much as I can." (emphasis mine)

I once worked at a place that also said this, I hired on with a cadre of 5 other senior developers and two of them really took that to heart, and didn't do anything for six months. They were both PIP'ed (performance improvement plan) and out (left volentarily) at 8 months. A savy employee ought to take the "6 months to get acclimated" with a large dose of salt.

In the end, a truly "senior" developer doesn't need training on anything, just point them at the code, build and deployment scripts, and that's all they need.

I had a completely opposite experience one time. Was also told to take it easy for the first year, wasn't really given any real work to do, etc.

I did not want to waste time and lose my skills, so I talked to a few people here and there, found a few sharp corners in the product that many wanted to improve and started working on them.

Turned out, the reason behind the "relax for 1 year" rule was stack ranking. In order to promote the right people and award them bonuses, the management needed a steady flow of newcomers that would perform poorly and get abysmal review scores.