
Fired because your skills are too far above your coworkers - nsoonhui
http://workplace.stackexchange.com/q/79992/979
======
johnloeber
Here is yet another person who doesn't understand that he is first and
foremost _hired to solve business problems, not to write software_. It so
happens that he writes software to solve these problems.

If it turns out that he actually _creates_ further business problems (and by
the content of the post, it certainly looks like it), then no matter how
"elegant" or "brilliant" his code is, it's rational to let him go!

~~~
spinningarrow
What further business problems is he creating?

~~~
dogma1138
If no one in the team can understand or maintain his code it doesn't matter if
it's because it's way above or below the coding standards of the company.

A company can't afford to pretty much be dependable on a single person, what
happens if they get sick or decide to leave?

Being a star employee is good, but it always comes with the risk, people think
that being indispensable is good, it might be good in a small startup but not
in a large company.

At the end regardless how good they are they are only a small part of the
delivery bandwidth of the company, and regardless of how good they are they
can't do the job of 10 people even if they are smarter than 10 people
combined.

As a developer their job is to produce reliable and maintainable code, this
means that the code can be picked up by anyone in the company and worked with,
if they don't they effectively create a bottleneck and a dependency on a human
resource which is a huge risk for any business.

It's ok to be good, it's ok to even be better than some, or even the rest as
long as you are a notch above the rest primarily due to soft skills, if the
product you produce is effectively alien to the rest of your team and the
company then what you produce is a liability not a solution.

~~~
cmdkeen
From the way I read it he is a contractor hired for a specific project - in
which case there is an expectation that he will leave at some point.

There's also a couple of serious red flags in describing a contract as "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."

Which means there's no use of code reviews, even as an opportunity to educate
someone else. There appears to be no process for knowledge transfer at all, so
how is the company going to gain these skills? Separate principles again
suggests not writing code in the same way as everyone else.

Plus if you're concerned after 2 previous incidents of this happening to you
and you find yourself months into a project being left on your own then some
pre-emption might be useful. Write lots of comments in your code, talk
colleagues through it, suggest training videos on the languages technology -
make yourself useful and available.

~~~
dogma1138
I'm not saying that this was handled well from either side, but as a
contractor you are hired to deliver a product to a company; if that product is
effectively useless once you are done with your product you have not delivered
what you were contracted to do.

A contractor that would produce some fully functional, and even elegant in
it's own way but convoluted piece of code is doing a poor job regardless if
it's because the code is so smart that almost no one can understand it or
because it's utterly inconsistent internally and is an unreadable mess.

You aren't selling a binary product here, a company isn't buying off the shelf
software, they are contracting you to further develop their IP if what you
produce is not useable to them you effectively wasted their time and money.

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

I doubt it has anything to do with his coding skills. You can be good at
programming but still be an arrogant asshole (not saying that an author
actually is, just one of possibilities). Working with a group of other people,
soft skills are no less important than technical ones. _Nobody_ let go good
programmers just because they are too good, that just doesn't make sense.

~~~
dozzie
It may also be that he actually produces shitty code, but with advanced
esoteric techniques, so it looks like smart code to somebody not trained
enough in those techniques. I've seen this happen (I produced such things
myself).

------
informatimago
He's not alone.

My advice would be:

\- find a better workplace (with more sophisticated and demanding co-workers,
or possibly, start up your own company, and even compete with your ex-
employer!), or

\- be more pedagogical (which is often harder and slower to give results than
it may sound).

Indeed, the problem this situation denotes is that we're surrounded by
incompetent and unknowledgeable people. It's not necessarily their fault:
economic and time constraints prevented them to get a good education, or to
learn on the job.

Sometime people don't want to learn and actively refuses to do a better job,
but this is not the most common case, at least in IT, programming.

But then teaching and raising the competency level of a team is a whole
different job, and you still need to be allocated the resources to do it:
while you're teaching and the coworkers are learning, you're not implementing
the next user story; what's more, eventually all this teaching would have to
be disruptive. Once you teach iteration to a coworker who used copy-and-paste,
you now accumulated technical debt since the team will have to rewrite all
those occurences of copy-and-pasted code with iterations! Users stories will
have to wait. Never mind that using iterations you will increase productivity
and be able to implement _later_, ten user stories in the times you
implemented only one, the product manager sees that this will occur _later_...

~~~
cmdkeen
"If you're the smartest person in the room, find another room". Especially if
you're at all early on in your career when you should be learning all sorts of
things from the battle scarred veterans.

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

I suspect there's more to this than just producing code that is "too good".

~~~
agd
Exactly. Either he's:

a) not as good as he thinks he is, or

b) he should be working on his soft skills

If your team is far behind, make sure you're giving them training and helpful
code reviews. Do a presentation on your latest bit of code to make sure they
are on board and understand it. Be proactive to see and deal with these
situations.

~~~
wolfgke
> If your team is far behind, make sure you're giving them training and
> helpful code reviews.

Without a strong willingness of the other team members to learn intensively
(also in their free time) - a property that few people have - this is futile.

------
jyriand
As I understand it's already third time he is been fired. This makes me
believe that there something else at play. Either he is self-delusional and
can't see the actual reason(cowboy programming,arrogance etc) or companies in
France don't like talented people.

~~~
pjc50
Sounds like the "architecture astronaut" anti-pattern. Either he's choosing
the wrong places to work (aim higher!), or he's insufferable to his colleagues
and doesn't actually ship the right thing his bosses want.

You can usually get away with _either_ being insufferable but delivering, _or_
faffing around with an air of pleasant cooperative helpfulness. But not both.
I strongly suspect he was delivering what he thought people "really" wanted,
not what they asked for or needed, and that made it easy to get rid of him
when he annoyed people.

(Also, team composition really does follow TVtropes narrative rules. You need
a balance of character archetypes and you can't have two divas.)

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

Seems a standard problem when people talk about methodologies, they need to
work in the real world not with what's expected of programmers.

Probably 4th time to me means OP needs to adapt to how things actually work.

Lots of working code earning $$$ doesn't use inheritance or composition. It
gets the job done, is made redundant and new code is written for the next
task.

~~~
shoo
Or sometimes you end up in situations where common "antipatterns" are at least
locally optimal.

E.g. if you are working on projects with people making low quality changes &
bad automated test coverage it can be better to have a bunch of duplicate/near
duplicate code if it lets you decouple things.

------
beeswax
About a decade ago I was working for a smaller company that provided local IT
services for a large SaaS provider which also enforced territorial protection
by only allowing a number of certified service companies in the area.

95% of all field personell was only able to arrive at the client, sit down and
grab a coffee to be talked through some items the first-level support was
aware of, while I could actually fix most of the problems due to my deeper
understanding of the underlying concepts of the stack (Windows Networking,
DNS, SMB, LDAP, SQL, …) right away.

This was the problem: No other engineer was able to see through those things
and of course the clients began to notice that I was able to help them way
faster; with hourly billing and reduced downtimes this also meant way cheaper.

I was kindly asked to „take my time“ and to „relax, get a coffee first - go
flirt with the female office staff“ so my colleagues would not look bad
compared to me.

Shortly after I handed in my notice and went for a freelance gig which was the
right decision for both the local market and me personally as well (I did not
continue with the field service thing but got into custom software
development).

------
minipci1321
From my own personal observations over a long period of time, in France
relatively more importance is attached to the teamwork than in other
countries/cultures I knew, precisely because the teams are frequently very
heterogeneous in levels of skills. Privileging assistance to other team
members over own's workplan-to-execute has never got anyone into trouble (let
alone into personal layoff) and is in fact frequently implicitly or explicitly
encouraged.

Sometimes small companies that are starting a new product, can hire an
extremely skilled and expensive specialist only to create the first version of
it, and then are not keen to keep him/her, as that becomes complicated and
expensive for no good reason (maintenance can or even has to cost less). That
said, I don't think anyone would lay off a goose laying golden eggs.

I feel the guy's pain, been through some situations myself .. the pain usually
brings with it adjustment to reality, only that comes later. What else can I
say.

------
bitL
I am pretty sick of the comments I read here. It's like everyone that sticks
out must be destroyed. What if the guy is really enormously talented and his
colleagues are lazy guys that stopped learning the moment they finished their
education? I hope he realizes he is on his own, starts his own company and
sells his services for 200x price he would get as a salaried person. That's
what his managers really deserve.

~~~
notacoward
As others have pointed out, if this is the third time then it's pretty highly
likely that there's more involved here than programming skill. Remember, we're
only getting one side of the story. But let's assume for the sake of argument
that it really is about a coding-skills gap.

Most code will be read far more than it's written. Somebody else will have to
read and maintain this guy's code after he's gone, especially since he's a
contractor. I think we can all agree that there are many ways code can be good
or bad, and that it can be good in one way but bad overall. If this guy's code
is hard to read and maintain, then in the most important sense it's not good
code. Nobody will care that it's "intelligently decoupled" as he (and he
alone) claims. Are there comments to make the relationships or interactions
between these decoupled components more clear? Or external documentation?
Decoupling is great in the abstract, but if it obscures intent or effects then
it's bad code. Ditto for any other kind of "greatness" we might attribute to
code. If it can't be maintained or enhanced efficiently, its greatness is
transitory at best.

This isn't about "sticking out" so much as putting one's own interests ahead
of the employer's. If the employer quite legitimately values code that is
consumable more than code that is impressive, and you insist on making the
opposite tradeoff, you're not providing what was paid for and you're also
showing disrespect to everyone else involved. For that you should be fired.

~~~
bitL
Third time might mean that he is just unlucky to find the same ol' company
type or that the prevailing culture of French workplace is that of doing
nothing and smiling to everyone around, and getting promotions by kissing up.
He might be headhunted by Google/FB/Netflix etc. later.

I know a guy who was absolutely being destroyed by his boss and director (by
being simply too good and threatening them, while they were pompously
presenting his achievements as their own outside), it drove him to mental
hospital, he rebounded and now is a top management member of some famous
German company directly affecting business with those two guys (i.e. they
aren't getting any business from his company anymore). If you decide to
unleash mob on somebody because "he simply can't be that good", think about
the consequences. In 5 years you might be shown the door as you become the
blocker for your own employer's business.

It's delusional to think that everybody can read somebody else's code. Imagine
Linus was employed by such employers; he would be fired within a month as
nobody would be able to understand what he wrote. But right, it must be that
guy who is wrong.

Show me also which new hire is able to maintain production-grade
Perl/Scala/C++/JEE code easily? It's a pipe dream of management.

There are so many nonsenses in this discussion it's unbelievable how low our
business now sank. It's like employer expects a person to be their company's
slave. Exactly the mindset most of us hate with a passion as we got into
computing with the goal of changing the world, not propelling everything that
was horrible to new heights.

~~~
notacoward
> Imagine Linus was employed by such employers;

Your hero-worship is cute, but Linux succeeded precisely because a whole lot
of people _could_ read and understand and extend Linus's code. Furthermore, it
was based on Minix, which was explicitly written with understandability in
mind. _That_ is great programming.

> Show me also which new hire is able to maintain production-grade
> Perl/Scala/C++/JEE code easily?

While it's true that not _every_ programmer can read and maintain _every_
other programmer's code, that's a bit of a strawman. The question is whether
some _easily hired_ programmer can maintain the code. If it requires someone
with buckets more ability and experience than average, then it's too esoteric.
I'll bet I can write more advanced code than you in a more difficult problem
area, but I know a lot of my code needs to be maintainable by mid-level
programmers (or below) so I write it in an appropriate style and try to
explain it well. The OP was obviously incapable of doing that. If 11 is his
only setting then - again - he's a poor programmer.

It's possible to be passionate about programming without making it one big ego
contest. If you want to write "clever" code, stick to TopCoder or HackerRank.
If you want to write code that actually stands the test of time and benefits
real people in real production, that's a whole different thing.

------
magoon
The real problem could be lost in translation of "skills were too far above."

I've found that a lot of coders over-engineer simple components in a way that
gets in the way. An example would be writing an entire module for wrapping
regular expression methods that already have a clean implementation.

~~~
douche
Needless complexity is one of my least favorite bugaboos. My mantra tends to
be "Do the simplest possible thing that will work first, and iterate from
there". For some reason it is hard to get that across, and some people seem to
delight in producing baroque heaps of code for simple tasks, which then often
doesn't work correctly.

------
krisgenre
Many comments seem to suggest going with the tide, I'd like to disagree.

Its likely that a smart coder became a smart coder because he hated bad code
with a passion.

Imagine a code like this

    
    
      if
        ...
        else if
             ...
             else if
             ...
                 else if
                     ...
                     else if
                     ...
             else 
                ...
       // goes on for another 100 lines
    

in a JSP with html spewed in-between with improper formatting.

Should developer who uses a template engine and design patterns instead of
following the above be kicked out?

~~~
zimpenfish
> Should developer who uses a template engine and design patterns instead of
> following the above be kicked out?

If it doesn't solve the problem they were brought into fix, yes. If it causes
the project to miss an important deadline, yes. If it costs more to implement
than it saves in the long term, yes.

It's not a simple black and white question.

------
mhomde
This strikes me more of a social/maturity issue. I can relate myself from when
I was younger and thought I was the best programmer around. Even if that was
the case (it wasn't) it doesn't matter much if you can't communicate and get
along with your teammates. I thought "my work should speak for itself" and
"quality over everything else"

One of the biggest lessons of corporate life is that how you behave and
communicate will have a disproportional effect on your success. Doesn't matter
how good you are if no one knows it, likes you, or people find you
troublesome. You have to pick your fights, know when you to compromise, and
how to put forth suggestions without stepping on anyones toes. Sometimes the
decisions and output of other people can be truly baffling but you still need
to manage them with strategy and grace. Just being a good human being, friend
and colleague will get you far, as long as you can be forceful when needed an
appropriate.

If you really is more experienced then becoming a good mentor is a skill in
itself. You don't want to be an arrogant ass that is perceived as being "more
than everyone else"

Another thing is understanding the trade-offs between clever code/maintainable
code. Even good programmers have a tendency for over designing and/or over
complicating stuff until they become more mature.

------
kkapelon
There is more context here
[http://workplace.stackexchange.com/questions/79675/im-
techni...](http://workplace.stackexchange.com/questions/79675/im-technical-
referent-but-i-lost-the-lead-for-technical-decisions)

------
Uptrenda
I have a feeling this is the kind of guy who tells everyone to rewrite a
million lines of production code in Go because its "more scalable." Not trying
to be cynical but it does strike me as strange that a company would fire
someone for this reason. Something tells me this isn't the whole story and
that it might be time for the OP to work on collaboration / people skills.

If you can't handle that then I can only suggest consulting or starting your
own company, but all-in-all working at a startup is a team sport.

~~~
markharris99
> I have a feeling this is the kind of guy who tells everyone to rewrite a
> million lines of production code in Go because its "more scalable.

As louis ck would say, but maybe???
[https://www.youtube.com/watch?v=0O5h4enjrHw](https://www.youtube.com/watch?v=0O5h4enjrHw)

I have to somewhat disagree with this. Sure, I give the point that you can
just throw more hardware at the problem of scaling. However, there are some
problems that do not linear scale and rewriting gives much more of a boost.

For example. Just last year I was at a company where they had a backend
product system in just under a million lines of code. I'm not going to say
what language it was because I know someone will say oh it didnt scale because
it's X.

In addition, it was starting to get cumbersome by having multiple developers
write in it. So the agreement was to rewrite it in GO.

What was the net effect?

\- Less servers, much less.

\- Faster processing times, significantly more so.

\- Less code cruft.

\- Faster feature push.

\- 1 developer let go of, saved $90k

I think all in all, they saved $150k-200 a year by switching to GO.

I know it's trendy to say, don't rewrite something in production. But
seriously, if the developers agree and the business WILL BE better off with
it.

Why not?

~~~
erichocean
> _Why not?_

The usual reason is that people tend to want to fix/add a bunch of other
things _beyond_ just rewriting in language X.

Sure, if it's a straight port for speed (I'm currently doing something similar
from TypeScript/Node.js to C++), and you're not adding a bunch of new stuff in
the process, that's relatively safe.

But generally, rewrites are expensive and businesses don't like spending a lot
of money for something without any new "features" (beyond cost, ironically).
If you find yourself with that kind of group, IMO, incremental improvements
are a better choice for that business most of the time.

------
kkapelon
Even more context here:

[http://chat.stackexchange.com/rooms/48551/discussion-on-
ques...](http://chat.stackexchange.com/rooms/48551/discussion-on-question-by-
mik378-im-technical-referent-but-i-lost-the-lead-for)

"I already made a full documentation and more than 6 hours in meeting to
explain them the architecture. On the moment, they enjoy, but in their mind,
it's too theoretical for them, besides numerous examples"

------
dep_b
Perhaps the Node.JS world just isn't waiting for smarty pants patterns but
prefers callback pyramids of doom? It's sometimes even hard in C# or Java to
figure out what some smart guy did to the code, making it hard to navigate it
and find out what comes from where and how it's wired together.

Also a lot of smart ideas rely on reflection and cause runtime instead of
compiler exceptions.

------
oliwarner
This sounds ludicrous but the base problem really isn't that odd. If your
output is _so_ completely out of the league of the other people in the
company, the business has to treat that as a risk. What happens if you get run
over tomorrow? Great, now we have an unmaintained product. There is probably
liability attached to that too.

But there are better available solutions than just erasing the existence of
this super-developer. They could train the other staff. They could hire better
developers.

Seriously, there are _so_ many things that don't involve scrapping this
developer's existing work producy... It makes me suspicious that their
brilliance isn't the only problem. A lone-wolf with a big head can really
tough to work with.

But if that's a misapplied stereotype, he should be talking to his managers to
dissolve the risk amongst the other developers safely, and/or hire new ones
for this product.

------
satysin
I know it sucks but sometimes you need to write code that isn't quite as
elegant as it could be. I will take the OP on his word that he is a great
coder, but if he writes code his team can't work with then it will be a
problem. Writing software isn't just about writing the very best code possible
but the best code that solves the problem while being workable for everyone
else. There is often not much benefit in only having one person understand how
everything works. Unless what they are working on requires super advanced
solutions to the problem it will just end up slowing everyone else down. The
same is true of all things that require complex solutions.

I don't have an answer for OP other than maybe dumb the code down a bit.
Companies want a solution to their problem that does not make it depend on a
single person being able to understand it.

------
ceejay
Here's what I think probably happens in these situations. Especially when all
parties involved are genuinely looking out for the best interests of the
company.

If you're with a company who depends on lower expectations to survive, they
are probably not just doing this with programmers. The managers are probably
under-qualified as well.

I get the sneaking suspicion the breakdown is in communication. If a manager
can recognize and articulate a problem with precise language, face it head-on,
and define a precise set of rules / constraints that a team needs to follow in
order to resolve those problems, and retains a tight feedback loop to
determine if the plan is working (adjusting if / when necessary), problems
like this should not arise and remain an issue. Unless, of course, the
programmer is unreceptive to the plan.

------
vladimir-y
It's usually called overqualified right? In my opinion if you are about to
take a new job except money you need to consider a possibility to learn
something, which means there should be a more experienced people in your area.
Ie it's a bad idea to be hired to work in a team full of newbies.

------
xupybd
I don't think he understands what good code is. Good code fits the job it's
doing. Sometimes that fit requires simple boring code. Boring bug free code is
often the best fit for business problems. Fancy out of this world code tends
only to be the best fit in very small niches and academia.

------
boggydepot
No, it's because they'd gain more profit by firing you. Most (if not all)
business are only there for the profit; it was never about making the world a
better place. If you disagree, think again.

------
Jugurtha
The number of comments fitting the following pattern is interesting:

"I (guess/think/have a feeling) he is (negative adjective). I'm not saying he
is, but (reasons that justify presumption)"

~~~
dozzie
It's not interesting at all. It's a standard strategy of formulating such
comments that seasoned internet debaters develop. You could see exactly the
same pattern years ago in discussions on usenet.

------
smoyer
I view this problem a little differently. His biggest problem is that the team
doesn't care to learn. As a lone wolf, he may also not be a suitable teacher.
But I've found the absolute best situation comes from being on a team where
everyone wants to excel at their craft. When one member learns something, they
pull the rest of the group to that knowledge. It also levels out knowledge a
bit as you can always learn something your coworkers don't know.

------
mcv
If your code is really so much better than that of the other developers that
they will be unable to read or maintain it, you should train the other
developers on how to read and maintain it. That spreads the expertise around,
it will make them better coders, and it removes the single point of failure.

Of course the expert coder who has now gotten the new responsibility of
training others, deserves a raise.

~~~
wolfgke
> If your code is really so much better than that of the other developers that
> they will be unable to read or maintain it, you should train the other
> developers on how to read and maintain it.

As I wrote in
[https://news.ycombinator.com/item?id=13015309](https://news.ycombinator.com/item?id=13015309):

"Without a strong willingness of the other team members to learn intensively
(also in their free time) - a property that few people have - this is
futile.".

------
trymas
If it's N-th time happening maybe there are more problems than just 'too good
code'?

------
xplusy
I feel the same pain in my industry where experienced are replaced with noobs
for less pay.

------
chrismcb
If he is so good, why is his code so hard to understand?

------
varjag
Sounds delusional.

------
amelius
Didn't read the article, but the title makes sense. If you write code that
your coworkers don't understand, then that's potentially a nasty situation.

~~~
dozzie
If one writes code that is "too smart" ("intelligently decoupled", as the
original poster in the thread quoted a colleague), it's a sign that his skills
are actually low with a large spike on some small area.

