I have been working for five months for a big French company building great things, a good product with trend methodologies.

I've just learned from an internal coworker (technical expert) that I will likely be let go because there's a too huge of a gap between me and other developers in terms of programming knowledge/practice.

He reveals me that the team manager often asked him:

"Is the code of Mik easily readable and understandable?"

He answered:

"Yes, but one should have a good level to understand it because components are intelligently decoupled."

Team manager response:

"But is it really good as he pretends?"

He answered:

"Sincerely, Yes, I used to read his code to learn TypeScript/Node.js at home."

Team manager response:

"But it's a real problem if the team doesn't understand his code ... even if the team has less knowledge. We can't depend upon him in a long-term".

I am upset.

I was doubtful about this reason, but I found this article.

It's the third time I have come across this situation; when you produce really good code, and you get fired without any reason.

It's not a joke, I could not stand to have this happen a fourth time, and it's impacting me mentally.

How can I avoid this in the future?

To be arrogant is not my nature. I like to share my knowledge.


A lot of answers deal with the fact that I should try to work for the team, and not for me only.

I just point out that I was not expected to work with the team.

In my contract, I had to work ALONE in order to build a complete software alone, with my own programming principles.

I was recruited BECAUSE the team has no skills at all in the demanding fields.

The team just looked at the code (by curiosity) one day during no more than 5 minutes, and directly talked to my manager.

5 minutes, really, for about 10,000 lines of code after 4 months of work.

Yes the companies were similar in the sense that I was expected to reduce the level of skills to fit my team and I strictly don't want. I enjoy the IT field because it is challenging for the brain. I need challenges.

Three times are enough to confirm me that I feel far better with passionate people that would challenge me than standard employees that do not expect to improve themselves. I just notice that their way of doing isn't successful, so why changing my mind to fit theirs, to be unsuccessful by the way. Those typical big companies whose IT is not the primary reason of existence are not for me.

  • 6
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Nov 19, 2016 at 6:22
  • 43
    After comments were moved to chat, 33 more comments were posted. Those can't be added to the chat room automatically and the extensive discussion in those comments sure doesn't belong here, so they're gone now. If you want to discuss this post, use the chat room. Comments are to request clarification or suggest improvements to the post, not to...chat. Commented Nov 21, 2016 at 19:02
  • 4
    Can you post 20-30 lines for example? And what is the programming language?
    – i486
    Commented Nov 22, 2016 at 10:49
  • 6
    Hi @RobertHarvey, unlike Stack Overflow, on Workplace SE, comments can easily lead to extended discussion and back and forth, something we want to discourage on a Q&A site. To quell the extended discussion, we typically move them to chat and encourage folks to post anything of value as an answer. When material is posted as an answer, it can be voted on, searched from search engines, and ranked according to votes. Please see Robert Cartaino's post, What "comments" are not..., for more details. Hope this helps.
    – jmort253
    Commented Nov 22, 2016 at 12:29
  • 6
    @Mik378 if there is information that you want people to know, edit it into your question. Don't put it in comments. Commented Nov 23, 2016 at 18:10

23 Answers 23


It's not a joke, I could not stand to have this happen a fourth time, it's impacting me mentally.

This line is important, because it shows that you feel it is time to change. It shows that you recognize this as a pattern, and would like the pattern to stop. That desire is probably the most important part of the solution. Fixing these sorts of situations often involves changing the way you, yourself, think. It's impossible for someone to do that for you, so your desire to change will be the one thing that makes the change happen.

For some background, I've been in similar "too good at coding for my job" situations before, though never to the degree you describe. I could cure cancer with template metaprogramming in C++, but many whom I work with are barely versed in the basics of Object Oriented Design. I wrote code which abused SFINAE and pushed right up against the exact wording of the C++ specifications, when many projects I worked on were still using antiquated and buggy versions of gcc. My approach was simply to show them just how amazing these tools are, and all the problems it could solve. I loved explaining little programming tips to people, and they largely enjoyed it.

Does that sound familiar?

"Yes, but one should have a good level to understand [Mik's code] because components are intelligently decoupled."

Consider this statement from a risk based perspective. Your boss needs to keep things going, no matter what. If you leave to go chase some awesome job opportunity, your boss still has to make sure the code gets maintained. What your coworker just said was that, if they have to replace you, they need to find a very skilled coder, because anyone who isn't that good will not be able to maintain it. This is a risk. What if they can't find a good enough developer, or can't afford to pay them enough?

You may have produced what you would call "good code," but the definition of "good code" is very much dependent on the context. What is "good code" at Google, with their cutting edge ways of thinking, may be very bad code for someone working at the FAA, who is predominantly concerned with reliability rather than keeping up with the cutting edge. Your boss' definition of "good code" includes the ability to maintain it in all sorts of situations, including without you. If your coworkers are not comfortable maintaining your code, then you are suddenly a liability to the company, because you produce product which they cannot maintain if you decide to go elsewhere.

From this perspective, one may argue that you are forcing them to accept your definition of "good code." Instinctively, this may appear to be a good thing, but it is fraught with difficulty, such as this risk based way of thinking which you may not have been thinking of.

We have a phrase, "putting the cart before the horse." One of the many meanings associated with it is putting the content you care about most (being able to use your advanced techniques) over the forces which should be pulling it forward (your coworker's understanding of these techniques). You've written the code in this advanced style, and then encouraged the other developers to "catch up" to this style. This can be effective, but if anything happens to you before they "catch up," the company is suddenly at risk because nobody can maintain the code.

How can I avoid this in the future?

Fixing this can be a terribly hard thing to do because it involves approaching the problem in a different way than you are typically comfortable. Instead of first writing code in this advanced style, and then teaching your coworkers how to think that way, you should flip it around. Teach your coworkers to like that style of coding, and then start writing code in that style. It may seem backwards, but its much more stable. From a boss' perspective, there's little to no risk from the team learning to code better. Once they code better, the style you want to develop in is suddenly less risky.

In the mean time, you will have to write code which, by your standards, is "less good," but that's okay. Your code is not your only product here. Your other product is helping teach the other developers, and the value of that can easily exceed the value of writing "perfect code."

Of course, it can be hard to tell when it's safe to write code in the style you want to write in. If it was easy to tell, you'd certainly have figured it out by now! One powerful technique you can use is to let others push for the advanced coding styles, rather than pushing for it yourself. It's one thing to teach someone the difference between inheritance and composition. It's an entirely different thing to teach them well enough that they advocate changing your existing codebase to be more clear in when it uses them. The latter case really lets you know that not only do they get the concept, but truly embrace it.

One ideal for teaching such concepts is to teach nothing. Let the students discover something, and then you point them in a direction that discovery can go. Maybe one of them discovers something neat about inheritance and you can point them towards the Visitor design pattern based on what they discovered. Don't just give them Visitor, but give them a sense of direction so that they can go out and find Visitor themselves.

It's a much more difficult approach, and you'll certainly want to find a happy medium between that and your current approach, but it can be very rewarding. More importantly for your answer, it can provide value to the company without the risk. If you are providing value to a company, and not putting the company at risk, you will virtually never get laid off. And in the few cases where you can still get laid off, management will provide a reason for it (such as a downturn in the economy, or a shift in direction of the company). If you do it very well, you'll find that management instead will start shaping your path, just as you shape your coworkers, and you'll find a curious tendency for you to have learned just the right skill just when they need it most.

  • 79
    @Mik378 I've never seen anyone more in need of a code review in my life. Look a code review isn't just about approval (really it shouldn't be about approval). It's a chance to watch people read your code and talk about it. It's part of becoming a socialized programmer. If you want to go really far in programming don't just program alone. Sit down with these guys and code together. It's called pairing. You may find you learn something from them as well. Commented Nov 20, 2016 at 5:10
  • 13
    @Mik378 It seemed you didn't try pair programming in the workplace that caused you problems. If you did, why would anyone find your code hard to understand?
    – Mołot
    Commented Nov 20, 2016 at 8:28
  • 17
    So, your contact says you had to work alone, but you were doing extensive pair programming? Commented Nov 20, 2016 at 8:52
  • 72
    @Mik378 - Your hypothesis that your colleagues can't read code would hold more water if this wasn't the "4th time" it has happened. Honestly (And I say this as a working manager of a development team), your comments and responses here scream an attitude of "I am a god among developers. I write awesome cutting edge code. Nobody else understands it because they are stupid and/or lazy." That is what comes across to me in 10 minutes of reading your question, and your responses to subsequent answers/comments.
    – JohnP
    Commented Nov 21, 2016 at 16:46
  • 10
    @JohnP You are right. The warning signs are rather strongly visible. However, having not seen his code nor met his coworkers, my inclination is towards solutions which work in all cases. If he is really that good as he claims, then this approach will help him lead the company forward. If your instincts are correct, then this approach will help him follow. Both are accomplished by listening, and trying to understand the desires of one's fellow coworkers. Thus we can find a path forward that is good, regardless of anyone's perceptions of his skill (including his own, yours, and mine).
    – Cort Ammon
    Commented Nov 22, 2016 at 16:05

Well I hate to burst your bubble but if this is the third time this happened that almost rules out "it's not you, it's them". Your title says that you were fired for being "indispensable" but apart from that being an oxymoron, it's also not what happened. You were fired for writing code that your colleagues can't understand, which is a critical performance issue for a programmer.

Good code is readable code, which is to say code that is easily understandable, even for novices. The situations where you need complex and tightly written code that should be written and maintained by true experts are very rare these days and you were evidently not working for those types of companies. What you describe sounds more like "fancy" code which is typically overly complex, full of esoteric programming tricks and takes ages to figure out and debug. It's a common failing for people who were classically trained and they're typically in for a rude awakening once they enter a productive environment.

  • 45
    Good code is readable code, but not when the gap is too huge. For instances, they didn't know what is the difference between inheritance and composition. You can't fight this deep lack of knowledge in a matter of weeks/months. They are used to use only if/else, everywhere in the code with a lot of DRY breaking.
    – Mik378
    Commented Nov 18, 2016 at 15:04
  • 60
    @Mik378 True, but I based my answer on the fact that you've had this happen twice before already and that makes it unlikely that there aren't any problems with your coding style at all, even if this latests dismissal was mostly because of incompetent colleagues. It's also the only aspect of your question that can really be answered as we can't really determe whether or not you're simply applying at the wrong companies.
    – Lilienthal
    Commented Nov 18, 2016 at 15:34
  • 12
    @Mik378: Have you considered training your coworkers? If you mentor them (for example, through code reviews), then not only can they get up-to-speed but on top of that your code no longer feels alien to them. Commented Nov 18, 2016 at 16:29
  • 75
    @Mik378 : The compiler is not your audience, your teammates are. If you can't adjust your writing to your audience, then you are failing to communicate. That this has happened more than once seems to indicate you are incapable of writing to your audience. Commented Nov 18, 2016 at 17:52
  • 77
    "Good code is … easily understandable, even for novices" — well that's just not true. In fact it's hilariously wrong and devalues this answer considerably. A well written paper on quantum statistical mechanics will be gibberish to a novice without any background in the field. The same is true for code describing a complex system. I'm not sure what purpose is being served by pretending that this isn't true (regrettably it appears to be a common misconception recently). Commented Nov 19, 2016 at 1:33

There are always reasons.

A previous employer did this with a coworker of mine. His skill level was far beyond our skill. So, he was let go.

Why does this make sense?

  1. He was the only one who could maintain his code
  2. He was not collaborative
  3. He did not follow shop standards
  4. While he was delivering more than needed, this was not a good thing
  5. Simple, solutions were needed instead of complex ones.

It's said so often that it's almost a cliché, but you have to be a "good fit" for the team.

Coding is only part of the equation. You have to be personable, communicative, humble to a degree, arrogant when needed, keep to shop standards, get along with your coworkers, be approachable, and quick to help when needed.

All of these soft skills are important, and not having them will cause trouble for you.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Nov 19, 2016 at 6:23

Good code is easy to understand, even for poor engineers. One advice I often received is "program like if the person that will maintain your code is a mediocre programmer, and a dangerous psychopath who know where you live".

And it's true. Too clever programming is bad, because maintenance is longer when you don't know the code. In maintenance, you often have fire everywhere, thousands of customers blocked, and a more clever and efficient solution might very well keep the maintainer stuck longer than a dumb script-like code full of repetitions.

Of course, totally dumb code is bad, too. There is a fine balance to find between dumb and genius: efficient, and still readable. It's more an art than a science. That's why clever concepts such as multiple inheritance are usually not advised. Even if they rock.

You have to take in account the context. If you work in a small edge firm that hire only the best, you probably can afford some exotic, brilliant things. If you work for a French bank that relies only on consultants of, errrm, random quality (sometimes they are lucky, sometimes not), and where each consultant has a domain of millions of LOC to maintain, then by all means make it simple enough for a mediocre to understand it at first sight. No pointers, no multiple inheritance, no clever tricks, etc...

  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Jane S
    Commented Nov 19, 2016 at 6:23
  • "Good code is easy to understand, even for poor engineers." I don't think the worksplace is a great place to talk about software engineering. I keep seeing naive comments like this, and that isn't the whole story. It's a vague generalization that sounds great in a sound byte for a TED talk or something, but doesn't hold any water in real life.
    – Cypher
    Commented Aug 13, 2019 at 19:18
  • @Cypher : the context is a "big French company". I happen to know those ones a little bit. Most work in such companies is done but consultants of, errrrrrm, random quality. That's why readability matters so much. Whatever you do in such a context, it has to be understandable by the next clueless guy that will take your seat within no more than 3 years. Other contexts may have other rules. I'm speaking about the OP's context. (and yes, IT in big french companies is in average very bad - their practice of never hiring and always using consultants is catastrophic - but it's the reality).
    – gazzz0x2z
    Commented Aug 20, 2019 at 14:40

It's unlikely that you are fired because you are too good. I guess that's just an excuse.

It's much more likely it's a behavior issue, or the boss just doesn't like you for reasons he can't tell you without creating grounds for a lawsuit. It's also possible that you are the most expensive and they believe in FTEs (i.e. every worker is the same).

If you really are that good, you can make yourself indispensable in a good way:

  • Mentor the junior programmers. Tell the benefits and drawbacks of different approaches and let them make their mistakes instead of telling them which approach to take.
  • Write good code that is easy to maintain by other people.
  • Advocate best practices in ways that increase productivity, as opposed to cargo cult best practices, which sound good on paper but kill productivity.
  • 2
    Did you read the article I linked in my OP? It seems that it's a kind of .."habit" for certain managers...
    – Mik378
    Commented Nov 18, 2016 at 14:49
  • 3
    As I said above, I planned 8 meetings about 2 hours each one, to teach them some good code practice. No effect.
    – Mik378
    Commented Nov 18, 2016 at 14:50
  • 8
    @Mik378 Mentoring and teaching in 2 hour lecture slots are very different things. Regarding the article, this is actually an instance of cargo cult - there are very good reasons to fire someone who makes themselves indispensable, but that's very different from firing someone who is just on a higher skill level
    – Peter
    Commented Nov 18, 2016 at 14:57
  • 1
    @EsotericScreenName It stands for Full Time Employee, but the term is used to describe workload (or sometimes pay). If it's used it assumes every worker is the same. In software development that assumption is usually rubbish.
    – Peter
    Commented Nov 18, 2016 at 16:04
  • 2
    @Peter I believe in the context you're using it, it's "Full Time Equivalent" - that is, if you have someone who works only Mondays and Tuesdays, and someone else who works only Wed-Fri, together they make 1 FTE. It is a poor organisation that expects the same performance from two such developers as one full time developer, however, which is the point you make.
    – AakashM
    Commented Nov 24, 2016 at 14:36

Firing indispensable people is actually sound management strategy. When your company relies on one single person continuing to do their job and nobody else in the company has their knowledge and/or ability, this creates a huge liability: what if that person is hit by a bus and dies (hence the term 'bus factor') or simply chooses to leave the company for a new challenge? Now your company is stuck in a terrible situation because nobody can immediately replace the indispensable employee and you had no control over the timing!

To prevent this situation, the company has two options. Either they can attempt to disseminate the knowledge and/or increase the ability of the indispensable person's co-workers, or they can pull off the band-aid in one go by firing the indispensable person at a time of their choosing and recover from the loss of said worker when they are prepared for that process.

As it's not always practical to close a large gap in knowledge and especially in ability, firing them can be the more logical choice.

As an employee, you should always attempt to prevent becoming indispensable. Share your knowledge with your colleagues and make sure that there are people who can do your job when you're not there. Make sure your practices are suited to the workers with the average level of skill at your company. If you feel that average level is too low, work with management to try and increase that level. Ensure that anything you create is well documented and that said documentation is of a high enough standard that any of your colleagues can use it to continue your work.

  • Meaningful answer
    – Mik378
    Commented Nov 18, 2016 at 15:46
  • 15
    +1 Hording knowledge, deliberately performing above your coworkers, only causes trouble. "Don't be irreplaceable, if you cannot be replaced, you cannot be promoted" Commented Nov 18, 2016 at 15:47
  • 13
    No, firing someone for being indispensable is not a good strategy. Really? You would get rid of an employee because he/or she has done a job too well? Promoting or moving them to other challenges, thus giving others opportunity to fill in the gap and relieve the dependency on the individual (which is what the article refers to) is good strategy. The inverse, keeping someone that should be fired because he or she seems to be indispensable is the real problem.
    – SteveJ
    Commented Nov 18, 2016 at 20:19
  • 4
    Yes, you should work to prevent low bus factors. Yes, you should ensure that people who have grown indispensable share their knowledge and skills. What you're suggesting is akin to cutting off your arm because a scratch on your hand might get infected.
    – Lilienthal
    Commented Nov 18, 2016 at 23:42
  • 5
    If there is an 'indispensable coder' then fire the manager. No one fires high quality workers for being good enough to become indispensable.
    – Tony Ennis
    Commented Nov 19, 2016 at 16:37

If the only thing in common between the three situations is you, then you need to consider that something you are doing is a problem.

Have you talked with your former co-workers and asked them to critique you? Not your code, but your behavior in the office. The way you communicate with your coworkers, the way you communicate with your boss, the way you do documentation, how you behave in meetings, etc.

Have you put yourself in your supervisor's position? Really thought about what they have to do, what their responsibilities are, what makes them feel good when they turn off the office light and go home? There are many, many examples where somebody writes amazing code from the perspective of other software engineers, but the company fails.

  • Indeed, I am used to often suggest strategies, to criticize existing bad strategies with courtesy. Maybe they interpret that as being "arrogant" or "Lessons giver". But criticizing is part of my job as an engineer.
    – Mik378
    Commented Nov 18, 2016 at 14:33
  • 5
    The hierarchy does not always want to hear those criticism. You say "we should do X instead of Y"; what the boss hears is "You are stupid because you decided to do Y in the past. If I had been here at that time we would have chosen X". No matter how politely it is worded.
    – John Feltz
    Commented Nov 18, 2016 at 14:40
  • 1
    Criticism kills relationships. Period. Commented Nov 19, 2016 at 7:25
  • 2
    Lack of constructive criticism kills companies.
    – Eric Lloyd
    Commented Nov 22, 2016 at 20:52

I looked at your profile, it says "your code should be cleaner than yourself". Also from your comments that you "spent a lot of time explaining concepts", and "criticizing is part of my job as an engineer"... I'm thinking you are keen on giving advice and your advice is simply not appreciated by your team-mates.

This may be due to what you are saying, or the way you are saying it, likely some of both.

Writing productive and maintainable code won't cause you to be fired. You WILL be fired if you can't get along with the team. This is your problem, not (as you imagine it) your code is too good. Your code might be really good - but MUCH more likely this is a personality clash issue.

My advice to you, is don't be the tail that tries to wag the dog. Keep your head down, stop telling people how to code, follow direction, work well with others, write maintainable code. And then you won't get fired.

I also note with interest this telling comment from your manager:

"But is it really good as he pretends?"

What this is telling you is that your manager does not trust you, your manager thinks you are inauthentic and thinks you are arrogant and/or have a higher regard for your own ability than you actually have. Relationships depend on trust to survive. Take note here your problem is not a technical problem. Your problem has very little to do with the quality of your code. What you have is a problem with the way you are relating to your colleagues and your manager.


People don't often get fired for being indispensable (why people get fired); That is a ridiculous assertion. The article that you reference clearly qualifies that "fire" doesn't necessarily mean let them go, rather make them not indispensable (by moving them, forcing them not to be involved in a particular project, etc..)

While overqualified will sometimes not get you hired -- it also rarely gets you fired. Good employees are very hard to find; No reasonable company is going to get rid of one because they are too good (unless you just work for a moron - then they are doing you a favor).

People DO get fired because they THINK they are indispensable and better than their peers and therefore refuse to make the changes that need to be made to the man in the mirror to function well in a team. (fired for bad attitude)

If you are building a bridge with a bunch of natives and pull out a laptop while the rest are tying rope - you may be smarter or more educated but you have become a detriment to the team and the problem is YOU.

If you are really as great as you make yourself out to be, you would be smart enough to adjust your own actions to make the most productive TEAM possible vs. dogmatically pushing your own agenda (which you are probably doing). Were you doing that, you would likely have a job for a very long time.

As someone that is regularly involved in the hiring process, I'll take someone that is good and personable over someone that is great and a potential cancer any day.


Every program is a communication with two audiences: a compiler or interpreter that will make it execute, and some humans who have read and understand it. You may be communicating extremely well with the compiler, and still be writing bad code because it cannot be readily understood by the other humans involved.

Typically, a programming team has a set of languages, frameworks, techniques etc. that are known to everyone in the team. New hires who are missing some of those pieces absorb them quickly because anyone in the team can explain them.

Using something outside that set carries a cost to the employer. For example, suppose you are the only programmer in the group who is familiar with framework X, and everyone else is familiar with an older framework Y that is used for some existing code and is almost as good as X.

Using framework X would be a mistake, unless it is so much better than Y that management agrees the technical gains from using it are enough to justify the training effort to get everyone familiar with X.

One technique you could use is to have your code reviewed by some of the least experienced people who need to be able to read it. See what they have to ask about, and consider how you could rewrite those pieces to be clearer to them. The more you treat failure to understand your code as a defect in the code, not in the readers, the better the feedback you will get.

  • 3
    I don't think you take it far enough--I suggest people think of a program as a conversation between a group of coders that happens to be machine executable. The ability of the machine to execute it comes secondary to the ability to maintain the code--or you could even say that buggy maintainable code can be fixed whereas "perfect" code that cannot be understood/maintained by the team must eventually be replaced. Note that different situations have different requirements--twitter's original architecture was dead-end but it got them the market share and time to completely re-write, success!
    – Bill K
    Commented Nov 18, 2016 at 19:48
  • To me, this is a unique angle that I appreciate. I have received feedback to the effect "isn't reflection slow" or "it's more optimal to use native structures". To which my ideal answer would be "let's write it in assembly" because if their criticism is truly about efficiency and performance, then we should just stop measuring "shoe sizes" and write it closest to the metal.
    – 杜興怡
    Commented Nov 20, 2016 at 5:04
  • 2
    These days, for most development work, with the exception of big data, optimizing for performance is over-rated. Maintainability and readability are far more important. Commented Nov 29, 2016 at 19:46

Decided to upgrade my comment to an answer:

Document your code very well.

Proper code documentation turns bad experiences where a junior dev bashes their head against an incomprehensible wall for hours into potential learning experiences.

  • 5
    Remember, good code is supposed to be self documenting :)
    – Peter
    Commented Nov 18, 2016 at 16:06
  • 7
    @Mik378 That presumes that your coworkers are actually going to go off, read the unit tests and understand them - from what I gather that's not the case. Good code is self documenting, but that presumes a certain familiarity with the conventions used. You should always be asking yourself "will my coworkers understand this code?". If not, comment it until they do. And to cut you off, "well, they would if they ..." doesn't cut it. You're documenting it for your current coworkers - as they currently exist - not for some hypothetical coworkers with ideal behavior and knowledge.
    – R.M.
    Commented Nov 18, 2016 at 18:20
  • 3
    Self-documenting has its limits. It is very important to document the rules for interfaces between modules. I once had to work through about 7 layers of call hierarchy to find out whether a null argument was permitted or not. Commented Nov 18, 2016 at 19:52
  • 8
    @Mik378: As someone with plenty of experience, working in an environment were previous engineer insisted that the BDD tests were the documentation, so that's all we had, I can tell you that this is simply not the case. It is just wishful thinking that the tests are as useful as documentation. The problem is one of organisation and of focus - tests don't narrate the interface in an accessible way to learn from, and they don't explain why things work in a particular way. Commented Nov 19, 2016 at 9:31
  • 2
    @RichardU But I'm sure you've seen practical examples where the documentation was less helpful than not having documentation. ;)
    – Peter
    Commented Nov 21, 2016 at 15:44

Most of the answers treated your post from the point of view as to whether or not your code was readable or not or as good as you say it is. But this situation can and does happen in all walks of life. I took a job on the Las Vegas Strip as a 21 dealer and floorman. My techniques and speed were so far ahead of the rest of their personnel that the people assigned to watch me could not keep up. In other words they could not follow my decisions. Since large amounts of money were being transacted within minutes they often felt confused and would report me to their superior claiming I made a mistake. I would always vindicate my actions to that person but the attitude of mistrust towards me deepened.

My ego and I suspect yours did not see the warning signs and indeed I reveled in my superiority, pouring it on so to speak. I was terminated and lost an extremely good paying position.

The lesson is simple, you must dummy down to the level of the others. If they get only 15 hands out per hour and you get 100 out you are not inspiring praise. You are inspiring jealousy and even hatred. If your pride can not do this, you must find some other way of earning a living because all places are essentially the same. People are people, you can not change them. I eventually settled into other lines of work where I was mediocre too and thusly did not stand out. Hope you can sort this out to your advantage.

  • 3
    Excellent advice. I learned this the hard way myself. One small caveat. You don't always need to dumb things down, but you do need to be a good fit. Commented Nov 22, 2016 at 13:37
  • 1
    A good fit-I like that. I needed to follow the rules. I felt that the rules were put in place so that they could hire mediocre people to watch other mediocre people. Sought of like the qwerty keyboard was originally implemented to keep people from typing too fast for the machine.
    – bobbym
    Commented Nov 22, 2016 at 15:11
  • Your experience is very interesting. You don't mention how you performed in terms of the house's cut. Did you make more or less than the average? A casino is a business and any decision would have been very much influenced by the revenue metrics.
    – CyberFonic
    Commented Nov 23, 2016 at 8:25
  • 2
    @bobbym but the rules were set up for medicore to watch medicore. Its expebsive to hire best and better than best to superwise.
    – joojaa
    Commented Nov 23, 2016 at 16:00
  • @ joojaa, true enough. But when a better than average fellow mistakenly falls into such a place they should nurture him, not fire him.@ CyberFonic, there was no house cut. I worked for minimum wage as an agent of the casino. The dealers in 21 must deal the game using a fixed set of rules.
    – bobbym
    Commented Nov 23, 2016 at 18:30

My read on this is that you were destined for this treatment from day one on the job. You said you were hired because you have skills no one else in the organization does (TypeScript, Node). And now that you have toiled to produce an elegant, expertly crafted, complex solution all alone, no one understands what you have done, and therefore you are seen as a liability by management.

If all this is true, there is really no other way this could have turned out.

In my view, the problem is structural, not personal, and therefore the blame lies in the situation and the process, not the person:

  • The organization hired a single person with a completely different skillset than everyone else, and at an advanced level of those skills, to perform a critical function. This guarantees that, if you perform well, you will be the only one who understands code that is critical to the organization's mission. (It is completely unreasonable to expect a senior-level resource to produce code that instantly makes sense to people who do not know the language used.)
  • The organization did not subject you to the code review process regularly. If they had, your code would have been rejected until you brought it into compliance with their readability standards. Since you are the only contributor to the code, with your own style, and using a different tech stack, it is virtually guaranteed that over time the code will become less and less comprehensible to others. The only way for you to prevent this would be to ask others for code review out of process, constantly, possibly drawing accusations of wasting others' time. A lack of code review process thus set you up for failure.

I have similar experiences in my background. I was hired once to fill a skill gap. No one else in the company had a skill that they suddenly needed. I did my job well and after a few months conflict started. I was the only one who could work with certain components of the application. I became a bottleneck as work piled up that only I could do. One day I was sidelined as the company decided to replace everything I had produced with completely new code, done their way. My pride was hurt at the time, but in retrospect, it was the correct decision for the company. After a while longer there it was time for me to move on, and I did.

If this sounds familiar, maybe it's time for you to move on. Maybe management will even re-assign you to something else if they continue to value your skills. Or if you can stomach it, maybe you can help re-write everything you've done in the corporate standard technology stack. If that's not possible, just leave. Either way, your code is probably on its way to the garbage can. That's probably the correct thing for them to do, if no one else understands it. And anyway it's the natural consequence of their choices.

Make sure that in your next job, others in your team are applying basically the same skills as you, and especially that they have a code review process. When they ask you to change your code in certain ways, do it. Don't consider code delivered until it has passed code review and your peers will tell management (if asked), yes the code is good. Then there is no problem. It's perfectly OK to ask questions about stuff like this in a technical interview; I have done so many times. Hopefully this other developer who studied your code will give you a good reference.

As a footnote, if you are at least partially responsible for your circumstances of working all alone, without buy-in from other team members, then you deserve at least some of the responsibility for the outcome too. (Did you push for using TypeScript / Node when others wanted to use something else? Did you use the newest, coolest library or technique even though something more basic would have done just fine? I've been guilty of this once or twice also.) If so, make sure to take a lesson from this outcome. But if not, take this experience to your next position with your head high.

  • What an answer! It's completely in phase with reality, Great!
    – Mik378
    Commented Nov 21, 2016 at 6:09

It is possible you simply are not as good as you think you are, but for the sake of civility, I will assume that you know how to write the correct amount of complex code to reduce the complexity and time requirements of the entire codebase by an order of magnitude. The fact that this is even possible takes many idiots by suprise. They find it an incredulous proposition, and the only way to convince them is to show them.

But that takes finesse, courage, and self control. You need to focus on three things before all others: proving you are not a threat, making the idiots look smart, and never letting a single idiot realize you know he is an idiot. If you cannot bring yourself to do these three things, you will fail, and it will be your fault. Pragmatism is a must, and there is no room for pride.

Though I cannot recommend this approach for everyone, what has always worked for me is to sometimes ignore what hostile idiots tell me to do. Instead, I find ways to what I want to do, produce the best software many of them has ever seen the code for in a very short time, and I present it in such a way that their bosses reward them with glowing praise. Even though they played no part in creating it. Even when they actively opposed it.

Is it right? Shouldn't I get full credit for my work? Should I really have to dance around everyone's feelings? Irrelevant. This is reality. If I do not adapt to it, then I am the idiot.

  • 5
    Code that five people can understand and maintain is better than code only one can maintain. (Assuming it meets requirements.)
    – WGroleau
    Commented Nov 19, 2016 at 3:53
  • Daniel, it looks like you have two accounts. You can use the "contact us" link at the bottom of the page to ask that they be merged, so all the activity will be on one account. Commented Nov 27, 2016 at 5:28

There are a lot of smart people who think that highly skilled developers are irreplacable and that's why you do want them. But you've seen the other answers to your question - most managers don't want to deal with the problems of a team with highly varying skill levels, and don't have the option of going purely high skill. They aren't necessarily wrong either, the problems are real, and the benefits of high quality code that's beyond the abilities of most of the people they are able to hire are greatly lessened.

If you are even roughly as good as you say you are then you are mismatched with your job. It sounds like you should try hard to work at a place where you can learn from your co-workers and your co-workers can understand your code.

If you have lost a few jobs due to this then you are going to look fairly bad to HR, recruiters, and managers. Hopefully you can network into a job by meeting developers of similar skill level who can vouch that the problem really is that your skill level is too high.

Finally, I have to add that you should do your best to honestly evaluate if your skill level really is that high. It sounds like there is evidence that it is, but most people believe they are better than they are. Also many developers go through a stage where they get very good at one approach, but don't yet always put everything together into a globally optimal solution, and still lack flexibility. For example, sometimes it might be best to go with an inferior solution that you know the people you have can maintain, if you know they can't mantain a more sophisticated one, and aren't likely to hire anyone else who can.

  • 2
    The problems faced by a team with highly varying skill levels are almost entirely inter-personal and emotional rather than technical. Commented Nov 19, 2016 at 7:22

To address the question specifically,

How can I avoid this in the future?

  • Find a local chapter of Toastmasters, actively participate, and earn the achievements. Something that seems so obvious as feedback, will hopefully become appreciated and sharpened into one of your most valued skills.

  • Practice being the student instead of the expert. Have you seen this Jon Skeet talk on the basics? Can you imagine how much more understanding can be achieved if all of us made documentation like this, it would benefit everyone, at all levels of a team!

  • A team is not one individual. Your team will grow and improve collectively. You have to help. It's not a team if each member is a cell going in different directions (e.g., you higher, and the newest member stagnating). 2 hr meetings is a good start. I would add on top of that, the N-day pairing rotation. This is 1:1 time you gift to your team mates AND they gift to you. In your case, lean toward the navigator role, and let your partner drive. Practice not-writing the code, as weird as that sounds.

  • Volunteer at a local Meetup and Hack-a-thons. It can force you to distill down your code because the purpose is to collaborate, and not build a fault-tolerant energy utility grid, right?

  • In each of these exercises, try this concept: leadership by serving. How can you do a task or accomplish something to help another team member's needs?

  • As pointed out, contribute to open source projects to get more angles about your code. They may confirm that you are brilliant, but also they may reinforce the suggestions that you are hearing from your current boss. At best, some review will give you a new idea.

  • Find a engineer that is better than you. It's not improving yourself to be the smartest guy in the room. There is a quote (my googling is split between Olgivy/Ford/Sorkin) paraphrasing goes like "You can't learn more if you surround yourself with bad talent".

  • I updated my OP.
    – Mik378
    Commented Nov 19, 2016 at 18:04
  • 1
    Do you think the same can be achieved by sending patches to some bigger FLOSS project?
    – Nemo
    Commented Nov 20, 2016 at 14:01
  • Toastmasters are more fitting in the crowd than anything else. For people who do not aspire to that, it could not be the best idea. I also did not find out the feedback was always honest, e.g. they deal it with too much diplomacy and kid gloves for my taste. Commented Nov 20, 2016 at 14:35
  • @Nemo I wish I remembered, yes! Contributing to projects in the open that will get more eyes to review, super idea to help me improve my code.
    – 杜興怡
    Commented Nov 20, 2016 at 21:11
  • @RuiFRibeiro This is true. It's also important to learn to filter feedback. It's not a small point. There's a book "Thanks for the Feedback" Stone & Heen that I've been working on to work on this. My recommendation is getting practice whether it's in a safe env like TM or another way, please get in your practice.
    – 杜興怡
    Commented Nov 20, 2016 at 21:20

TL;DR : Find a more appropriate workplace, and be honest about the skills you still have to learn.

You sound to me like the "software craftsmanship" style of developer - interested in best practice, and always finding and following good ways to do things in code. Perhaps you'd be happier in an environment where other developers are more interested in that kind of thing - and there are plenty of such workplaces.

However, some of the things you've said give the impression that you sometimes think there is a single 'best way' to do things in code that should always be followed. Maybe I'm incorrect there - but if I am correct, then possibly you have some learning to do when it comes to exploring the pros and cons of alternative choices, and finding the way that represents the best balance for the business. In fact, I will say you definitely need to improve there - because we all do!


I'm going to assuming that your description of the situation is as you say it is. I can't say I've had this exact experience but there's are aspects of this that are familiar to me.

You say this is a 'big' company. I don't know how it is in France but often larger companies do not value internal developer skills especially if they are not technology focused companies. I attribute this mostly to the fact that managers in such companies are often not from technical backgrounds or moved away from development because they were never that good at it.

There's also a historical aspect of vendors selling tools that are supposed to remove the need for talented developers. Even if your team is not using one of these horrible things, there's a chance that the management of the company has been indoctrinated in an anti-intellectual notion of development teams. I have actually had a manager tell me to my face that I was smart enough to do build a given solution but then no one else would be able to maintain it so we needed to buy something (shelfware.) So I believe that this can happen.

You might need to look for a different kind of company. One that values highly skilled developers. You might have to contend with not being the best developer there, though. If you were an aspiring chef, you would likely be unhappy working at McDonald's. They don't need chefs. They need people to follow a recipe. You may be chef material and this company (and others like it) is McDonald's. The question you need to ask yourself is why you haven't already done this.

  • Nice chef/McD analogy - yes, or "too many cooks spoil the broth" Commented Nov 19, 2016 at 7:13
  • your hypothesis about France's "grands comptes"(big fishes, especially banks) is absolutely true. I've done "clever" code over there only when I had no choice. In most cases, doing like others did, just cleaner, was enough to do the job - and to be readable. And I didn't expect my very few clever programs to be maintenable by anyone else.
    – gazzz0x2z
    Commented Sep 6, 2017 at 13:50

Some times, when talking with others, you have to "dumb" it down so that you do not offend people. Especially if you are well above the others you work with, they are likely offended when you talk about tips and facts that they probably should know, but did not.

I would say to comment your work really well, so that people checking it can understand it. You might even need to "justify" why you choose that coding method over a different one inside of your comments. You might be the best coder, but if you are inside of a team, you have to work as a team.

If working as a team means to work with one hand behind your back, (by this I mean following their coding preference), then do it. At least then they can read it, understand it, and the team itself is better off (even if that means you are screaming inside).

Almost anywhere you go where you are part of a team will have guidelines over how they want things to be coded- and you need to follow these guidelines.


How can I avoid this in the future?

Don't work with anyone unless you are reasonably ensured that their coding standard match yours. Which means refuse any job if none of the following apply:

  • They ask you programming questions during their interview process
  • They have peer programming exercises
  • They ask for a code sample and are ok with it
  • You can see some of the code they have produced

How can I avoid this in the present?

This has been covered by other answers.

If you are just that better, get to their level and slowly teach them to be better programmers. The first time I had to manage an intern I almost wiped out the entire code he produced. I was literally furious when I saw what has been committed (fortunately I had no witness :P ).

You need to encourage peer programming, code reviews. Sit with another programmer and try to code together for 2 or 3 hours. Drop concepts which may be too hard to explain (new advanced Java 8 features for instance), and explain those which are easier (inheritance).

  • Yes, the thing is that I suggested all of these. Answer was: "we don't have time to learn".
    – Mik378
    Commented Nov 21, 2016 at 17:08
  • 2
    then their culture and yours doesn't match. In other places saying "I don't have time to learn" is a good way to be terminated.
    – UmNyobe
    Commented Nov 21, 2016 at 17:11
  • Agree :) I'll leave next Friday.
    – Mik378
    Commented Nov 21, 2016 at 17:15

You sound as if you're a good enough programmer to be able to adapt to many situations. Look at how others code and act accordingly. On occasion, ask if you can try different ways and make sure it is not too far beyond what everyone else can comprehend.

I normally wouldn't give this advice, but this problem seems to follow you wherever you go, so stop fighting it until you can find a job where this isn't a problem. You may consider getting involved in a project where there are a small number of other developers that you could help bring along so it doesn't look like it's just you who programs so "abnormally."

It's a shame others don't value your work or want to learn from it if that's the case. Stop beating your head against the wall. Who knows, some project/task will come up where you're the only hope of making it work. No one will care about how complicated your code is in the long run if you just make it work when no one else can.

  • We were 3 developers on the team.
    – Mik378
    Commented Nov 18, 2016 at 18:22
  • Everyday I explain them some programming tips, and they largely enjoyed it. The issue is that while being happy to hear me talking about, in their mind was installed a kind of inferiority complex. That was the begin of my manager reaction.
    – Mik378
    Commented Nov 18, 2016 at 18:24
  • 1
    @Mik378 Everyday is far, far too often. Pick a simple change that would bring a big payoff. Demonstrate the difference between the code written the team's usual way and your proposal. Let that sink in for a while, before trying something else. Commented Nov 19, 2016 at 4:06
  • 6
    "and they largely enjoyed it" - are you sure about that? maybe they are just polite. How does someone being made to feel inferior, "largely enjoy it". Your statement is not consistent. Commented Nov 19, 2016 at 7:10
  • 1
    @Mik378 if you pick up nothing else from this question, you should believe Brad Thomas's comment - it is probably the key to your situation. Commented Nov 25, 2016 at 11:48

We can't depend upon him in a long-term

That's the major problem. They don't want to be dependant on you, but you were hired because they are actually dependent on you.

You can either quiet the management down with:

  • You are not thinking to go elsewhere anyway, so they can count on you on the long term.

I think I'm challenged with problems that keeps my skill used so I think I finally find a workplace I can enjoy for long time

  • You are willing to provide training to other team members to provide further value to the team.

I noticed that other's code is not really up to date with cutting edge software development tecniques, it's not a problem, I can stop using that tecniques altogether, however it would be beneficial if everyone starts using that tecniques gradually to improve the team's performance. I can help with that.

  • You were requested to implement features XY, havin that features shipped within time required your skill, stuff could have been done in different ways but in much more time and with the risk of additional bugs.

May I have some extra time to finish next features? I really worked hard to get things done properly, I achieved to do that but I fear not everyone can understand that, Instead I want to take some time to make things understandable to others.

Be honest, if some statement does not apply (I do not now on what you worked), do not lie, ever.

If they are going to fire you, then they are not really dependent on you for real. Anyway, at least 2 people in the team understand your work: You and your coworker. And chances are that more people will be able to understand it in future. Basically you are not a bottleneck in your team, they fear you can become it later however. They should invest some time in training anyway.


Read The Wagon, the Blackbird, and the Saab. It should resonate with you.

I've had kind of similar issues in the past; I've learned some things about how to cop, but we have both been using mop and bucket to try to clean up the output of a fire hose.

I am not here suggesting that you merit a DSM-V mental health diagnosis, but I am suggesting that you might be well advised to find a good counselor and work on non-threatening behavior and social skills. You might also read Theory of alien minds.

You must log in to answer this question.

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