Fired because your skills are too far above your coworkers | Hacker News Reader

Fired because your skills are too far above your coworkers

workplace.stackexchange.com

60 pointsnsoonhui73 comments

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!

What further business problems is he creating?

Software that's not maintainable by his coworkers.

Is quality Typescript/Node.js code, which is "intelligently decoupled", harder to maintain than poorer quality code?

If it's so far from the normal coding standard and practices within the company it doesn't matter if it's better or worse it's just as unmaintainable.

Intelligently decoupled, no. Needlessly abstract, yes. Many rockstars can't tell the difference.

Software is, among other things, a form of communication between humans. That's what Knuth's "literate programming" ideas aimed towards. It's also a driver of lots of these methodologies he's so fond of: we use them because they are easier to understand than the wordier alternatives.

Whatever else his code is (and remember, we only have his opinion that it's good, we can't judge for ourselves), he's failing really badly to communicate with his co-workers and bosses.

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.

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.

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.

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

So the problem is that the other people in the team are too lazy to learn to understand coding techniques that are a little less trivial?!

Would you as a company rather you fire 1 person or 99 people?

I see that this is a stupid rhetorical question, but I openly say that in many cases it might be a better decision to rather fire the programmers that are not willing to learn new things on the own, even if they are the majority. I openly prefer to work (and do business) with few highly intelligent individuals who always learn new skills on their own than with many people with opposite properties, since I believe this qualitative (in opposite to quantitative) enhancement also reflects in financial gain (thus business advantage).

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

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

>Nobody let go good programmers just because they are too good, that just doesn't make sense.

Yeah, they do. I've seen this happen. It's simply an occurrence of the principal-agent problem. In theory the company doesn't want to see good programmers go but poor programmers in positions of weak authority don't like to see their authority challenged by better programmers and they usually don't like change either. They are motivated to get programmers better than them let go.

Upper management (the "principal") typically don't have visibility into the development process. They usually can't tell who is good and who isn't. They can see the disastrous results of shitty code but they don't necessarily know who or what to blame (if anybody). They often end up following recommendations.

>soft skills are no less important than technical ones

This kind of misses the point.

In practice if "soft skills" end up mattering more than technical skills then that's a sign that the environment is highly politicized. Which is fine if that's what you want, but if you want to build great products and exercise your technical skills it's a very poor environment to be in.

On the bright side, if you really are that good and you're mobile (i.e. not stuck in some backwater city with a few poor quality employers) and you really were fired for being too good, and you really are much better than your coworkers then finding a better paying job should be easy.

Of course it make sense, happens all the time!

At some point he should realize the common denominator behind all these firings, instead of blaming everyone else.

Maybe it's even him doing bad client selection and he's truly flawless in programming, but still.

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

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

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

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.

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

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.

As one of the commenters on SO said, good code is a question of your environment. The fact that he can produce very advanced code doesn't mean that it's good code where he works. It's crucial to write code that others will be able to understand and maintain. If he's hired into a company where most employees have little knowledge of the domain, he needs to be extra careful to structure the code as simply as possible.

If you start somewhere and disagree with the programming languages or techniques they use, the answer is not to use what you think it's best. The answer is to either go with the company policy, or to try and change it. But not just producing what you think is great code, even though no one else can understand it.

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

It's entirely possible that he's only worked in companies that don't recognize talented people and treat them as just another cog in the machine.

I think outside of a few tech hotspots (and even to a large extent, within them), this is pretty normal, and you can judge this by seeing the pretty terrible average quality of code in most companies.

Never attribute to malice that which is adequately explained by stupidity:

> https://en.wikipedia.org/wiki/Hanlon's_razor

Being surrounded by stupid people is a very typical situation.

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

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.

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

I guess, but what project doesn't end up using a library that does indeed use inheritance or composition? You can say oh black box, I don't need to care, but inheriting from a library's base class is programming in the real world 101. It's just kinda silly really if you're a working programmer and don't understand the difference. It takes like 1-15m of googling and reading to be like "oh ok, ya I see now."

Furthermore, how can you plan effectively if you can't even see these things? From Joel on Software "Painless Functional Specification - Part 1: Why bother?":

> Why won't people write specs? People claim that it's because they're saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It's as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to "wing it." Programmers and software engineers who dive into code without writing a spec tend to think they're cool gunslingers, shooting from the hip. They're not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.

-- http://www.joelonsoftware.com/articles/fog0000000036.html

So if you don't really know how to plan because you don't understand the common set of patterns (but instead just treat everything like a nail cause all you got is a hammer), you're gonna just write code like crazy and eventually hit a wall and be like what happened? This could occur if the code becomes way too entangled or you do things in some unique idiosyncratic style and then just ditch the project and the next guy is like uh? I think business risk here is pretty obvious. Patterns create cohesive, uniform solutions that can be expanded on. Antipatterns slowly eat away at the project.

So if this guy's components are intelligently decoupled -- and he took the time to plan that -- but the other programmers can't understand the pattern, who's really at fault? That's the crux of the issue if you're a guy like Joel working with gunslingers. It's not long before they turn their guns on you as the problem 'cause they're threatened. Now, just being realistic here, I think if this happened to the guy 4x he either is amazing and should go work for Google or has some other kinda attitude problem. I just wanted to counter the point that real world code doesn't need to concern itself with inheritance or composition patterns.

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

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.

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.

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.

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.

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

Most of the cost of developing software is spent on maintenance. Even if you are a 10x rockstar or whatever if your code is twice as hard to maintain you are a huge liability to the company. If your boss wants maintainable code then it is literally your job to write maintainable code, if you can't do that then it definitely is best to leave the company and find somewhere where you fit better.

Not true any more! Most software is write-once. If you spend more than a little time on it, you're wasting your employers time and money. The whole 'agile' thing is all about writing code like the wind, to a minimum spec, and never revisiting it.

Yeah, and it works for apps. Do you think it works for operating systems and other infrastructure software? Nope nope nope. That code still lives on for a long time, and I would run very far away from any such software written with your "write once" mentality. If I wrote data-storage software that way I'd expect to get fired and I'd know I deserved it.

That's the thing, I was writing what you call infrastructure software, powering large telecoms of Europe, going super deep with transaction processing, ensuring ACID down to cluster failure level, high availability, and often there were some "tabu" areas nobody was allowed to touch because they simply worked somehow, nobody understood consequences of changing them in production and they were just too critical to do something about them. And they were written in an absolutely horrible way with no documentation nor comments, probably spewed out during a week-long night shift of some once-in-a-generation genius in Santa Clara. According to you, (s)he should have been fired because the code wasn't maintainable (nobody was able to understand it down to all details as it would require top-end education in distributed algorithms, formal verification beyond mere PhD), yet was powering half of the world and made the company insanely rich.

If you can find no one else who could do it then of course they shouldn't be fired. If you can find another programmer who can do it as well and have it also be maintainable then fire the original guy immediately. Lack of maintainability incurs a risk and a cost on businesses so unless they are adding enough value to make it worth it (as the person in your example is) then they probably should be fired

> they were written in an absolutely horrible way with no documentation nor comments

Clearly not talking about a good programmer here, are we? Maybe one with some specialized knowledge, but deficient in other areas.

> According to you, (s)he should have been fired because the code wasn't maintainable

Damn right. It's possible to write maintainable code in any domain. The burden of doing things besides code - documentation, tests, proofs, whatever - gets higher, but that's part of the job.

> it would require top-end education in distributed algorithms, formal verification beyond mere PhD

This is exactly the kind of stuff I do every day. Have been for many years. And I hand it off to others who are able to maintain it. So I don't think your story proves what you want it to. Working in a difficult problem domain is a challenge to do better, not an excuse for doing worse. "Your friend" wasn't demonstrating greatness. "S/he" was demonstrating great carelessness and lack of discipline - hardly qualities I'd expect in someone who claimed to be passionate about their profession, and certainly not qualities I'd reward with continued employment.

Sorry, this sounds like a nitpicking. It's akin to saying that Peter Sagan is a loser, because unlike Chris Froome he will never win Tour de France GC. Not to mention Mark Cavendish or Marcel Kittel, who are complete losers.

People have various talents and their mental capacity is used best accordingly; if you start forcing them to do work that "hurts them", their best parts disappear, you won't get any results and their lives will be miserable. All because you decided how it must be while ignoring nature.

Just out of curiosity, are you a German? I see similar thinking around here a lot.

> if you start forcing them to do work that "hurts them", their best parts disappear,

No offense, but this is starting to sound a bit Nietzschean. The ubermensch is how he is. He need not change, bears no responsibility for improving himself or finding another job more suited to strengths and weaknesses, others must accommodate. Bollocks. Skill must be matched with discipline, or else it's worthless. I'm sure your TdF idols would agree. If they couldn't apply discipline to do the job in front of them and to keep getting better at it, they wouldn't be in the Tour de France.

> Just out of curiosity, are you a German? I see similar thinking around here a lot.

No, but thanks for the stereotype. I know some Germans, I've been to Germany pretty recently, I think I'd fit in pretty well there, but I'm not German. (Actually there might be a percent or two of German blood in there, but there's far more Irish.) It's also pretty ironic that you'd say I seem that way, since you're the one echoing a German philosopher.

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.

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.

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?

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

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.

There is more context here http://workplace.stackexchange.com/questions/79675/im-techni...

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.

> 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

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?

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

Even more context here:

http://chat.stackexchange.com/rooms/48551/discussion-on-ques...

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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

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

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

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

Sounds delusional.

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.

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.

Reply on news.ycombinator.com