How to work with headstrong colleague

I have gotten a job in a small company that owns a codebase which has been growing in the hands of a single developer for nine years. The code does what it must, the company seems to be successful.

What exactly have you been employed to do?

Have you been employed to actually kick the code into shape and teach the established guy how it's done, or have you been employed to support the existing edifice (sharing some of the workload, but mainly deputising for the established developer)?

On many occasions, he listens to my arguments and then decides to have it done his way, which of course deflates my motivation and has a potential of undermining my confidence.

I realise English might not be your first language, but this comes across as a supremely egocentric line of argument in the context.

Having good advice disregarded may be demotivating, particularly if it leads to clearly adverse consequences, but a mere difference of opinion or difference in style of work should not lead to a loss of self-confidence.

Joining the team, I noticed that there's a lot of code smells and legacy coding patterns, like static methods used througout, classes with thousands of lines of code, violation of many coding standards like SRP etc.

All a bit airy to my ear.

A 9-year-old application is bound to be showing some signs of age and of compromises, but if it's not bug-riddled or breaking down every 5 minutes, and if the main developer can still make good progress when performing changes, then it probably isn't so bad.

Gain the trust of the team members before coming up with big suggestions about code refactoring. If nothing changes, then: Ask the CEO to have more say in the matter. They clearly hired me for my experience in past jobs, so there's no use in having my input overridden constantly.

Unless your colleague's work is unsatisfactory in its own terms, then I really don't see you reaching the point where your mere opinions count for more than your colleague who has single-handedly written the application and has almost a decade of employment under his belt.

Your colleague might not actually be rejecting your arguments, he may simply feel that the advantages of the changes you propose are not sufficiently compelling to retrofit or to tolerate a variation from established patterns or arrangements in the application.

Sometimes you need to live and exist within the jungle in which you've camped.

You've said that the code base works at it is - it might not be the most efficient code, but it works and generates revenue in the way that it should.

So I'd suggest that you maintain the code base without trying to change the world. Any new classes/interfaces etc., you can craft in a more maintainable, efficient way.

You may need to lead the charge toward better coding standards in a more subtle way and play the long game here. I'm not sure you'll get too far in suggesting widescale code refactoring.

It's Option C. Ask the CEO

Not that you want to get the CEO involved yet, but you need to know what is expected of you, how much you are expected to push back against headstrong guy (HG), and how much support you will get. I've been in your position.

So go to your CEO with descriptions of improvements you've recommended, how they would improve the company's process and codebase, and what HG's response was. Ask him specifically whether you were brought in to improve the codebase and coding process, and how hard he wants you to push to accomplish this.

I expect this response to fall into one of three categories:

1. We recognize that our code and processes are not really good, and we want you to specifically improve them for long term sustainability of development. Keep lobbying for these changes and management will support you.
2. HG is our best developer and we don't want him upset. What he says goes.
3. I don't want to be bothered with technical things like this. I expect the team to get on with doing things and agree on how amongst themselves.

Answer number 2 means you need to "decouple your ego" (or disconnect your critical faculties) and get on with writing "idiosyncratic" code. That doesn't mean you can't lobby some of your other co-workers to your side by pointing out to them ways things could be done better, but keep it low key.

Answer number 3 means that you can keep challenging HG but you need to be careful about it. Keep pointing out ways things could be improved, but don't expect much movement. Again, talk to your co-workers about how things could be improved.

Answer number 1 give you much more leeway, and indicates you can keep pressuring HG - while keeping everything polite and professional.

I'm having an issue with OP definition of this person. The 'headstrong' classification is reflection of OP's view on interactions with him.

For 9 years he was the only one developing this product, I assume all levels from UI to database access, and handled any issues arising from integration of evolution it to the product.

If product works, running around, screaming

this is not the way things are done

is the last thing that should be done.

The code base that evolved over 9 years of development is inherently messy and OP need to make his peace with this fact.

IMHO, OP can gradually introduce his vision of development (coding standards, development patterns etc) being mindful that every change has a potential to unravel entire system, given IDE, frameworks and supporting assemblies are evolving constantly and current revision may handle same API calls in entirely different way.

Pick your battles.

You're the new guy. If you don't have an explicit mandate to change things, you need to earn it.

I'd suggest starting with an issue in the system that has some sort of business impact. Maybe a certain process fails a lot or making changes in a part of the system takes a long time.

Then raise the issue and work with the other developer and the business to find a solution. That'll give you an opportunity to build trust and to have constructive discussions about better ways to do software engineering.

Involving the CEO will almost inevitably escalate matters, making future cooperation very difficult. It could quite possibly lead to a him-or-you situation, which you will lose, unless the company is actually already sick and tired of him.

I generally find that coding disputes are best resolved by showing and not telling - so if at all possible, you could demonstrate your coding style in a new component. It is important that you haven't changed his code, but only added new code.

There is no guarantee this will be well received, as his somewhat reasonable expectation is that you mimic his style to keep the code base as homogeneous as possible. However, you have been hired for experience and not merely as an obedient coding-drone - so using your experience is also entirely reasonable.

When following the above approach, I have had the full spectrum of reactions - from being completely dismissive to clearly interested.

Regardless of the reaction you get, you will at the very least be more certain in your diagnosis of the issue. In a perfect world, your code would be accepted and the conflict would be replaced by cooperation. Alternatively, you will know that you are cast as a junior that must follow orders - and need to evaluate whether that will work for you.

Would concentrating on building more thorough testing for the current code help? If you want to do a major refactor, you'll have to do that anyways and it should help the problems you're seeing currently.

I don't know if you are at the same level in the hierarchy as this guy as a contractor. If you are a contractor, I would try to find out from whoever hired you if they want you to do this kind of refactoring. You'll probably have to deal with the other guy being angry if they say yes so you'll have to be ok with conflict.

See The Codeless Code: Case 123 Order and Chaos.

A certain monk, known for the elegance of his code, had a habit of refactoring the code of his fellows to match. “For inconsistency multiplied becomes chaos,” he would explain, “and chaos breeds complexity, and complexity brings confusion, and confusion is the mother of ten thousand defects.”

Also consult the other cases in The Codeless Code, or a similar compilation of advice for working in teams as a software engineer. There's no need to make these mistakes if you can let other people make them for you: second-hand experience is still educational.

You have your experience, but others also have theirs. The true measure of experience is success. Do not be hasty to dismiss that which works, without first understanding why it works.

Refactoring an existing codebase is often useful, but self-taught / solo developers tend to be a bit too eager to do so. Refactoring feels productive, but doesn't help as much as you'd think, and it hurts institutional knowledge. Don't overcorrect to the point you'll never refactor a horrible codebase, but until you'd give advice like this yourself, ease off a bit, and stick to well-documented, non-controversial changes in new / peripheral parts of the codebase.

I would focus on test-automation as the field on which to fairly debate the other coder. What's the pure-unit test coverage like? Is that terse/elegant? Is there good mocking use? What about higher layers in the test pyramid integration/service/component and full-stack functional clicking via Selenium, Playwright and friends? When I was at Google I heard "design for testability is better design anyway", but I can't remember who said it, but it is a profundity. I think it was Joe Walnes, but he's not answering yes or no to the Q.

He is the architect! This is important.

Things are as they currently are for reasons - probably very good ones too - until you understand why, do as he says. Also listen to the reasons why your suggestions are discarded.

In the long run you may become the new architect. THEN you can change things, but then you may not want to because you understand why things are the way they are.

If I were you I would 1) add test automation, then 2) refactor toward a better codebase to support more of 1. These should be difficult to refuse.