giving greenfield stuff to newbs
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?
May 23rd, 2012 at 8:39 am
When I’ve started out in a job with a large codebase, I’ve always been given bug fixes for about the first three months. Yes, it was frustrating because I knew there were people in the organization who would be able to fix these bugs much more quickly than I could. However, I do think it’s a perfectly good way to become familiar with the codebase. In fact, I’m quite happy to start by fixing bugs. I spend as much time as I think is acceptable on attempting to fix the bug, then if needed go off and find the person who wrote the code (if they’re still there) and ask questions. This gives me a good excuse to talk to other engineers as well, and we get to know each other’s style. It also gives me a chance to prove myself, since I’m really pretty good at bug fixes, and I won’t come pestering other developers unless I’m at a roadblock.
It appears to me that organizations use those first couple of months as a test to see how fast you learn and mesh with them. They don’t want you working on a new feature because, if you’re a complete disaster, you’ll get canned and your work will have to be redone by someone else. If you mess up a couple of bug fixes, it becomes pretty clear you’re not doing well and it’s easier to phase you out.
In addition, most developers like greenfield work, but in general there’s more bug-fix work to be done. Developers who have worked at the company longer than you have done their fair share of bug fixes already, and are usually impatiently waiting to build new features, themselves. By starting with bug fixes, you’re just paying your dues like everyone else.
Re Code reviews: Wow. Never worked at a company which made them a regular practice. Sure would be nice to find a place like that!
May 23rd, 2012 at 10:02 am
@Marya – I think maybe you missed my point, or I didn’t make it clear enough. I’m not saying that you can’t learn the codebase doing bug fixes. I’m saying that I think it’s more efficient when there’s a part of that codebase you establish ownership of early on that gives you a consistent context for other pieces you encounter. While you may be taking greenfield work away from other devs, I’m not talking about the big, juicy stuff. I’m talking about small, one-off bits. Probably not 100% crucial to the success of the business. We’ll-get-around-to-it-someday type projects.
I have to say, I’m aware of organizations “testing” new employees and I think it’s bullshit. That’s not how you treat professionals. If you’re honestly that unsure of whether they will leave you – at bare minimum – something other devs will be able to modify, they should never be hired in the first place.
May 23rd, 2012 at 10:59 am
It was so nice to read this! I just started at a new job and I’m going through the same thing. I’m fixing lots of little bugs, and the hardest thing about the job right now is just finding the code that I need. It’s really boring. I see so many things that could be addressed with a larger project.
You have to make a lot of changes when you start a new gig, but that goes both ways. It’s our job as the new people, especially those of us with experience, to come in and bring new perspectives, to point out the blindspots, or to call “bullshit” on the stuff that everybody else knows about but is too busy to address.
I’m a little afraid that if I just keep fixing bugs and making incremental progress on features, I’ll just be sucked into their machine instead of letting my experience transform them. I think giving the new people a greenfield project is a great way for a team to have their own assumptions challenged.
May 23rd, 2012 at 6:51 pm
@Ryan – I kind of agree. No matter how experienced you are, it’s important to learn from those with institutional knowledge, but the perspective of outsiders not yet indoctrinated into a certain way of doing things is also valuable. I do think greenfield projects can be a good proof of concept for different approaches, though. It’s a good point.
May 25th, 2012 at 5:26 pm
I found that often that it’s very helping to have a good project editing tool. I use Eclipse for everything because it allows to see the project as a whole and to search quickly, and search multiple projects. When presented with unfamiliar code (not necessary a new job, but it might be a third party project to quickly hack and integrate), I determine the keywords to search for, then within search results determine what’s relevant. Probably, a skill on itself. I’m not sure it fully applies to Javascript but I used to for Javascript too.
I myself never had a chance to just fix bugs for the first 2 months, usually for a couple of days… nobody would let me to do more “introduction” then that. Then it becomes features AND fixing bugs (because nobody wants to do those). And it’s not because somebody is nice to me. I find it rather unfair that I’m given higher standards then other people, otherwise those companies wouldn’t have hired me.
May 31st, 2012 at 5:42 pm
Once quit a gig because, after six months, I never worked on a greenfield project. Instead, I was required to patch a rubbish legacy code base with more senseless dead ends than the Winchester Mystery House.
Giving people fresh, clean ways to assert what they know (and what you allegedly hired them for) yields the high morale they’ll need to survive the boring projects.