3 ms·
> A true "10x" engineer raises up the team by 10x by doing the things a lot of devs hate doing - docs, mentoring, guidance (without taking over someone's featur
by username90 7y ago
> A true "10x" engineer raises up the team by 10x by doing the things a lot of devs hate doing - docs, mentoring, guidance (without taking over someone's feature), and knowledge sharing. Not shipping :all-the-things: on their own.
That is gate-keeping, a person who could replace a team is 10x no matter if he is super helpful to slower developers or not. Of course you'd prefer to work with the guy who makes you look better instead of the guy who makes you look bad, but both are still 10x. However a person who just wants some development work done would prefer to work with a single 10x over trying to organize a whole team, a single guy will be more agile and much easier to communicate with while trying to get 10 persons to pull in the same direction is a monumental task. In that environment it doesn't matter if the dev can help slower devs or not, all that matters is that he can communicate with stake holders and users about requirements.
Development is a team sport, yes, but it is a team sport where some people can act as a whole team on their own.
- mugsie 7y ago> 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 replace a team Doesn't exist. > However a person who just wants some development work done would prefer to work with a single 10x over trying to organize a whole team, a single guy will be more agile and much easier to communicate with... A person "who just wants development work done" may well prefer a single developer, but it is not sustainable in the long run. That one 10x dev needs vacation, family/friends, sick leave, and career progression at some point. > Development is a team sport, yes, but it is a team sport where some people can act as a whole team on their own. Nope, not for any product that will last longer than a year, is anyway complex, or has more than one timezones worth of usage.
- username90 7y agoI 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 agoLet 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.