4 ms·

> That is gate-keeping Lol wut? The entire 10x meme is gatekeeping, this is about including more people than Rockstar DevOps SRE Ninjas. > a person who could

• username90 7y ago
  I see you are focusing too much on your own problem space where you need people ready to fix fires any time in the day and you need to ensure that you have people who can fix fires for years to come. In that environment you need replaceable cogs, then I agree that 10x engineers can't fill that role since you can't get a steady supply of them. 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. Writing solid libraries is useful everywhere, since it can make work easier for the rest of the organization and such. Forcing people to only hire replaceable cogs and ignoring that some developers can be vastly more productive is therefore counter productive, even in organizations which mostly need replaceable cogs.
  • 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.