File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Jobs Discussion and the fly likes Conflict with the Lead Developer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Careers » Jobs Discussion
Bookmark "Conflict with the Lead Developer" Watch "Conflict with the Lead Developer" New topic
Author

Conflict with the Lead Developer

Andy Williamson
Greenhorn

Joined: Dec 07, 2010
Posts: 1
So, here's my situation. I started working for this company shortly after college. I've been there for just over a year now. We have moved out of the design phase and are now in development. A new guy from within the company was brought on the team as the lead developer. I'm not sure how much experience he has, but its certainly way more than me. Along with myself, he is one of the few team members with Java experience. Half of our development team, including the chief engineer, is using Java for the first time (they were C++ guys before). The chief engineer is therefore heavily relying on the lead developer for understanding various aspects of Java software development.

This lead developer is clearly experienced and has been instrumental in getting the development infrastructure in place and getting us started on the right foot. He strikes me as being very capable of programming a solution to a given problem. However, I'm beginning to worry that his solutions and coding approach are not robust and have poor design. For example:

-He told me never to use super.clone() when overriding the Object.clone method, suggesting instead that I should use a constructor. (Unless your class is final, a constructor violates the clone contract.)
-He told one developer to write a isGreaterThan and isLessThan method. He must have forgot about the Comparable interface.
-He used java.rmi.RemoteException outside the context of any RMI.
-He wraps all his exceptions into one SoftwareException, thus preventing the caller whose catching the exception from knowing what actually went wrong.
-He told the chief engineer that a List prohibits duplicate objects. (They don't. A Set does.)
-He prefers bug-prone methods like this, "Object objectFromXml(ObjectTypeEnum type, String xml)", as opposed to a safer method like, "<T> T objectFromXml(Class<T> clazz, String xml)".
-His view of good design regularly contradicts nearly everything I've read, including the oft-cited Effective Java by Joshua Bloch.
-Etc.

One of the customer's key desires is for the product to be robust, maintainable, and extensible over the long-term. This is also the kind of software in which certain bugs could have a remote chance of causing people to get hurt or killed. To me, this means we should be careful to use proper design principles, follow best practices, and adhere to Java standards. The lead developer says that we must rely on future developers to follow good coding practices and that testing is used to catch developer mistakes. However, I’ve always thought that you should write code that, where reasonably possible, prevents developers from making mistakes in the first place.

I frequently argue with the lead developer, but he can always resort to the phrase, "well, in my experience its always worked to...," to which I always concede the argument. He should know, right?

If the customer weren't seeking a robust and extensible long-term software product, I don't think I would be nearly as bothered about his "get 'er done" approach. Am I crazy? Do I just not understand how software development works?

I'd be interested to hear your opinions of the situation and how I should handle it.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29220
    
135

Welcome to the Ranch!

Andy Williamson wrote:I frequently argue with the lead developer, but he can always resort to the phrase, "well, in my experience its always worked to...," to which I always concede the argument. He should know, right?

I encountered this from one person when I only had a year or two of experience. I got frustrated too. I countered it with something like "Since you are experienced, you can explain it to me". Sometimes it worked and sometimes it resulted in a claim that it was too complicated for me to understand. I should have pushed back on that one too but I didn't know better.

I would bring a copy of Effective Java to the office and see if I could slip it into conversation. Or anonymously leave a copy on his chair.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Mike Isano
Ranch Hand

Joined: Jan 19, 2007
Posts: 144


There are different classes of "bad". There is mild stuff like doing it in a non-standard way, but functionally works fine. Then there is stuff that has a direct negative impact. And everything in between. If you are compiling with an older java compiler the wrong way is sometimes the only way. (kiss generics good bye)

For your own code, do it the right way. If he is making you change your code make him justify it. If you are trying to change him, save it for things having a real negative impact.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15629
    
  15

We all have our misconceptions, as I had hammered into my face yesterday. The main thing is not to hold on to the harmful ones dogmatically.

Figuring out what's "harmful" can be a challenge, however. I've seen hack solutions that worked for years suddenly fail and take an entire mainframe operation out of business (fortunately, not for long, but Your Truly had to fix it. At 3 am, which isn't my most brilliant time). Which is why I make faces when I'm told "It always works for me".

Your best best is to amass some good technical sources. People will believe anything if it's in a book, magazine or radio/TV show. The only thing that carries more weight is to have some horribly overpriced and appallingly ignorant consultant pronounce it as Gospel. Even if one person's ego is so wrapped up in a position that they cannot conceive of letting go, "authoritative" sources will usually carry weight with the Powers that Be.

Of course, you could just out-clever this guy. Instead of doing cloning "wrong", suggest that the project would benefit from a general purpose cloner like dozer (sourceforge.net). That way you can avoid having to write "wrong" code, and you might even find that Dozer is a useful tool in its own right.




Customer surveys are for companies who didn't pay proper attention to begin with.
T. Huy Nguyen
Ranch Hand

Joined: Nov 02, 2010
Posts: 57
Andy Williamson wrote:

-He told me never to use super.clone() when overriding the Object.clone method, suggesting instead that I should use a constructor. (Unless your class is final, a constructor violates the clone contract.)
-He told one developer to write a isGreaterThan and isLessThan method. He must have forgot about the Comparable interface.
-He used java.rmi.RemoteException outside the context of any RMI.
-He wraps all his exceptions into one SoftwareException, thus preventing the caller whose catching the exception from knowing what actually went wrong.
-He told the chief engineer that a List prohibits duplicate objects. (They don't. A Set does.)
-He prefers bug-prone methods like this, "Object objectFromXml(ObjectTypeEnum type, String xml)", as opposed to a safer method like, "<T> T objectFromXml(Class<T> clazz, String xml)".
-His view of good design regularly contradicts nearly everything I've read, including the oft-cited Effective Java by Joshua Bloch.
-Etc.


Perhaps he known more "old" Java stuff and even not aware of or not familiar with things like Comparable or generic. If so, in my opinion, you can try to introduce it to him by preemptively presenting and defending your suggestion before he can show his idea. And if he still disagree, reply him with his own words "it always works for me". I'm half joking there but seriously, to your code's external component/client (= your lead developer), implementation is not important and he don't need and shouldn't worry about implementation details.

Last but not least, while I'm not against following best practices, it's still good to understand why in some cases other people decided NOT to. I remember entity bean was once considered a best practice...




My material for SCJP (2008), SCWCD (2010), SCBCD (2010). About me
Lee Kian Giap
Ranch Hand

Joined: Jan 23, 2008
Posts: 210
Forget about it, after 3 years of industry experience, more or less you will meet this kind of people. Even you may meet someone who is senior than you, even he don't know Java, he can tell you Java is easy "only Create, Read, Update, Delete".

Remember one thing, working is for salary, for three meals a day, save your time for other important thing which can earn you more income or even passive income to move out from rat race. When you are rich, "Money work for me", no more "Comparable, Generic work for me". Move to a higher pay job rather than keep argue with senior, this is wise, in this world money is more important than Java.

SCJP 6, SCWCD 5, SCBCD 5
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 36453
    
  15
Lee Kian Giap wrote:Forget about it, . . . in this world money is more important than Java.
That looks like strange advice to me.

Obviously you need money, otherwise you won't get your "three meals a day", but money is by no means the most important feature of a job.
Lee Kian Giap
Ranch Hand

Joined: Jan 23, 2008
Posts: 210
Campbell Ritchie wrote:
Lee Kian Giap wrote:Forget about it, . . . in this world money is more important than Java.
That looks like strange advice to me.

Obviously you need money, otherwise you won't get your "three meals a day", but money is by no means the most important feature of a job.


Sorry to confuse you, the point I try to bring out is simply don't keep arguing with person who have higher position than you if they don't accept your opinion. I will say no point, you hurt yourself more, human egoism and bureaucracy is there, unless you are able to climb above him.

I don't mean that you just keep quiet, you have to suggest because is your duty, but not into conflict. It is because when conflict comes, you make yourself feel uncomfortable. When you know you are right, and from those book such as Effective Java written by IT Expert prove that you are right, that's it, you can't force your senior to accept you if he don't. It is just like the Author of the book Effective Java, will he force everyone to accept his best practice ? No, let go, and complete the job, and get the salary.

Or if you really want to make him accept, write a blog, create this debate on different forum, as many as you can, until your topic can rank in top 10 of Google ... then hope that your senior one day when he search the web , he find the majority prove that you are right , and he himself persuade that he is wrong.

Don't let the conflict burnt yourself, you still need salary. Unless you prepare to change job if anything bad happens.

Kaustubh G Sharma
Ranch Hand

Joined: May 13, 2010
Posts: 1268


=
-He told me never to use super.clone() when overriding the Object.clone method, suggesting instead that I should use a constructor. (Unless your class is final, a constructor violates the clone contract.)
-He told one developer to write a isGreaterThan and isLessThan method. He must have forgot about the Comparable interface.
-He used java.rmi.RemoteException outside the context of any RMI.
-He wraps all his exceptions into one SoftwareException, thus preventing the caller whose catching the exception from knowing what actually went wrong.
-He told the chief engineer that a List prohibits duplicate objects. (They don't. A Set does.)
-He prefers bug-prone methods like this, "Object objectFromXml(ObjectTypeEnum type, String xml)", as opposed to a safer method like, "<T> T objectFromXml(Class<T> clazz, String xml)".
-His view of good design regularly contradicts nearly everything I've read, including the oft-cited Effective Java by Joshua Bloch.
-Etc.




I also saw many people don't having any knowledge about the technology but still they're on the key post...But they face problem(if they're not very lucky) pretty soon (like the time of recession)...I also agree with that knowledge of technology is important but sometime we forget to take many important skill with us which might is shown by others. So there's no need to be dishearted by seeing someone by achieving more without having much skill..Better to sharp yourself and fixing you wakeness can make your day..(kinda bookish but works)


No Kaustubh No Fun, Know Kaustubh Know Fun..
Lee Kian Giap
Ranch Hand

Joined: Jan 23, 2008
Posts: 210
In addition to my above opinion, I share my bad feeling in early years of job

Here is one of the example that I share with you, the most simple thing in Java.

My opinion to my senior (even the newbie know this) that using List as a Class is wrong, get what I mean ? See below:

my senior:


my opinion:


I keep argue on this, and a lot of code in the application all using List as Class, you know how difficult to develop it ? how terrible to debug it ? But, do you know that the system use by more than 10 company and more than 50,000 user which doing transaction on that system everyday ? It keep earning money for the boss for every transaction happen on that system.

What response I get you know ?
Senior ask me :"the application got bug ? the application hang ? the application fail ? No, right ? So what's wrong with ArrayList instead of having lot of class file ? I use ArrayList and write all code in JSP without servlet, when user need changes, I change it and deploy immediately, no server restart needed ! You use classes every place, more and more file, every change which need immediate upload need to build and server restart."
Senior continue ask me :"How many yearSSS of experience you have?"
I answer:"1.5 years"
Senior say:"That's why!"

In addition to that, I also argue on the database design, no relational constraint which causes all rubbish data inside there, not using CVS/SVN to manage code ... end up ... I get a warning letter from management level ... said that "Our company don't encourage this kind of attitude ... ... As a junior, job scope is to fulfill ... ..."

At last, I tender resignation letter and leave. I spend one month to get the next job, one month without salary is a difficult feeling for me, I have to tight my belt ... I get pressure from my family

Do you know what is the current position of the senior who use bad practice ?
Become a MANAGER earning big salary, so you get what I mean ? Company is setup to earn money from customer, not setup for you to implement best practice.

... ... this is the 2 cents experience of mine ... ...
Kaustubh G Sharma
Ranch Hand

Joined: May 13, 2010
Posts: 1268

Lee Kian Giap wrote:In addition to my above opinion, I share my bad feeling in early years of job

Here is one of the example that I share with you, the most simple thing in Java.

My opinion to my senior (even the newbie know this) that using List as a Class is wrong, get what I mean ? See below:

my senior:


my opinion:


I keep argue on this, and a lot of code in the application all using List as Class, you know how difficult to develop it ? how terrible to debug it ? But, do you know that the system use by more than 10 company and more than 50,000 user which doing transaction on that system everyday ? It keep earning money for the boss for every transaction happen on that system.

What response I get you know ?
Senior ask me :"the application got bug ? the application hang ? the application fail ? No, right ? So what's wrong with ArrayList instead of having lot of class file ? I use ArrayList and write all code in JSP without servlet, when user need changes, I change it and deploy immediately, no server restart needed ! You use classes every place, more and more file, every change which need immediate upload need to build and server restart."
Senior continue ask me :"How many yearSSS of experience you have?"
I answer:"1.5 years"
Senior say:"That's why!"

In addition to that, I also argue on the database design, no relational constraint which causes all rubbish data inside there, not using CVS/SVN to manage code ... end up ... I get a warning letter from management level ... said that "Our company don't encourage this kind of attitude ... ... As a junior, job scope is to fulfill ... ..."

At last, I tender resignation letter and leave. I spend one month to get the next job, one month without salary is a difficult feeling for me, I have to tight my belt ... I get pressure from my family

You know what is my senior position now ?
Become a MANAGER earning big salary, so you get what I mean ? Company is setup to earn money from customer, not setup for you to implement best practice.

... ... this is the 2 cents experience of mine ... ...


Interesting Story
T. Huy Nguyen
Ranch Hand

Joined: Nov 02, 2010
Posts: 57
Interesting story, but I keep wondering if you didn't argue with your senior then, for money is more important than Java, would you be where you are today?
Lee Kian Giap
Ranch Hand

Joined: Jan 23, 2008
Posts: 210
T. Huy Nguyen wrote:Interesting story, but I keep wondering if you didn't argue with your senior then, for money is more important than Java, would you be where you are today?


Yes, I am where I am today, what senior want is "Getting Things Done". Just that easy, they happy, you get promoted. Get my point?

Again, as mentioned above, you suggest, you give opinion, you know you are right, you don't need to argue with them, you don't need to force them to agree with you, really, no point. You know you are right, you keep the knowledge, use it when you have chance, because you got the ability to spot all this bad practice. If they don't allow, just let go, use what they want, when problem comes, they blame you, worst come to worst, you change job, whose fault? their fault! Right? If nothing happens, they happy, you happy, two win situation, they get promoted, you get promoted ... got it ? bureaucracy (unless your company organization culture, and team structure is different, you report directly to director instead of going through few level of barrier), you wish you can cross above your senior ? how high is the chance ?

Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29220
    
135

I think it depends on the company. It's unfortunate that "junior" people are treated as people without ideas where you work. I can't tell you how many times someone junior to me as had a great idea/suggestion. That's how a team grows together.

I did a lot of process improvement on my team when I was one of the most junior people as well. Respect doesn't just come from age/number years experience. Picking a specific area to focus on/show why another approach is better is often useful. It doesn't work everywhere there. Some places don't care which is a major cultural problem. (corporate culture, not where you live culture)
Mike Isano
Ranch Hand

Joined: Jan 19, 2007
Posts: 144
Lee Kian Giap wrote:
he can tell you Java is easy "only Create, Read, Update, Delete".


For CRUD applications that statement is correct.

Lee Kian Giap
Ranch Hand

Joined: Jan 23, 2008
Posts: 210
Mike Isano wrote:
Lee Kian Giap wrote:
he can tell you Java is easy "only Create, Read, Update, Delete".


For CRUD applications that statement is correct.



This statements only partially correct.

Most application which involve database have CRUD operation, for those operation is easy for us, only JDBC or ORM to cater CRUD code. Imagine your senior is a System Analyst with Oracle DB cert who don't even able to handle Classpath problem, how can he throw such a statement to you. Between, that is only one layer of the whole Architecture, and in that project I have implemented Abstract Factory Pattern, Observer Pattern, and even debug the Tomahawk JSF extension's Date component polymorphism exception. Do you think that my senior should say that to me? Can I reply him that Oracle Database very easy, only SQL, create Index, Grant privilege ?
rags fry
Greenhorn

Joined: Apr 07, 2009
Posts: 1
Sometimes we need to wear the hat of Tester (Validator) and put out a case which points out the flaws of the design/coding. A test case is never far away.
Just a small chat with Tester might work as invisible help.

Conflicts within the project especially with folks who are not open to other persons ideas aren't constructive and leave a bad taste. Sometimes some innovative methods always help. Like a team review, where you propose something and ask the rest to point out the flaws and record the minutes.

Thanks,
Raghu




R. Grimes
Ranch Hand

Joined: Aug 23, 2009
Posts: 42
Believe it or not, your dilemma is not one that is unique to "newbies" in the IT field. I've been developing software for 27 years and, most of my career, my bosses have been guys whose skills are quite a bit antiquated. In fact, my current boss' only development skill is RPG, a procedural language. I did that myself for 17 years, but have spent the last 10+ years with Java and frameworks like Spring and Apache CXF. In addition, I develop client-side AJAX, XSL, Flex, Flash. So, do I feel like maybe I ought to be calling the shots, since I have OO experience and a far greater skill set? Sure, but the reality is you're probably always going to have a boss/lead whose software skills are not up-to-date.

I've had two jobs where, had the lead listened to me, they wouldn't have ended up throwing aways millions of dollars on a project gone bad. But, more often than not, the arrogance of being the lead prevents them from listening to good advice from the underlings.

So, what do you do?

First, don't get your nose bent out of shape over things that you can't control and are not responsible for. Sometimes the hardest thing to do is to know something can be done a lot better, but not pressing the issue because you don't have the final say. Offer your input, explain why you are in favor of your solution, and then let it go. I run into this a lot with my boss creating a DB that is horrendously designed, but I still have to make my server programs access and update it efficiently. Quite the challenge. Does it piss me off? Sure, but I allow myself about 5 minutes of venting to computer monitor, and then get on with the job.

Second, and most importantly, do some CYA. Keep all emails where instructions are given to do things in a "bad" way. If the instruction was not given in a written form, then keep a log or minutes of meetings with their date/time. This way you have proof, when the software begins functioning poorly in production, that you were only following instructions. Along this same line, shoot quick (emphasis "quick") little emails to your lead indicating your disagreement. They should be quick and to a "single" point. For example, "Hey ???, would it be ok to use the Comparable interface instead of creating isGreaterThan and isLessThan methods? ...." Keep these emails and any responses. By following this tactic, you provide yourself with CYA so that when the old proverbial feces hits the fan, you are free and clear.

Lastly, it's important that you learn to let go of things you can't control, and be happy about it. If you let your dissatisfaction with the decisions become part of your personality at work, you will never grow into a lead position yourself. Executives and managers will look to happy, glad handing, back slappers as leads before they will look to highly competent, disgruntled, "know-it-alls".

Technical people can often be overly anal about "being right" and making sure everyone knows they are right, and are the smartest guy in the room. My best advice to you, as an old timer in this field, is don't let that need get in the way of your being happy at work and enjoying what you do. Do your best within the area you do control, offer your best advice once and only once when you disagree with something, and be happy that you have a job.

Ron



T. Huy Nguyen
Ranch Hand

Joined: Nov 02, 2010
Posts: 57
Many thanks Ron. Those are really good advices!
Won Cho
Greenhorn

Joined: Dec 22, 2010
Posts: 6
This is my first post in Java Ranch ^_^

I agree w/ many advises here. The only thing you can do is "suggest" new technique to your tech lead. Heck, I didn't even know about cloneable interface and would suggest the constructor way. Even if using old solution like using constructor to create clones is not that big of a deal. You got few more lines of code which can be generated very quickly~ For me, I would watch out for how your tech lead architects the project. The good one's would try to balance out how to make it parallel development along w/ "ility" factors. For example, separating the Web Layer, Service Layer, DAO Layer, and etc... This is much bigger impact than arguing over should I create lessthan or comparable interface. Also, remember the phrase "Everything can be better" when coding. Whatever solution you come down to, I'm sure someone can come up w/ a better one. However, project is tied to budget, schedule, and requirements. So, as a team must decide a solution and execute it. I'm guessing that your techlead won't care if you use cloneable or comparable interface, I would leave that to the individual developers. Later, I would set up a code review and only mention the one's that can be problematic.
Collin Dugas
Ranch Hand

Joined: Jul 10, 2009
Posts: 91
um, I'd say find a better place to work at.

You have a team of developers working on Java for first time for a critical project where bugs could hurt or KILL people? Either you're bluffing or the place has got some serious issues.

The place doesn't sound fun at all

People here get pretty worked up on language so I'd only say run from there man.

PS : How I hate seeing folks fighting over variable and method names.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18103
    
  39

Collin Dugas wrote:um, I'd say find a better place to work at.

You have a team of developers working on Java for first time for a critical project where bugs could hurt or KILL people? Either you're bluffing or the place has got some serious issues.

The place doesn't sound fun at all

People here get pretty worked up on language so I'd only say run from there man.

PS : How I hate seeing folks fighting over variable and method names.



To be fair, this is told from one point of view -- and even then, nothing jumps out as really that bad.

Cloneable or new constructor, Comparable or not, RMIException for non-RMI, List vs Set, are not only minor; and in some cases even arguable. Architecture, design, etc. is at a level much higher than these -- which seems just like details that can be debated at the code review.

Furthermore, it is actually very good considering that the lead is new to Java.

Henry
Collin Dugas
Ranch Hand

Joined: Jul 10, 2009
Posts: 91
Henry Wong wrote:

To be fair, this is told from one point of view -- and even then, nothing jumps out as really that bad.

Cloneable or new constructor, Comparable or not, RMIException for non-RMI, List vs Set, are not only minor; and in some cases even arguable. Architecture, design, etc. is at a level much higher than these -- which seems just like details that can be debated at the code review.

Furthermore, it is actually very good considering that the lead is new to Java.

Henry


What kind of mission critical projects get assigned to a team where no one knows Java?
A lead developer does not know if there lists allow duplicates or not? Thats basic CS 101..
IMO a good design does not depend on the designer having prior experience or not and the above debates seem to indicate he does'nt..
If the response to your questioning is "well, in my experience its always worked to...," then I can say the place is not open to free debate..

I'd still stand by my advice but thats just me.. YMMV..
arulk pillai
Author
Ranch Hand

Joined: May 31, 2007
Posts: 3216
Little knowledge can be dangerous. I am currently working at a place where my manager thinks he is technical and intervenes in technical decision making process If you speak to him for 5 minutes you may think that he knows his stuff, but if you ask a few questions and spend say 15 minutes, you will realize that he is full of hot air. Getting things done is not only all about technical skills, but also about soft skills to to be tactfull, understand the politics, slowly changing things and earning the reputation, etc.


Java Interview Questions and Answers Blog | Amazon.com profile | Java Interview Books
Lee Kian Giap
Ranch Hand

Joined: Jan 23, 2008
Posts: 210
arulk pillai wrote:Little knowledge can be dangerous. I am currently working at a place where my manager thinks he is technical and intervenes in technical decision making process If you speak to him for 5 minutes you may think that he knows his stuff, but if you ask a few questions and spend say 15 minutes, you will realize that he is full of hot air. Getting things done is not only all about technical skills, but also about soft skills to to be tactfull, understand the politics, slowly changing things and earning the reputation, etc.


Yes, you are right ! SOFT SKILL !

Developer usually lack of soft skills to persuade others to accepts their "Best Practice". Most developer desires others to say that "You are expert! You are right!". Especially when developers meet those senior who is lack of technical skills but pretending and intervening the decision, they will always complains in the heart "What a Sly Dog!". If you understand human behavior, you let them taste a portion of the cheese, give them self-gratification without pointing out their weakness, or even more praise them for knowing ... then you realize that things change easily!
Dan Walin
Ranch Hand

Joined: Nov 11, 2003
Posts: 109
I just had to give my general opinion on this discussion: I have worked for 28 years in development at a large corporation. During that time I have been new and senior and have worked with great people and people who did not know what they were doing. If you goal is to succeed (which to me means remain employed, doing good work and being rewarded for it), you must learn to get along. If you have a senior person who is wrong or confused, privately offer advice and help. Competing with them or challenging their ability does not help. Their human nature is to defend themselves and fight back. Offering help and not telling they are wrong is often the way to go. I can just picture if someone said "you are wrong" to me what my reaction would be compared to if they came to me and said, "here's the way I would have coded that and here is why". It's not what you say so much as how to say it and when.

If the project is to succeed you must work together and not against each other. That may mean compromising. The code will not be 100% exactly right according to standards, but there is a better chance that it is completed on time and meets the user specifications than if developers are trying to prove they are right over small details. By arguing over every detail a person can give the appearance of putting their ego and opinion above the success of the project. I can guarantee that nothing I have worked on in my years has been perfect, but we have completed many projects successfully and have made major contributions to the corporation over the years just by working as a team and not as separate developers with our own agendas.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 29220
    
135

I mostly agree with what Dan said and think it is an excellent point.

Dan Walin wrote:The code will not be 100% exactly right according to standards, but there is a better chance that it is completed on time and meets the user specifications

And that it is maintainable and doesn't blow up later. Dan probably implied it, but I doesn't always go without saying. Some companies focus so much about "completing on time" that quality gets sacrificed. If something blows up in production or every time an error condition happens or the like it wasn't really completed on time. We just gave the illusion of that being so.
Dan Walin
Ranch Hand

Joined: Nov 11, 2003
Posts: 109
Yes. I definitely did not mean to sacrifice quality. If there are many approaches that produce the same result, then arguing over them is not always that productive. Discussions and constructive feedback should always be part of every team effort of course. I was mainly commenting on a person being a "squeeky wheel" just for the sake of proving themselves. That does not usually help and can sidetrack progress. We had a person on our team that was like that - he wanted to argue with everyone and debate everything. Even very minor issues. He is no longer with the company.

If the senior person was completely incompetent, I think that would be another matter and I would discuss it with management. But I did not get that impression from the original posting.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Conflict with the Lead Developer
 
Similar Threads
Software Development Engineer : Permanent in Kirkland, WA
Senior Software Engineer Java/Oracle (architecture/design/development skills) Hightstown NJ 21Sep09
Tech Leads with Agile/XP background-Cincinnati, OH
Software Development Engineer
Software Development Engineer : Permanent in Kirkland, WA