"team" work
-
without naming names... ;-) how would you handle adding to someone else's class... as part of your assigned tasks... but that code does not follow company SOP. A) Fix the code to spec and thoroughly piss off the original author B) write all new routines in company spec format thus showing two different formats in the same code and thoroughly pissing off the original author but letting management deal with the solution. C) write non SOP code to match the original author and not pissing off the original author. :) I also want my sharks with fricken' laser beams for Christmas. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
El Corazon wrote:
A) Fix the code to spec and thoroughly piss off the original author
Frack the original author. If his ego was too big to write it to spec, it's too big to avoid complaining about it...and get taken down a peg for not writing it to spec in the first place. However, if you do this, you'd better make NO mistakes whatsoever in the conversion.
-
The original author is the owner of the code.
xacc.ide - now with TabsToSpaces support
IronScheme - 1.0 beta 1 - out now!
((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))leppie wrote:
The original author is the owner of the code.
Nonsense. The employer owns the code. The original author wrote the first take of the code, and if he hasn't twigged onto the fact that software is written on toilet paper, then he needs to get a clue. Now, I'll give a caveat - function should not be part of the coding standards. Example: standardizing on one sort algorithm is stupid. A code format standard, however, simply insures that everyone in the organization can expect to read anyone's code without having to allow for umpteen variations in indentation, block marking, etc.
-
I think leppie has it right - the original author is the owner. By giving him an answer that you knew he would misinterpret, you disrespected him. Being deceitful to team members might be satisfying to you, but will have the expected impact on the way others trust you, whether you were following SOP or not.
Jim Turner wrote:
I think leppie has it right - the original author is the owner. By giving him an answer that you knew he would misinterpret, you disrespected him. Being deceitful to team members might be satisfying to you, but will have the expected impact on the way others trust you, whether you were following SOP or not.
What was deceptive about his response? The team's standards are the company standards. De facto behavior does not make a standard. Ergo, El Corazon's reply was correct, and if it was misinterpreted that misinterpretation was due to an egotistic assumption on the part of the listener. Your statement makes the implicit assumption that the "team" is centered around El Corazon's "original author". El Corazon, rather, casts him as a code bully. Are you saying it's better to follow a successful code bully than your manager's policy?
-
It sounds like a case of a toxic coworker, a prima donna who has nothing to contribute to the team effort but discord. That individual needs to be served for Thanksgiving dinner - a turkey in developer clothing. Management has only two choices available, acknowledge his superior judgement and adopt his way as the SOP, or give him his walking papers, as he's a disruptive element that damages the efficiency of the entire organization. There is no middle ground, and if management attempts to weasel out of making the decision, it's time to find another employer.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
Amen!!
-
actually the SOP does cover this. It is just fewer and fewer programmers are following the SOP. I am about to be the last. :) so the need is to make the decision while its still near 50:50 do we change the code to matche SOP or the SOP to match newer programmers refusal to match it?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
El Corazon, where is your manager in all this? Why hasn't your manager stepped in to assert policy?
-
hehehe which is why I chose B) when I took the assignment from our project leader the original author asked if I was going to follow the "team" methods ( meaning his and those he has convinced) I said "yes" (meaning the company line) it isn't my fault he forgot to define team. :) as desired, he demanded a code review on my code within an hour of checkin. :) Management can make the call. It took years to get an SOP in place, until it is changed I am going to play rogue. He's intimidated everyone now to ignoring the SOP I am the last holdout. I just want management to make the call. :) He can call me rogue, old-fashioned, antiquated, or whatever he wants. I'll change when the SOP is changed not to avoid a fight. I am now the last holdout, which means the policy may change, that is fine too. :) But I want it changed first. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
>the original author asked if I was going to follow the "team" methods ( meaning his and those he has convinced) You didn't mention that in the first posting - that he has his own methods/standards that he's pushing. That redefines the teamwork idea. Hard to tell if it matters, since no examples of how they differ are given - whitespace, comments, naming conventions, or something functional? Sounds like a good decision for your project leader (or other management) - "what style shall I code in?"
-
without naming names... ;-) how would you handle adding to someone else's class... as part of your assigned tasks... but that code does not follow company SOP. A) Fix the code to spec and thoroughly piss off the original author B) write all new routines in company spec format thus showing two different formats in the same code and thoroughly pissing off the original author but letting management deal with the solution. C) write non SOP code to match the original author and not pissing off the original author. :) I also want my sharks with fricken' laser beams for Christmas. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
You'll have to judge based on the unwritten parts of your situation, but in general, ignore the author if you can. Enlist the aid of a developer more senior than yourself to advise you on what to do if you need to -- they will know the individual and office politics and can advise you better than us strangers. That said, it isn't a license to go willy nilly converting code -- maintain style for minor mods, new functions or files do corp SOP, everything else is a judgement call (but remember, the more you rewrite, the more others will have to retest). Truthfully, the only people I've met like that have been the very ones who are in over their heads and can't actually work at that level.
patbob
-
You'll have to judge based on the unwritten parts of your situation, but in general, ignore the author if you can. Enlist the aid of a developer more senior than yourself to advise you on what to do if you need to -- they will know the individual and office politics and can advise you better than us strangers. That said, it isn't a license to go willy nilly converting code -- maintain style for minor mods, new functions or files do corp SOP, everything else is a judgement call (but remember, the more you rewrite, the more others will have to retest). Truthfully, the only people I've met like that have been the very ones who are in over their heads and can't actually work at that level.
patbob
I am the most senior developer. :) it is why this other developer and I go head to head often. :) I am ancient and any rule that we created before him that he doesn't agree with is because I am ancient and should be mothballed along with the rules. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
I am the most senior developer. :) it is why this other developer and I go head to head often. :) I am ancient and any rule that we created before him that he doesn't agree with is because I am ancient and should be mothballed along with the rules. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
If this is a battle you feel you must win with this developer, and you have the power or influence to do so, then it sounds like you'll have to pull rank on this individual. Is it really that important? Or can you just do what you think is right and be amused by their outrage? I know where you're coming from, luckily minus the attitude :)
patbob
-
If this is a battle you feel you must win with this developer, and you have the power or influence to do so, then it sounds like you'll have to pull rank on this individual. Is it really that important? Or can you just do what you think is right and be amused by their outrage? I know where you're coming from, luckily minus the attitude :)
patbob
I absolutely hate pulling rank. Of course this individual pulls youth as a power card at least once a month and usually once a week. That is the only thing that tempts me to pull rank. I is just a hick programmer from a small mining town in NM... :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
I absolutely hate pulling rank. Of course this individual pulls youth as a power card at least once a month and usually once a week. That is the only thing that tempts me to pull rank. I is just a hick programmer from a small mining town in NM... :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
Pulling youth as a power card that often makes me wonder about their motivations. Do they really have that high of an opinion of themselves, or are they trying to convince managemnt of something? Could the dredded office politics thing be happening right before your eyes? Hick from a small mining town? Pshaw.. talent is where you find it, not just in large metropolises (metropolii?) or ivy league colleges.. and never, never, just because someone is young. Trust me on this :)
patbob
-
Pulling youth as a power card that often makes me wonder about their motivations. Do they really have that high of an opinion of themselves, or are they trying to convince managemnt of something? Could the dredded office politics thing be happening right before your eyes? Hick from a small mining town? Pshaw.. talent is where you find it, not just in large metropolises (metropolii?) or ivy league colleges.. and never, never, just because someone is young. Trust me on this :)
patbob
politics is ALWAYS going on here. We wrote the book on office politics. :) and the hick is my own joke. I have votech Business Computer Science... but I practically wrote the book on controlling full scale air vehicles using gaming graphics in a close loop fly-by-wire display. :)
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."