I'm coming up on two months at my new job (feels like a lot less), and with the amount of code we have, that means there's still plenty I haven't seen or worked with. There are certain processes (e.g., deploying) that have become automatic, but others I haven't yet done. I still get automated emails and have no idea what the hell I'm supposed to do with or about them, if anything.
No matter how far along you are in your career, integrating yourself into a big system takes some effort. Flexibility and lack of process in a smaller system usually speeds things up, but it can be hard to deal with in a bigger system, maybe because it's hard to trust that there aren't hidden processes or toes to step on in some part of the system you haven't stumbled into yet. I had a thought about how it's easiest for me to deal with that uncertainty, as well as to work toward becoming familiar and overcoming my newbishness; I wonder if anybody else feels the same. I kind of think that, maybe against all sense, the best thing an employer can do with a new employee - especially in a big engineering group - is give them a greenfield project.
I've almost always started out fixing bugs. Tiny, trivial things. A couple of pixels of missed padding, some content tweaks, an IE6 issue half the team has looked at and no one's been able to reproduce. Dude, that shit is frustrating! Not only do I spend sometimes entire days just trying to find the code I'm looking for to insert debugger statements or whatever, and have to learn how things are built on the backend and what the organization is, but once I finally do that, all I have to show for it is a paltry and brainless task that someone familiar with the codebase could probably have completed in five minutes. Conventional wisdom is that this is how you become familiar with the codebase. I'm not so sure, though. I think you become familiar over time, as you gain context. The patterns become predictable to you. You know that one of these three people will have worked on it, so it will be coded and organized one of these three ways. But your time to learn those things is measured in months, not tickets closed. Trying to hurry it along, I think, may be fruitless.
Contrast this with a small greenfield project. You're still going to need to touch a hell of a lot of code. You'll still have to go exploring, and learn the little bits of style guide that evolved from an oral history of alert()s and never quite made it into the wiki. But instead of leaving breadcrumbs through a confusing maze as you try to fetch a pebble, you're building a tiny monument using the stones you find closest to you. And you may do it wrong. It's almost certain that something about the task won't match up with the standards of your new employer. But then you can have a code review, and hear about those standards in context, while you have an open buffer to save them to. Having a project composed of tasks, instead of a project with a single incidental task, gives you a place to begin and a way to attach more meaning to the structures and processes you discover.
I don't think I've ever started and been given a greenfield project. Or maybe I have, but without understanding that they were truly mine to take ownership of. It hasn't mattered as much at the past three places I've worked, since the code was so much more segmented, and there was less to learn. Here, though, with one pretty substantial codebase, I'm finding that I really want a home base in all of it to start exploring from. Do other people feel like that when they're starting out somewhere?