I work in a small team of 5 web developers.

The team currently is used to using some poor and outdated coding and work practices that make development harder and inconvenient, and overall make our jobs more difficult and take longer. For example, all our code is in a few huge files, making it hard to find anything. Soon we will be working on a bigger project.

I would like to introduce my team to using modern js development. I already use modern JS development in my personal projects. Personally I think using better and newer technologies and practices will make our work better and more efficient and improve our experience.

The problem:

2 coworkers are my superiors (aka "senior developers") who are set in their ways and don't know anything about the technologies that I want to use. They think up to date practices like automated tests are not useful and laugh at people who talk about these "useless" things. Other coworkers already know these technologies and would also be happy to use them.

So the audience is difficult, any idea how to make them at least try to use these new technologies? What I want is they should at least learn the basics and be willing to use them, which will make everyone's job easier.

I will talk to the team next week, I got the task to prepare the "framework" (clean up the big files) for the next project. Personally I have the feeling like we are working on stuff that was "cool" 10 to 15 years ago and these people stopped learning.

How can I convince them to be open to learning and using new tools and technologies?

  • 8
    Have you considered asking this in The Workplace?
    – Johns-305
    Aug 10 '19 at 11:49
  • @Johns-305 I'd second the suggestion of Workplace. Seems like lots of people there have run into the same issues with coworkers and choice of technology.
    – DaveG
    Aug 10 '19 at 12:54
  • I did it once, I recommended them composer (package manager for php). It was a drama but after 2 years they slowly accepted it. Modern JS is more than just using some package management tool. I am not really sure how to sell them the idea. But I will of course try next week when we have a meeting. Maybe you guys have some advice so they don't tell "thats bad, we don't need it.."
    – MilMike
    Aug 10 '19 at 13:01
  • Are all developers going to work on that project ?
    – MlleMei
    Aug 11 '19 at 20:54

I know one sure-fire way to get developers to use a new tool or technique: have it solve a problem they are struggling with. Here's a real life example, from many, many years ago.

From college and my previous job, I was used to using lint on my programs. At this time the job of the C compiler was to compile code. Not to hold your hand or tell you you might be making a mistake. There was a separate tool, lint, to "pick bits of fluff" from your program.

I must have talked or made a presentation at a staff meeting about lint. One of my fellow developers, who was struggling with a segmentation violation in his code, decided to take a break and asked me for a demo of lint. I was happy to oblige, so I showed him how to run against his program.

We're going through the output, and run across a warning about a possible uninitialized pointer. Yes, this was the very bug the developer was struggling with. And from that moment forward, he linted religiously.

The moral of this story is that lecturing people on how something is a better tool or how they can change their code to look better is generally non-productive. Instead, show them how the change you are proposing solves a problem that they are having right now.

Listen to what your fellow developers are complaining about or struggling with. Figure out how what you want to do helps them along. And if you can't come up with anything other than it "looks better" or "it's best practices" then maybe they are right and this isn't the time to change things.

  • The issue with the kind of developers OP mentions (older devs who are set in their ways) is that they often don't have an issue with how they code, and they see those new technologies as creating more problems than solving them. What do you propose OP does in that case ?
    – MlleMei
    Aug 11 '19 at 20:58
  • @MlleMei That's exactly what my answer addresses. Show how the OP's changes solve a problem. I'm one of those "older devs". Older devs have learned that constant churn is a bad idea. I'm happy to change and improve when it makes sense, and to leave well enough alone when it makes sense.
    – DaveG
    Aug 11 '19 at 23:57
  • There are devs who don't mind the constant churn, and prefer it to learning something new. People who don't do self-reflection and aren't interested in improving their work or the process. The description OP gives of some of his co-workers seems to fit that kind of mindset. What I asked in my comment is do you have any suggestions if this is truly the case ?
    – MlleMei
    Aug 12 '19 at 9:08
  • @MlleMei "the constant churn" refers to the churn of changing things for the sake of getting "the new stuff" regardless of whether it makes sense or not. It's worth remembering that one of the Agile principles is "maximizing the amount of work not done".
    – DaveG
    Aug 12 '19 at 11:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.