How would you handle inflexible bad coding standards at a new job? [duplicate]

Question

I have only been working at my current position for a little over 3 months and I feel that some of the coding standards that are in place go against my personal best practices. The biggest clash seems to be when writing SQL code, I like to make my code very readable, easy to understand, and easy to test but apparently that is not part of the standards here and I am asked to remove items I put in place to promote my best practices which again makes it easier and quicker for me and I am sure others who come behind me to understand and test.

The enforcer is my manager and very strict about the standards and makes it nearly impossible to get a word in and completely disregards any reasoning behind my actions falling back to "this is not standards". Why can't they be then? Why not make them standard? What is so wrong with having easy to understand code that makes it easy to test and tweak?

The other part of my frustration comes from feeling like I am the only person that these standards are being imposed upon. I have found many times code that makes me cringe and does not match what our standards are yet.. it exists and is recently written.

Right now this is my biggest concern with where I am working, I like that we have standards and that they are enforced but I am not digging the inflexibility and closed mindedness of the standards and it is becoming very frustrating.

On top of it I started hearing a new line this morning, "[Director's Name] does not like..." though he is no longer writing code and I feel his personal coding style should not dictate a possible improvement to the standards.

What would you do? I feel like I am stuck between a rock and a hard spot.

Though, this post is less about what my standards are and more about how to handle a conflict of standards especially when you feel they hinder the speed in which you work.

Answer 1

You aren't a special snowflake nor working in a vacuum

my best practices

Unless you are your own manager, you don't get to dictate what standards you use. And even if you are you likely will do work for others and still need to abide by their standards.

This is a significant part of the reality of working for others.

Also keep in mind standards have a lot of history in many cases. Perhaps some previous dev did something which caused a ton of problems when the dev left. Perhaps a manager had a power trip. This will never be immediately clear, especially as a new person.

The other part of my frustration comes from feeling like I am the only person that these standards are being imposed upon.

I suspect this is partly if not entirely because of your attitude. There are a lot of factors other than simply your work which affects your bosses perspective on you.

By this point, it is likely your boss feels you are a problem employee. Everything in your question reads like, "I am right, why won't the idiots I work with understand and believe me! It's so obvious!"

What would you do?

If you want to have significant influence in your workplace learn to "play" office politics.

Another reality check: if you want to start influencing people you need to do so in ways which are effective. This means people skills are more important than technical knowledge. Before you disagree with this, realize your entire question is a result of this problem - if technical skills/perspective was of the highest importance you wouldn't have had to ask this question.

This is the dreaded "politics" component to work which most technical people shy away from.

A key component to politics is realizing the "how" is more important than the "what."

People will forget what you said

People will forget what you did

But people will never forget how you made them feel.

New person arguing with management (especially if directors get involved) is not a good career move, almost ever. This is different than disagreeing constructively.

Action Steps

1. Talk with your manager. Indicate you are sorry for arguing and ask if you can talk through the current standards
2. In this conversation, stop arguing. Understand the "why" to what your manager is suggesting. Don't automatically assume "you are an idiot"
3. Listen to what your manager says for "why." If you don't get this, try to get the why - don't even try disagreeing with it or saying "but, but, but." People generally get defensive when people argue with them. And get a lot more willing to listen if you listen and seek to understand first.
4. After fully understanding why your manager wants these standards (you probably should say something like, "So if I understand correctly, the reasons for these standards are X, Y, Z" - if you can't do this, you need more information), ask something like: "Would it be ok if I explain what I have been doing and why to determine if they could be included in the standard?"

Tread lightly in this conversation. If you have any level of argument you are likely to lose badly, given you have history with your manager.

Answer 2

Great answers above, but I would like to add one more point.

Good bad or otherwise, there is a history to these standards. If they are being followed, there is likely a significant code-base written to these standards. Your request to change the standards would create a need to revisit the entire code-base to restructure the old code. This could be a significant effort and adds risk for inadvertent code changes. If the team doesn't touch the old code, you are now leaving by two (or more) standards.

In my experience, if you have more than one standard, you probably really have none.

Answer 3

I know this isn't what you want to hear, but the sad truth is that companies (Or rather the people running them) don't always follow logic or the "best way". This is for a variety of reasons, some reasonable (Compatibility, compliance, standardization etc), some not (Fear of change, lack of understanding etc).

The other unfortunate truth is that you're not always in a position to change that. Some things will never change, other things you may be able to influence over time. What I will say, however, is that you're a new member of staff and it's clear there is a real driving force to do things a particular way. My suggestion would be to mold to these, whether you like them or not, and assess your position when you're further embedded in the company.

Picking a fight with senior management and company leaders is a dangerous game at the best of times - even when you're top of the technical tree, the people who own and run the company can (and sometimes will) over rule you. Doing it when you're new is bordering on suicide.

Answer 4

Just because the reason for a standard is not visible does not mean it is irrational.

While I agree with everything said above (about new employees needing to maximize their people skills and learning the local company politics) one thing that may help lower your frustration level is understanding that some coding standards are based not so much on illogical-and-arbitrary factors but rather on valid-but-invisible ones.

Consider your example which you described as

"one more WTF standard which I just roll with but seems completely pointless"

I have actually seen this exact standard in two different organizations and there was a very valid reason for it.

In both of cases I discovered that management was using certain software to analyze the code development & evolution process and this software had strict expectations of how the comments would be formatted (aka standards). The "TICKET" lines you describe might only include "comment:" in your department but later on down the line in production there might be live incidents that arise which requires troubleshooting and modifying the software. Techs and management involved in those events might add TICKET lines with things like "problem:", "fix:", "change:", "reference:", "evidence:", "decision:" and even "policy:". If you get assigned to work on fixing/upgrading legacy code you may see some lines like that yourself.

One concrete thing I can suggest for you is to try and learn about something called "ITIL" and/or "ITSM". These are collections of world-class best practices for IT, both from a technical viewpoint and a management perspective at the same time. I kid you not that it can be very hard to understand them at first if you are a pure techie (non-management) but in the long run it will dramatically improve your ability to see the "big picture" and it can be considered a marketable and/or promotable skill if you decide to go as far as to become ITIL certified.

Answer 5

All good advice re: new guy should not make waves, etc. and yes, sometimes it is best to just hold your nose and follow standards, policy, etc.

But sometimes management is wrong; sometimes a company's 'standards' really are bad or worse.

In that case, find another job; long experience taught me that it is impossible to fix a dysfunctional organization. Those places have a self-reinforcement culture, and if you stay there for too long, you too will become broken.