12 ms·

Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther aw

Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist (in my mind it is someone whose work moves you farther away from the project goals, rather than closer to them). But a lot of the bullets sounded like stuff bad managers do, not bad engineers. Off the top of my head these are the most common two "negative engineer" behaviors I have seen 1) Biggest one: an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place. This is the key to never shipping and destroying entire companies. 2) Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is the key to your product dying a slow death over several years. There are negative engineers doing this stuff ALL. THE. TIME. EVERYWHERE. Despite unquantifiable volumes of both ink and blood spilled trying to prevent them.

svachalek 4y ago
These are so common. The problem engineer will tend to be seen as a genius with inadequate help, the only one who can save us (from the pit he dug for us).
- passwordoops 4y ago
  And it's funny how wherever things finally come to a head and you part ways to much hand-wringing and doom and gloom scenarios... Lo and behold, turns out the new guy can make it work just fine. In fact he's refactoring out the unnecessary complexity as we speak
- mgkimsal 4y ago
  Holy tamole. Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks. About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!" This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that. You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...
  - cratermoon 4y ago
    > "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it?" Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.
    - arcanemachiner 4y ago
      "If you can't explain it to a six year old, you don't understand it yourself." - Albert Einstein* *I'm skeptical of any quote attributed to Einstein, but Goodreads said it's by him.
      - elcritch 4y ago
        Pretty sure that one is from Feynman.
    - denton-scratch 4y ago
      I don't believe a fellow is clever, unless he can explain his clever thoughts clearly. Feynman was seriously clever.
      - mynameisvlad 4y ago
        Yep, someone smart enough to come up with something should also be smart enough to be able to break down and explain what he came up with.
    - digging 4y ago
      Totally agreed. I don't trust smart people who can't explain their ideas. It's not that I don't think they're right, it's that I don't think it's a good business idea to operate on faith. But also, being able to break a concept down increases the smart person's level of comprehension of their ideas - it's not only proof, it has tangible benefit.
  - yamtaddle 4y ago
- shagie 4y ago
  From a bit ago: We fired our top talent. Best decision we ever made. - https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/ https://www.freecodecamp.org/news/we-fired-our-top-talent-be... ( https://news.ycombinator.com/item?id=15474893 https://news.ycombinator.com/item?id=15474893 125 comments; https://news.ycombinator.com/item?id=32211953 https://news.ycombinator.com/item?id=32211953 30 comments) > “You will never be able to understand any of what I’ve created. I am Albert F**ing Einstein and you are all monkeys scrabbling in the dirt.” > And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde. > He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed. And then follow up: A team reborn after the fiery departure of its misanthropic guru - https://blog.solha.co/life-after-rick-our-team-reborn-after-the-fiery-departure-of-our-misanthropic-guru-b1fbaf3b8621 https://blog.solha.co/life-after-rick-our-team-reborn-after-...
  - ARandomerDude 4y ago
    Great read, thanks for (re)sharing. Amazing how much of this resonates with behaviors I've seen over the past few years.
  - JohnMakin 4y ago
    Thanks for reposting this. Sounds so eerily similar to my last principal that I wonder if it's the same guy, although I'm sure this is a common phenomenon.
  - oblio 4y ago
    https://workchronicles.com/prevention-and-cure/ https://workchronicles.com/prevention-and-cure/
  - mike_hock 4y ago
    Awesome. They fired him after he'd become burned out and snapped, but were perfectly happy to let him grind away day and night for years while the rest of the team was twiddling thumbs.
- Viliam1234 4y ago
  The "genius" who saves the company from the problems he created, is not the apex negative engineer. The time he spends fixing his own mistakes is the time he does not spend creating new ones. Sometimes his creativity will be limited to a single project. There is also the type of "genius" who creates an overcomplicated framework as a foundation for a new project, and then leaves the implementation details to lesser minds trying to understand his work, while he moves to start another new project. He is always too busy working on a new project, doesn't have time to answer questions about the old ones. (The problem is sometimes solved by gradually removing his code. In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called.)
  - pcthrowaway 4y ago
    > In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called Ah yes, if the wrong people become aware that the code is never called, better to claim that it happened as too many people had their hand in the pot, and hey, the code is still working, and the tests are passing, so you didn't realize anything was wrong, rather than ruffle feathers and say you didn't want to touch the "genius" code because it was stuck up its own ass.
austin-cheney 4y ago
Super subjective. The most common thing I see is developers compensating for this by never writing original code and then demonizing others who do when they cannot read it. By original code I don’t mean config files or glue for frameworks.
- whateveracct 4y ago
  Yep I've seen seniors/principals come in and steamroll people trying to do FP by claiming that it was inscrutable and irresponsible. Sometimes even going up the chain to cause shake-up without the team's input. Even though said FP was in production, working with a low bug rate, and the entire team was fine with it. And I've seen this happen at multiple companies. I've come to think it's the biggest existential risk to doing Haskell in industry - it's red meat to org-chart climbing sharks. And the people who tend to be willing to learn and do FP in prod tend to not be politically-minded (usually due to strong principles and values), making them even weaker to these attacks.
  - Starlord2048 4y ago
    It seems as though the main issue here is not with FP itself, but with the politics and power dynamics within organizations.
    - whateveracct 4y ago
      Oh definitely, but sadly I think the culture and people involved in FP tend to be susceptible to politics. But I am in no way _blaming_ that or acting like FP should change. Those same cultures, values, and people are what make the various FP languages and communities out there great.
  - vbezhenar 4y ago
    I am that guy. Because you’ll leave and there will be no one brave enough to support and expand this code. And so it’ll get rewritten from the scratch. Why not write it in a maintainable way from the start. A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.
pl90087 4y ago
And the problem our industry has is that these concepts are not well-defined. You can easily have engineer A strongly claim that the code that was put in front of them from engineer B is terribly designed and will be unmaintainable and then they write an alternative proposal that they love, and then the next guy C comes with the exact criticism of the alternative, and the twist is that C is actually B, the guy who wrote the originally criticized code. You can watch this kind of stuff first hand here in HN discussions. It's so sad, it's actually pretty comical again if you are not vested in it.
- highwaylights 4y ago
  The solution is D, which means we come up with a methodology that solves problems A-C and then mandate that everyone sticks to it. And now we have problems A through E.
  - letitbeirie 4y ago
    Oblig: https://xkcd.com/927/ https://xkcd.com/927/
    - haweemwho 4y ago
      [flagged]
- z3t4 4y ago
  The solution is that the one who write the software/architecture is also the one maintaining it. When it comes to writing easy to maintain code, that can only be learned by maintaining code for a long time. If that dude leaves the team and you have no one that can edit it, just rewrite the code from scratch! So you basically want to follow the Unix philosophy or micro service architecture. This allows you to hire any kind of programmer, you no longer need to find someone experienced in programming language X, with frameworks Y for platform Z (which is impossible), you can hire anyone that is experience enough to do the work and let him/her write the software in whatever environment he/she pleases.
chinchilla2020 4y ago
We hire for case 2. The hiring process requires deep, esoteric knowledge on sub-optimal data structures and algorithms. A frontend developer that uses lots of bitwise operations and tricky mathematical algorithms to display CRUD is simply a developer who studied those things.
donkeyd 4y ago
I had a -10x engineer in my team. They refused to test their own work, because that was the tester's job. They sometimes implemented a feature in the wrong place, both technically and functionally, requiring a complete rewrite (and removing code, roll-back was not an option in this tool). They started using float in HTML while we used grid, this caused stuff to be on top of each other. Unfortunately, this guy played management in a way that caused him to keep getting away with the behavior. Awful person to work with!
- ngc248 4y ago
  I call them 100x engineers, since they create 100x more work for others
digging 4y ago
I find #2 is fairly easy for me to avoid by focusing on code quality and readability. But working in front-end, I'm always afraid of doing #1. The paradigms shift so quickly I never feel sure I'm using the right patterns. Time has proven that generally I'm close enough, but I still fear it.
JohnFen 4y ago
> an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is my biggest pet peeve of them all. I tell wet-behind-the-ears engineers "always strive to make the life of the next person to touch the code easier, even if only because the 'next person' will probably be you."
- amatecha 4y ago
  Yeah, I've had so many experiences of coming back to something I wrote 6-18mo ago, and being so relieved that I wrote it "simply" and with clear comments explaining the intent/purpose. Not only a great refresher, but anyone else could also gain context and easily make changes. I think there's also an aspect of that "broken windows" phenomenon[0] where inscrutable code existing in a project becomes a sort of implicit acceptance of more such inscrutable code being added to the project. [0] https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory
skrtskrt 4y ago
> an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place I have dealt with opposite - a monolith-based company grew to a point where more complexity was required, but none of the engineers there seemed to have been equipped with an iota of distributed systems knowledge. The "senior" and "staff" engineers obviously built something, and everyone was still monkeypatching out all the consistency issues 5+ years later, and some of them were still around declaring that there are no issues.
Herval_freire 4y ago
>Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist I don't believe 10x engineers actually exist. Maybe 1.5x, 2x, or 3x engineers exist at most. 10x is a huge exaggeration of human capability. Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible. You also might get a lead who can ramp up the effectiveness of an entire team by say 3x at most. If the size of the team was N, then it's N*3X. If N is like 4 then it's a 12x increase. This is the closest thing to an actual 10x engineer. But it's not actually a 10x engineer here it's just better management.
- hcs 4y ago
  Negative 10x
  - Herval_freire 4y ago
    Oh man. My eyes just skipped over that negative sign every time. Now it makes sense. I thought the article was sarcastic. I'm blind.
- nrclark 4y ago
  a 10x engineer might not exist. A -10x engineer (or more accurately: a 1/10x engineer) definitely does. This article isn't about engineers that make your team better; it's about engineers that make your team worse.
  - rzzzt 4y ago
    The distinction is important: someone else already wrote that the -10× person will move you further away from the goalpost, while the 10⁻¹× counterpart is still moving towards it, only slower.
    - 4y ago
r00fus 4y ago
So is someone who can grok and refactor an inscrutable codebase a +10x engineer (since they fixed a -10x engineer's work) or ... something else?
babyshake 4y ago
It's all too common for engineers to encourage (or to "request changes" and block a pull request from merging) changes to some code to eke out a bit of non-perceptible performance improvement by rewriting code in a way that makes it more difficult to understand or more complex. There are certainly situations where every ounce of performance gain is worth it, but no, your web app serving 100 DAUs is not it.
jiggawatts 4y ago
> Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable The most spectacular example of this I've ever seen was a developer writing Java that only ever used single-character identifiers. As in the following style: class D { public A foo(B b, C c ) { D d = b.x( c ); return new A(d.f(1)); } } Now imagine this for several hundred thousand lines. Zero comments. Massive functions. You might be wondering: what happens when he gets to "z" and runs out of identifiers? No problem! He just kept going thus: aa, ab, ac, ad, etc... I saw code up to "dh" or somesuch. He had perfect job security... right up until the startup he was working for imploded because nobody could collaborate on that code.
- xnx 4y ago
  Wow. He probably thought this was making the code more compact/efficient/faster.
  - edandersen 4y ago
    No, it was job security. This happens all the time when incentives are not aligned. Some engineers even have private dictionaries to convert between the obfuscated code and the real definitions.
- pmoriarty 4y ago
  This looks like typical variable naming in Haskell. That community just loves one-letter variable names... I'll never understand why.
PaulHoule 4y ago
3) “Engineers” who resist any kind of structure on the assumption that (1) is going on. That, is, the fear of (1) is just as bad as (1). One manifestation of is today is pythoners resisting real solutions to packaging problems thus making packaging problems impossible to solve.

svachalek 4y ago

These are so common. The problem engineer will tend to be seen as a genius with inadequate help, the only one who can save us (from the pit he dug for us).

passwordoops 4y ago
And it's funny how wherever things finally come to a head and you part ways to much hand-wringing and doom and gloom scenarios... Lo and behold, turns out the new guy can make it work just fine. In fact he's refactoring out the unnecessary complexity as we speak
mgkimsal 4y ago
Holy tamole. Had worked someplace for a short stint. There was a guy who'd started a couple months before I did. His work was 'revolutionary' and 'groundbreaking' - he'd been trying to build some sort of AOP-style PHP system - PHP4, mind you - without any extensions or internals work. It was just 'program this way' - undocumented patterns that encouraged copy/paste to half-way almost get you something usable (except, not really). "Build a form to take a few fields input and store in a database" example took days to develop, because... he was just winging it. Session management? nope - we'll need to roll our own, and that'll take a few weeks. About half the team (20ish folks) were enraptured by this guy. Someone rambled about great this guy was, said something along the lines of "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it? that's where we're at, and it's just so awesome - I can't wait to learn more!" This guy saying that was, at the time, like... the #2 guy on the team, had been there for years, and was the defacto 'team lead' for that work, and he was taken in by a huckster. The aop guy was there for about 10 months, then left abruptly - left on a friday, sent an email on monday with "i resign, i got another job". somehow, some folks were "shocked" at his "unprofessionalism". The entire tenure had been unprofessional, but few cared to label it that. You're so good and smart that you built something we all need to use, but you can't explain it (let alone why it's good/better), everyone else plainly admits they don't understand much about it, and use the lack of understanding as evidence that they're so bad this must be genius-level work. Insane...
- cratermoon 4y ago
  > "you know those sorts of geniuses that are so far ahead of everyone else that they can't even explain things, and no one else can quite understand it?" Richard Feynman was certainly a genius and he was well-known for his ability to explain complex topics in ways laypeople could grasp.
  - arcanemachiner 4y ago
    "If you can't explain it to a six year old, you don't understand it yourself." - Albert Einstein* *I'm skeptical of any quote attributed to Einstein, but Goodreads said it's by him.
    - elcritch 4y ago
      Pretty sure that one is from Feynman.
  - denton-scratch 4y ago
    I don't believe a fellow is clever, unless he can explain his clever thoughts clearly. Feynman was seriously clever.
    - mynameisvlad 4y ago
      Yep, someone smart enough to come up with something should also be smart enough to be able to break down and explain what he came up with.
  - digging 4y ago
    Totally agreed. I don't trust smart people who can't explain their ideas. It's not that I don't think they're right, it's that I don't think it's a good business idea to operate on faith. But also, being able to break a concept down increases the smart person's level of comprehension of their ideas - it's not only proof, it has tangible benefit.
- yamtaddle 4y ago
shagie 4y ago
From a bit ago: We fired our top talent. Best decision we ever made. - https://www.freecodecamp.org/news/we-fired-our-top-talent-best-decision-we-ever-made-4c0a99728fde/ https://www.freecodecamp.org/news/we-fired-our-top-talent-be... ( https://news.ycombinator.com/item?id=15474893 https://news.ycombinator.com/item?id=15474893 125 comments; https://news.ycombinator.com/item?id=32211953 https://news.ycombinator.com/item?id=32211953 30 comments) > “You will never be able to understand any of what I’ve created. I am Albert F**ing Einstein and you are all monkeys scrabbling in the dirt.” > And so our resident genius, our Dr. Jekyll, explosively completed his transformation into Mr. Hyde. > He declared this in front of the product design team, developers, management, and pre-launch customers. One of our project sponsors had the temerity to ask when the problem crippling our product would be fixed. And then follow up: A team reborn after the fiery departure of its misanthropic guru - https://blog.solha.co/life-after-rick-our-team-reborn-after-the-fiery-departure-of-our-misanthropic-guru-b1fbaf3b8621 https://blog.solha.co/life-after-rick-our-team-reborn-after-...
- ARandomerDude 4y ago
  Great read, thanks for (re)sharing. Amazing how much of this resonates with behaviors I've seen over the past few years.
- JohnMakin 4y ago
  Thanks for reposting this. Sounds so eerily similar to my last principal that I wonder if it's the same guy, although I'm sure this is a common phenomenon.
- oblio 4y ago
  https://workchronicles.com/prevention-and-cure/ https://workchronicles.com/prevention-and-cure/
- mike_hock 4y ago
  Awesome. They fired him after he'd become burned out and snapped, but were perfectly happy to let him grind away day and night for years while the rest of the team was twiddling thumbs.
Viliam1234 4y ago
The "genius" who saves the company from the problems he created, is not the apex negative engineer. The time he spends fixing his own mistakes is the time he does not spend creating new ones. Sometimes his creativity will be limited to a single project. There is also the type of "genius" who creates an overcomplicated framework as a foundation for a new project, and then leaves the implementation details to lesser minds trying to understand his work, while he moves to start another new project. He is always too busy working on a new project, doesn't have time to answer questions about the old ones. (The problem is sometimes solved by gradually removing his code. In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called.)
- pcthrowaway 4y ago
  > In extreme case, the library remains included, to avoid a political conflict, but the code is actually never called Ah yes, if the wrong people become aware that the code is never called, better to claim that it happened as too many people had their hand in the pot, and hey, the code is still working, and the tests are passing, so you didn't realize anything was wrong, rather than ruffle feathers and say you didn't want to touch the "genius" code because it was stuck up its own ass.

austin-cheney 4y ago

Super subjective. The most common thing I see is developers compensating for this by never writing original code and then demonizing others who do when they cannot read it. By original code I don’t mean config files or glue for frameworks.

whateveracct 4y ago
Yep I've seen seniors/principals come in and steamroll people trying to do FP by claiming that it was inscrutable and irresponsible. Sometimes even going up the chain to cause shake-up without the team's input. Even though said FP was in production, working with a low bug rate, and the entire team was fine with it. And I've seen this happen at multiple companies. I've come to think it's the biggest existential risk to doing Haskell in industry - it's red meat to org-chart climbing sharks. And the people who tend to be willing to learn and do FP in prod tend to not be politically-minded (usually due to strong principles and values), making them even weaker to these attacks.
- Starlord2048 4y ago
  It seems as though the main issue here is not with FP itself, but with the politics and power dynamics within organizations.
  - whateveracct 4y ago
    Oh definitely, but sadly I think the culture and people involved in FP tend to be susceptible to politics. But I am in no way _blaming_ that or acting like FP should change. Those same cultures, values, and people are what make the various FP languages and communities out there great.
- vbezhenar 4y ago
  I am that guy. Because you’ll leave and there will be no one brave enough to support and expand this code. And so it’ll get rewritten from the scratch. Why not write it in a maintainable way from the start. A significant part of choosing a technology is economics of people available to hire. Who can work with that technology 5 years later, when original authors will be long gone.

pl90087 4y ago

And the problem our industry has is that these concepts are not well-defined. You can easily have engineer A strongly claim that the code that was put in front of them from engineer B is terribly designed and will be unmaintainable and then they write an alternative proposal that they love, and then the next guy C comes with the exact criticism of the alternative, and the twist is that C is actually B, the guy who wrote the originally criticized code. You can watch this kind of stuff first hand here in HN discussions. It's so sad, it's actually pretty comical again if you are not vested in it.

highwaylights 4y ago
The solution is D, which means we come up with a methodology that solves problems A-C and then mandate that everyone sticks to it. And now we have problems A through E.
- letitbeirie 4y ago
  Oblig: https://xkcd.com/927/ https://xkcd.com/927/
  - haweemwho 4y ago
    [flagged]
z3t4 4y ago
The solution is that the one who write the software/architecture is also the one maintaining it. When it comes to writing easy to maintain code, that can only be learned by maintaining code for a long time. If that dude leaves the team and you have no one that can edit it, just rewrite the code from scratch! So you basically want to follow the Unix philosophy or micro service architecture. This allows you to hire any kind of programmer, you no longer need to find someone experienced in programming language X, with frameworks Y for platform Z (which is impossible), you can hire anyone that is experience enough to do the work and let him/her write the software in whatever environment he/she pleases.

chinchilla2020 4y ago

We hire for case 2. The hiring process requires deep, esoteric knowledge on sub-optimal data structures and algorithms. A frontend developer that uses lots of bitwise operations and tricky mathematical algorithms to display CRUD is simply a developer who studied those things.

donkeyd 4y ago

I had a -10x engineer in my team. They refused to test their own work, because that was the tester's job. They sometimes implemented a feature in the wrong place, both technically and functionally, requiring a complete rewrite (and removing code, roll-back was not an option in this tool). They started using float in HTML while we used grid, this caused stuff to be on top of each other. Unfortunately, this guy played management in a way that caused him to keep getting away with the behavior. Awful person to work with!

ngc248 4y ago
I call them 100x engineers, since they create 100x more work for others

digging 4y ago

I find #2 is fairly easy for me to avoid by focusing on code quality and readability. But working in front-end, I'm always afraid of doing #1. The paradigms shift so quickly I never feel sure I'm using the right patterns. Time has proven that generally I'm close enough, but I still fear it.

JohnFen 4y ago

> an engineer who writes code that is inscrutable and therefore unmaintainable (always by others, often by themselves as well). This is my biggest pet peeve of them all. I tell wet-behind-the-ears engineers "always strive to make the life of the next person to touch the code easier, even if only because the 'next person' will probably be you."

amatecha 4y ago
Yeah, I've had so many experiences of coming back to something I wrote 6-18mo ago, and being so relieved that I wrote it "simply" and with clear comments explaining the intent/purpose. Not only a great refresher, but anyone else could also gain context and easily make changes. I think there's also an aspect of that "broken windows" phenomenon[0] where inscrutable code existing in a project becomes a sort of implicit acceptance of more such inscrutable code being added to the project. [0] https://en.wikipedia.org/wiki/Broken_windows_theory https://en.wikipedia.org/wiki/Broken_windows_theory

skrtskrt 4y ago

> an engineer who is not experienced at architecting complex systems, goes and architects one when complexity was not required in the first place I have dealt with opposite - a monolith-based company grew to a point where more complexity was required, but none of the engineers there seemed to have been equipped with an iota of distributed systems knowledge. The "senior" and "staff" engineers obviously built something, and everyone was still monkeypatching out all the consistency issues 5+ years later, and some of them were still around declaring that there are no issues.

Herval_freire 4y ago

>Yeah that was an interesting read. I like the concept of a -10x engineer because they definitely exist I don't believe 10x engineers actually exist. Maybe 1.5x, 2x, or 3x engineers exist at most. 10x is a huge exaggeration of human capability. Get this, say a project takes a year to complete. The concept is saying a 10x engineer can do this in about month. If such a person exists it will be so rare I estimate that most people haven't ever encountered an actual "10x" engineer. Even a 3x engineer is super rare. I can see something like 2x happening where a project that takes a year is done in 6 months. That is rare but plausible. You also might get a lead who can ramp up the effectiveness of an entire team by say 3x at most. If the size of the team was N, then it's N*3X. If N is like 4 then it's a 12x increase. This is the closest thing to an actual 10x engineer. But it's not actually a 10x engineer here it's just better management.

hcs 4y ago
Negative 10x
- Herval_freire 4y ago
  Oh man. My eyes just skipped over that negative sign every time. Now it makes sense. I thought the article was sarcastic. I'm blind.
nrclark 4y ago
a 10x engineer might not exist. A -10x engineer (or more accurately: a 1/10x engineer) definitely does. This article isn't about engineers that make your team better; it's about engineers that make your team worse.
- rzzzt 4y ago
  The distinction is important: someone else already wrote that the -10× person will move you further away from the goalpost, while the 10⁻¹× counterpart is still moving towards it, only slower.
  - 4y ago

r00fus 4y ago

So is someone who can grok and refactor an inscrutable codebase a +10x engineer (since they fixed a -10x engineer's work) or ... something else?

babyshake 4y ago

It's all too common for engineers to encourage (or to "request changes" and block a pull request from merging) changes to some code to eke out a bit of non-perceptible performance improvement by rewriting code in a way that makes it more difficult to understand or more complex. There are certainly situations where every ounce of performance gain is worth it, but no, your web app serving 100 DAUs is not it.

jiggawatts 4y ago

> Close runner up: an engineer who writes code that is inscrutable and therefore unmaintainable The most spectacular example of this I've ever seen was a developer writing Java that only ever used single-character identifiers. As in the following style: class D { public A foo(B b, C c ) { D d = b.x( c ); return new A(d.f(1)); } } Now imagine this for several hundred thousand lines. Zero comments. Massive functions. You might be wondering: what happens when he gets to "z" and runs out of identifiers? No problem! He just kept going thus: aa, ab, ac, ad, etc... I saw code up to "dh" or somesuch. He had perfect job security... right up until the startup he was working for imploded because nobody could collaborate on that code.

xnx 4y ago
Wow. He probably thought this was making the code more compact/efficient/faster.
- edandersen 4y ago
  No, it was job security. This happens all the time when incentives are not aligned. Some engineers even have private dictionaries to convert between the obfuscated code and the real definitions.
pmoriarty 4y ago
This looks like typical variable naming in Haskell. That community just loves one-letter variable names... I'll never understand why.

PaulHoule 4y ago

3) “Engineers” who resist any kind of structure on the assumption that (1) is going on. That, is, the fear of (1) is just as bad as (1). One manifestation of is today is pythoners resisting real solutions to packaging problems thus making packaging problems impossible to solve.