Yes, reading code is important, but there's no such thing as being "quickly" productive on a new code base. Anyone who makes changes quickly is probably being

Yes, reading code is important, but there's no such thing as being "quickly" productive on a new code base. Anyone who makes changes quickly is probably being careless. Some, and perhaps most, legacy code bases belong in a top 10 on TheDailyWTF. The last thing you want is for someone to start tinkering with a fragile code base and breaking things that seemed unrelated. A code base of any significant size could take weeks to understand properly, and very few changes should be made until it is understood properly. Managers of new engineers need to be cognizant of this lead time. When working with a new code base, the only thing that's "productive" is spending the first month just studying code, asking questions of colleagues, writing tests and documentation, and making sure that the effects of various potential changes are fully understood. Any time spent on new features at this stage is just expanding the bloat and adding risk to the project.