4 ms·

> I see you are focusing too much on your own problem space I have worked in many problem spaces, and what I have said stands for all of them. > I agree that

by mugsie 7y ago

> I see you are focusing too much on your own problem space I have worked in many problem spaces, and what I have said stands for all of them. > I agree that 10x engineers can't fill that role since you can't get a steady supply of them. 10x engineers definitely can, just not Lone Ranger style mavericks that poison teams, or "replace teams" > Then it is better to have an extremely good team build a good solution I 100% agree. key work in that sentence is team > However in an environment where you are writing solid libraries which are not meant to break or change much and therefore wont need much maintenance the requirements are very different. Then it is better to have an extremely good team build a good solution once and then ship it and then mostly leave it alone. Very little code these days is write, compile and ship once. Compilers, runtimes, interpreters, base libraries, kernels, OSes, CPUs, and tooling all change. Unless you are deploying to a main frame that is slated to run for the next 40 years, all of these changes require updates to code, and that isn't even accounting for security issues (how many companies do you think were frantically trying to recompile programs with retpoline mitigations? How many "run once" pieces of software had to be recompiled with updated OpenSSL after Heartbleed?) > ignoring that some developers can be vastly more productive is therefore counter productive, So is discounting the harm they can cause, or the opportunity cost of them not lifting up their teammates.

username90 7y ago
Let me explain what my job is at Google: I work in a larger team, but I always solve problems alone. When others have failed to solve something important they give it to me, and I always solve it quicker than them putting a team of staff-engineers on it would. Often my solutions are good enough that they make the whole team pivot in a different direction since it solves many problems for the wider organization. I often design new architectures in doing so, build frameworks etc which others then use. Note that I am relatively new on the team, so it is not that I designed things which others don't understand. Instead I came in, started fixing a lot of shit and my responsibilities just grew. The most senior engineers on the level of senior directors noticed that I could fix a lot of things others couldn't so I get tasked with solving large problems which are blocking a lot of other efforts. Almost always it involves cleaning up bad architecture and implementing something which allows us to solve more problems. There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me. Would you say that having me on the team is bad? Am I toxic? I think I wouldn't fit into a lot of teams, but I still think that I can help a lot. If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done.
- mugsie 7y ago
  > Would you say that having me on the team is bad? Am I toxic? Without knowing you, or your team, I can't know. I have worked with people like this before, (and done it myself on a few teams), and it is a mixed bag. > There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me. Again, I don't know your team, but I would doubt there is no-one on your team you can teach. Pairing is not what I was talking - I personally really dislike it, and it doesn't suit me either. Designing a solution, and helping teammate(s) through implementation of the designs is valuable in this context, and helps lift up other team members. > If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done. No one is a perfect engineer - the solution you design might not have been produced, but this team existed before you joined, and most likely will after you leave, and it produced solutions. > Note that I am relatively new on the team .. This is a key point - I have done things before that were great solutions / libraries that others could use, so I didn't sink much time into docs / comments in the code. No one would need to change the library, just the config and stuff calling it. Which was true for about 2.5 years, at which point we needed to update what should have been something minor. cue me spending a week trying to understand my own code, after someone else tried and gave up. Time is the real judge of how much impact someone has on a team, and which direction it is in.
  - username90 7y ago
    Your judgement doesn't really matter in this situation, the distinguished engineer and the rest of our senior team thinks I am doing an awesome job and they review my changelists and design docs. But I realize there is not much I can do to convince you, in your mind I don't exist so you try to find alternate explanations for everything. > Again, I don't know your team, but I would doubt there is no-one on your team you can teach. What would I teach them? I can go into an unknown codebase in a new domain and solve problems quicker and cleaner than the team who wrote the code. There is no secret knowledge I posses, no bag of tricks I apply, I just see the code, figure out what happens and solve it. If I could reliably teach that to people then I could become the richest man on earth. My skills are good enough to reach a decent position as an IC, nothing to brag about really, but they aren't worthless either.

by mugsie 7y ago

username90 7y ago

Let me explain what my job is at Google: I work in a larger team, but I always solve problems alone. When others have failed to solve something important they give it to me, and I always solve it quicker than them putting a team of staff-engineers on it would. Often my solutions are good enough that they make the whole team pivot in a different direction since it solves many problems for the wider organization. I often design new architectures in doing so, build frameworks etc which others then use. Note that I am relatively new on the team, so it is not that I designed things which others don't understand. Instead I came in, started fixing a lot of shit and my responsibilities just grew. The most senior engineers on the level of senior directors noticed that I could fix a lot of things others couldn't so I get tasked with solving large problems which are blocking a lot of other efforts. Almost always it involves cleaning up bad architecture and implementing something which allows us to solve more problems. There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me. Would you say that having me on the team is bad? Am I toxic? I think I wouldn't fit into a lot of teams, but I still think that I can help a lot. If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done.

mugsie 7y ago
> Would you say that having me on the team is bad? Am I toxic? Without knowing you, or your team, I can't know. I have worked with people like this before, (and done it myself on a few teams), and it is a mixed bag. > There is no point in pairing me with others, I can't teach them to work like me. However I can teach them to work with the code I wrote, but not to actually solve problems like me. Again, I don't know your team, but I would doubt there is no-one on your team you can teach. Pairing is not what I was talking - I personally really dislike it, and it doesn't suit me either. Designing a solution, and helping teammate(s) through implementation of the designs is valuable in this context, and helps lift up other team members. > If I weren't here they would need to put teams of people to achieve the same or worse results as me, or the work simply wouldn't have been done. No one is a perfect engineer - the solution you design might not have been produced, but this team existed before you joined, and most likely will after you leave, and it produced solutions. > Note that I am relatively new on the team .. This is a key point - I have done things before that were great solutions / libraries that others could use, so I didn't sink much time into docs / comments in the code. No one would need to change the library, just the config and stuff calling it. Which was true for about 2.5 years, at which point we needed to update what should have been something minor. cue me spending a week trying to understand my own code, after someone else tried and gave up. Time is the real judge of how much impact someone has on a team, and which direction it is in.
- username90 7y ago
  Your judgement doesn't really matter in this situation, the distinguished engineer and the rest of our senior team thinks I am doing an awesome job and they review my changelists and design docs. But I realize there is not much I can do to convince you, in your mind I don't exist so you try to find alternate explanations for everything. > Again, I don't know your team, but I would doubt there is no-one on your team you can teach. What would I teach them? I can go into an unknown codebase in a new domain and solve problems quicker and cleaner than the team who wrote the code. There is no secret knowledge I posses, no bag of tricks I apply, I just see the code, figure out what happens and solve it. If I could reliably teach that to people then I could become the richest man on earth. My skills are good enough to reach a decent position as an IC, nothing to brag about really, but they aren't worthless either.