Iyfjky

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:

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

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?

@JBKing I have heard of pick my battles and lowered my expectations a lot. Usually, I won't criticize unless I interact with a certain piece of code anyways and is affected by it. I feel I would be happy if someone tells me what I am doing wrong, so I can learn, but that's not the attitude I see here. Since I don't have as much "experience", I read up on many other professionals experience and accumulate an informed decision. I have tried email with a subset of developers, but they are not receptive/didn't care to do any research. I find I have a huge problem with that mentality! — Mar 19 '14 at 0:01
You could start by changing the title to e.g. "How can I raise concerns about quality, get them considered, and get on with my colleagues". Most of the rest of the post is pretty generic already. Replace "I consider ...framework" with, e.g., "I consider my technical ability to be quite good in specific areas but weaker across the board because of my lack of experience". Etc. You still probably need to say somewhere that you're in the software industry for context but I think that @Pheonixblade9 is quite right: you'd get a wider range of answers if you made your questions generic. Good luck! — Mar 19 '14 at 0:31
What exactly is it that worries you about the "code quality". Please be very specific! — Mar 19 '14 at 7:51
asked and answered in multiple questions at Programmers, eg: How do you make people accept code review? — Mar 19 '14 at 7:58
questions about involving management to support this also have been asked and answered at Programmers, for example: How to convince my boss that quality is a good thing to have in code? — Mar 19 '14 at 8:13

Jim G. 11.8k105373 · Answer 1 · 2014-03-19 16:29:49Z

up vote
29
down vote

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.

edited Mar 19 '14 at 16:29

Jim G.

11.8k105373

answered Mar 18 '14 at 23:16

Brad Thomas

2,744820

I did not know what Serenity Prayer was officially called. I have seen the saying before (and reading it gave me a good chuckle, in a good way). On your 2nd point, I feel like some of what you are saying means letting code quality go(?) What is a code review if you can't give feedback? For example: "you could use named constants here instead of magic numbers because it will be more obvious to the next developer. Or better yet, enums..."
â€“Â user1766760
Mar 19 '14 at 0:39

(Breaking out my comment into two, because it's too long and awkward to keep in one.) I do fully appreciate your feedback on how to put things right again and will work on giving others recognition and try to keep it light.
â€“Â user1766760
Mar 19 '14 at 0:40

5

Keep code quality as high as you can. Be as productive as you can. Give help/advice/ideas to other developers - when they ask for it. It sounds to me that the code reviews you have are meetings with several people? Ugh, how demoralizing. I'd go so far as to say those kind of code reviews are actually worse than a waste of time; being counter-productive to team cohesion. Few people take criticism well. Almost no-one takes public criticism well. Coding is very personal. It's a personal style and a personal work of art.
â€“Â Brad Thomas
Mar 19 '14 at 1:47

8

You mean I have to go sit there with x other people who are going to tell me in what ways I should change my personal style and why my art, my baby is not up to their standards. Oh joy! Yeah sign me up! Those kind of code reviews have always been a dead horse. The problem here is that you are trying nobly to make a dead horse run as you feel it should. You can't. It's dead. It's a broken system. You can only make a scene. Quit beating it, sit quiet, and listen to what other's needs are. Then you will be well placed to help them, which when executed will win you friends and influence.
â€“Â Brad Thomas
Mar 19 '14 at 1:47

4

@Telastyn "harm" is subjective. Someone who's writing sloppy code but delivering good business functionality fast is going to be a superstar to management no matter what you or I think. Try telling that person or management they are "harming the product", see how much traction you get. I'll wager you'll have the same outcome as opening poster. Besides, I'm not saying sit complacent, I'm saying focus mainly on what's within your control, and handle the provision of criticism with care and empathy... constructively, thoughtfully and professionally.
â€“Â Brad Thomas
Mar 19 '14 at 17:09

Â |Â
show 3 more comments

JB King 15.1k22957 · Answer 2 · 2014-03-19 00:24:42Z

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

Don't criticize, condemn, or complain.

Give honest and sincere appreciation.

Arouse in the other person an eager want.

Never show others that you are not interested in what they have to say.

Six Ways to Make People Like You

Become genuinely interested in other people.

Smile.

Remember that a person's name is, to that person, the sweetest and most important sound in any language.

Be a good listener. Encourage others to talk about themselves.

Talk in terms of the other person's interest.

Make the other person feel important Ã¢Â€Â“ and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

The only way to get the best of an argument is to avoid it.

Show respect for the other person's opinions. Never say "You're Wrong."

If you're wrong, admit it quickly and emphatically.

Begin in a friendly way.

Start with questions to which the other person will answer yes.

Let the other person do a great deal of the talking.

Let the other person feel the idea is his or hers.

Try honestly to see things from the other person's point of view.

Be sympathetic with the other person's ideas and desires.

Appeal to the nobler motives.

Dramatize your ideas.

Throw down a challenge.

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

Begin with praise and honest appreciation.

Call attention to people's mistakes indirectly.

Talk about your own mistakes before criticizing the other person.

Ask questions instead of giving direct orders.

Let the other person save face.

Praise every improvement.

Give the other person a fine reputation to live up to.

Use encouragement. Make the fault seem easy to correct.

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.

Buy a copy of How to Win Friends and Influence People and keep it within arm's reach of the loo or similar place. — Mar 19 '14 at 14:58
@AnsisMalins I bought it a couple months ago but have yet to sit down and read it (part of me is afraid to...) — Mar 19 '14 at 18:49

Communityâ™¦ 1 · Answer 3 · 2017-04-13 12:48:42Z

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.

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.

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.

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.

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.

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.

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.

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.

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.

I really like your answer, but it seems to me that only applies when your work is relatively isolated from others's work. For example if someone is not respecting const-correctness but you do then each time you use this other person's code it is more work for you and it decrease the quality of your code, since you would have to cast-away constantness or something equivalent. Would you still not try to change the way that other person is coding? — Mar 21 '14 at 18:01
The point is to carve out areas that are "yours" and, using good encapsulation, minimize the impact of the bad code. At the job where I talked about going on vacation above, all the code rested on a really ugly foundation of Singletons and Statics. I was given ownership of a subsystem, and I rewrote it so exactly one place knew about all that ugliness, and the rest of the code acted like it was very clean and decoupled. Whenever I got assigned a significant amount of work, if I possibly could I'd rewrite it to minimize contact with the "ick." — Mar 21 '14 at 20:41
I see, never thought about the problem this way! I'll try it next time! — Mar 21 '14 at 21:08

TooTone 1,69011130 · Answer 4 · 2014-03-19 00:17:51Z

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.)

score 4 · Answer 5 · 2014-03-23 15:41:36Z

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.

FYI - I picked on Martin Fowler (real person) in this post, in no way should this be considered a slight against him or even an opinion on his work. He is certainly an old timer with a lot of really good ideas. I used his name simply as a real reference to an "internet personality" whom people in the programming industry like to quote. — Mar 24 '14 at 14:20
Great answer - you made me want to read more exchanges between 'OP', Bob, and Jim! :-) — Jul 13 '15 at 8:05
@EleventhDoctor: thecodelesscode.com/contents is probably the best I've seen. — Jul 13 '15 at 15:02

user18099 1914 · Answer 6 · 2014-03-19 15:33:21Z

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.

Malachi 264413 · Answer 7 · 2014-03-19 17:53:30Z

Regarding your questions:

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.

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

Hogan 1011 · Answer 8 · 2014-03-19 18:02:38Z

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.

Jim G. 11.8k105373 · Answer 9 · 2014-03-19 16:29:49Z

up vote
29
down vote

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.

edited Mar 19 '14 at 16:29

Jim G.

11.8k105373

answered Mar 18 '14 at 23:16

Brad Thomas

2,744820

I did not know what Serenity Prayer was officially called. I have seen the saying before (and reading it gave me a good chuckle, in a good way). On your 2nd point, I feel like some of what you are saying means letting code quality go(?) What is a code review if you can't give feedback? For example: "you could use named constants here instead of magic numbers because it will be more obvious to the next developer. Or better yet, enums..."
â€“Â user1766760
Mar 19 '14 at 0:39

(Breaking out my comment into two, because it's too long and awkward to keep in one.) I do fully appreciate your feedback on how to put things right again and will work on giving others recognition and try to keep it light.
â€“Â user1766760
Mar 19 '14 at 0:40

5

Keep code quality as high as you can. Be as productive as you can. Give help/advice/ideas to other developers - when they ask for it. It sounds to me that the code reviews you have are meetings with several people? Ugh, how demoralizing. I'd go so far as to say those kind of code reviews are actually worse than a waste of time; being counter-productive to team cohesion. Few people take criticism well. Almost no-one takes public criticism well. Coding is very personal. It's a personal style and a personal work of art.
â€“Â Brad Thomas
Mar 19 '14 at 1:47

8

You mean I have to go sit there with x other people who are going to tell me in what ways I should change my personal style and why my art, my baby is not up to their standards. Oh joy! Yeah sign me up! Those kind of code reviews have always been a dead horse. The problem here is that you are trying nobly to make a dead horse run as you feel it should. You can't. It's dead. It's a broken system. You can only make a scene. Quit beating it, sit quiet, and listen to what other's needs are. Then you will be well placed to help them, which when executed will win you friends and influence.
â€“Â Brad Thomas
Mar 19 '14 at 1:47

4

@Telastyn "harm" is subjective. Someone who's writing sloppy code but delivering good business functionality fast is going to be a superstar to management no matter what you or I think. Try telling that person or management they are "harming the product", see how much traction you get. I'll wager you'll have the same outcome as opening poster. Besides, I'm not saying sit complacent, I'm saying focus mainly on what's within your control, and handle the provision of criticism with care and empathy... constructively, thoughtfully and professionally.
â€“Â Brad Thomas
Mar 19 '14 at 17:09

Â |Â
show 3 more comments

JB King 15.1k22957 · Answer 10 · 2014-03-19 00:24:42Z

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

Don't criticize, condemn, or complain.

Give honest and sincere appreciation.

Arouse in the other person an eager want.

Never show others that you are not interested in what they have to say.

Six Ways to Make People Like You

Become genuinely interested in other people.

Smile.

Remember that a person's name is, to that person, the sweetest and most important sound in any language.

Be a good listener. Encourage others to talk about themselves.

Talk in terms of the other person's interest.

Make the other person feel important Ã¢Â€Â“ and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

The only way to get the best of an argument is to avoid it.

Show respect for the other person's opinions. Never say "You're Wrong."

If you're wrong, admit it quickly and emphatically.

Begin in a friendly way.

Start with questions to which the other person will answer yes.

Let the other person do a great deal of the talking.

Let the other person feel the idea is his or hers.

Try honestly to see things from the other person's point of view.

Be sympathetic with the other person's ideas and desires.

Appeal to the nobler motives.

Dramatize your ideas.

Throw down a challenge.

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

Begin with praise and honest appreciation.

Call attention to people's mistakes indirectly.

Talk about your own mistakes before criticizing the other person.

Ask questions instead of giving direct orders.

Let the other person save face.

Praise every improvement.

Give the other person a fine reputation to live up to.

Use encouragement. Make the fault seem easy to correct.

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.

Buy a copy of How to Win Friends and Influence People and keep it within arm's reach of the loo or similar place. — Mar 19 '14 at 14:58
@AnsisMalins I bought it a couple months ago but have yet to sit down and read it (part of me is afraid to...) — Mar 19 '14 at 18:49

Communityâ™¦ 1 · Answer 11 · 2017-04-13 12:48:42Z

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.

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.

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.

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.

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.

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.

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.

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.

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.

I really like your answer, but it seems to me that only applies when your work is relatively isolated from others's work. For example if someone is not respecting const-correctness but you do then each time you use this other person's code it is more work for you and it decrease the quality of your code, since you would have to cast-away constantness or something equivalent. Would you still not try to change the way that other person is coding? — Mar 21 '14 at 18:01
The point is to carve out areas that are "yours" and, using good encapsulation, minimize the impact of the bad code. At the job where I talked about going on vacation above, all the code rested on a really ugly foundation of Singletons and Statics. I was given ownership of a subsystem, and I rewrote it so exactly one place knew about all that ugliness, and the rest of the code acted like it was very clean and decoupled. Whenever I got assigned a significant amount of work, if I possibly could I'd rewrite it to minimize contact with the "ick." — Mar 21 '14 at 20:41
I see, never thought about the problem this way! I'll try it next time! — Mar 21 '14 at 21:08

TooTone 1,69011130 · Answer 12 · 2014-03-19 00:17:51Z

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.)

score 4 · Answer 13 · 2014-03-23 15:41:36Z

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.

FYI - I picked on Martin Fowler (real person) in this post, in no way should this be considered a slight against him or even an opinion on his work. He is certainly an old timer with a lot of really good ideas. I used his name simply as a real reference to an "internet personality" whom people in the programming industry like to quote. — Mar 24 '14 at 14:20
Great answer - you made me want to read more exchanges between 'OP', Bob, and Jim! :-) — Jul 13 '15 at 8:05
@EleventhDoctor: thecodelesscode.com/contents is probably the best I've seen. — Jul 13 '15 at 15:02

user18099 1914 · Answer 14 · 2014-03-19 15:33:21Z

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.

Malachi 264413 · Answer 15 · 2014-03-19 17:53:30Z

Regarding your questions:

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.

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

Hogan 1011 · Answer 16 · 2014-03-19 18:02:38Z

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.

Search This Blog

Iyfjky

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

8 Answers
8

Your Answer

Post as a guest

8 Answers
8

8 Answers
8

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

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

8 Answers 8

Your Answer

Sign up or log in

Post as a guest

Post as a guest

8 Answers 8

8 Answers 8

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

8 Answers
8

8 Answers
8

8 Answers
8

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor