Fired because your skills are too far above your coworkers

Question

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.

Update

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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

Answer 17

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.

Answer 18

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!

Answer 19

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.

Answer 20

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

Answer 21

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.

Answer 22

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.

Answer 23

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.