8 ms·

Fired because your skills are too far above your coworkers

60 points by nsoonhui 10y ago

xplusy 10y ago
I feel the same pain in my industry where experienced are replaced with noobs for less pay.
minipci1321 10y ago
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.
amelius 10y ago
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 10y ago
  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.
aaron695 10y ago
> 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 10y ago
  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.
- joslin01 10y ago
  > 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 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.
jpatokal 10y ago
> 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 10y ago
  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 10y ago
    > 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 10y ago
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.
- dx034 10y ago
  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.
- pjc50 10y ago
  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.)
- crdoconnor 10y ago
  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.
- 10y ago
vladimir-y 10y ago
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.
kbart 10y ago
"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 10y ago
  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).
- crdoconnor 10y ago
  >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.
- informatimago 10y ago
dep_b 10y ago
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.
magoon 10y ago
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 10y ago
  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.
johnloeber 10y ago
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 10y ago
  What further business problems is he creating?
  - AimHere 10y ago
    Software that's not maintainable by his coworkers.
    - i_feel_great 10y ago
      Is quality Typescript/Node.js code, which is "intelligently decoupled", harder to maintain than poorer quality code?
      - dogma1138 10y ago
        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.
        deleted 10y ago
        [deleted]
      - Tiquor 10y ago
        Intelligently decoupled, no. Needlessly abstract, yes. Many rockstars can't tell the difference.
      - 10y ago
trymas 10y ago
If it's N-th time happening maybe there are more problems than just 'too good code'?
informatimago 10y ago
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 10y ago
  "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.
xupybd 10y ago
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 10y ago
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.
smoyer 10y ago
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.
krisgenre 10y ago
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 10y ago
  > 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.
Uptrenda 10y ago
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 10y ago
  > 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 10y ago
    > 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.
bitL 10y ago
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 10y ago
  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 10y ago
    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.
varjag 10y ago
Sounds delusional.
mhomde 10y ago
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.
crapstartups 10y ago
This is actually a common problem. I was recently pushed out of an early stage startup despite being the lead dev, having built the entire stack, the apps, the mobile clients, the whole shebang. The reason? I discovered that the CTO couldn't code. Despite beating his puny chest, bleating about part glories at Google etc, his code was amateur hour, every hour. Really really low grade enterprise-ish Java-like efforts. Despite the language or platform. I now test the hiring manager, as well as them testing me, before I join any new organisations.
satysin 10y ago
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.
Jugurtha 10y ago
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 10y ago
  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.
ceejay 10y ago
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.
beeswax 10y ago
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).
consultanturnot 10y ago
Many of the comments here are from people that are not consultants. 3-4 issues with clients is not unheard of. I've 'reported' to c-levels and help desk managers, and everything in between. Rarely do clients that need a consultant have the in-house skills (or, generously, the time) to solve a problem or understand the solution. The more niche and high tech the problem/requirement/solution the fewer that understand it. I've been in similar situations and it is because it is human nature to both want to be perceived as being smart and protecting your job if someone you brought in might show others that you aren't as smart as you think. This is part of the reason for whistleblower protections and why such protections are rarely tested or work as advertised...people protecting their ignorance/bad practices/behaviors and jobs.
kkapelon 10y ago
There is more context here http://workplace.stackexchange.com/questions/79675/im-technical-referent-but-i-lost-the-lead-for-technical-decisions http://workplace.stackexchange.com/questions/79675/im-techni...
kkapelon 10y ago
Even more context here: http://chat.stackexchange.com/rooms/48551/discussion-on-question-by-mik378-im-technical-referent-but-i-lost-the-lead-for 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"
mcv 10y ago
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 10y ago
  > 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.".
oliwarner 10y ago
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.
chrismcb 10y ago
If he is so good, why is his code so hard to understand?

60 points by nsoonhui 10y ago

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

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.

amelius 10y ago

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 10y ago
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.

aaron695 10y ago

> 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 10y ago
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.
joslin01 10y ago
> 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 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.

jpatokal 10y ago

> 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 10y ago
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 10y ago
  > 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 10y ago

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.

dx034 10y ago
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.
pjc50 10y ago
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.)
crdoconnor 10y ago
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.
10y ago

vladimir-y 10y ago

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.

kbart 10y ago

"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 10y ago
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).
crdoconnor 10y ago
>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.
informatimago 10y ago

dep_b 10y ago

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.

magoon 10y ago

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 10y ago
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.

johnloeber 10y ago

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 10y ago
What further business problems is he creating?
- AimHere 10y ago
  Software that's not maintainable by his coworkers.
  - i_feel_great 10y ago
    Is quality Typescript/Node.js code, which is "intelligently decoupled", harder to maintain than poorer quality code?
    - dogma1138 10y ago
      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.
      - deleted 10y ago
        [deleted]
    - Tiquor 10y ago
      Intelligently decoupled, no. Needlessly abstract, yes. Many rockstars can't tell the difference.
    - 10y ago

trymas 10y ago

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

informatimago 10y ago

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 10y ago
"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.

xupybd 10y ago

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 10y ago

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.

smoyer 10y ago

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.

krisgenre 10y ago

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 10y ago
> 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.

Uptrenda 10y ago

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 10y ago
> 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 10y ago
  > 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.

bitL 10y ago

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 10y ago
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 10y ago
  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.

varjag 10y ago

Sounds delusional.

mhomde 10y ago

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.

crapstartups 10y ago

This is actually a common problem. I was recently pushed out of an early stage startup despite being the lead dev, having built the entire stack, the apps, the mobile clients, the whole shebang. The reason? I discovered that the CTO couldn't code. Despite beating his puny chest, bleating about part glories at Google etc, his code was amateur hour, every hour. Really really low grade enterprise-ish Java-like efforts. Despite the language or platform. I now test the hiring manager, as well as them testing me, before I join any new organisations.

satysin 10y ago

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.

Jugurtha 10y ago

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 10y ago
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.

ceejay 10y ago

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.

beeswax 10y ago

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

consultanturnot 10y ago

Many of the comments here are from people that are not consultants. 3-4 issues with clients is not unheard of. I've 'reported' to c-levels and help desk managers, and everything in between. Rarely do clients that need a consultant have the in-house skills (or, generously, the time) to solve a problem or understand the solution. The more niche and high tech the problem/requirement/solution the fewer that understand it. I've been in similar situations and it is because it is human nature to both want to be perceived as being smart and protecting your job if someone you brought in might show others that you aren't as smart as you think. This is part of the reason for whistleblower protections and why such protections are rarely tested or work as advertised...people protecting their ignorance/bad practices/behaviors and jobs.

kkapelon 10y ago

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

kkapelon 10y ago

Even more context here: http://chat.stackexchange.com/rooms/48551/discussion-on-question-by-mik378-im-technical-referent-but-i-lost-the-lead-for 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"

mcv 10y ago

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 10y ago
> 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.".

oliwarner 10y ago

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.

chrismcb 10y ago

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