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 cod

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.