The 10x dominates the tools ( and techniques and people and capital) that multiply her.
If you have a car you can easily and consistently go 10x faster that walking pace. The same applies for your job.
Working on a given company, with access to capital and people and tools can multiply you.
- Person A gets assigned a bug, that there is a memory leak in the library, they are familiar with the code, they open up the profiler, see that there's an excess of Object X, they look for all the allocations, and see that it's not freed in one of 3 places. Whereas Person B does not really have a really good grasp on how either a library or the profiling tools work and mulls around, perhaps has to ask for help, and takes a lot more time.
- A is confronted with an algorithmic challenge, they figure out an elegant solution in 1 hour, they think it through really well, the solution is flawless the first time. B takes more time, say 2x, and still are not sure in the solution. They implement it nevertheless, and pass it onto QA, who finds bugs, and the issue needs to be reconstructed, the code rewritten and retested. These things compound and add up.
- Writing tools instead of doing things manually as others have pointed out
- Using a library meant to solve a problem instead of rolling your own
All these things are based on concrete experiences that happened to people around me.
10x is systems for the system, including good judgment
The difference isn't in quantity, but imo rather in mentality. Relentlessly automating repeatable tasks can net 100x or 2x or 0.5x depending on context, but something that don't happen often enough.
I believe this is incorrect. The baseline (or 1x) is the lowest-performing member of the team. At least that's how I learned the term.
I’ve always internalized as a “typical, competent programmer” rather than team-specific anything (Peopleware’s definition notwithstanding).
A negative number. A 0.1x programmer gets work done acceptably but is slow.
A negative programmer on the other hand creates more work for other people to fix, and you’d be better off not having them touch the code at all.
Libraries instead of cutting your own code for everything.
Effective searching for projects who have already done the thing you’re about to do.
Sometimes: it’s as simple as taking a day or few days to think the problem through to ensure you really understand it.
Finding a way to deliver the needed functionality in Excel/Sheets instead of a custom application.
With some gentle pushback on requirements they can help clarify what the real issue is. Of course, this has to be done carefully or it will quickly get very annoying.
Another useful skill is to have a feeling for when problems get too hard and it's time to backtrack. At least in my work, most of it is basic CRUD of different varieties. If I find myself inventing new things or not finding any answers Googling my problem, it's likely that I'm on the wrong track and there is a simpler path I missed.
All the biggest and most important productivity and outcome enhancing things I've done at work have been done without management knowledge or approval.