How to deal with senior developer who sets bad coding and work practices?

Question

We have one of the special kind of senior developers with his own style of programming and work-life balance that is part of the project leadership setting the direction of the project. Our colleague is hard-working and gained the trust of the client and management. His code works but no one makes any critical look on it.

The person is rather hard to work with. When it comes to programming he's always fast and dirty. Comments like "iterate through the objects" before a loop, his own unique naming of things and some bad practices like semicolons for Python. His code looks like write-only.

He finishes always first with his tasks, fast and dirty - management likes that.

The bigger problem is I have to use his code. We don't have any time for refactoring and it's hard to suggest anything to people above you. Arguing with the management's favorite developer is shooting yourself in the feet.

I'm experienced developer but not a team lead or manager.

What is a good approach to improve my position?

• Ignore the situation and do my best. I have the feeling problems are coming for me, not doing things that fast and dirty.
• Do everything fast and dirty as well, bend to the project and colleague style.

Edit: I'm more experienced in some areas(python in the case) and have higher expectations in the coding style. Yes, the code works, but it's horrible.

We are consulting company and writing like this creates the stereotypes like "People from X country are incompetent and write horrible code".

Answer 1

I've been in exactly this situation. Actually twice: I've held two software jobs (many years ago), and there was a guy like this at both workplaces. The second one was worse and, on a smaller team, impossible to avoid. After that I got out of the industry.

For the sake of others who seem skeptical of the situation, the sloppy by-the-pants coding made achieving velocity myself as a programmer almost impossible. Variable and argument names were nonsensical. Builds routinely broken. For any feature to be added, I'd practically have to perform a disassembly process to determine how existing code worked. The "senior" programmer couldn't (or wouldn't?) answer any questions about his own code. Once (sci-fi game development here) he had a function with parameters (beamed, beamer, beaming) and I asked, "Which one is the person?". And his answer was, "Yes, I think so".

What is a good approach to improve my position?

So I think we all agree that there is nothing that will change this state of affairs. The management knows this developer well, he's been there longer, they're friends, they perceive him as having a proven track record. They see him as their single primary competitive advantage. He is apparently the linchpin of the entire company's performance. They do not see the technical debt being thrown up daily, serving as a barrier to the rest of the team's performance. The slower other team members perform, the better the guy looks like in comparison. Nothing will entice management to put any roadblocks to the guy's current behavior.

The short story is that you should look for a new job. This can be taken as an object lesson in having raised awareness about what kind of workplace you'd like to move to. "Do you do code reviews for everyone?" can be a question to ask in the interviews.

In the meantime, you can think about whether working "dirty" would actually make you happier or increase your performance. For me, it would not, and I rather suspect it won't for you either. In this regard, I'd suggest practicing your craft as best you know how until your next opportunity arrives.

I have the feeling problems are coming for me

Finally, I sympathize and am familiar with this overarching anxiety. It's likely the rest of the company doesn't give you as much mind-share one way or the other. Other software jobs are available for you, and some day you will move on and this won't be an issue. Meanwhile, this company will go barreling on with the indecipherable coder until the business is sold or no longer viable.

Answer 2

Comments like "iterate through the objects" before a loop

Hardly the worst thing in the world. At most he's guilty of assuming the reader has followed the code through and not describing the 'why' part.

his own unique naming of things

Unique how? are they, for example, single-letter variables for everything? Unique doesn't necessarily equal bad.

and some bad practices like semicolons for Python.

This probably comes from using other computer languages such as C++ - where semicolons are mandatory. Regardless, I fail to see how that is a hindrance to you.

His code looks like write-only.

How so?

I'm not seeing much that describes 'fast and dirty' here, and I'm not seeing any serious problems with the style outlined here. It might be different for you and it may be something you're not used to.

I think your real issue is with management here, and I feel that, given you aren't able to (or at least haven't done so here) translate your issues here into objective problems about the project, your only real courses are to stay the course or jump ship.

Answer 3

Producing useful software quickly can be very valuable for a business.

There is a tradeoff to be made. Software that is produced quickly is usually also software that is difficult to maintain, i.e. fast to build means slow to change.

Your management likes that the senior developer produces code as quickly as he does. The question is, do they expect you to be able to change his code just as quickly? If they do, they are maybe not aware of this tradeoff, and it might be a good idea to try to make them aware of it. You can't get blood from a stone.

But, if they're happy with the fact that any work that involves changing the senior developer's code after the fact will take a little more time, then, there is really nothing you can (or should) do -- the business is working as expected.

If you want to try to tolerate this situation better, the next time you find yourself looking at his code and saying to yourself "Why do I have to work with this garbage", remind yourself there are people out in the world who have to work with real actual garbage, and they're probably paid a lot less than you are.

Answer 4

Other than that the practices of the senior dev clashes with what you think is good programming, what is bad about those practices? Is it hurting the business? Is your style better? Can you back that up?

Developing something quickly certainly has value. There is a price (often in code being harder to maintain), but there is no general way of saying whether than price is too high -- that will differ on a case to case bases. Furthermore, a price you pay in the future (maintenance) is better than a price you pay now (longer development times).

As for the example you are giving, is that really that bad?

Comments like "iterate through the objects" before a loop, his own unique naming of things

That's not enough context to comment on -- and that's going to be subjective in any case.

some bad practices like semicolons for Python

Sure, you don't need semi-colons in Python, but does it hurt if they are there? My main programming language is Perl, where semi-colons between statements are mandatory. But I do write in bash, AWK, Python, Node.js and Ruby as well, where they aren't mandatory. Out of habit, I often put them in. I don't think my code suddenly becomes harder to read, or harder to maintain. Personally, if such stylistic issues bother you, then that's something you should work on.

We don't have any time for refactoring

So? Refactoring for the sake of refactoring has a quantifiable cost to the company (you are spending time refactoring existing code instead of writing code which could make money), but it is hard to quantify what the value is (and it's even harder to quantify when the pay off will be).

What is a good approach to improve my position?

That depends. You should do what is best for the business (or, at least, do what the business thinks it's best for the business). If you are writing software which keeps planes in the sky, quick and dirty may not be right way to go. If you are writing front-end features for a web-site where A/B testing kills 90% of the features in their infancy, quick (and perhaps dirty) is the way to go.