How do I raise a quality concern when there is a contentious history?

Question

At my work, I am increasingly concerned about code quality, but find I cannot fix it. I am mostly thinking about the large statement of work incoming and developers I have worked with.

I feel some background on my work situation is relevant. I consider my coding ability to be better in terms of OOP, but less when it comes to variety of technology/framework. I am technically at a lower pay level/job title, and also physically younger than most (I can be most of my co-workers' children).

Things I have tried in the past, but did not work that well:

I have tried to raise coding concerns via code reviews. But usually, no one really says anything and I end up saying a lot. At some point, I just learn to shut up (I feel I have offended others, and/or they just don't listen to me unless manager backs me up).

On two occasions, an issue would get too heated and confrontational between myself and another developer. I build my standpoints by researching the best coding practices online and write emails to them, inviting discussion, all to be countered with "Don't trust the internet" and "experience".

I have also privately relayed concerns with my manager, but I feel at this point I have already exhausted that venue as well.

Questions:

1. How do I raise legitimate concerns and give critiques and have them be considered, accepted and/or ultimately addressed?
2. Perhaps I have already ruined the chance to have a cordial work relationship with some developers. How do I change/fix how others perceive me, so they will listen to me again?

Answer 1

How do I raise legitimate concerns and give critiques? (and have them be considered, accepted and/or ultimately addressed)

• In person.
• One-on-one.
• And only for things that Really Matter.

What you need to realize is that you are not going to significantly change how other developers code. Religion aside, ever heard of the Serenity Prayer? How other developers code is for the most part, outside of your control and always will be, and the sooner you can be at peace with that, the better for everyone.

Perhaps I have already ruined the chance to have a cordial work relationship with some developers. How do I change/fix that? (how others perceive me, listen to me again)

Yes, you may have amazing technical skills, but you are still really learning people skills. Empathize. Next time you think about criticizing, which you may see as trying to help someone else improve, think about it from the perspective of their needs first. What do your colleagues need? Respect for their code, recognition, an easy, fun working day. Start giving them that and you will begin to put things right.

Answer 2

How do I raise legitimate concerns and give critiques? (and have them be considered, accepted and/or ultimately addressed)

Consider how are you bringing this up. Are you believing that there is only one way to do things and thus if it isn't that way, it has to be wrong, poor or suboptimal? There can be lots of ways to do things and it may be that you are not understanding someone else's perspective here for one point.

Consider how well are you using these habits from 7 Habits of Highly Effective People:

Habit 1: Be Proactive
Habit 2: Begin with the End in Mind
Habit 3: Put First Things First
Habit 4: Think Win-Win
Habit 5: Seek First to Understand, Then to be Understood
Habit 6: Synergize
Habit 7: Sharpen the Saw

Note, habits 2,4, and 5 for a few that may be worth considering here in your environment. What specific ending do you want when you bring up concerns? How well do you understand the trade-offs of doing things in various ways? Some companies may have to make tough choices and so while you may come from the academic world where there is lots of time to do things well, that isn't necessarily how companies run in the real world.

Perhaps I have already ruined the chance to have a cordial work relationship with some developers. How do I change/fix that?

How to Win Friends and Influence People has some ideas that I'd suggest you carefully consider these ideas:

Fundamental Techniques in Handling People

1. Don't criticize, condemn, or complain.
2. Give honest and sincere appreciation.
3. Arouse in the other person an eager want.
4. Never show others that you are not interested in what they have to say.

Six Ways to Make People Like You

1. Become genuinely interested in other people.
2. Smile.
3. Remember that a person's name is, to that person, the sweetest and most important sound in any language.
4. Be a good listener. Encourage others to talk about themselves.
5. Talk in terms of the other person's interest.
6. Make the other person feel important – and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

1. The only way to get the best of an argument is to avoid it.
2. Show respect for the other person's opinions. Never say "You're Wrong."
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions to which the other person will answer yes.
6. Let the other person do a great deal of the talking.
7. Let the other person feel the idea is his or hers.
8. Try honestly to see things from the other person's point of view.
9. Be sympathetic with the other person's ideas and desires.
10. Appeal to the nobler motives.
11. Dramatize your ideas.
12. Throw down a challenge.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Call attention to people's mistakes indirectly.
3. Talk about your own mistakes before criticizing the other person.
4. Ask questions instead of giving direct orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give the other person a fine reputation to live up to.
8. Use encouragement. Make the fault seem easy to correct.
9. Make the other person happy about doing what you suggest.

Do you ever point out where things go right? Do you ever recognize good work that others do? If not, then I could easily see where you are causing a lot of problems trying to bring in things without realizing how well or not so well is that for this team and situation. Some best practices may not always be great as not every place will have an environment where you have what may seem like an unlimited budget and time to do things with the latest technology, great machines and no tight deadlines.

Answer 3

Congratulations. If you can leverage it, you have an opportunity that can launch your career into the stratosphere.

What sorts of things do you think go on the resumes of highly-qualified engineers? Could it be things like implementing practices from scratch on a team, educating teammates, etc.? You don't get an opportunity to do these things on a team that already scores high on the Joel Test. So landing on a team of people who don't care about those things is a blessing in disguise--there are all of these Senior Engineering things waiting to be done, and exactly one person who cares about doing them.

If you're going to leverage this opportunity, you'll need to adjust your thinking somewhat.

1. Realize your teammates will never care as much about code quality and good practices as you do. Your expectations have been ratcheted up by sites like this one that imply that most developers are constantly pushing themselves to learn the latest and greatest thing and to do things in line with "best practices." The reality is that the stuff we all care about here doesn't even register on the radar of the vast majority of programmers. Learn to accept that your changes are likely to be small at first, but every change that makes things better is significant.
2. Learn to think about it from their POV. Yes, it sounds great in theory to just rewrite things from scratch to use good code quality. But writing bad code is hard, and you're asking them to throw away hours and hours of slogging away. In addition, your new code is not going to be bug-free, so there's a whole QA process that's going to have to be redone. Even if you're not advocating a complete rewrite, the nature of bad code is that anything you touch in one area could bring down the whole house of cards, so even refactoring carries a high risk. Their experience tells them about the risk of trying to fix things, but not the rewards.
3. Their current approach is already working (from their perspective). They are already meeting whatever expectations management has of them without using your new-fangled ideas. Keep in mind, your manager has no idea who is right and who is wrong. He does, however, know who has generated a lot of revenue and who hasn't. I suspect you may fall into that latter category. Also, keep in mind that for your manager to support a change he needs to work his way around to the idea that the developers and practices he's been supporting all this time are wrong. This is hard for him, because he needs to reevaluate his own history and take a more negative view of the history of people he probably likes.

Here are some things that you can do to build trust and improve your own situation.

1. If possible, get your own application or sub-system to work on. Usually people don't mind if you implement clean code in your own space--they just aren't interested in changing what they are doing. Put all your ducks in a row so that your sandbox is ready to shine when anyone looks at it. Document everything, have tests if you can, etc. The first time I did this, I went on vacation--this was after what was supposed to be the delivery date but before a new deadline--and left a manual for other developers to use my system. Everything went off without a hitch while I was gone. Further, that subsystem got a reputation for being the most reliable in the entire application.
2. Find polite ways to "make" people do things the right way. This is easier if you have your own subsystem or application. For example, once my boss said "we should probably start thinking about using version control," I promptly put all my sites into version control both locally and on the network, and people needed to use version control if they wanted their updates to be propagated to all environments. If someone commented that something that should have been in the wiki wasn't right, I'd reply that I didn't find the relevant information there--and I'd offer to add it.
3. You actually have to be better, faster, and more bug-free than your coworkers. I rewrote our entire framework in a new language, and even while I was doing that I was still able to meet aggressive deadlines and my framework did things the old one never dreamed of. Still, in the short term every time there was a bug the new framework had that the old framework didn't have, I'd have to answer uncomfortable questions about why. In the longer term, the framework has proved itself to be lightning fast to develop in and far more bug-free, but the challenge is for you and your framework to survive that long.
4. Learn those frameworks you feel you're weak in. If you want to act as an architect (and to meet this challenge, that is what you will have to become), you need to understand the concepts behind them. You may or may not want to use them "as is," but if you are going to build your own architectural solutions you need to understand why existing ones work.
5. Realize that you will probably need to move on to reap the full benefit of what you're going to accomplish. Because your teammates will probably never care about code quality per se, you're unlikely to be appreciated or compensated based on any accomplishments in that area where you are. What you're doing now is garnering valuable experience that you've lucked into an opportunity to acquire, and then that experience will go on your resume to earn you more money and, more importantly, a spot on a team that has the same values you do.

Please also see my answer in How to be constructive and solve problems in an unconstructive environment.

Answer 4

It seems like in writing the question you've figured the things that you've been doing weren't working. So, if you haven't already, stop doing them. It doesn't matter if you were technically right or whether what you were doing may have worked in a different environment: it wasn't productive, so stop.

Re your questions, in my opinion, regardless of the rights and wrongs of the situation, you need to keep quiet for a while, listen to your colleagues and your manager, and establish yourself as someone who can successfully work on what they're asked to and who can form productive working relationships with other team members. If there is a lot of work on, it is likely expected that team members will take the load and not rock the boat.

How do I raise legitimate concerns and give critiques? (and have them be considered, accepted and/or ultimately addressed)

Establish yourself first. You clearly can't get your technical ideas across to your colleagues and influence the team as a whole, but use them as much as you can within your day to day work. Demonstrating that you get your work done faster and more reliably than your colleagues will put you in a good position in the future to get your ideas across.

I had a similar experience recently where I couldn't convince my manager to adopt my ideas, but used them myself and at the end of the project the manager did notice that the project had gone well, and commented on it (without me asking). If your manager or your colleagues don't notice your good work, and aren't then receptive to discussing it, you don't have a hope of getting your ideas considered nevermind addressed.

Perhaps I have already ruined the chance to have a cordial work relationship with some developers. How do I change/fix that? (how others perceive me, listen to me again)

I doubt that. Most people just want colleagues who can do their job and who they can get along with. If it turns out that you're both of those things in your colleagues' view, I don't see there's a problem. The key thing is whether you can stop talking and start listening. Once again I make no judgement about the technical rights and wrongs of the situation. If you're right about your technical ideas, you may well flourish in other companies.

Looking to the future, in my opinion one key question is how much you're learning. Let's say you establish yourself, stop talking and start listening more. How much do you then learn from your more experienced colleagues, technically, and in terms of things like how projects are managed, how business is done, etc? Are you then able to engage in productive, back-and-forth discussions with colleagues around the work you're doing, and, eventually around the work of the team as whole, discussions where you all learn something?

Something that struck me as significant in your post was when you said your ideas were countered with "Don't trust the internet" and "experience". It seems like you have a lot of interests and ideas, and want to be in a high-achieving team. If after adjusting your talk-listen balance you aren't in an environment which values honest and open discussion of ideas above years-in-post, then it might not be the right place for you. Of course in the meantime it makes sense to get on with the work at hand and with your colleagues.

(I have deliberately tried not to make this answer software-specific, in view of the comment by Pheonixblade9 under the question.)

Answer 5

On two occasions, an issue would get too heated and confrontational between myself and another developer. I build my standpoints by researching the best coding practices online and write emails to them, inviting discussion, all to be countered with "Don't trust the internet" and "experience".

One of the things that a new person entering any industry needs to learn is humility. The statements "don't trust the internet" and "experience" are actually completely valid whether you know that yet or not. More to the point, you appear to be butting heads against people that have far more experience than you... They simply won't like a much younger person getting in their face.

In their eyes, you don't have the "battle scars" that comes from spending an unholy number of late nights beating your head against a wall trying to fix something that just should have worked. You probably haven't sat there for hours looking at a piece of code such as var x = 1 + 1; and been baffled by why the program insists that x actually equals 3. Once you've done this, not just once but over a period of years, then you start to figure out that the internet is often wrong. That the ideas and concepts presented might be good solutions .. but in very specific situations.

I know I've seen a large number of junior guys rushing off to implement the latest thing they've read about, often written by some other junior guy, without actually understanding the consequences. I've also spent quite a few late nights trying to salvage a project when I've been called in to clean up their mess. To that end I've developed a policy of "if you can't explain it in plain language and convince me that this solves the problem in front of us then you don't understand it enough and therefore it doesn't belong."

That said, the key here is really in how you approach things. Telling a dev who has been around the block several times that they are wrong will just never work. Trying to justify that with a link to an article or even saying "Martin Fowler said..." again doesn't work. Experienced guys learn to judge a piece of code or an approach on it's merit, not on who the messenger is.

Instead, you need to approach this from a totally different direction. Namely, have them teach you why your idea is wrong. This is essentially reverse psychology and in asking them to point out your deficiencies (which they will happily do) one of two things will happen. Either they'll realize that their approach is bad and therefore end up agreeing with you OR they will educate you on why you're wrong. Both should be welcome situations.

Look at the following conversations:

Bad Way

You:: "Bob, you should have used the Inversion of Control pattern
here, Martin Fowler in his paper at www.wherever.com says you should. What you did needs to be completely rewritten."
Bob:: "It works just fine. Don't you have a class to go refactor? Maybe CS 101?"
You:: "But he said..."
Bob:: "Be gone welp!" aside to Jim::"What are they teaching these kids?"

Not exactly a good approach as it immediately puts Bob on the defensive. Further it shows that you simply lack experience and therefore credibility by only using a reference to someone else's opinion to justify your statement. However, if you did something like this:

Better way

You::"Bob, what would you think about using an IoC pattern here? Wouldn't that help make testing easier? We could set a config parameter so we know what environment it's in and remove all this other code."
Bob::"Maybe... Of course not a lot of people understand how to do IoC right and usually end up with really hard to read code. In this case I'd rather have something that was easier to understand."

Much better approach. You have made a suggestion and presented a clear reason of why that applies while deferring to Bob's experience. Rather than be on the defensive Bob is now engaged and will naturally try to "educate" you. More importantly, you have an opportunity to give more detail in order to allay his concern. Over the course the discussion he might change his mind or you will learn some of the pitfalls with what you read. Either way you should learn something important.

To fix things at this point you need to do three things. First, stop quoting the Internet. Second, ask questions, don't make statements. Third, know what you are talking about before you bring it up. This means actually play with that "coding practice" and use it in a test project so that you know what's wrong with it.

Answer 6

Try a different perspective. When you are not in a position to win, then do not create friction.

You cannot change your age. Your job senior title comes with patience. Others need to trust your expertise. That comes first.

It doesn't matter what you think of your skill level, or how the quality of your work is. Because communication is the response you get. What matters, for your particular problem, is what they think of you.

Solve that first. And it will be much easier to champion any improvements you see appropriate.

Answer 7

Regarding your questions:

1. That takes time, don't rush in, and keep calm.

   It's all about finding the right time and the right place to raise such issues. No one likes a smart person and people won't listen and disregard what you say because they sense you are one.

   In a work environment you have 2 jobs. The job you are doing on a day to day basis and the second is the one where you build relationships and trust.

   So, if you're good at you job and respectfully you want raise an issue without the respect and support of your co workers most likely no one will listen and you be the odd one out.

   Best advice I can say is be patient. You tried raising an issue and it didn't go as planned so take a breather and don't let it bother you. Slowly start working on another tactical approach if you feel so strongly about raising the issue. Perhaps other people there feel the same way about this issue too, you just need to find them. It takes time.

2. Invite those developers out for an evening drink. Say its on you this time round. Most of the best work type relationships happen outside the office. Have a few drinks and relax. You find people will listen better when they are out of the office and relaxed. Especially in a Bar. Talk about common things like sports or films or pets or whatever. People will relate to you much better.

   Maybe after sometime when you go out again for a drink from work perhaps then you talk about the coding standard issue. From my experience you will stand a better change for someone to listen to what you have to say.

Good luck

Answer 8

Maybe you are wrong about your concerns and the code quality issues that you are raising were specific choices made by informed and experienced engineers.

Consider the following scenario:

A team has management pressure to rush out a project and because of this pressure they cut some corners on design and development time.
Then to add salt on the wound, management hires cheap inexperienced team members with an expectation this will to improve team productivity but all this new member does is complain about the quality of the code and the design choices.

I'm not saying this is your story, but it could be.

Remember these are people you have to work with every day -- be respectful and considerate, there may be more to the story -- you will be better served and learn more in the long run if you are quick to praise and not quick to criticize.