A coworker complained to me that his attempts at providing better, or unorthodox (compared to existing) solutions in his work are being cut short by his team leader.
The manager in question is new in his current role, although a veteran in company.
I can sympathise with the team leader in question, as the new team he's in charge of creating from scratch is highly visible and has a lot of hopes hanging on it (a new, company wide initiative being led by it).
Additionally, he's rather strapped for manpower currently (a three person team, including him).
Professionally, I think he's a good programmer, with (possibly too much) sensitivity to business/product requirements.
As far as I can tell, it leads him to make safer, less radical choices when it comes to day to day work and developing new features, and less likely to deviate from existing patterns.
I'll note that this is conjecture on my part, as I haven't actually discussed this with him, nor am I part of his team.
The coworker in question is a relatively new hire, although I was impressed by him as being professional conscientious programmer, with disdain for writing bad code or propagating bad design decisions and staying up to date with current practice and so on.
He confided in me that he's feeling frustrated and constrained, being forced to write code that is less maintainable, elegant and performant than he could and should.
He's aware of the (possibly) precarious position of his team, but he still thinks some more leeway should be given for doing things better.
When speaking with him, I told him that I think he has a point and should be able to be given the leeway to do things his way ti a reasonable degree.
However, the final call should still be his manager's, and he can't maintain friction with him without it having bad consequences.
I also pointed out that the manager in question could be justified in doing things the way he did, given the risks he has to deal with (which he acknowledged).
I suggested that he should raise his concerns to his manager, but in general keep a low profile, avoid friction and hope that at some future, less turbulent time he'll get a chance to work in a more palatable manner (in the same team or another).
Is this sound advice?
Should I've said or done something differently?
Is there anything else I can or should do?
A little clarification
I'd like to address a couple of points @sascha raised:
- The coworker in question, although being fresh, has long work experience behind him.
- The changes he suggested, in my view, didn't appear to be more time consuming and lent themselves to be a good foundation for future work.
- The codebase which he works on is a hot mess, a big monolith rife with inconsistencies, anti-patterns and pitfalls, which isn't being defended by anyone presently working at the company.
- The long term strategy for the codebase is to gradually refactor commonly used code, introduce new functionality into new ("micro") services and generally avoid introducing new code into the monolith.
According to what my coworker says, the direction of work done by his team contradicts that last point.
We're all aware of business requirements and that sometime reality dictates we have to write code we're not proud of, but the claim in this case is that bad practices are preserved even when there's enough leeway to do things right.
Incidentally I agree with the sentiment, and that it's the correct thing to do, but my question is how to communicate this to higher ups, find a compromise, or failing that, how to keep working with that fait accompli?