How to handle a senior developer diva who seems unaware that his skills are obsolete?

Question

I am an IT productivity consultant brought in to a small software development company (twenty employees). The problem is a senior developer on a team of five developers who work on the leading product of the company.

For a few years, the founder was unhappy about the technical skills of the employees, and he recently hired a senior developer for the double role of technical lead and project manager. He was the only one doing an interview, and the only one deciding to hire this person.

This senior developer has an impressive CV listing a career of twenty-five years in IT, with a lot of successful projects accomplished for companies ranging from tiny ones to multinational corporations.

The team, however, became much less appreciative of his profile over two months. I had an opportunity to talk with three of five members of this team, and they all highlighted three issues:

• According to them, the guy is a jerk, and has no respect towards the other members of the team. One recent quote of him talking to a junior programmer in front of the team is very illustrative: “I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a******.”

  One should note that I had a few meetings with this person, and he seemed very nice and polite. I wouldn't believe that this was the same person who was constantly insulting his team mates, if I didn't have the testimony of three team members.

• In the past, decisions were taken by all team members. When members wouldn't agree, they would discuss it all together and come to an agreement, or at least explain the reasoning to the ones who won't agree.

  Now, all important decisions are taken exclusively by the lead developer. Those decisions cannot be questioned or discussed, even if all five team members find that a decision makes no sense.

• The senior developer's skills and practices seem a bit... obsolete. A few examples:

  1. He hates IDEs, auto-completion, and features which are intended to help programmers write code faster, and claims that the team should use Notepad++ to be productive. While it makes sense in different circumstances, it's difficult to imagine C# developers suddenly abandoning Visual Studio for Notepad++.

  2. He doesn't refactor the code, and doesn't care about style (which is inconsistent across his own code), the reason being that “he only cares about things that actually matter”. As a side note, style was previously checked by a nightly build, which started to fail since the arrival of the new lead.

  3. He rejects the idea of a nightly build, as well as automated tests. According to him, “any professional developer tests his code anyway by hand, so there is no reason to waste time writing automated tests”. The nightly build is also a waste of time, according to him.

  4. He thinks that version control is mostly useless, and seem to misunderstand how to use one. This leads to the situations where he develops a feature alone for three to five days, and when he finally commits his changes, he does “take mine” for all conflicts. If other team members complain that their code was erased, he invites them to rewrite it. On several occasions, other members did the same, erasing the code of the lead developer. He looked surprised (it seems that he doesn't know how to use svn log or diffs), and did his changes again, complaining that “they were mysteriously lost” and blaming SVN for screwing up.

  5. He overstates the importance of code optimization. His approach is correct, i.e. he runs a profiler, determines a bottleneck and fixes it; the problem is that there are no non-functional requirements of performance, and no elements indicating that the users may consider the application as being slow (and hosted on low grade development VMs, the app feels very responsive). He, on the other hand, spends practically half of the time optimizing the code.

  6. He writes all SQL by hand, and rejects the idea of an ORM. One should note that the current product is based on Microsoft's ORM Entity Framework, and two of the five developers never used SQL before.

  7. He rejects frameworks and third-party libraries, considering that it's much easier to write stuff from scratch. He decided to abandon all JavaScript libraries and frameworks except jQuery, claiming that when he started programming in JavaScript fifteen years ago, there were no frameworks, and the life was much easier.

  8. He thinks that mobile devices (including tablets) are just a hype, so there is no reason to waste precious time to ensure the compatibility of the site with those devices and to make responsive design. The product is a public web application which is not expected to be used a lot from mobile devices. Responsive design, however, could be very interesting to have for this app, since even on desktops, it will be displayed on both 19-inch monitors as well as large high-res ones.

  9. He asks the team to stop using internet (especially StackOverflow) and rely on their brains, the offline documentation (I didn't even know Microsoft still sells MSDN CDs!) and the books.

Team members complained to the founder of the company about their new lead about those three issues. The founder responded that they are overreacting, and that he has an absolute trust in the skills of the new lead, based on his CV and the interview, which is exactly why he assigned to this person the role of a lead developer in the first place.

What should the team do to:

• Either throw the lead out of the team or the company,

• Or force him to change his attitude towards the team?

---

A lot of questions were asked in the comments, so here is some additional information.

• What's the company structure above him? Who is his superior?

  Given the tiny size of the company, the structure is quite flat. At the very top, there is the founder of the company. And then there are employees, which report directly to the founder. Legally, the new lead is at the same level as the remaining five team members. For instance, he has no power to fire a team member or even move him to a different team.

• Some of what you say in the bullets as points against him are actually points for him. I mean he is right in at least half of them

  Indeed, this is the way I tried to present the subject. Personally, I find that some of those nine points make sense, but not in the context of the current team. For instance, my primary development environment is vi, but I won't force a C# developer to go use vi instead of Visual Studio, nor would I use vi myself when developing C# apps for Windows.

• I really don't understand why this guy is wasting his time at your little company. He could probably make a lot more money working somewhere else as "the guy who still knows how to maintain our 25-year-old, undocumented, business critical legacy system, written in a programming language that only 3 people in the universe still understand."

  Indeed, it is not very clear for me either. Should I mention that he knows COBOL?...

• I do not believe this is an actual question. In my opinion this is a post intended for trolling. You basically took all possible bad habits combined them together and asked what to do.

  My role of a IT productivity consultant means that I'm called when companies experience difficulties with their teams of developers. More than half of the cases are about inexperienced and often demotivated programmers who are forced to work on crappy code of a boring software product. The other part, however, deals with situations of conflict, strong politics, mutual misunderstanding and general mess. Therefore, I'm indeed facing TheDailyWTF-style situations much more often than ordinary developers, since it's actually my job to be where WTF is happening.

  This already happened before. I posted a question describing a WTF situation, and some people assumed (their comments being removed since then) that I'm trolling. I imagine that a lot of situations I faced would be considered the same way here, which is understandable. By the way, the situation I describe here is far from being among the worst ones I've seen.

  Unfortunately, there is no way I can show that those situations are real. For instance, for obvious reasons, I can give neither the name of the company, nor the name of the developer diva in the current case, and even if I could, nobody here knows this company or this developer (unless some of you worked in France in financial sector maintaining legacy systems).

• It sounds slightly odd that the perceived problem is with the new lead, and that there is no perceived issue with the people working under him (such as you). Was the founder correct to be unhappy about the current team? If not, why was he?

  Note that I'm not a member of the team, but merely a consultant.

  I think the founder is absolutely right to be unhappy about the current team. The four developers have little experience in programming in general, and C# in particular. The fifth is more experienced and he's the one who originally insisted at using version control, who set up the nightly build, etc. Still, the overall level of the team is not as high as one would need to build well a product they are building right now.

  It was an excellent idea to decide to hire a technical lead. However, things would have happened much better if it was a person who would teach the current team instead of blaming them, and work with the current members, not against them.

• Why would anyone oppose using Internet to get help on software issues?

  I don't know the official reason, but I would suppose that the lead developer always did it this way and considers that StackOverflow's quality is inferior to official MSDN documentation.

• Did it ever occour that the purpose of this guy is for the team to quit?

  Interesting idea. Making team members quit would make a huge financial benefit for a small company which may not be able to afford firing them. Once those programmers leave, the company may hire more experienced developers and move the developer diva to another team.

• So I don't know to what length your team members have complained to your boss about the lead dev. But have you had a good round the table conversation with them?

  Indeed, there were individual complaints, but no round the table conversation. Good suggestion.

Answer 1

The founder responded that they are overreacting, and that he has an absolute trust in the skills of the new lead, based on his CV and the interview, which is exactly why he assigned to this person the role of a lead developer in the first place.

The head guy has spoken. It's not a government or a political party. You can't throw anyone out or lead an insurrection.

If you're not willing to deal with it, you really have one option. You can band together and threaten to quit unless something happens.

I'm saying can, not should. There's an extraordinarily good chance that this will not end well. You're basically trying to place yourself ahead of the boss who's made his decision and people in charge don't like them being challenged.

I suppose the "correct" thing to tell you is to find techniques to encourage him to see your way of thinking. But I'm not going to do that. I'm a 30 year senior developer and I can tell you that I have largely become set in my fundamental ways. No, I'm not a luddite like this guy and yes, I take suggestions. I embrace new technology and so on. This guy's clearly wrong on a lot of things. However, what I can tell you is that when I'm set on something and I'm convinced I'm making the right decision, I stand by it. I don't take well to threats and coercion or manipulation is even worse.

My point is that he's convinced he's "Programmer Jesus" (which is a sad unfortunate attitude) and you'll never change him, not at this stage in his career. He's convinced he's right and he thinks his experience backs him up. Unfortunately, the boss does too.

Honestly, it's probably not worth the stress of you and your team. I'd suggest each of you start looking for a new job and leave when you've found one. When a person leaves, make sure they tell the boss why. Eventually he may get the picture. Even then, it's no guarantee.

RUN Seriously, I don't know why anyone would want to be there. Ask yourself, is there anything in what you told us that doesn't spell eventual doom for the product? I'm sure you know this. I question the founder's basic intelligence for that matter. Developers usually make very lousy project/program managers. It's a separate skill set and they need to balance each other out. It's like saying "we don't need separate testers, developer testing works great." Both are recipes for disaster. Good luck. I mean that.

Answer 2

The OP's description of the situation is likely one-sided. That's ok.

I am an aging developer (~54 yo) brought into a company to not rule, but to provide some experience. (The IT boss actually said "gray hair", lol.) The dev staff was far more adept, on the balance, than any team I had worked with previously. They taught me a lot, especially about humility! But we found places where their technological wizardry didn't solve the problems and in some cases hid those problems, ultimately making them worse. This is where I was able to really contribute.

Your lead sounds severely autocratic. It sounds like he's been given a mandate by the owner. The owner is unhappy with the dev staff and has brought in this "hard-nosed no-nonsense go-getter" guy to improve delivery speed.

First, look at your staff. Do you have weaklings - developers who do not "see the Matrix"? If so, find them new positions within the company or give them a good reference for an employer who needs their unique skills.

He hates IDEs

I know a few that do. It makes me roll my eyes, but ultimately I do not care. If people produce using vi, then ok. I love my IDEs.

He doesn't refactor the code, and doesn't care about style (which is inconsistent across his own code)

Red flag on the first part. Is he a copy-paster? I am also guilty about not caring about style, but that's because I use my IDE to instantly make my Python code PEP8 compliant. But he does not use an IDE...

As a side note, style was previously checked by a nightly build, which started to fail since the arrival of the new lead.

He rejects the idea of a nightly build, as well as automated tests. According to him, “any professional developer tests his code anyway by hand, so there is no reason to waste time writing automated tests”. The nightly build is also a waste of time, according to him.

This also sets off a red flag, but for different reasons than you might expect. Before this guy was hired, how many times was the owner told that he could not do X (give a demo, use the system, etc) because the nightly build failed? What if the owner perceives that the nightly build is the problem? What do you think he'd tell the Lead to do?

But I have concerns about the Lead's attitude; automated tests are amazing. As before, the boss might not understand the value of the tests, but he surely knows that Y% of the dev staff's paychecks are paying for them. When I arrived at my present company, the "100% test coverage mafia" had taken over the dev staff and ran costs waaaay up. One bad apple later and the dev staff was purring again.

He thinks that version control is mostly useless...

This is a red flag of the highest order. He is as wrong as possible. He is being irresponsible with the owner's money.

He overstates the importance of code optimization.

Back in the day, code optimization could make a difference. Now machines are so fast it is less important. Instead, we now need to worry about database performance and network throughput. But his "code optimization" habit is a hard one to break, trust me. I have to make myself not pre-optimize. At least his behavior in this case is not destructive, except for the time taken. (Do you have numbers for his "half his time" or is this hyperbole? If you are critiquing your supervisor, no hyperbole can be allowed. You must be pathologically objective.)

He writes all SQL by hand, and rejects the idea of an ORM.

Guilty as charged! I do not understand peoples' fear of SQL. I do not understand burying SQL, which is drop-dead simple, under layers of ORM that obfuscates. Can't help you here :-D But please, dump all your SQL into one place - don't distribute all throughout your code.

and two of the five developers never used SQL before.

That's unacceptable. This is 2016. They need to skill-up.

He rejects frameworks and third-party libraries, considering that it's much easier to write stuff from scratch.

He could not be more wrong. I doubt your company is so special that your utilities need to be written in-house. We had a few developers that would embrace 3rd party tools - until they did something in a way the dev didn't like. It was an excuse to throw the tool out and write their own. This just adds to the load on the dev staff, slowing them down further. This unhelpful code is expensive to write, test, debug, and maintain. We spent so much money for -zero- benefit. These developers are gone now.

He decided to abandon all JavaScript libraries and frameworks except jQuery, claiming that when he started programming in JavaScript fifteen years ago, there were no frameworks, and the life was much easier.

This one is not so clear cut. The reason is that life was much easier 15 years ago is that the business ask was much much simpler. That's where the problem has come from. The web was invented as a batch system (fill out a form, submit it, get a response, repeat) and now we're trying to write web apps that behave like desktop apps. His observation is right, things are hard now. But he does not realize why. Tool complexity is in response to a more complicated business ask. Thus he makes poor choices.

We're using AngularJS and it seems to be decent. Like all powerful tools, it can be used for good or evil.

He thinks that mobile devices (including tablets) are just a hype, so there is no reason to waste precious time to ensure the compatibility of the site with those devices and to make responsive design. The product is a public web application which is not expected to be used a lot from mobile devices.

He's wrong again. They are not hype. They are here to stay because they are useful. BUT the business does not need it. Don't develop things you don't need. It's expensive.

Responsive design, however, could be very interesting to have for this app,...

Is it so interesting you'd pay for the development personally? If this is a good idea, you ought to be able to sell the idea to the owner. Otherwise, don't spend a dime on it.

He asks the team to stop using internet (especially StackOverflow) and rely on their brains, the offline documentation (I didn't even know Microsoft still sells MSDN CDs!) and the books.

He's wrong. The internet is great for this. If the dev staff is copy-pasting from Stackoverflow without understanding how the code works then they are wrong too. Is there time for training and personal improvement in the development schedule? It's hard to not robotically copy-paste when you're always under the gun.

---

While I have limited information, there are lots of issues here. It sounds like the owner hasn't gotten the code he is paying for as quickly as he expects. It sounds like he's heard a lot of excuses about things he cares nothing about; he's focused on the result. If I am correct, you have a self-inflicted wound, and you have re-opened it more than once. This Lead is the owner's solution to the problem the dev staff has posed, and given his limited information, it is understandable.

I will also bet you're running a non-agile shop and have poor requirements definition which changes as the wind blows. There isn't a layer of insulation between the dev staff and the owner. Except for this Lead.

Now, what can you do?

1) Train the lead that the use of automated testing and code management is the way to go. It may take time to gain credibility with him - the owner has probably told him the staff is defective. See if you can prevent him from making sweeping mandates such as "delete all that useless testing crap and repurpose the SVN server". This will give you time to show value.

2) Continue using code management at a personal level. At least then you can recover from your own mistakes. Don't tell him you're doing this, though don't lie to him either.

3) Continue automated testing (unit tests, if nothing else) at a personal level. As before, don't mention it though don't hide it.

4) Work with the Lead to determine what the actual perceived problems are. Be open minded; I bet there are real issues with the staff. Work with the lead to address the problems, not the symptoms.

5) Discuss with the Lead various development topics, such as the benefits of waterfall and agile. Neither is perfect. Ask him questions such as, "Under what circumstance would automated testing be worthwhile"? If he gives a dubious answer, ask him how successful companies like Google have managed to thrive in spite of it.

So you can see I'm all about engaging the Lead and seeing where his head is at. Build trust. Agree on issues versus symptoms. This is not always easy, especially when you feel he's like Godzilla and is tearing your work apart.

There is a chance he cannot compromise. He will crush automated testing. Code management is for careless people. My Way or the Highway.

If it has gotten to this point, however, it will be time for you to leave. Working in a tool-less shop, and I mean software and software engineering tools - does not build your resume. You will begin to rot the same way the Lead has rotted. In that case, move on.

Answer 3

twenty-five years in IT [...] change his attitude

Not gonna work, sorry.

Your real problem isn't the incompetent lead developer. That problem is insignificant compared to the real problem you describe:

Your founder trusts an incompetent* stranger more than he trusts his existing employees.

You need to figure out how the team lost his trust, and how to win it back. This would have been easier had it been done before the stranger was hired. Now this is hard, because any good work will be attributed to the new team lead, and any poor work will be attributed to all of you - so you can't fix it by working harder.

There are only 2 things I can think of, to improve the situation at this job:

1. Find a mediator. Are there multiple founders, or something like board members?
2. Maybe the trust issue is a visibility issue. In that case anything that helps visibility helps you. E.g. make sprint demos exciting and interesting enough that the founder actually attends and learns about the status and progress of the team.

---

*While most points raised by the OP don't necessarily make the stranger incompetent, his approach to Version Control and Continuous Integration in a 5 person team certainly does.

Answer 4

This answer might be unfavorable and considered crass by some but...

---

The first red flag is For a few years, the founder was unhappy about the technical skills of the employees

Have the employees attempted to rectify the unhappiness?

---

The second red flag is two of the five developers never used SQL before

It's hard to create an efficient system if the developers are not familiar with core technologies and truly understand what the ORM is masking.

---

It's hard to imagine that I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a******. was actually uttered but I will take it at face value and believe you.

However, do consider the first red flag I mentioned and the "unhappiness" the founder has had to deal with for years.

To this, I add: you guys have known about the founder's unhappiness for years?!

How was this information divulged to you?

---

I am inclined to think that this guy is doing precisely what he was hired to do; get you guys into shape.

Getting you into shape does not refer to adopting the new guy's bad practices but it does involve throwing you out of your comfort zone to learn at a deeper level.

Answer 5

For a few years, the founder was unhappy about the technical skills of the employees, and he recently hired a senior developer for the double role of technical lead and project manager. He was the only one doing an interview, and the only one deciding to hire this person.

Sounds like the founder doesn't trust you chaps.

The team, however, became much less appreciative of his profile over two months. I had an opportunity to talk with three of five members of this team, and they all highlighted three issues:

• According to them, the guy is a jerk, and has no respect towards the other members of the team. One recent quote of him talking to a junior programmer in front of the team is very illustrative: “I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a******.”

Sounds like you're only getting one side of the story. I can picture a few situations where I might need to slap down a young know-it-all myself, and I have. just playing devil's advocate here, but it sounds like he was provoked. What was the provocation?

• In the past, decisions were taken by all team members. When members wouldn't agree, they would discuss it all together and come to an agreement, or at least explain the reasoning to the ones who won't agree.

apparently, past practices did not generate the results that the founder wanted.

Now, all important decisions are taken exclusively by the lead developer. Those decisions cannot be questioned or discussed, even if all five team members find that a decision makes no sense.

Again, it sounds like a vote of no confidence from the founder. He brought in this type of person for a reason. Sounds like the reason was to whip the rest of the staff into shape.

1. He hates IDEs, auto-completion, and features which are intended to help programmers write code faster, and claims that the team should use Notepad++ to be productive. While it makes sense in different circumstances, it's difficult to imagine C# developers suddenly abandoning Visual Studio for Notepad++.

IDEs can slow you down if you're a fast programmer. Notepadd ++ is superior to some for quick coding. The idea is that you write your code, then drop it into the IDE for quick correction instead of constant interruptions.

2. He doesn't refactor the code, and doesn't care about style (which is inconsistent across his own code), the reason being that “he only cares about things that actually matter”. As a side note, style was previously checked by a nightly build, which started to fail since the arrival of the new lead.

Shop standards are something to discuss with the founder, especially since you're running it through the nightly build. But again, reading between the lines, it looks like the founder doesn't trust you.

3. He rejects the idea of a nightly build, as well as automated tests. According to him, “any professional developer tests his code anyway by hand, so there is no reason to waste time writing automated tests”. The nightly build is also a waste of time, according to him.

He's right automated tests don't account for the sheer genius of some fool doing something never intended. I've personally broken several programs that went through automated testing.

4. He thinks that version control is mostly useless, and seem to misunderstand how to use one. This leads to the situations where he develops a feature alone for three to five days, and when he finally commits his changes, he does “take mine” for all conflicts. If other team members complain that their code was erased, he invites them to rewrite it. On several occasions, other members did the same, erasing the code of the lead developer. He looked surprised (it seems that he doesn't know how to use svn log or diffs), and did his changes again, complaining that “they were mysteriously lost” and blaming SVN for screwing up.

Everyone is at fault here. Doesn't anyone backup? If he's having trouble with version control, it is the team's responsibility to work as a team and not just give him a hard time over it.

5. He overstates the importance of code optimization. His approach is correct, i.e. he runs a profiler, determines a bottleneck and fixes it; the problem is that there are no non-functional requirements of performance, and no elements indicating that the users may consider the application as being slow (and hosted on low grade development VMs, the app feels very responsive). He, on the other hand, spends practically half of the time optimizing the code.

There is no way to overstate the importance of code optimization. The purpose of code optimization is not to make sure it's running right today the purpose is to optimize it so that you're not fixing some problem three years down the line which could have been prevented with code optimization.

If you only care about the users being happy today, you're going to have them banging on your door tomorrow.

6. He writes all SQL by hand, and rejects the idea of an ORM. One should note that the current product is based on Microsoft's ORM Entity Framework, and two of the five developers never used SQL before.

Two of the five developers should be fired then. If you're relying on an ORM, you will never be able to get under the hood and fix things manually. I'm starting to see why he called someone a 'code monkey' in frustration. ORMs are fine and good, but you need to understand the SQL if you are ever going to go beyond the limitations of an ORM.

7. He rejects frameworks and third-party libraries, considering that it's much easier to write stuff from scratch. He decided to abandon all JavaScript libraries and frameworks except jQuery, claiming that when he started programming in JavaScript fifteen years ago, there were no frameworks, and the life was much easier.

He's right. Frameworks and third-party libraries have limitations, and if you don't understand enough to go in and fix it yourself, you don't understand the code. An argument could be made either way. If, however, nobody on the team can code without using the frameworks, then you have a very weak team.

8. He thinks that mobile devices (including tablets) are just a hype, so there is no reason to waste precious time to ensure the compatibility of the site with those devices and to make responsive design. The product is a public web application which is not expected to be used a lot from mobile devices. Responsive design, however, could be very interesting to have for this app, since even on desktops, it will be displayed on both 19-inch monitors as well as large high-res ones.

From everything you've stated, it sounds like he's been brought in to clean house. If mobile devices are not a major player for the application(s), spending too much time is a waste. While it might be a "nice to have" on a desktop, a "nice to have' is not a necessity for rollout.

9. He asks the team to stop using internet (especially StackOverflow) and rely on their brains, the offline documentation (I didn't even know Microsoft still sells MSDN CDs!) and the books.

Good for him. Looks like he wants to know who can do their own homework and who's been cheating.

Team members complained to the founder of the company about their new lead about those three issues. The founder responded that they are overreacting, and that he has an absolute trust in the skills of the new lead, based on his CV and the interview, which is exactly why he assigned to this person the role of a lead developer in the first place.

What should the team do to:

• Either throw the lead out of the team or the company,

• Or force him to change his attitude towards the team?

How about working with him and not sabotaging his every move.?

In all honesty, it sounds like he's been brought in to clean house, given what you've posted, it sounds more than justified.

The owner is NOT satisfied with your performance. It would behoove you to take this fellow's advice for what it's worth. We relics have a bit of experience and we know what the books will never teach you. Yet, rather than see this as an opportunity to learn and grow, your team is having a massive hissy fit.

Answer 6

So I don't know to what length your team members have complained to your boss about the lead dev. But have you had a good round the table conversation with them? Explain the problems that you're having with the lead dev to your boss and let him have his side of the story.

Quitting should be a last resort.

Answer 7

The owner needs to hire a personnel manager

Other answers have hinted at this, but the elephant in the room is that the owner (understandably) seems to be having difficulty successfully carrying out personnel functions like hiring, training, firing, etc. Case in point: owner staffs an under performing team, puts up with them for years, then hires a 25 year veteran to fix things, then hires a consultant when the 25 year veteran can't fix things. The owner doesn't seem to know how to run the personnel side of the business. That's okay, there are people who do this for a living, and that's why most organizations have people managers. The owner needs to hire one stat. This will free the owner up to focus on the strategic side of the business, so it's a win win.

Perhaps OP could help with the interviewing (after all, the owner seems to need help in this regard)?

Answer 8

A "wrinkle" that I haven't seen here yet. It's pretty common for people with a lot of experience to get defensive about not being up to speed on current developments. I used to get the same way with people talking about how horrible VB6 was in relation to the marvelous .Net, when those people were just repeating things they had heard about VB6 and didn't really know much about it.

As you say, a lot of things that the leader says are on point. But that doesn't mean that they all are, as you say. Perhaps Mr. 25 years can open his mind and synthesize his approach with the best of the status quo, but not if he's afraid of being less than perfect and in denial about being afraid. As far as I'm concerned, that's the actual problem here. There may be other problems with the juniors (defensive about their lack of expertise, for example), but that seems to be the underlying issue here.

If everyone gets together and addresses their fears in an open and honest way, then they should begin to move in a more positive direction. I can't say it sounds like a high probability, but it is what needs to be done.

Answer 9

1. Have the entire team together spoken to this developer and tried to explain the benefits of things like version control and IDEs? A frank discussion en masse may help

2. I agree insulting other developers is unprofessional and this should be explained to him forcefully. Ask him if he is happy if others adopt the same tone

3. Ask him if he is undergoing any stress domestically or has a health problem like Diabetes that is causing him to be irritable

4. Ask him if he is happy to be getting ancient and a grumpy old git with mind atrophying as he learns nothing new.

5. If all else fails say all his errors will be documented to save your own skin and conversations with him may be recorded