3 ms·

Well, two things: 1. It's a great way to learn a new codebase. 2. It's a good way to get some political capital so that you can get autonomy more easily. Y

by j_baker 16y ago

Well, two things: 1. It's a great way to learn a new codebase. 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.

geebee 16y ago
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.
Groxx 16y ago
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.

by j_baker 16y ago

geebee 16y ago

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.

Groxx 16y ago

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.