Comment Growing Pains: My First Three Years in Industry (Score 1) 507
It's a very personal journey to move from criticizing other people's code to taking the code for what it is. I've been in the industry for nearly 3 years now, and I pride my earlier self on having quickly gotten out of the rut that is "xeno-codo-phobia". Here are my own self-observations.
Stage 0: I don't want to look at other people's code. I'd rather roll my own stuff given the opportunity. If I have to work in larger code bases where reading code is a necessity, I want to just get in and get out without so much as even looking at the decorations or saying hi.
Stage 1: Okay, you've convinced me, Mega Corp X. I've seen some cool things in some code reviews that have been passed around and/or assigned to me. I might be open to taking at look at.. OH MY ***, IT'S ALL TERRIBLE. I NEED TO REWRITE THIS POS! A little, no some, no all of it! Hmm, my lead won't let me rewrite it? Okay, I'll just spend extra long on new features, stage 0 style, or I'll work on other people's code and complain the whole time to them about how they do X, Y, and Z wrong.
Stage 2: Hrmm, my coworkers had wills of steel and could repel my complaints. I didn't change their minds very much. After finding out about the code's history, I almost 100% agree with the decisions that led to the code being the way it is given the constraints upon writing time. The only person I upset by complaining/harboring a negative mental state about the code was myself. Maybe I should just be more constructive with my complaints or not complain at all.
Stage 3: When I see code I don't like, I spend time to first educate myself about it. I add docs/comments when there are none and otherwise make tiny checkins to beautify the code where I can. Sometimes I find bugs this way. Sometimes I simply add clarification (for myself and the next reader). Sometimes it spawns discussions with the original devs about how and why we did things a certain way, and there's almost always a reason. Sometimes it teaches me to avoid that code like the plague as the original dev left and now it's a maintenance nightmare that all devs use to play hot potato. 100% of the time I learn something new. 100% of the time, judging before I do my due diligence results in either a waste of my time or a waste of someone else's time.
Stage 3 is basically where I not only know logically but also believe that:
* I am smart and my coworkers are smart. Given the same inputs, we tend to code the same way.
* My senior coworkers typically have a deeper understanding of the problem space. (they have more input than me)
* My senior coworkers typically better understand the priorities imposed by the business/culture of the company. (they have more input than me)
* Given the discrepancy between my understanding (my input) and their understanding (their superset of input), they are probably making better decisions for the company.
Sure the code might be locally worse because one of the above assumptions may occasionally break. Sure the code might not adhere to some theoretical golden ideal. BUT. I have tremendous faith now that the code is for all intents and purposes in one of the best possible (where best is relative to the company) states it can be in. The deleterious effects of time may have already taken their toll, but at the time the devs made those decisions, they were most likely optimal for the larger organization.
So yeah. I basically had to learn and accept that I was just full of myself and that an open mind trumps a closed one.
My advice? If you like the intern and want them to come back, be patient. Put them in situations where they learn the above, and don't take personal offense as they go through this phase of their professional life. If you don't like them and don't want them to come back, call them out on their pigheadedness so they associate their failure (not getting a return offer) with their close minded values. You probably don't want someone like that on your team (at least in the immediate future), and it will be better for them (and the community) in the long run.
Best of luck!
Stage 0: I don't want to look at other people's code. I'd rather roll my own stuff given the opportunity. If I have to work in larger code bases where reading code is a necessity, I want to just get in and get out without so much as even looking at the decorations or saying hi.
Stage 1: Okay, you've convinced me, Mega Corp X. I've seen some cool things in some code reviews that have been passed around and/or assigned to me. I might be open to taking at look at.. OH MY ***, IT'S ALL TERRIBLE. I NEED TO REWRITE THIS POS! A little, no some, no all of it! Hmm, my lead won't let me rewrite it? Okay, I'll just spend extra long on new features, stage 0 style, or I'll work on other people's code and complain the whole time to them about how they do X, Y, and Z wrong.
Stage 2: Hrmm, my coworkers had wills of steel and could repel my complaints. I didn't change their minds very much. After finding out about the code's history, I almost 100% agree with the decisions that led to the code being the way it is given the constraints upon writing time. The only person I upset by complaining/harboring a negative mental state about the code was myself. Maybe I should just be more constructive with my complaints or not complain at all.
Stage 3: When I see code I don't like, I spend time to first educate myself about it. I add docs/comments when there are none and otherwise make tiny checkins to beautify the code where I can. Sometimes I find bugs this way. Sometimes I simply add clarification (for myself and the next reader). Sometimes it spawns discussions with the original devs about how and why we did things a certain way, and there's almost always a reason. Sometimes it teaches me to avoid that code like the plague as the original dev left and now it's a maintenance nightmare that all devs use to play hot potato. 100% of the time I learn something new. 100% of the time, judging before I do my due diligence results in either a waste of my time or a waste of someone else's time.
Stage 3 is basically where I not only know logically but also believe that:
* I am smart and my coworkers are smart. Given the same inputs, we tend to code the same way.
* My senior coworkers typically have a deeper understanding of the problem space. (they have more input than me)
* My senior coworkers typically better understand the priorities imposed by the business/culture of the company. (they have more input than me)
* Given the discrepancy between my understanding (my input) and their understanding (their superset of input), they are probably making better decisions for the company.
Sure the code might be locally worse because one of the above assumptions may occasionally break. Sure the code might not adhere to some theoretical golden ideal. BUT. I have tremendous faith now that the code is for all intents and purposes in one of the best possible (where best is relative to the company) states it can be in. The deleterious effects of time may have already taken their toll, but at the time the devs made those decisions, they were most likely optimal for the larger organization.
So yeah. I basically had to learn and accept that I was just full of myself and that an open mind trumps a closed one.
My advice? If you like the intern and want them to come back, be patient. Put them in situations where they learn the above, and don't take personal offense as they go through this phase of their professional life. If you don't like them and don't want them to come back, call them out on their pigheadedness so they associate their failure (not getting a return offer) with their close minded values. You probably don't want someone like that on your team (at least in the immediate future), and it will be better for them (and the community) in the long run.
Best of luck!
