4 ms·

Of course you're going to meet resistance as the new guy telling everyone else how messed up a project is. When starting at a company never try to change anyth

Of course you're going to meet resistance as the new guy telling everyone else how messed up a project is. When starting at a company never try to change anything about it within the first several months of working there. Learn what they do. Emulate what they do. After you've reached a trusted status then you can start suggesting improvements. Don't be that guy.

ctvo 10y ago
Great advice. So many developers screw this up. You are in no position to understand the culture, context and constraints previous developers were under when they made certain decisions. Have some humility and withhold judgement.
bpchaps 10y ago
I tend to be "that guy", and I don't really see any major problem if things are actually bad. Last time I tried to "fix" something, it was four months into a job where the scheduling server was put onto my shoulders to fix, among the other things I was asked to fix, simultaneously somehow. I spent two weeks on it and digging through terrible java logs filled with red herrings galore and a badly designed Oracle schema. My boss helped out at the end, but at no point were developers willing to spend a fraction of that time to fix their own code. I mean, they said they would, but never did. What do you do when upper/mid managers and developers aren't willing to fix a major issue that effects prod's upstream and you're wasting 20 hours a week on something they can easily fix? Continue flailing while affecting my reputation in the meantime since I can't figure it out? Every company I've ever worked at has told me, "You have a fresh eye, so if you see anything wrong, we trust your expertise, so you should bring it up." When trying to exercise that, though, it consistently ends with push back from all sides. Every time, then, I bring up the initial mention of a fresh eye, where they agree, apologize, and nothing comes from it. My experience is my own, my learning methods are my own, and I was hired for that reason. If someone's hired on trust and experience that they can do a good job, then forcing "emulation" is a slap in the face. I'm not saying that they shouldn't try to fit the workplace's work patterns, but trying to force someone to do something that's orthogonal to their natural flow or experience without listening, then of course there'll be resistance! There's a point where resistance is good. There's a point where it's bad. There's also a point where not listening to that resistance is worse than the resistance itself.

ctvo 10y ago

Great advice. So many developers screw this up. You are in no position to understand the culture, context and constraints previous developers were under when they made certain decisions. Have some humility and withhold judgement.

bpchaps 10y ago

I tend to be "that guy", and I don't really see any major problem if things are actually bad. Last time I tried to "fix" something, it was four months into a job where the scheduling server was put onto my shoulders to fix, among the other things I was asked to fix, simultaneously somehow. I spent two weeks on it and digging through terrible java logs filled with red herrings galore and a badly designed Oracle schema. My boss helped out at the end, but at no point were developers willing to spend a fraction of that time to fix their own code. I mean, they said they would, but never did. What do you do when upper/mid managers and developers aren't willing to fix a major issue that effects prod's upstream and you're wasting 20 hours a week on something they can easily fix? Continue flailing while affecting my reputation in the meantime since I can't figure it out? Every company I've ever worked at has told me, "You have a fresh eye, so if you see anything wrong, we trust your expertise, so you should bring it up." When trying to exercise that, though, it consistently ends with push back from all sides. Every time, then, I bring up the initial mention of a fresh eye, where they agree, apologize, and nothing comes from it. My experience is my own, my learning methods are my own, and I was hired for that reason. If someone's hired on trust and experience that they can do a good job, then forcing "emulation" is a slap in the face. I'm not saying that they shouldn't try to fit the workplace's work patterns, but trying to force someone to do something that's orthogonal to their natural flow or experience without listening, then of course there'll be resistance! There's a point where resistance is good. There's a point where it's bad. There's also a point where not listening to that resistance is worse than the resistance itself.