I've joined a team of around five developers building a microservice-based website, in a shop that emphasises autonomy and learning. However, it turns out one of the developers is writing "his" parts in his favourite new language, X.

I won't name X to avoid religious arguments, but instead list why I'm concerned:

  • X is new, relatively obscure, and seems more aimed at writing command line utilities, not web service APIs
  • it's evolving fast - apparently on going to document some older code, some base functionality had been removed, wouldn't compile in newer versions, so took a couple of days to re-implement it.
  • there seems little prior art for how to approach a given task in X. An upcoming request is to add searching to API endpoints. He has no idea how to go about this, happily admitted each endpoint is implemented differently and "might re-write the whole thing". I like his can-do attitude, but is this really how to approach production code?
  • the other developers are clearly uncomfortable with X despite some months of exposure. I've seen live site issues from deploying broken code when he was out. Yes, a conversation is needed around testing, but them not being able to spot showstopper errors in X is a red flag
  • He's started adding plugins to other services, "to make them more X-like". Not sure yet what that means.
  • etc. etc.

He's a pleasant and approachable person. He's not arrogant or argumentative or anything like that. He's just really, really into X, dropping it into every conversation, including to non-technical people. It's nice to see he's passionate, yet it's bordering on obsession.

I'm his new line manager, concerned about both the low bus number and the clear day-to-day risk from brittle, hard-to-understand bags of X.

While I could ask him to stop using X, it clearly wouldn't go well, and anyway I want my team to be autonomous and happy, building them up, not shutting them down. And yes, I am setting time aside to learn what X I can. Perhaps I'll see the light and I can help him that way.

How can I handle the risk to the project presented by X? Is X itself even really the problem?

  • 3
    Who is the team lead?
    – DarkCygnus
    Commented Jul 11, 2019 at 17:12
  • 349
    For what its worth, I think its absolutely brilliant that the language is not specified in this question as it is really not relevant to providing an answer.
    – Neo
    Commented Jul 11, 2019 at 17:24
  • 42
    @ventsyv naming the language in question would make the answers less useful, rather than more useful, while also generating extra work for the moderators. The only win would be in the mind of people who get an opportunity to argue for/against their own personal cherished/hated X. It is better left anonymous. +1 to the question for this delightful innovation.
    – Ben Barden
    Commented Jul 11, 2019 at 17:29
  • 3
    Have you asked the other devs if they dislike it?
    – rogerdpack
    Commented Jul 12, 2019 at 14:06
  • 6
    Now that this question has an accepted answer and has attracted some good answers and comments, will we get to learn what language X is? Commented Oct 23, 2019 at 12:13

16 Answers 16


I suggest you put the question up for discussion to the team. Present your concerns at the next team meeting and ask what they think about them.

Since they sound like valid concerns I would imagine you'll get support from the other developers.

Make sure the discussion stays professional and keep an opened mind. Focus on how using X affects the rest of the team. This way the developer will be less likely to become defensive and when he realizes how his use of X affects the rest of the team it will be very difficult for him to simply dismiss their concerns.


How can I handle the risk to the project presented by X?

To address this, I am going to use your own words:

it's evolving fast / unstable - on going to document some older code, he found some base functionality had been removed, wouldn't compile in newer versions, so took a couple of days to re-implement it


the other devs are clearly uncomfortable with X despite some months of exposure. I've seen live site issues from deploying broken code when he was out. Yes, a conversation is needed around testing, but them not being able to spot showstopper errors in X is a red flag

This language is obviously not very mature. Building your empire on quicksand is not a good plan, and I think you know that. As the manager it is up to you to manage the risk, and set the standards.

Is X itself even really the problem?

I think the problem may be that there are no standards set in your group. I would suggest you and your team agree on what languages are going to be used and then move forward.

Any new technologies should be presented to the team before they are used in production. When a new technology is presented, the team then votes on the validity of the technology. This way there isn't a single bad guy should X get voted down.

Also, and this is really important to you: You have to be able to support the code when a developer leaves. If you allow one off's, this becomes more difficult for you. You also might wish to do some research on this languages popularity and usage to make sure you can hire new help when the time comes.

  • 7
    Amen to this. You can't say if X is "the problem" or not without defining what constitutes success. One of the most important balances in running a software shop is giving developers freedom to do things the way they see as best, balanced against doing things that are best for the company in terms of sustainability. It's best when you can meld those two goals, and having good standards is how you achieve that.
    – dwizum
    Commented Jul 11, 2019 at 17:54
  • BTW, knowing X for a future hire and showing that you are using X is a very important attractive point for most future developers (the best ones, those that you want to hire). That is why many reputable companies are permitting some small usage of strange languages. BTW, most companies use make, but a few attractive ones use ninja for nearly the same role. Commented Jul 12, 2019 at 8:59
  • Agreed. All successful companies I've worked with have standardised on languages (and generally coding standards to make everyone's code look similar). The most important part of software is not making it do what it initially does, it's making sure that it can reasonably be maintained in future (which may not be by you!).
    – Graham
    Commented Jul 12, 2019 at 9:39
  • 4
    @BasileStarynkevitch "knowing X for a future hire and showing that you are using X is a very important attractive point for most future developers (the best ones, those that you want to hire)" Eh?! I'm not sure how you can claim that, not knowing what X is. In any case, I don't think I know many, if any good developers who actively seek out roles that work with strange, esoteric languages. Quite the opposite usually.
    – berry120
    Commented Jul 12, 2019 at 10:38
  • Developers getting to choose technologies is great and all, but only to a certain point. And one of those points is not letting each guy silo himself. Not only because other people will have to review and maintain this code, but your admin/ops/security people will absolutely prefer not to have to yet another tech to maintain and keep track of.
    – pboss3010
    Commented Jul 12, 2019 at 10:58

I'd be very, very concerned about this.

If he gets hit by a bus tomorrow, or decides to leave tomorrow, then you currently have:

  • A massive cost, both time and money wise, of finding an expert in X to replace him;
  • A team that doesn't understand any of the code he's written;
  • A team that can't reliably even deploy any of the code he's written;
  • Code that is likely to only work with a specific, unknown version of X, and break with future versions.

You'll then have your superiors raining down on you like a ton of bricks asking why the hell you let this happen in the first place.

You say he's a nice guy - just over-enthusiastic, so I'd put these problems to him, and the whole team in general. Ask for their thoughts on solutions. Emphasise that this isn't a punishment or anything they've done wrong, just a potential problem you all need to solve. Emphasise that this isn't a language driven problem, it's a business driven problem. Make sure you're open to criticism if your understanding of any of the above points are incorrect, but if not, you need to stand your ground in making sure:

  • No new code is written in X;
  • Preferably, you have a longer-term plan to migrate existing code he's written in X to another language.

That's not to say he shouldn't be instrumental in picking another, more suitable language that can be used, and that's not to say he needs to abandon X entirely. Perhaps you could set up workshops or presentations where he demonstrates new patterns / paradigms in X, and how they can apply to (relevant language for the workplace.) Perhaps he can search for another language that's more mainstream, but has more of X's properties.

However, if I were the team lead I certainly wouldn't budge on allowing such a language to be used in a business critical context.

  • 13
    Keep in mind, the bus factor is a common analogy for a risk evaluation, the user isn't trying to be dramatic. Commented Jul 12, 2019 at 18:49
  • 4
    @TravisClark Fun fact; the link you have goes to a page where a Wikimedia picture described as "A bus waiting at a pedestrian crossing in Lima" is captioned "A person in danger of being hit by a bus." Talk about glass half-empty/half-full!
    – kingledion
    Commented Jul 13, 2019 at 14:20
  • Solution for specific version of X: "check compiler into source control"
    – Joshua
    Commented Jul 14, 2019 at 21:48

Hard no.

Pet languages, or even excessive numbers of languages, getting introduced into a project make it completely unmaintainable in the long term. When the developer leaves, you'll end up with the code in their pet language in whatever status they left it in, and a pile of workarounds in the other components to get things done without having to change the code that nobody understands. I speak from experience on projects where this has happened.

  • 1
    This team/project/company obviously either has unlimited resources or is going to die quickly.
    – Sentinel
    Commented Jul 13, 2019 at 20:50

Absolutely not! Entire companies have died because they picked the wrong language in which to write their codebase. If the language dies, becomes unpopular, or leads to intractable scalability issues, the code dies too. Can you afford to rewrite it?

When you need to completely rewrite a piece of software in a different language, you will be a sitting duck, because you can't release a new product until the rewrite approaches feature parity with the old product. If it's possible to avoid a rewrite, you should!.

Case studies:

  • Twitter suffered from frequent "Fail Whales", and eventually rewrote their Ruby on Rails server.
  • WordPerfect got crushed by Microsoft Word. While there are many business reasons for their downfall, part of their problem was that much of the code was written in assembly language, making it hard to port to Windows.
  • John Ousterhout, who invented the Tcl language, founded Ajuba Solutions, a company whose software was mainly written in Tcl. While there wasn't really anything technically wrong with Tcl, it just wasn't that popular. His company had a few talented and dedicated Tcl developers, but it was difficult to hire. Eventually, the company got acquired, the codebase was abandoned, and the majority of the developers lost interest in working after the acquisition.

No single programming language excels at everything, and you do want developers to be able to pick the right tool for the job. That said, there have to be some constraints when introducing languages into your company's codebase. Some criteria to consider:

  • Enough of your team has to be fluent in the language so that there can be code reviews and multiple maintainers.
  • You have to be able to hire programmers who are willing to work in the language and its ecosystem. (And you have to be able to tolerate the kinds of developers who tend to gravitate towards those languages.)
  • The language should be versatile enough to make the investment worthwhile.
  • You should recognize and accept the risks associated with the language (e.g. frequent incompatible changes, frequent security vulnerabilities, quality of the standard library, scalability, memory safety, readability, error-handling strategies, unintuitive behavior, etc.)

Sometimes there may be mitigating factors to the risk of choosing a more obscure language. For example, a language might interoperate with other languages on a Java Virtual Machine or Microsoft's Common Language Runtime. Or the language (e.g. Swift) might be designed to interoperate with another (Objective-C). Interoperability at least gives you a migration path that doesn't leave you stranded during a rewrite.

You might consider granting more flexibility for throwaway code or prototype code. Sometimes the ability to prototype rapidly trumps the long-term concerns listed above. Beware, though, that prototypes can have a tendency to grow into permanent solutions.

In your particular case, you said that you have a microservice-based website, with parts of it implemented in another language. Even if you're not betting your company's future on language X, unnecessarily mixing implementation languages is harmful to building a cohesive architecture. (The fact that one developer has total free reign over one part of the project raises a red flag about the lack of architectural design at your company.) Having to learn the language is not the only barrier; it also increases the complexity of the tools for developing, building, static analysis, testing, and deployment. Then, there are also more libraries that you'll need to patch in the future. You also mentioned that the language introduces incompatible changes from time to time, which indicates that it is experimental-quality, not production-quality, software. If the entire team bears these costs just because of one developer's personal preference, everyone is going to resent that developer, whether secretly or openly.

In general, the choice of programming language (or, for that matter, programming frameworks) has to be a team decision, and should not be made by a single lone wolf or rock star developer. It sounds like your team is not comfortable with language X, and the group sentiment should be a good reason to require the maverick developer to stop using it.

  • 1
    Majority vote is a good way to go I think. But still people need to learn coding conventions and idioms before starting with any language, and only way to ensure people are writing idiomatic code is with code reviews.
    – JaDogg
    Commented Jul 12, 2019 at 9:11
  • 11
    Beware, though, that prototypes can have a tendency to grow into permanent solutions. Absolute +1 from me - I built a "prototype" system in VB3 (I know, I know) for a major City of London company just as proof of concept and it ended up going into production. 4,500 people used it in the end. I still shudder to this day.
    – Spratty
    Commented Jul 12, 2019 at 13:39
  • Word deliberately targeted WordPerfect initially and had Exchange to leverage the Office suite. Commented Jul 13, 2019 at 15:49

This is one of the few things were I think a manager should put his foot down and not give in. What the developer is doing will hurt the company in the long run. And it doesn't matter what X is -- all that matters is that your company does not have a lot of expertise in X, and it will be hard to attract expertise in X.

Your developer is wrong that X is the right solution. Not because it's the wrong language for the project, it's the wrong language for the company.

Tell your developer that his actions are not the actions of a senior developer, and even below expectations for a normal developer. Make it clear that his actions are not going to reflect well in his next performance review, and if he continues in this way, if will effect his chances on promotion and bonusses.

Tell him that you expect developers to act what is best for the company and that you're working on a product which is expected to be developed and maintained for a long time, and not just by him. Every current and future developer should be able to work on the product, without first having to learn a different language. Tell him that you expect good developer to consider what the situation will be next year, five years and ten years from now. And that decisions made today will influence the future.

In other words, tell him to leave his pride at the door and become a team player.

  • 17
    This sort of approach is extremely heavy-handed and can create resentment in a team where collaboration and cooperation and creativity are valued. There are times when an employee should be encourage to "do their own thing", and times when employees need to be told to toe the line. Since this wasn't against the rules of the team, a manager must take a more gentle approach. Commented Jul 11, 2019 at 18:07
  • 8
    As I said elsewhere, this is work, not adult Montessori school. That said, I agree with you AND Julie in Austin. It's clear the developer needs to stop treating X like the answer to all problems, but the way the message is delivered matters. The heavier hand could become necessary if he entirely refuses to do his job (i.e. expects work to be his personal playground), but that doesn't need to be the tone out of the gate.
    – SemiGeek
    Commented Jul 11, 2019 at 21:29
  • 1
    This answer is funny, because it talks about acting int he best interest for the company, but if the OP were to speak to the developer in such a manner it's likely the company would suffer. Being part of a leader is training subordinates in what's important. While maintainability may be an obvious concern for some, for others it just doesn't register on the radar. Commented Jul 12, 2019 at 3:18

Is X itself the problem?


X is not the problem... for every value of X

This is a management problem. As a new manager, you landed a tough one.

You problem is that you

  1. have a very enthusiastic programmer who you would like
    to redirect into a more productive employee.
  2. You suspect that if you tell him he can't use X you will have to replace him because he will leave
    He's telling non-tech people about X, so you're right (it is currently religious for him)

Explain how the world works:

As a new manager I love to let people use what they are passionate about. In your case that is X.

The problem is that we get graded poorly when things break. This reflects poorly on the whole team.
A few times the build has broken when you weren't here. I'm trying to learn X so I can join you. While it is interesting, I can't devote a enough time to it right now.

How we can keep X without making everyone look bad?

Because there aren't an established set of best practices for what we do, we cannot standardize on a language as new as X. This is why we have had problems with it even though you are an expert in it.

So... how do we address this in the short term?
Are there more stable builds that can be used? How can we ensure that nothing breaks and no one else has to stop what they are doing to learn X?

Change "the build has broken" to the most obvious problem caused by X being present.

Give him time to respond. If he doesn't respond with much, let him go back to his desk (repeat the question before he goes to get him focused on "how").

  • 1
    As I just explained on another answer, the solution to dealing with a rapidly changing compiler is "check compiler into source control".
    – Joshua
    Commented Jul 14, 2019 at 21:51

I think you're approaching the problem from the wrong perspective.

You are turning it in our pet language vs. his pet language problem. Languages are only tools, quite universal one, so their choice is a side issue.

The real problem is that you have a total chaos in team. It looks like everyone can do what he want, choosing any tool, even those he's really not familiar with. This is what you need to address.

Having only one person in team being able to support any relevant part of the project is simply insane. Either at least 2 people in team should master X to the extend allowing the maintenance, or X must go away.

The fact that your X-pet developer is not sure how to implement one of the crucial aspects in X means, that even he doesn't master it to reasonable extend. It's a moment to say sorry, but your company is employing people to do the job, and not to have fun learning new tools.

A considerable solution might be to allow him to develop experimental tools/features in up to, say, 20% time. Totally banning X might be counterproductive, if you want to keep this guy in your team (and you most likely will, since team of 5 turning into team of 4 in productive application will surely not help maintaining the app).


As others have said, this situation should not be allowed to continue. It does indeed sound like the fundamental answer is going to be of the form "No, sorry, you can't use X." And you are well within your rights to say that. Your worst case scenario is this dev gets upset and quits. That would be sad, but is his perogative and your answer should probably still be "No X."

As well as the problems already identified, one dev going off on their own with a pet language

  • makes effective code review impossible
  • makes interoperability with the work of other devs difficult
  • requires code duplication for all common utilities used by X and not-X (particularly those that are bespoke and not found in the X standard library)
  • Reduces team cohesion, particularly between X and not-X factions.

Perhaps a more helpful response than just saying "No X" in a loggerhead fashion is

  • Ask what in particular about X is desirable. If genuine, investigate whether some of these advantages could be used in a more standard language. (You'd be surprised at how many trendy features make it to new versions of old languages like C++ and Java, or at least get 3rd party library support)
  • Invite the dev in question to take the lead (although not without oversight) in developing what useful lessons can be learned from X and transferring them to Y best practices.
  • Collate some data to defend your point. E.g. it may help being able to say "We've already spent _% of X dev time just dealing with the instability of X, compared with _% in updating for changes to Y" or "Integrating and debugging X code has reduced the performance of the team overall by _%.
  • Consider whether there are underlying causes of this issue beyond the language preferences. For example, if this reveals a general team culture of isolated devs working on isolated features, do something about that. It may be, for example, that introducing pair programming could help address the roots rather than the symptom.

As an aside, it is possible for the right answer to be "yes, let's all transition to use X." That is not the case here, very compellingly because X is small, obscure, unstable, and a poor fit for the problem. However, suppose for example you're an Android shop and you have one dev agitating to move from Java to Kotlin, because Google have recommended transitioning from Java to Kotlin and promised that Kotlin will be better supported going forward than Java. Ultimately, they're very plausibly right.

Many of the same concerns apply. You'll need to worry about training, about code compatibility, about how members of your team respond, and potentially even the risk that one of your devs so dislikes the change that she decides to quit. Meanwhile, many of the same mitigations would apply: authorising invested people to spearhead it, collating data about why the decision has been made, listening to various stakeholders, etc.

  • I would highlight the concept of pair programming in Josiah's answer. Having to explain X's syntax to everyone would either get the dev to return to known languages or get the whole team excited about X.. Commented Jul 12, 2019 at 19:57
  • 2
    “Makes effective code review impossible” is a significant justification all by itself. I have seen this very thing happen, and that developer ran rampant, because no one was able to check his work.
    – VGR
    Commented Jul 12, 2019 at 21:12
  • In a team that “emphasizes autonomy and learning,” do they have code reviews (learning) or not (autonomy)? And is the tie breaker quality (code reviews) or fun (no code reviews)?
    – WGroleau
    Commented Jul 14, 2019 at 13:36

I'm the question author. This has been popular! Re-discovering this two years later, will give an update.

At first accepted https://workplace.stackexchange.com/a/140159/106726 as the answer - which TBF the developer had started doing on his own. But a couple weeks later he handed in his notice. He made clear this wasn't because of me, or X, but the company in general.

So, time to replace X, right? Nope. The business (read CEO / CTO) weren't interested in migrating, even though I was clear X was holding the company's products back, was a serious source of risk, and made multiple proposals for moving the product forward. (Anyone familiar with "brochure over functionality" startups should recognise this).

We limped along using X. We could compile and deploy it, and as I grew the team, a couple of talented engineers learned enough to make various changes. I left things open for if they became fans, but no. The X-community infighting killing the framework we used didn't help. I made sure that the rest of the stack had no X and used standard approaches. We worked around it when needed.

I left the company several months ago. As far as I know, they are still using X for a business-critical, customer-facing web API.

EDIT: oh go on then. X is Rust.

  • 6
    May we now know what X is? It's been bugging us for two years! Commented Aug 11, 2021 at 8:30
  • Just commenting because I also want to know
    – bibleblade
    Commented Aug 12, 2021 at 8:27
  • my money is on perl or lua. Commented Aug 12, 2021 at 15:21
  • Yes, allright then :) Have edited. X is Rust.
    – vavojediha
    Commented Aug 17, 2021 at 7:30
  • 1
    If you do take this to the CEO/CTO you essentially robbed your team the capability to vote X off the island. Commented Aug 17, 2021 at 16:30

No, language X itself is not really the problem. What you've described here are the symptoms of a much deeper problem that will affect all the other systems your team produces as well: the team isn't really working as a team but instead as a bunch of disconnected individuals.

Your instinct that you "want [your] team to be autonomous and happy, building them up, not shutting them down" is correct; you need to solve this problem by coaching the team to fix it. I would start with trying to remove the clear code ownership that's happening where the code written in language X is "his" code. It's the team's code, and the team as a whole needs to be responsible for maintaining it and extending it.

You might start with how stories (or whatever your equivalant) are assigned. Ideally all members of the team should be regularly working on all parts of the system, rather than specific parts of the system "belonging" to particular developers. It's fine if you have some developers who are experts in a particular technologies or parts of the system while others are not, but there should be nothing in your system where there aren't at least two developers who feel they know that part well enough to be the technical lead on any particular story where it's a major component.

Pair programming and just asking for help are typical solutions for spreading knowledge. Extreme Programming handles this by allowing anybody to pick and be the lead on a story, no matter how much or little they know about it, and relies on developers not being allowed to say "no" to requests for help with that story, allowing that developer as he gets his help to learn all the gory details necessary to getting the story done. (Story assignment in XP is actually a project management function: the developer managing a story for that iteration is responsible for making sure it gets done, finding all the resources necessary to do so. This will typically result in the developer having a reasonably deep technical understanding of the story by the end of the iteration, whether she started out with that or not.)

So explain to your team that you're happy with using language X, or anything else, if the entire team has a consensus that it's a good idea and agrees that if the developer in question is kindnapped by aliens the team will carry on just fine without him. It's then up to that developer to sell his technical ideas within the team. Make it clear that even if the team doesn't agree to make X the primary development language for all new features this doesn't mean it can't be used at all; perhaps it could be used in just certain smaller areas in order to test it and gain experience with it. Encourage regular reviews both of how language X is working out where it is used and of specific subsystems (whether using language X or not) regarding how well they're working, what kind of problems are typically coming out of it, and how these can be mitigated.


Building on other answers, I agree that languages/technologies to be used in the project should be positively selected by the team before being used (excepting possibly a trial or test case for feasibility, with no promise or critical-path to be used in the project itself).

I worry that that wasn't done, and trying to bring the topic up for discussion with the team now would result in no one willing to confront the rogue programmer and say "no" (following from the fact that even the manager is currently fearful of taking that step).

Consider the following as a possible way to solve this: Have a "reset" meeting, where the team will jointly select/approve technologies to be used and supported in the project. Act as though the project was being newly started, no languages had been selected to date, and you're starting from a blank slate. Now the burden of proof is on getting to "yes" for the new language (as it should be), instead of the "no" (where it currently seems to be).


You should make it obvious for the higher-ups and the team that X in its current state is a problem, because apparently there is currently no understanding that this is the case. Tell everyone that the team needs at least two X experts, in case one of them calls in sick. Ask for a training in X for the whole team. Every time the project breaks because of an incompatible X update, or a trivial bug which wasn't found because testers are not familiar with X, start a discussion on how to prevent such mishaps in the future.

Either the company will decide to drop X, or they decide to go all-in and make X widely adopted. In either case, the problem of X being a "pet language" will disappear.

And don't blame the developer for "bringing X upon us". Approachable and passionate developers make great company assets and great colleagues. It's not their fault the management bought into their idea of adopting X which they thought was brilliant, without evaluating the risks.


I think you need to have a discussion with the team on this language. Let the developer to present the language first, hear the advantages the language can give as well as what disadvantages language has. Bring up your concerns about stability, compatibility, etc. Take a look on the track record of who developed the language (for example Microsoft is known to kill the technologies that they were promoting shortly before kill announcement (see multiple iterations of Windows Phone, Silverlight, etc.)) Encourage other developers to provide their thoughts.

If discussion turns against X and you do not really want to entirely shutdown that developer or it would get even you can make a decision on to keep the language to a one off project and see how is it going to go and have a second round when the project is complete (honestly, this is what I would do no matter what (unless X is a complete trash): let a small one off project fully be done in that language and have a second round).

PS: sometimes some really "strange" and uncommon languages can give a huge advantage in some projects: http://www.paulgraham.com/avg.html (Article is almost 20 years old so you can ignore the technologies and languages but think more about a concept)


In top of the answers

I think the problem is about confidence.

your developer is confident of using X and afraid of using any other language he is not so good at.

probably a training in the capabilities of your Y language may give him some confidence in using Y


Consider the possibility that your developer (the one who really likes X) is on the autistic spectrum, or at least has autistic traits. The obsessive focus on one thing, talking about it all the time, may indicate that this person has some sort of condition, which makes it difficult for him to approach the matter objectively.

The reason why I'm saying this is because, if this is the case, you may need to handle the matter differently than you would have with a neurotypical (i.e. "normal") person. It doesn't mean that said developer is less suited for the job.

My employer pays me to write software that we sell to customers. They don't pay me to muck along and do whatever I like. I like to play video games, for example, but that doesn't bring in any money.

Similarly, a non-established language like X appears to be causing more problems than that it is solving. It means that the productivity and performance of your entire team is at risk, because of one guy who wants to do things differently.

If using X can be shown to have a net positive effect on productivity and performance, keep it. Otherwise, make clear to your developer that he needs to separate hobbies (his fascination with X) from work (what pays his wage).

At work, I'm experiencing a somewhat similar scenario. In my department, there are basically two main pieces of software that were written a long time ago, and haven't really been updated. Anaemic object model, poor coding practices, old-fashioned technologies and frameworks... The list goes on.

And while I have the experience and knowledge to introduce new concepts, like domain-driven design, micro-services and single-page applications, I also need to consider that the other developers will need time to catch up. It's a delicate balance that needs to be struck.

But in the end, you need to focus on the well-being of your entire team, not its individual members. You cannot make everybody happy. It's a company, not a democracy. It's imperative to listen to people, but it's equally imperative to make a decision and ensuring that everybody sticks to it. Otherwise, don't be a team leader.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .