"Now one of the things I was doing with new hires at the time was getting them to work on bugs – it helped me knock down the backlog and gave them exposure to a variety of areas across the system. I also gave them plenty of time early on to learn the ropes and get up to speed and it would typically take a few days to get through the first few bugs and start having some ah-ha! moments with the codebase."
This is a little bit of an aside, but how many people out there take this approach with a new hire? If you're a manager/team lead, do you start new developers out fixing bugs? If you're a developer, how do you feel when bug fixes are your first assignments?
Personally, I think that fixing someone else's bugs is one of the hardest tasks in programming. Depending on how the interview went, it can also be a very depressing and alarming task (autonomy? creativity, opportunity to influence the project? we've found that our recruitment success increased by 10% every time we used one of those words. now here's your task list, go fix some bugs).
I want to be sure that I emphasize that people have the right to pick their own management style, and I'm not questioning it. It also sounds like Richard was very reasonable about this - giving programmers adequate time to navigate the system (though "adequate" is a relative term... if "a few days" is enough for new devs to have their a-ha moments and fix several bugs, you probably have very high quality code and documentation).
But let's add this as reason #458 why young programmers prefer to start their own companies: their first "assignment" is creating a product, not fixing someone else's crap code.
2. It's a good way to get some political capital so that you can get autonomy more easily.
You just don't usually start out with the plum assignments when you start a new job. If you do, you won't be given the autonomy to make them satisfying. So in my opinion, it's better to start off with jobs that you know will be drudgery to prove your worth than it will be to get a neat-sounding task where you'll be kept on a short leash.
Fair enough. I think this is an important thing for developers to understand about themselves before taking a job. Do I want to work with a large existing code base? Do I want to work for an organization where I need to build political capital to gain autonomy?
For some people, the answer will always be "no". For others, it's complicated, and potentially impossible to answer without trying out the company for a while.
Suppose the code is well organized and understandable. The bugs are not the product of bad design, they're just the inevitable side effect of any real software project. The programmers who created these bugs are largely still with the organization, they are highly competent, and are more than willing to help a new dev get up to speed - and the documentation (and code quality) is so good that it usually isn't necessary. Lastly, the team and management is eager to give autonomy and flexibility to a talented, proven dev, so it's not a problem to build up that "political capital" you mentioned. Well in this case, what you said is reasonable and more than acceptable to many good devs, even if it isn't right for everyone.
Then there's the nightmare scenario - the team is not highly competent, and the reason you were hired is that the good programmers keep quitting and there's nobody to help you. The code base is a mess, and documentation doesn't exist or is useless. Even getting a build to work is difficult and painful. The reason the management is giving you bug fixes is that they don't really know what to do with a new hire, so they assign some bug fixes, that'll keep you busy for a while. Lastly, they're aren't interested in listening to new suggestions, so political capital won't get you anywhere. O course, in this case, I suppose it doesn't really matter what your assignments are.
By the way, there is another way to get political capital. In my first real programming job, I had an almost ludicrous amount of autonomy. Like, "find something that might be useful and write software for it" levels of autonomy. This was the dot com boom, and there was enough money to hire people for this kind of thing. Of course, they didn't give me high impact assignments, but they did give me broad flexibility in meeting (and even determining) my assignments. This can be an alternate way to build up the political capital you mentioned. Instead of having a limited role on a high impact project, you have a broad role on a low impact project. That can work well for some people - however, these jobs are very rare. Usually, you have to trade the stability of a paycheck for that kind of freedom, especially early in your career.
It's a great way to learn a new codebase if that codebase is well documented and explained to them. Otherwise you're just turning `if (i = 1)` into `if (i == 1)`, which may or may not actually be correct.
My current job had almost zero documentation anywhere, and nobody knew the entire system (or even the over-arching design, which I discovered was none). Which is starting to royally screw them over. And I started with a fairly highly integrated project. I learned it in spite of what I was doing in their system and lack of education for me (ie, zero), not because of it - they wanted things finished, I didn't want to finish them incorrectly.
You wouldn't want a new hire tackling some hairy mess of a bug. But this is common practice in open source projects - there's a massive backlog of minor bugs and nice-to-have feature requests, stuff that's pretty easy to finish if you had the time and the will.
Having someone take care of some of this stuff first to familiarize himself with the project and get used to the processes before jumping straight into a big task seems like a good idea to me.
"Personally, I think that fixing someone else's bugs is one of the hardest tasks in programming. Depending on how the interview went, it can also be a very depressing and alarming task (autonomy? creativity, opportunity to influence the project? we've found that our recruitment success increased by 10% every time we used one of those words. now here's your task list, go fix some bugs)."
Indeed!
Many developers view fixing bugs as a punishment. Perhaps that is part of the reason why so much software is riddled with bugs.
I really enjoy using various tools like static analysis programs and memory checkers to ferret out the offending bits of code, figuring out why they're broken, and fixing them.
It gives me a certain sense of satisfaction to finally conquer a bug. Particularly when it's a really tricky bug I've been bashing my head against for days.
Then again, when I've been after a given bug for days it can get really frustrating, and I don't enjoy the frustration.
And it's not like my dream job is doing nothing but fixing bugs. I also enjoy architecting new systems, learning new concepts, and applying them during the quest to complete a project.
I suppose a healthy mix of tasks, from architecture, to writing new code, to fixing bugs is ideal.
But what I really hate is writing documentation. I know it's necessary. And my (non-throwaway) code has quite a lot of comments in it because I know it's necessary and good practice. But it can get quite tedious.
I love bug fixing too, especially if I have a good repro and its from a customer. Few things feel better than fixing a bug and delivering it to a customer.
I actually treat bug fixing as a little treat. When I want a break from coding -- I'll go and find a few bugs to fix.
When I joined the company I am with right now, I wanted to jump into the codebase and start working on something, the way I get myself familiar with a codebase is reading the code, but it has to have a goal. I have to understand a piece of the code to use it (API with bad documentation), or because I need to fix a bug or add a feature.
I started working on the bugs by choice, it was an easier way to familiarise myself with the source code and gave me some problems that the other developers hadn't been able to fix, or hadn't gotten to yet.
When I started at Netscape (the social news site, not the browser), I spent my first two days doing QA on the application, and I would heartily recommend having new hires do this. I got acquainted with all the aspects of the site, I didn't have to deal with other people's code (yet), and I gained that admiration and respect of my new co-workers by submitting a long list of bugs and XSS vulnerabilities that I found for them to fix. (Not really on that last part, but I don't think there were any hard feelings.)
This is a little bit of an aside, but how many people out there take this approach with a new hire? If you're a manager/team lead, do you start new developers out fixing bugs? If you're a developer, how do you feel when bug fixes are your first assignments?
Personally, I think that fixing someone else's bugs is one of the hardest tasks in programming. Depending on how the interview went, it can also be a very depressing and alarming task (autonomy? creativity, opportunity to influence the project? we've found that our recruitment success increased by 10% every time we used one of those words. now here's your task list, go fix some bugs).
I want to be sure that I emphasize that people have the right to pick their own management style, and I'm not questioning it. It also sounds like Richard was very reasonable about this - giving programmers adequate time to navigate the system (though "adequate" is a relative term... if "a few days" is enough for new devs to have their a-ha moments and fix several bugs, you probably have very high quality code and documentation).
But let's add this as reason #458 why young programmers prefer to start their own companies: their first "assignment" is creating a product, not fixing someone else's crap code.