<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>throwaway10x</author><text>Reading your comment and the parent gave me goosebumps, I might be guilty of being this type of engineer.&lt;p&gt;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&amp;#x27;m the &amp;quot;tech lead&amp;quot;. 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&amp;#x27;s a very complex priduct, not just a CRUD. I&amp;#x27;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&amp;#x27;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&amp;#x27;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&amp;#x27;m not getting anyone.&lt;p&gt;I&amp;#x27;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.&lt;p&gt;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&amp;#x27;ll match the pattern of a regular team, though to what end I don&amp;#x27;t know.&lt;p&gt;Is there any advice you can give? I&amp;#x27;m sure I&amp;#x27;m not seeing something obvious here that I&amp;#x27;m doing wrong, and am fully open to honest input.</text><parent_chain><item><author>JohnBooty</author><text>Ouch. I used to work with a guy like this.&lt;p&gt;Generally speaking, this is an occurrance that is exceedingly common &lt;i&gt;and&lt;/i&gt; extremely under-recognized in our industry.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    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
&lt;/code&gt;&lt;/pre&gt;
Our guy accomplished this via different means but the end result was the same: because of various factors, he became &amp;quot;architect&amp;quot; and essentially was able to make decisions alone. Then we had to live with them.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Eventually he became the architect by virtue of operating in 
    isolation, where we couldn&amp;#x27;t discuss his decisions. Everyone 
    else was forced to work around his code. 
&lt;/code&gt;&lt;/pre&gt;
Yyyyeeeeeeep.&lt;p&gt;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 &amp;quot;10x&amp;quot; coder in terms of raw talent. Call him perhaps a &amp;quot;1.2x&amp;quot; or &amp;quot;1.5x&amp;quot; in terms of raw talent.&lt;p&gt;However, he was essentially able to operate as something like a &amp;quot;10x&amp;quot; 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.&lt;p&gt;Whether or not you believe there are legitimate &amp;quot;10x&amp;quot; engineers (we&amp;#x27;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.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Worse yet, having someone like that on the team drives away other great employees.
&lt;/code&gt;&lt;/pre&gt;
Yes. Two big reasons.&lt;p&gt;1. It&amp;#x27;s not a good way to make software, obviously. Great employees want to make great software and will be frustrated.&lt;p&gt;2. It&amp;#x27;s career fucking suicide to work under somebody like that. It&amp;#x27;s &lt;i&gt;impossible&lt;/i&gt; to shine when working under somebody like that. You can&amp;#x27;t clean up a mess as quickly as other people can create a mess. You just can&amp;#x27;t. With very rare exceptions you simply cannot mop a floor well enough to be seen as something other than a janitor.</text></item><item><author>PragmaticPulp</author><text>I had a similar brilliant engineer with odd working hours at one point. I also had the same problem with other engineers requesting the same odd hours, with equally negative results.&lt;p&gt;In my case, I eventually learned that the odd hours weren&amp;#x27;t the key to his perceived success. 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, because no one else was awake or online at the same time to discuss them.&lt;p&gt;Eventually he became the architect by virtue of operating in isolation, where we couldn&amp;#x27;t discuss his decisions. Everyone else was forced to work around his code. If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor and waste time updating their PRs to match his work.&lt;p&gt;Worse yet, having someone like that on the team drives away other great employees. Eventually everyone else will get sick of accommodating the architects isolated schedule. If they have other opportunities, they&amp;#x27;ll leave.&lt;p&gt;&amp;gt; I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.&lt;p&gt;It&amp;#x27;s not on you. Brilliance and individual productivity aren&amp;#x27;t everything in a team setting. If your project must scale past a single person, you need everyone operating on the same page. It&amp;#x27;s painful in the short term to lose the quirky rockstars, but it makes for a healthier team in the long run.</text></item><item><author>heyflyguy</author><text>I had this exact situation come up with an engineer that I can only call brilliant, with the most conservative of overtones.  He was more than that.  Being a maker myself I gladly encouraged him to work when he wanted, sometimes that meant he&amp;#x27;d work 48 hours straight and sleep for two days and show up Friday.  His 3 days of work (as his peers would describe it), easily was double the quality and output of his closest colleague.  I loved having him on my team.&lt;p&gt;Eventually, other people started asking to work 3 days a week, suggesting that they too would pull all-nighters in an effort to have 2 mid-week days off.  I let a few experiments happen but sadly in most cases the result was less than 50% of what they had been previously able to accomplish.&lt;p&gt;This led to a new merit based working system when we placed emphasis on sprints and achieving.  This too ended up failing because the interconnected dependandcies of sprints were always bottlenecked by the slowest operator.&lt;p&gt;The final result was the eventual departure of my most prized teammate, and mostly due to peer pressure.  I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.</text></item></parent_chain></comment><story><title>Makers, Don&apos;t Let Yourself Be Forced into the &apos;Manager Schedule&apos;</title><url>https://blog.nuclino.com/makers-don-t-let-yourself-be-forced-into-the-manager-schedule</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>hinkley</author><text>I&amp;#x27;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&amp;#x27;t very many 10x engineers but there are a lot of 4x engineers who make everyone else .4x engineers.&lt;p&gt;I was a lot happier and less busy trying to be a 3x engineer making everyone else into 1.5x engineers.</text><parent_chain><item><author>JohnBooty</author><text>Ouch. I used to work with a guy like this.&lt;p&gt;Generally speaking, this is an occurrance that is exceedingly common &lt;i&gt;and&lt;/i&gt; extremely under-recognized in our industry.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    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
&lt;/code&gt;&lt;/pre&gt;
Our guy accomplished this via different means but the end result was the same: because of various factors, he became &amp;quot;architect&amp;quot; and essentially was able to make decisions alone. Then we had to live with them.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Eventually he became the architect by virtue of operating in 
    isolation, where we couldn&amp;#x27;t discuss his decisions. Everyone 
    else was forced to work around his code. 
&lt;/code&gt;&lt;/pre&gt;
Yyyyeeeeeeep.&lt;p&gt;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 &amp;quot;10x&amp;quot; coder in terms of raw talent. Call him perhaps a &amp;quot;1.2x&amp;quot; or &amp;quot;1.5x&amp;quot; in terms of raw talent.&lt;p&gt;However, he was essentially able to operate as something like a &amp;quot;10x&amp;quot; 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.&lt;p&gt;Whether or not you believe there are legitimate &amp;quot;10x&amp;quot; engineers (we&amp;#x27;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.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    Worse yet, having someone like that on the team drives away other great employees.
&lt;/code&gt;&lt;/pre&gt;
Yes. Two big reasons.&lt;p&gt;1. It&amp;#x27;s not a good way to make software, obviously. Great employees want to make great software and will be frustrated.&lt;p&gt;2. It&amp;#x27;s career fucking suicide to work under somebody like that. It&amp;#x27;s &lt;i&gt;impossible&lt;/i&gt; to shine when working under somebody like that. You can&amp;#x27;t clean up a mess as quickly as other people can create a mess. You just can&amp;#x27;t. With very rare exceptions you simply cannot mop a floor well enough to be seen as something other than a janitor.</text></item><item><author>PragmaticPulp</author><text>I had a similar brilliant engineer with odd working hours at one point. I also had the same problem with other engineers requesting the same odd hours, with equally negative results.&lt;p&gt;In my case, I eventually learned that the odd hours weren&amp;#x27;t the key to his perceived success. 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, because no one else was awake or online at the same time to discuss them.&lt;p&gt;Eventually he became the architect by virtue of operating in isolation, where we couldn&amp;#x27;t discuss his decisions. Everyone else was forced to work around his code. If he refactored the codebase in the middle of the night to make his job easier, the other team members were all forced to work around his refactor and waste time updating their PRs to match his work.&lt;p&gt;Worse yet, having someone like that on the team drives away other great employees. Eventually everyone else will get sick of accommodating the architects isolated schedule. If they have other opportunities, they&amp;#x27;ll leave.&lt;p&gt;&amp;gt; I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.&lt;p&gt;It&amp;#x27;s not on you. Brilliance and individual productivity aren&amp;#x27;t everything in a team setting. If your project must scale past a single person, you need everyone operating on the same page. It&amp;#x27;s painful in the short term to lose the quirky rockstars, but it makes for a healthier team in the long run.</text></item><item><author>heyflyguy</author><text>I had this exact situation come up with an engineer that I can only call brilliant, with the most conservative of overtones.  He was more than that.  Being a maker myself I gladly encouraged him to work when he wanted, sometimes that meant he&amp;#x27;d work 48 hours straight and sleep for two days and show up Friday.  His 3 days of work (as his peers would describe it), easily was double the quality and output of his closest colleague.  I loved having him on my team.&lt;p&gt;Eventually, other people started asking to work 3 days a week, suggesting that they too would pull all-nighters in an effort to have 2 mid-week days off.  I let a few experiments happen but sadly in most cases the result was less than 50% of what they had been previously able to accomplish.&lt;p&gt;This led to a new merit based working system when we placed emphasis on sprints and achieving.  This too ended up failing because the interconnected dependandcies of sprints were always bottlenecked by the slowest operator.&lt;p&gt;The final result was the eventual departure of my most prized teammate, and mostly due to peer pressure.  I often think about how I could have better allowed his brilliance while not alienating the rest of his team, but in the end I failed.</text></item></parent_chain></comment><story><title>Makers, Don&apos;t Let Yourself Be Forced into the &apos;Manager Schedule&apos;</title><url>https://blog.nuclino.com/makers-don-t-let-yourself-be-forced-into-the-manager-schedule</url></story>