How to work with senior staff who are averse to new ideas? [closed]

Question

My senior developers have around almost a decade of experience. They are open-minded to whatever THEY believe is good. They also lack interest in general problem solving and are not interested in learning.

There's also an ego problem along with this. I am poor in arguments and discussions therefore, I get easily pushed even in discussions on matters that I have researched thoroughly. This is primarily for the fact that I open the discussion showing that I might not be completely right hoping to get the words heard. In addition, the discussion often gets overturned with my own words echoed back at me, e.g., "that's what I've been telling you!", "so you understand now.". This also means I don't get credit for matters I proposed. Even when casually reviewing, they respond with "yeah yeah, I know", "was gonna do it.", etc.

Their limited horizon of experience and ego issues, I believe, is hurting the projects we work upon. For example, someone with such experience not having learned about symlinks. We do get stuff done, but one will quickly realize that the models have not been structured properly, making the work done less satisfactory. They're not to get the entire blame but the way things are structured it's tough for someone new like me.

We will be working on a new project soon and I have suggested the use for a native-hybrid app stack but have felt that I might regret this decision. I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.

My questions here are:

1. How do you deal with individuals that are unwilling to credit you for your proposal?
2. Do what's best for the job at hand ignoring under-appreciation?

Answer 1

If it ain't broke, don't fix it.

We do get stuff done, but one will quickly realize that the models have not been structured properly, making the work done less satisfactory.

"We do get stuff done" is a very, very good thing.

"Less satisfactory" is hard to evaluate. If you can demonstrate e.g. a significant maintenance cost due to how the models were structured, you may have a case for change. The sort of information that might support making a change would be to show that the next few feature additions or changes would have been simpler and easier to implement with the approach you suggested.

The gain from the proposed change has to outweigh the costs of adding another framework etc.

If, after considering all this, you remain convinced that your proposed changes are justified, pick the one for which you can make the strongest case. Back off for a while from proposing changes, to avoid people ignoring your proposal out of habit. Then present the very strongest, well supported, case you can make for the business benefits of that one change.

There is nothing wrong with wanting to use new languages, frameworks, APIs etc. to keep your skills up to date, but do that on your own time.

Answer 2

As a developer I'll make a rather controversial answer that probably some won't like but here I go.

They also lack interest in their job

As long what they're paid for is done there is professionally nothing wrong here.

and are not interested in learning

Every people working are not passionate about their job.

Linux OS had no idea about symlinks

For the ones that do not know what it is, it's like a shortcut in windows, a junction (ty @StephanBranczyk) to be more accurate, so it's pretty basic knowledge for anyone who learned on it. This tell a lot, they probably learn linux without proper formation, they're used to do things in a only one manner to get it working. So they don't try new things, they stick to what works.

I would love to try a lot of new things such as FP in this

I have seen things gone really bad because people wanted to "try" new things on projects. As people with lot of experience, they're surely aware of this.

Finally : I have seen CV with 2 years of experience with a stack of like 20-25 names of technologies. Consider 3 years of learning in general IT school, compute what they passed on some technologies that take month of experience to be able to built projects on it and you get developers that for some pasionated that work a lot outside extra-hours are able to do something with that, others are barely competent, not at all if it was my opinion.

Personally I'm a full stack angular/spring/jpa/bootstrap & some others. And I prefer to focus on them at the moment to get the best of them instead of getting a never-ending cv of somewhat not so much experienced in all of kind of technologies.

If you want to add new technologies, first get some experience yourself on it. Build something with it, match it to what it would look like with their techno, and present it to them.

Answer 3

As a maintenance coder, I've had to deal with the effects of "trying new things" on existing projects. There is a reaspn COBOL is still alive and kicking more than 20 years after it was supposed to be dead.

If you've got 10 years under your belt, it's not so much a resistance to change as it is responsibility + tried and true methods = not willing to put one's backside on the line to try something new.

I would love to try a lot of new things such as FP in this, but I don't think it is worthwhile to be teaching them this for reasons aforementioned. This might hurt my freedom to experience and try such things.

What will hurt you more is trying new technologies on existing systems when tried and true methods work. Additionally, you'll be adding technologies into the mix so that the next person to work there will need to learn them in addition to the existing tech, all because you want to "try" something.

Let me be blunt about something. There is a tone in your post that seems to say that you don't have much respect for your coworkers. I may be mistaken, but if that is the case, your chance to win them over is less than zero.

To answer your two questions directly:

Is it legitimate? No, you're young and energetic, but they know the systems. You should be learning from them, not trying to influence them in the fashion you've been attempting.

How would I deal with the scenario? If I were one of your coworkers, it would be to take you down a few pegs.

If I were you, I'd handle the situation by doubling down on learning the shop standards and adhering to them, and do outside projects on your own time learning the new technologies.

Answer 4

As a Project Manager working with Agile Teams, and now as a Program Manager working with different types of PMs - I experience this quite frequently. Pushback is to expected - older guys/gals are set in their ways, an organization is used to a defined process/going at it "cowboy" (i.e. Shooting From The Hip).

As long as they are doing the work that is assigned to them, it really does not matter if they do not care otherwise - it is a pain in the rear for sure, but as long as they show up, do their work, that is there prerogative.

As a Junior Dev - you may have better luck trying to rally them towards positive change, I am not sure how you do your Projects where you are and I do not want to make any assumptions, but if you can get other Team Members (i.e. QA, SAs, Engineers, PMs, etc) on board you may have better luck.

Change is ALWAYS painful, always slow, it does not matter if you are swapping out members, changing your project management methodology/framework or moving into another iteration of work - there will always be pushback and feet-dragging.

Of course to quote the Mantra of Mantras "If It Ain't Broke - DO NOT Fix It!"