What is the best advice to give someone in this industry who resists change? [closed]

Question

I'm having a discussion with someone quite older than me, so I have no place in telling him what is wise. He is in the computer field but resists change, and we're discussing how his co-workers are enjoying learning a new technology and he's just avoiding it like the plague.

I'm looking for maybe some good reading or testimony to support following trends and learning new technologies, rather than falling behind and sticking with what you know even as it's outdated. The kind of stuff which you might have someone who's in love with BASIC or PASCAL or mainframes read, because they won't listen to you directly.

Internet articles or convincing, well-written blog posts preferred, but any good books are welcome too.

Answer 1

Resisting change isnt a bad thing, or a good thing. It entirely depends on what the 'change' is, dont you think? The thing is, older developers have seen technologies come and go, and know that there's often better things to do with one's time than delve into a technology that will likely just end up as a footnote in programming history.

There are certainly a lot of (typically older) devs who will resist changes that are good ideas. Planning ahead for and being aware of new technologies is a smart thing. If their resistance to learning new things comes not from their judgement that the technology isnt a good path to pursue, but rather from simple fear of change, then that can be a problem.

On the other hand, there are a lot of (typically younger) developers who easily become infatuated with every amazing new technology that comes along the pike, and then feel they must implement it everywhere. Thats just as dangerous to projects, because you end up with the wrong technology used for the wrong thing, and no coherent, long term strategy. Older devs may not share their younger counterparts' enthusiasm about a certain amazing technology because they've been there, done that. That amazing new technology may be wondrous and new to a younger dev, but simply a retreaded idea or yet-another-fad to the elder who has seen these things come and go.

Answer 2

New just for news sake is not a good idea, and you will learn that when you find the number of legacy applications based on archane technology you have to maintain.

Experienced persons have seen more technologies come and fade than you think.

WHen that is said, you also need to stay current, but not as much as you may think. Which technologies from the last 10 years was absolutely NEEDED to learn? 20 years?

Answer 3

If you can't stand the heat, get out of the kitchen

I was about to write a long answer on past experience but it is fairly simple :

• Measure it

Good objective measurements are not as sensitive to subjective arguments. Measure the code quality, measure the time spent creating VS time spent fixing. This is hard, but is the safest way to get what you want : evolve.

As shanusmagnus pointed out, if they do not want to learn then no amount of reading thrown at them will matter. If after giving good metrics they are not convinced you have two choices left :

1 - The person is not in control, let that person deal with the maintenance of the legacy stuff and start working on the next generation with the people who want to move forward.

2 - The person is in control, change jobs ! you will spend you last drop of energy fighting windmills when your talent could actually be of use somewhere change is seen as a positive force to adapt to rather than the cursed flames of hell.

In either case the person (or company) will be more and more isolated and eventually follow the Dodos down the unforgiving laws of evolution.

Answer 4

The last Scala application running in the Cloud will be replaced by a Cobol application running on a mainframe...

"Change" is often applied for the sake of applying change, especially by youngsters like yourself. Older, more experienced people have seen it all, have been there, have done that. They by now know it's not the way to go, that just changing things because they've been that way for a while is not a good thing, that adopting every new "tech" that comes along is a recipe for missed deadlines, lost revenue, failed projects, and ultimately bankrupt companies.

That old guy is quietly evaluating things all the time, and will apply what's appropriate when appropriate. Which may well be (in fact is likely to be) not before the hype around it has long died down and the next Big Thing (tm)(r) hits the hype circuit (and with it your junior mind as being the best thing since before sliced bread).

Answer 5

depending on his age, if he's high than 35 i would probably be like him. it is not easy learning a new language. if what he knows makes him money and he's happy then let him be. if you've been with a language for a good amount of years you wont go learning something new that easily. there would have to be a very very good reason to make the switch. if he is stuck to a language like pascal or whatever ancient language you should look it up. programmers that know pascal are paid top dollar because their hard to find.

Answer 6

I'm having a discussion with someone quite older than me, so I have no place in telling him what is wise.

So why are you trying to give him advice?

If there is a clear need for a new technology, chances are good that Old Boy will pick it up faster than the n00bs, by standing on a tall stack of experience.

If not, well, then there's probably no point in talking to him anyway!

Answer 7

Some great progress have been made since the childhood of computers, but the core of what a programmer do is still exactly the same.

Sure, there are still new landmarks to be reached, but for every big achievement in language design there will be hundreds of inventions of which only a few are worthy of being called small improvements. It's certainly not wrong to experiment, it's needed to make that progress, but don't think your code gets better just because you are using flavour of the month language/construct/technique.

If you want to become a better programmer, improve your general programming. If you think trying out all the new stuff is fun, by all means do that as well. But don't mistake new for better, and don't think other programmers have to share your interest.

By the way, you didn't tell us what specific technologies the dispute is about, you only indirectly compared his choices to Basic, Pascal and mainframes. Why not put the cards on the table? If you want some good arguments it might be good to know exactly how old-school this guy is.

Answer 8

The short answer is that you don't, anymore than you convince a smoker to stop smoking or someone who eats poorly to eat well -- they know the arguments, and have rejected them for whatever reason. The dude from your example has a lot of reasons he wants to write in "Pascal" and you can rest assured that he's built a magnificent edifice in his head about why he's right, why "object DISoriented programming" (or whatever) is a bad idea, etc. etc.

The sad news is that you are unlikely to be the source of his epiphany regardless of what kickass inspirational blog post you unearth, and will instead come across as an annoying git for trying to 'improve' him. If some new technology would let him get his work done way faster or way easier, then demonstrating that might get through to him, but I doubt if anything short of that will.