243

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.

  • 11
    Comments are not for extended discussion; this conversation has been moved to chat. If you want to troll the OP, that's not acceptable. If you want to answer them, use the "answer" box. If you want to talk about all the others subjects which I deleted comments about, such as politics or favorite websites or development tools, take it to the provided chat link. – enderland Oct 14 '16 at 14:37
  • 10
    I couldn't help but noticed your profile includes what is likely your own picture. Bossman won't be pleased if he stumbles across it. Like, when a co-worker tips him off. – Tony Ennis Oct 15 '16 at 19:54
  • 4
    Reminder: this question is based on the poster's interpretation of the friend's interpretation if the situation. That's two layers of possible misunderstanding. We can respond to this as written, but there is real risk that specific answers will not be a good match for what is actually happening. Caveat lector. – keshlam Oct 15 '16 at 21:22
  • 3
    Vote to close as off topic because it's highly unclear what your position and options are. "Should throw out the lead?" YESOFCOURSE, if that's an option why are you even bothering to post this. If that's not an option then please elucidate us what you want to do and what you can do. – user42272 Oct 17 '16 at 22:37
  • 3
    And yet no less than 10 people found the question able to be answered which nearly 200 people thought WAS a good question. I'm wondering if there should be a closure reason that says "Even though 200 people understand it, I and 4 others don't, so close it." – Chris E Oct 24 '16 at 14:06
260

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.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Monica Cellio Oct 16 '16 at 3:09
  • A founder that trusts a new hire so unconditionally despite having no way to judge that the guy is even capable isn't worth arguing with. I agree, run at the first convenient opportunity. There are better jobs for devs out there. – Magisch Oct 17 '16 at 14:14
  • 1
    @Magisch I've seen that exact scenario play out many, many times in my career. Guy with impressive resume (or good at selling himself) gets hired and is not the "Golden Boy". In every single case, the GB loses his luster and ends up on the outs as well. Unfortunately, it's usually after he has decimated his team (which is how he covers himself when he first starts to show his incompetence). – Chris E Oct 17 '16 at 14:23
  • 1
    @tuskiomi that picture's a couple years old but I've always looked young anyway. I got carded into my 30's. My first job in IT (we called it DP then) was in 1986 so it's been 30 now. Doesn't seem possible to be honest but my first project was installing Advanced Netware 2.0a on a brand new PC's Limited (Dell) 386-16 server with 2Mb RAM and 2 full-height 70Mb drives on a thin-ethernet backbone. :) – Chris E Nov 29 '16 at 21:18
  • 1
    I realize that the OP's initial version missed an important detail: that she is not an employee, but a consultant brought in to (presumably) fix this problem. Telling her to run away from the problem doesn't really help, which makes it look all the more strange that she "accepted" the answer! Not criticizing your answer, of course, it is excellent as always, just pointing out what I found odd. – Masked Man Feb 24 '18 at 9:59
86

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.

  • 6
    As for code optimization, I largely agree (though there are definitely exceptions). Algorithm optimization, that's a different story. I generally don't care if I'm using a 32-bit or a 64-bit integer variable to hold some quantity; if I think there's a risk that 32 bits won't be enough, I'll use 64 bits and not think any more of it. However, it's impossible to make the software perform well if you use O(n^3) or O(n^4) algorithms on large datasets where it's possible to get the work done in O(n^2) or maybe even O(n log n). Nothing you do to the implementation of O(n^4) can get you O(n log n). – a CVn Oct 15 '16 at 18:15
  • 9
    Without an ORM, it can take hours to write code to reconstitute a hierarchy like order -> shipment -> item. With an ORM this takes minutes. Just pull the orders, prefetch the shipments and items. – kevin cline Oct 15 '16 at 20:35
  • 2
    @Josef I agree! Spending time on fixing things that aren't problems is very often a waste of time. But I disagree with that you wouldn't identify that kind of issues with a profiler. The purpose of a profiler is to identify code segments that take overly long to execute during some particular workflow. The next step after that is to identify whether that long execution time is a problem and, if it is, why and what to do about it. The profiler provides raw execution time data as an input to that process, but there's no point then in making small adjustments if the algorithm is bonkers. – a CVn Oct 16 '16 at 8:55
  • 5
    I always like when I get to ease off problems by using SQL smartly. SQL is a super easy way to get what you want, and no ORM frame work could be easier, imo. – Magisch Oct 17 '16 at 14:17
  • 2
    I cant agree with your opinion about raw SQL. I agree that every serious developer should know SQL and be aware of SQL when using ORM, but seriously, if specific problem can be solved using ORM and is not a bootle neck, should not be solved using raw SQL. Not because ORM is more fancy, absolutely no. Its much safer and easier for maybe less experienced people who are working with you to take over your code. You may think its wrong but this is how it is, I knew senior developers that didn't remember how to use group by. We may like it or not but we work together. – marxin Oct 17 '16 at 15:39
45

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.

  • Nowhere does the OP say "agile" or "sprint". I suspect this place has an ad-hoc methodology, at best. – Tony Ennis Oct 15 '16 at 19:50
  • 3
    @TonyEnnis That's why I used "e.g.". There should be something comparable to sprint demos if you want to be visible, no matter what methodology you use. – Peter Oct 15 '16 at 20:07
  • 2
    Ah, I see. Getting some tangible results in front of the boss is a good idea. – Tony Ennis Oct 15 '16 at 20:17
16

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.

  • 33
    The flags you highlight are important issues that weren't address, but everything else about this dev lead flatly contradicts the idea of "getting you into shape" unless the founder is likewise stuck in techniques from 25+ years ago. – eques Oct 14 '16 at 13:19
  • 52
    "into shape" by abandoning testing, style, documentation, version control, respect and communication ... yeah right :/ not the best joke you're making here, though. – Daniel Jour Oct 14 '16 at 13:28
  • 2
    @eques Depends how deep the motives go. The founder personally interviewed and hired this guy without additional input. Without knowing the discussion behind closed doors NO ONE can provide anything more than conjecture right now. – MonkeyZeus Oct 14 '16 at 13:29
  • 13
    @MonkeyZeus I'm not saying that your answer is unfavorable, I'm saying that your answer doesn't answer the question. I would infer that you are telling the OP to suck it up and do what the manager says, but then the last line says "don't adopt the new guy's bad practices." How does the OP do both? – David K Oct 14 '16 at 13:39
  • 4
    While it would make sense to hire someone with particular skills to get a team into shape if their technical skills are lacking/not satisfactory, however, given the other aspects (if accurately described), that could not be the direct case unless a) the founder is of a similar technical mindset or b) the founder is completely ignorant of technical skills and development technique. Given the OP does not specify whether the founder is a technical founder it's quite possible that the founder doesn't recognize the technical limitations of his new hire (not that those are the only issues) – eques Oct 14 '16 at 13:54
8

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.

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.

  • 12
    It seems like everybody else here has assumed that "the chief has spoken", but it might not be the actual case. From what I've read, the employees and the new manager have only had individual talks with the boss, and not all at the same time. Could be worth a try. – user1306322 Oct 14 '16 at 11:04
  • Can you expand and explain more? This is a valid counter opinion to Chris's answer, but right now there's not enough detail for it to be a good answer. – David K Oct 14 '16 at 13:07
  • 5
    +1 For let the diva tell his side. The complains are so blatant they look like untrue. For sure it's a classical ego clash and at least one dev here is a toxic person – jean Oct 14 '16 at 14:28
  • If you're unhappy with your job, and not interested in getting shit on for trying to fix that, why stay? There are plenty of better jobs. – l0b0 Oct 14 '16 at 18:11
1

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.

1

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)?

-6
  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

  • 6
    Nobody is going to change their opinion on version control and IDEs after 25 years. I'm not going to change my opinion. Lucky enough for me, my colleagues, and the companies I've been working for I'm all for version control (even for work I've done on my own; it has saved my ass before), and for using IDEs (why on earth would anybody not use an IDE). But again, no discussion will change his mind. – gnasher729 Oct 14 '16 at 13:01
  • 22
    "Ask him if he is happy to be getting ancient and a grumpy old git with mind atrophying as he learns nothing new" Something tells me this would not go over well. – MissMonicaE Oct 14 '16 at 13:23
  • 7
    +1 for trying to explain the benefits. -2 for insulting him, no matter how rude he is. – l0b0 Oct 14 '16 at 18:15
  • 1
    I think the main problem with this answer is that it implies that the team lead is on the same level authority-wise as the rest of the team, which isn't the case. While the team lead can't fire anyone, the owner put the team lead in charge and the owner can certainly fire people, so it's not hard to imagine that being rude back to the team lead might not end well for team members, even though it might be tempting. – bob Apr 30 at 15:57
  • 1
    It is always wise to use tact when interacting with one's superiors. – bob Apr 30 at 15:57

protected by enderland Oct 14 '16 at 14:37

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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