"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."
As a manager, I'd want to know that some resident asshole wasn't following the company line - which I've put in place for a reason. You know, whenever I see the word team and your name, I can actually hear the despair.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
-
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."
1 - C) Add to the class in the original format, just to get the job done. 2 - B) Rewrite the entire thing correctly. 3 - D) Insert rewritten code at the top of the file as a comment.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
As a manager, I'd want to know that some resident asshole wasn't following the company line - which I've put in place for a reason. You know, whenever I see the word team and your name, I can actually hear the despair.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
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."
-
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."
-
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))The company is the owner of the code.
-
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."
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.
-
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."
Reject the code and don't work on it until it's fixed. Actually, I had a similar situation a bunch of years ago. The code was originally written for OpenVMS using dumb termini (VT100) so the coding policy was that indents would be four SPACEs -- no TABs. (Also a maximum line length of eighty. X| ) Along came a bunch of yahoos using Visual Studio and who didn't set VS to insert four SPACEs as they were instructed. I'd fetch a file from CMS (version control), open it in EDT, and find lines all over the place. I'd complain. They'd say, "Just go to Edit|Advanced|Untabify". I'd say, "I don't frickin' have a Edit|Advanced|Untabify in EDT!" I had to write a program just to untabify. :mad:
-
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."
B: Bitching about it without an answer is not an acceptable solution - it's just bitching. Do B, proves it can be done, it is then a positive response to the problem. I won't accept anyone going outside the SOP - hunt them down and offer to remove their keyboard. I am flexible about changing the SOP and am always looking for improvements but unless the dev can justify the change (there can be a huge cost in changing SOP) it just get delayed. When there are enough changes we will implement a whole slew of them. This happens about every 18 months.
Never underestimate the power of human stupidity RAH
-
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))in preference to company policy always? or meaning that changes should wait until he has time? he did give permission. I assume because he too wants this to come to decision.
_________________________ 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 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.
true. and why this has not come to confrontation before. however he has intimidated everyone through threats of putting folks up for code review unless they change to "his team" methods instead of the SOP. This has been coming for a long time. I have avoided conflict until now. The reverse does not hold true. My code has been changed to non-SOP as well as intimidating others into giving up the "obviously" wrong SOP. None of us has time for a code review. But nor can we avoid it any more. I refuse to change the code he wrote, or those he has convinced to write the same. Again the reverse has not held true. This was innevetable. I have suggested to change the SOP, but management still agrees this is the preferred format. It may be better now to change the SOP since "someone" has been changing mine and other's code to violate the SOP to the new "team" method. :) I look at svn updates too. :) I only want a management call. :) Reviewing my code is easier than others since that is one of the threats being tossed around to intimidate. what more can be expected of an old dog? :)
_________________________ 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."
-
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."
D. Talk to the original author about the class if possible.
John
-
true. and why this has not come to confrontation before. however he has intimidated everyone through threats of putting folks up for code review unless they change to "his team" methods instead of the SOP. This has been coming for a long time. I have avoided conflict until now. The reverse does not hold true. My code has been changed to non-SOP as well as intimidating others into giving up the "obviously" wrong SOP. None of us has time for a code review. But nor can we avoid it any more. I refuse to change the code he wrote, or those he has convinced to write the same. Again the reverse has not held true. This was innevetable. I have suggested to change the SOP, but management still agrees this is the preferred format. It may be better now to change the SOP since "someone" has been changing mine and other's code to violate the SOP to the new "team" method. :) I look at svn updates too. :) I only want a management call. :) Reviewing my code is easier than others since that is one of the threats being tossed around to intimidate. what more can be expected of an old dog? :)
_________________________ 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."
how is a code review, a threat ? I wish more people did it. I submitted some code yesterday, it was reviewed overnight and now I know better how to fit in with the team I am working with. How is that an issue ? If code review is a threat, then it's being done wrong.
Christian Graus Driven to the arms of OSX by Vista.
-
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."
Accidently "miss" a missile that's targetted at his cubicle. :-D
-
how is a code review, a threat ? I wish more people did it. I submitted some code yesterday, it was reviewed overnight and now I know better how to fit in with the team I am working with. How is that an issue ? If code review is a threat, then it's being done wrong.
Christian Graus Driven to the arms of OSX by Vista.
Christian Graus wrote:
how is a code review, a threat ?
I wish we did more of it too. However. Since I pointed out the "I hate windows" this person lays into everyone at code reviews nitpicking to death. Code reviews have become a threat. I still would like us to round-robin the reviews and get everyone online again. I don't intimidate easily anymore, especially not with threats of what I want to do anyhow. :)
_________________________ 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 company is the owner of the code.
PIEBALDconsult wrote:
The company is the owner of the code.
well, actually the US Army is. But that would be picking nits. :) The Army doesn't care what the code looks like and hasn't got time to look at any of it. They rely on the company to have a policy in place for what it should be, and you follow it -- they ask you how you are doing, you say "great" and all is well. ;-) If your policy said all code should run backwards with gotos and you didn't... then there is a problem... either change the policy or the code. :)
_________________________ 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."
-
D. Talk to the original author about the class if possible.
John
Both of us gave up on that. His way is right and the company is wrong. I tried to convince him to try to change the SOP, but it is too much red tape to do what you should have done anyhow. I think the current plan is to change everything to nonSOP and then convince management it will cost less to fix the SOP than to conform the code.... but ONE programmer keeps adding to the workload by writing SOP code he has to change. :)
_________________________ 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."
-
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."
-
how is a code review, a threat ? I wish more people did it. I submitted some code yesterday, it was reviewed overnight and now I know better how to fit in with the team I am working with. How is that an issue ? If code review is a threat, then it's being done wrong.
Christian Graus Driven to the arms of OSX by Vista.
-
Well as you well know there's the right way and the wrong way and no other way.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
no. There is the way your bosses or your customers tell you to do it. If you don't like it, you try to convince them to change. Not blackmail them into changing. :) I just want the SOP to reflect the code. I have no interest in right or wrong. We get graded on conformance to our own standards. Right now that grade is about 50% or less. how in the hell does one flunk the standards your own company puts forth? at least if we change the SOP we all have the same reference.
_________________________ 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."
-
how is a code review, a threat ? I wish more people did it. I submitted some code yesterday, it was reviewed overnight and now I know better how to fit in with the team I am working with. How is that an issue ? If code review is a threat, then it's being done wrong.
Christian Graus Driven to the arms of OSX by Vista.
Christian Graus wrote:
how is a code review, a threat ?
Maybe it's a threat because there's one guy on the team that believes if he didn't write the code, it's wrong and will destroy the code in the review. Plus, maybe the managers believe what he says is law. So, maybe all code reviews result in the code being needlessly rewritten. Having to rewrite perfectly (and probably correct and efficient) code makes developers angry and frustrated and makes code reviews dreaded ordeals. Not that I've gone through any of that or anything.
Don't blame me. I voted for Chuck Norris.