It's so weird to see so many people argue so hard that the Usain Bolt's of the programming world simply cannot / should not exist.
Development - team sport. You could put Messi on my company's 5 a side lunch time team, and we still wouldn't win the champions league, and the skill of the others on the team would atrophy, and they would become over reliant on a single person. Not a great thing for a team.
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.
One of my assertions is that Messi hasn't proven himself to be a GOAT until he's been great somewhere else. It's easy* to perform at a high level when the entire team is built around you as at Barcelona. In non-Messi-specific environments (ie Argentina national team), he just doesn't perform as well.
Whereas Ronaldo, on the other hand, has done it in several distinct environments and elevated the teams he's been in (which I guess makes him a "true" 10x player?)
The original 10x term was about productivity (and namely, lines of code that is pretty much bunk).
For me is always about what is a 1x developer. If we consider them a professional developer that does their tasks (somewhat) on time, documented, and with minimal bugs, which I would consider the baseline for what I would call a professional developer, I have a strong opinion you won't find 10x developers compared to this.
On the other hand, if a 1x developer is a person that can't create a simple algorithm(fizzbuzz), copy pasts code from every possible source, including his own code from file A to file B, etc etc, then sure, 10x developers are there, but this is because we set the bar too low.
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.
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.
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.
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.
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.
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.
> 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.
I would trust that a DE in GOOG knows how to leverage their team in the most efficient / useful way.
My point isn't that very smart / productive engineers don't exist (they definitely do), but that the meme of the dev in the corner who sits in the dark, and spews out golden code, without talking to anyone else on the team is actively harmful for our industry, especially in the smaller startup R&D teams that the current batch of publicity about them comes from.
- Be good (and fast) at Googling things.
- Know your foundations, deeply. Don't memorize design patterns and algorithms: instead, learn how to arrive at them organically and how to analyse and understand them.
- Avoid overengineering like the plague and stop seeking perfection. I've seen lots of teams of "1x" engineers fail because they're too worried about peer approval, so they end up trying too hard to arrive at the "perfect" solution. And then business changes its mind and they have to rearchitect everything.
- Accept that business people will change their minds and design your software around it. The world doesn't revolve around your precious codebase. If the higher ups want to change something, you have to do it. Your codebase should have been malleable enough for a 180 degree pivot.
- Stop chasing unicorns. Yeah, maybe Vim will give you that extra 10% edge you need, but if you're comfortable with Atom, why change?
- Keep it simple, don't be clever. Only use the subset of the programming language that is free of "gotchas". What's the output of `[].push(1)` in ES6? Who gives a shit? Keep that stuff out of your code.
- Learn to evaluate if using an external dependency is actually faster than writing something from scratch or just copying some code. Sometimes it isn't, and people miss out on having simpler code, simpler interfaces AND learning new stuff because of that. Of course, you're not going to do that with a crypto
- Avoid things that might slow you down. The CI taking 30 minutes to run or the compilation taking 10 minutes are a sign that you're doing something very wrong and too complicated.
--
As for practical recommendations:
- A single integration test is better than multiple disconnected unit tests that have the same coverage. It allows you to change your code without changing the tests.
- Avoid transitive dependencies in your classes/functions by using simple Dependency Injection. Just pass those dependencies as a parameter or whatever. This will help you have units of code that are more testable, more flexible and don't require maintenance. Also you don't need those mock-in
- Make code simpler to read and to debug. Avoid reflection, metaprogramming and stuff like that. Don't do things that require magic.
This is a lot of extra work, but it meant that I always had an extremely strong foundation to stand on. When I know something I really know it, and having learned this way since early school I have spent a really long time doing it so it covers quite a lot.
Also when you learn this way you don't forget, so it just compounds. There is no way a person who "cheated" by implementing for example algorithms and data structures without deriving things themselves can compete. They have spent their entire lives learning how to apply things without understanding, they would have to redo all of that to catch up.
When you know things this well then being much faster than others is not very hard. Also creating original solutions is not something scary or time consuming, it is something you've done throughout your entire life.
Anyhow, I am not sure if others can learn this way, I just know it works for me. I've tried teaching others to do it, but it didn't work that well. It might be that it was too late, I just naturally learned mathematics this way from early school so I already knew how to think about algorithms before I even started programming. I mean, calculating things by hand or in your head are the original algorithms so if you can confidently alter those as you wish then you already know the basics of programming.
A 10x engineer is just a workhorse who happens to know enough of everything to be truly useful wherever. I like to call them "glue engineers" instead because it's a little more friendly to the team setting. They do exist, though.
If someone is a Usain Bolt of software development though, they probably are someone who should be guided into, or are in, a senior engineering role. Glue Engineers / Smokejumpers / problem solvers are different, and useful, but when companies become over reliant on them it is an issue. And no matter how productive they are, they should be held to the same standards as other engineers.
It's hard to argue against excellent programmers, statistically they must exist. All this work identifying them and the qualities is a bit silly when it's hard to even define the term.
A runner is doing everything you'd be doing running, but more, and can achieve far greater speeds that you ever can.
I agree that it's weird, and to me it's also a delusion.
As a delusion, though, it also has a function. Most of the people will never meet outliers in their field, and this will protect their self-esteem with the thought that the outliers don't exist, can't exist or that those skills can be reached with enough effort.
If the connection success was disconnected from identity, then there would be no need for this delusion, since admitting that somebody could be immensely better in a certain field wouldn't hurt self-esteem.