6 ms·

Ouch. I used to work with a guy like this. Generally speaking, this is an occurrance that is exceedingly common and extremely under-recognized in our industry.

Ouch. I used to work with a guy like this. Generally speaking, this is an occurrance that is exceedingly common and extremely under-recognized in our industry. Instead, he used the odd hours to force us to give him only work that could be accomplished alone. We were lulled into letting him make key architecture decisions in isolation Our guy accomplished this via different means but the end result was the same: because of various factors, he became "architect" and essentially was able to make decisions alone. Then we had to live with them. Eventually he became the architect by virtue of operating in isolation, where we couldn't discuss his decisions. Everyone else was forced to work around his code. Yyyyeeeeeeep. Our guy was genuinely, I think, the best engineer on a team of pretty good engineers. But in terms of sheer talent he was not a "10x" coder in terms of raw talent. Call him perhaps a "1.2x" or "1.5x" in terms of raw talent. However, he was essentially able to operate as something like a "10x" talent because he got to do a lot of greenfield work, make sweeping architecture changes and decisions, and so forth. Meanwhile we were all left to deal with his fallout. Whether or not you believe there are legitimate "10x" engineers (we'll set that debate aside for a moment) I think it is very, very obvious that we have misidentified the talent level of many engineers. Your actual output level as an engineer, be it 1x or 100x, is always a product of many factors and your actual talent level is only one of those factors. Worse yet, having someone like that on the team drives away other great employees. Yes. Two big reasons. 1. It's not a good way to make software, obviously. Great employees want to make great software and will be frustrated. 2. It's career fucking suicide to work under somebody like that. It's impossible to shine when working under somebody like that. You can't clean up a mess as quickly as other people can create a mess. You just can't. With very rare exceptions you simply cannot mop a floor well enough to be seen as something other than a janitor.

Aeolun 7y ago
I still think I’d rather have my architectural decisions made by a 1.5 coder than a 1.0 coder. This causes other people to have to follow the style, but it also prevents them from making something worse.
- Neeek 7y ago
  I think their point was that architectural decisions shouldn't be dictated by any one single engineer.
  - f0rfun 7y ago
    Not sure about that. Too many chefs spoil the broth. And in most cases, if this one single engineer has the proven track record, I'd give his opinions and decisions slightly higher weightage but at the same time, dictate that he run through his decision making process with the rest of the team. Think of it as forcing him to communicate/knowledge share so that the rest of the team can keep up, learn or simply be convinced. Otherwise, the session serves as a Q&A for the rest of the engineers to shoot. It makes this 'rockstar' a more wholesome engineer in the end, whether he buys it or not. Communicating well is more difficult than perceived, and it's definitely a critical competency to master if you want to really call yourself a rockstar/10x techie.
    - JohnBooty 7y ago
      Yes, this is how it should work. Assuming your 1x engineers are smart, competent engineers with relevant real world experience under their belts (and are not recent code school grads)... they should have a great deal of input into architecture decisions. They should never have architecture level stuff thrust upon them. Too many cooks spoil the broth indeed but nobody should be doing this stuff in isolation and dictating it unless perhaps you’re doing truly bleeding edge shit and your 10x engineer is a true, Carmackian generational talent. However. Howwwwwever.... The ILLUSION of democratic (or at least collegial) meritocracy is how our faux-10x engineer pulled the wool over folks’ eyes. He gave the appearance of soliciting feedback. We had internal RFCs and everything. But in the end though he really did just push his ideas through unmolested, because he had management's blessing to do so. Not sure how much was an intentional masquerade on his part. I think he really did think it was a meritocracy and his ideas were simply the best. It is certainly not unheard-of for folks to fail to recognize their own privilege. Whatever the case, management enabled it. He was not an awful guy in general, and I rather liked him, just not as architect-dictator. One of his favorite tactics was to spend weeks or months coming up with something in isolation. If you raised objections he’d brush them off by demanding to know your alternative. Which was horseshit - how could you have a viable alternative when he’d had weeks to come up with his idea and you’d only had 10 seconds, especially when these "ideas" are his fulltime responsibility and your responsibility is to ship 40 or 50 hours' worth of software a week. And past experiences had taught you resistance was futile anyway, so why pour your heart into a doomed battle in this latest bit of asymmetrical warfare? This tactic played well to management though. He looked like the brilliant idea guy and you looked like the negative Nancy. This is a very common bit of political and rhetorical warfare and you see it everywhere. It is, essentially, a tactic that has much in common with the dreaded "Gish gallop" - you fling stuff at your opponent faster than they could possibly refute it. https://en.wikipedia.org/wiki/Gish_gallop https://en.wikipedia.org/wiki/Gish_gallop The cure for this in the software simple and difficult. Managers "simply" need to be aware of this possibility. However, they also need a certain level of technical chops IMO. If they're too far removed "from the trenches" they can't accurately judge the situation.
prpl 7y ago
Code reviews help gate this behavior, a bit. If a coworker does this and drops a 40k line PR, they get code review duty for everybody else for a little while _before_ their code can get merged. Letting them go unfettered definitely is a mistake.
hinkley 7y ago
I've worked with too many engineers who got a lot done by making it hard for anyone else to get things done. I think there aren't very many 10x engineers but there are a lot of 4x engineers who make everyone else .4x engineers. I was a lot happier and less busy trying to be a 3x engineer making everyone else into 1.5x engineers.
- JohnBooty 7y ago
  Ideally, this is how it works. Ideally you could even be a 0.5x engineer and make everybody else a 3x engineer and the team would still come out ahead. That sort of work often goes unrecognized though, if you are an in-the-trenches engineer. Unless your manager is pretty hands on and spends time “in the trenches” with the team they won’t see that. Most organizations reward selfishness and punish benevolence. Not on purpose. They just can’t see it, because they are too far removed from the work and benevolence is nontrivial to measure. So it takes a back seat to trivial measures.
  - hinkley 7y ago
    The first time this became an issue for me I pointed out that I'd saved a frustrating half hour a day for our dev team by making a series of QoL improvements. Across the team that was well over 40 hours a week. If you do things that make other people faster but not yourself then you look bad... to a shitty boss (and Mike was the shittiest I've ever had.) These days I'm more likely to fix things that bother me and then share them after they're debugged. And often after I have my fingers in something new. It makes me wonder if the proportion of 'scratch your itch' projects wouldn't be lower if people weren't disillusioned by the process of doing something solely for other programmers.
throwaway10x 7y ago
Reading your comment and the parent gave me goosebumps, I might be guilty of being this type of engineer. I created a side project that became its own very successful product, and now there are a couple of other engineers in the team and I'm the "tech lead". We have a front end and backend component, and I have another brilliant full stack taking full charge of the frontend. the other two engineers are _very_ mediocre at best. The code is complex partly because I (without formal training) wrote it all myself, but also because it's a very complex priduct, not just a CRUD. I'm Constantly stymied by the fact that on the backend, asking the mediocre engineer to do something means it will take a full Sprint instead of the two hours it'll take me. The other engineers are also not able to fully understand the PRs (because the code is still too complex to them after six months joining the project) so I feel minimal upside to wait for their code reviews (which I still do anyways). I've asked to staff with better engineers but given the complexity of the product (directly query very large datasets with very complex jobs from a clean frontend) and our small orgs inability to attract great talent, I'm not getting anyone. I'm forced with two possibilities: 1. Ask for the mediocre engineers to be removed from the team, and continue working on the backend solo (but making it actively a job to document and make it as easy as possible for a good engineer to take over after me). This would actually boost productivity 2x from what we are now frankly. 2. I stop coding fully or slow down 5x and work primarily as just someone who asks others to code. It would probably slow us down 3-4x,but I suppose it'll match the pattern of a regular team, though to what end I don't know. Is there any advice you can give? I'm sure I'm not seeing something obvious here that I'm doing wrong, and am fully open to honest input.
- JohnBooty 7y ago
  So, I think any engineer can be "guilty" of this. In fact, I might say that pretty much every engineer will be guilty of this if they have been in the industry long enough. It doesn't mean you're evil! It just means you're the one who created a bunch of stuff and naturally you can work with your own stuff more efficiently than others can. In fact I actually was "this guy" with one section of the code at my old company; the one where we had the "faux 10x" architect-dictator. I did manage to achieve a fairly clean transition once my involvement in that bit of the code ended. Ask for the mediocre engineers to be removed from the team It sounds like this codebase is significantly complicated that even above-average engineers might find it an uphill battle. Is this true? If so, perhaps the answers are the largely the same whether or not the mediocre engineers are replaced. "asking the mediocre engineer to do something means it will take a full Sprint instead of the two hours it'll take me" "[Transitioning from coder to mgmt/mentor] would probably slow us down 3-4x" How many hours of useful coding do you do per day? There are a lot of studies that suggest even great engineers don't code for more than a few hours per day. I don't think I'm great, but this definitely applies to me. Maybe you could divide your time in a way that's not too painful. Perhaps you could spend a fixed 1-2 hours per day on knowledge transfer (pair programming, etc) and not impact your productivity. Here's what I would say. 0. Get buy-in from the rest of the management/leadership team. They should fully support your efforts to get others up to speed. Tell them you are concerned about being the only one who can maintain the product effectively. They should NOT want you, personally, to remain an indispensible single point of failure. What if you leave? What if you are hit by a bus? 1. As I said above, if you can devote perhaps 25% of your week to full-time knowledge transfer, you might find that you accomplish a lot without sacrificing your other productivity unduly. 2. Pair programming is, I think, the fastest form of knowledge transfer. An hour or two of pairing with the newbie engineers at the outset of a task goes a LONG way and may save dozens of hours later in the sprint. It sounds like these engies should never, ever begin a task without this guidance from you. They will learn the code, they will learn the thought process that went into the code, and they will learn your problem-solving process. 3. Is your test suite awesome? Writing or improving tests can be an excellent way for folks to get up to speed on the code in a low risk way. And a strong test suite has long-lasting benefits. If you don't have a test suite at all, even a very rudimentary one will reap large rewards down the road. 4. I document my code (via inline code comments) more than most. My opinion is that if a bit of code represents a non-obvious technical kludge, or a bit of business logic, it should have an explanatory note. Theoretically this could be accomplished via diligent commit messages, but sifting through hundreds of commit messages is awfully tough. 5. YOUR ENGINEERS ARE PEOPLE. Working on your legacy hairball of code is... frustrating. Recognize their pain. Be sure to get them some "wins" on a regular basis so they can feel good. Praise their efforts in private, and in front of others in meetings. Good luck to you! My email is john edmund rose "at" gmail if you want to correspond. I'd like that!
tomrod 7y ago
Is this superhero syndrome? Where the engineer creates messes that only they can truly clean up? If not, what is a better term here?
- JohnBooty 7y ago
  There should be a term for it, so that people like me can describe it in less than a billion words. Wikipedia says: People with hero syndrome generally cause an accident or disaster with the intention of then coming in to render aid, and become the 'hero'. The reasons for this often vary. The perpetrator may be trying to validate their own self-worth, or be seen as brave by others. From that description, it sounds like the would-be "hero" in hero syndrome deliberately creates these disasters. I think things are a little less clear-cut in the sort of (common, IMO) engineering scenario I was talking about. I feel it's often more of a systemic situation, where the company/team does not properly value the knowledge transfer, empowerment, and management skill necessary to avoid those situations. In the specific situation I described I don't think our architect intentionally created messes, and I think probably believed at each step of the way that his actions were best for the company.
  - tomrod 7y ago
    Let's call it 10X syndrome. Spread the word!!!

Aeolun 7y ago

I still think I’d rather have my architectural decisions made by a 1.5 coder than a 1.0 coder. This causes other people to have to follow the style, but it also prevents them from making something worse.

Neeek 7y ago
I think their point was that architectural decisions shouldn't be dictated by any one single engineer.
- f0rfun 7y ago
  Not sure about that. Too many chefs spoil the broth. And in most cases, if this one single engineer has the proven track record, I'd give his opinions and decisions slightly higher weightage but at the same time, dictate that he run through his decision making process with the rest of the team. Think of it as forcing him to communicate/knowledge share so that the rest of the team can keep up, learn or simply be convinced. Otherwise, the session serves as a Q&A for the rest of the engineers to shoot. It makes this 'rockstar' a more wholesome engineer in the end, whether he buys it or not. Communicating well is more difficult than perceived, and it's definitely a critical competency to master if you want to really call yourself a rockstar/10x techie.
  - JohnBooty 7y ago
    Yes, this is how it should work. Assuming your 1x engineers are smart, competent engineers with relevant real world experience under their belts (and are not recent code school grads)... they should have a great deal of input into architecture decisions. They should never have architecture level stuff thrust upon them. Too many cooks spoil the broth indeed but nobody should be doing this stuff in isolation and dictating it unless perhaps you’re doing truly bleeding edge shit and your 10x engineer is a true, Carmackian generational talent. However. Howwwwwever.... The ILLUSION of democratic (or at least collegial) meritocracy is how our faux-10x engineer pulled the wool over folks’ eyes. He gave the appearance of soliciting feedback. We had internal RFCs and everything. But in the end though he really did just push his ideas through unmolested, because he had management's blessing to do so. Not sure how much was an intentional masquerade on his part. I think he really did think it was a meritocracy and his ideas were simply the best. It is certainly not unheard-of for folks to fail to recognize their own privilege. Whatever the case, management enabled it. He was not an awful guy in general, and I rather liked him, just not as architect-dictator. One of his favorite tactics was to spend weeks or months coming up with something in isolation. If you raised objections he’d brush them off by demanding to know your alternative. Which was horseshit - how could you have a viable alternative when he’d had weeks to come up with his idea and you’d only had 10 seconds, especially when these "ideas" are his fulltime responsibility and your responsibility is to ship 40 or 50 hours' worth of software a week. And past experiences had taught you resistance was futile anyway, so why pour your heart into a doomed battle in this latest bit of asymmetrical warfare? This tactic played well to management though. He looked like the brilliant idea guy and you looked like the negative Nancy. This is a very common bit of political and rhetorical warfare and you see it everywhere. It is, essentially, a tactic that has much in common with the dreaded "Gish gallop" - you fling stuff at your opponent faster than they could possibly refute it. https://en.wikipedia.org/wiki/Gish_gallop https://en.wikipedia.org/wiki/Gish_gallop The cure for this in the software simple and difficult. Managers "simply" need to be aware of this possibility. However, they also need a certain level of technical chops IMO. If they're too far removed "from the trenches" they can't accurately judge the situation.

prpl 7y ago

Code reviews help gate this behavior, a bit. If a coworker does this and drops a 40k line PR, they get code review duty for everybody else for a little while _before_ their code can get merged. Letting them go unfettered definitely is a mistake.

hinkley 7y ago

I've worked with too many engineers who got a lot done by making it hard for anyone else to get things done. I think there aren't very many 10x engineers but there are a lot of 4x engineers who make everyone else .4x engineers. I was a lot happier and less busy trying to be a 3x engineer making everyone else into 1.5x engineers.

JohnBooty 7y ago
Ideally, this is how it works. Ideally you could even be a 0.5x engineer and make everybody else a 3x engineer and the team would still come out ahead. That sort of work often goes unrecognized though, if you are an in-the-trenches engineer. Unless your manager is pretty hands on and spends time “in the trenches” with the team they won’t see that. Most organizations reward selfishness and punish benevolence. Not on purpose. They just can’t see it, because they are too far removed from the work and benevolence is nontrivial to measure. So it takes a back seat to trivial measures.
- hinkley 7y ago
  The first time this became an issue for me I pointed out that I'd saved a frustrating half hour a day for our dev team by making a series of QoL improvements. Across the team that was well over 40 hours a week. If you do things that make other people faster but not yourself then you look bad... to a shitty boss (and Mike was the shittiest I've ever had.) These days I'm more likely to fix things that bother me and then share them after they're debugged. And often after I have my fingers in something new. It makes me wonder if the proportion of 'scratch your itch' projects wouldn't be lower if people weren't disillusioned by the process of doing something solely for other programmers.

throwaway10x 7y ago

Reading your comment and the parent gave me goosebumps, I might be guilty of being this type of engineer. I created a side project that became its own very successful product, and now there are a couple of other engineers in the team and I'm the "tech lead". We have a front end and backend component, and I have another brilliant full stack taking full charge of the frontend. the other two engineers are _very_ mediocre at best. The code is complex partly because I (without formal training) wrote it all myself, but also because it's a very complex priduct, not just a CRUD. I'm Constantly stymied by the fact that on the backend, asking the mediocre engineer to do something means it will take a full Sprint instead of the two hours it'll take me. The other engineers are also not able to fully understand the PRs (because the code is still too complex to them after six months joining the project) so I feel minimal upside to wait for their code reviews (which I still do anyways). I've asked to staff with better engineers but given the complexity of the product (directly query very large datasets with very complex jobs from a clean frontend) and our small orgs inability to attract great talent, I'm not getting anyone. I'm forced with two possibilities: 1. Ask for the mediocre engineers to be removed from the team, and continue working on the backend solo (but making it actively a job to document and make it as easy as possible for a good engineer to take over after me). This would actually boost productivity 2x from what we are now frankly. 2. I stop coding fully or slow down 5x and work primarily as just someone who asks others to code. It would probably slow us down 3-4x,but I suppose it'll match the pattern of a regular team, though to what end I don't know. Is there any advice you can give? I'm sure I'm not seeing something obvious here that I'm doing wrong, and am fully open to honest input.

JohnBooty 7y ago
So, I think any engineer can be "guilty" of this. In fact, I might say that pretty much every engineer will be guilty of this if they have been in the industry long enough. It doesn't mean you're evil! It just means you're the one who created a bunch of stuff and naturally you can work with your own stuff more efficiently than others can. In fact I actually was "this guy" with one section of the code at my old company; the one where we had the "faux 10x" architect-dictator. I did manage to achieve a fairly clean transition once my involvement in that bit of the code ended. Ask for the mediocre engineers to be removed from the team It sounds like this codebase is significantly complicated that even above-average engineers might find it an uphill battle. Is this true? If so, perhaps the answers are the largely the same whether or not the mediocre engineers are replaced. "asking the mediocre engineer to do something means it will take a full Sprint instead of the two hours it'll take me" "[Transitioning from coder to mgmt/mentor] would probably slow us down 3-4x" How many hours of useful coding do you do per day? There are a lot of studies that suggest even great engineers don't code for more than a few hours per day. I don't think I'm great, but this definitely applies to me. Maybe you could divide your time in a way that's not too painful. Perhaps you could spend a fixed 1-2 hours per day on knowledge transfer (pair programming, etc) and not impact your productivity. Here's what I would say. 0. Get buy-in from the rest of the management/leadership team. They should fully support your efforts to get others up to speed. Tell them you are concerned about being the only one who can maintain the product effectively. They should NOT want you, personally, to remain an indispensible single point of failure. What if you leave? What if you are hit by a bus? 1. As I said above, if you can devote perhaps 25% of your week to full-time knowledge transfer, you might find that you accomplish a lot without sacrificing your other productivity unduly. 2. Pair programming is, I think, the fastest form of knowledge transfer. An hour or two of pairing with the newbie engineers at the outset of a task goes a LONG way and may save dozens of hours later in the sprint. It sounds like these engies should never, ever begin a task without this guidance from you. They will learn the code, they will learn the thought process that went into the code, and they will learn your problem-solving process. 3. Is your test suite awesome? Writing or improving tests can be an excellent way for folks to get up to speed on the code in a low risk way. And a strong test suite has long-lasting benefits. If you don't have a test suite at all, even a very rudimentary one will reap large rewards down the road. 4. I document my code (via inline code comments) more than most. My opinion is that if a bit of code represents a non-obvious technical kludge, or a bit of business logic, it should have an explanatory note. Theoretically this could be accomplished via diligent commit messages, but sifting through hundreds of commit messages is awfully tough. 5. YOUR ENGINEERS ARE PEOPLE. Working on your legacy hairball of code is... frustrating. Recognize their pain. Be sure to get them some "wins" on a regular basis so they can feel good. Praise their efforts in private, and in front of others in meetings. Good luck to you! My email is john edmund rose "at" gmail if you want to correspond. I'd like that!

tomrod 7y ago

Is this superhero syndrome? Where the engineer creates messes that only they can truly clean up? If not, what is a better term here?

JohnBooty 7y ago
There should be a term for it, so that people like me can describe it in less than a billion words. Wikipedia says: People with hero syndrome generally cause an accident or disaster with the intention of then coming in to render aid, and become the 'hero'. The reasons for this often vary. The perpetrator may be trying to validate their own self-worth, or be seen as brave by others. From that description, it sounds like the would-be "hero" in hero syndrome deliberately creates these disasters. I think things are a little less clear-cut in the sort of (common, IMO) engineering scenario I was talking about. I feel it's often more of a systemic situation, where the company/team does not properly value the knowledge transfer, empowerment, and management skill necessary to avoid those situations. In the specific situation I described I don't think our architect intentionally created messes, and I think probably believed at each step of the way that his actions were best for the company.
- tomrod 7y ago
  Let's call it 10X syndrome. Spread the word!!!