In addition to Scott’s and many, many other 10x Developer posts here are opinions from someone labeled ‘hyper-productive’ on most projects.
- 10x is a zone we enter at times, it cannot be sustained
- 10x has historically (in Mythical Man Month etc) meant the difference between worst and best developers
- Being 10x better than average is a rare occurrence with short duration
- 10x zone is only achieved after months or years perfecting required skills/ preparing conditions for the highly productive period to commence
- Many important tasks take very similar amount of times regardless of the individual – e.g. attending the daily stand up, liaising with another department, manual testing etc.
Common Characteristics of being ‘in the 10x zone’
- Task that does not lend itself to parallelism – efficiency is gained from reducing communication etc.
- Full stack developer avoids need to interface with knowledge silos – this is a common with hyper-productive developers but often leads to resentment from the team unless great care/preparation is taken to handle political backlash
- Using a library/ technique highly suited to task at hand – a great example is deserializing/ serializing xml by hand vs. employing a tool like xsd.exe or JAXB. Many thousands of lines vs. a trivial library call can lead to man-months of saved effort
- Already familiar with business/ technical problem – second time around is always faster. By the third time most problems are solved many times faster
- Bust through politics – obtain access to all systems, and are shielded from political backlash of stepping on toes
10x Projects are a far Bigger Deal
Over the years I have seen around fifty projects. Excluding the really crazy ones 5->10x is a rough measure for the difference in productivity we see at the project level. More if operational problem are factored in; too many systems are moved to production before being fully stable. Many projects fail, so technically there is an infinite difference in productivity. 5-10x is a rough approximation between ones that make it to production.
Common Characteristics of very inefficient Projects
- Too many people – and/or too many of the wrong people
- Cumbersome, un-enjoyable process
- Developers treated as commodities – no praise for quality work
- Rude, non-technical leadership
- Best developers flee the project
Anyone with a few software development projects under their belt knows the main issues that lead to poor projects. Unfortunately after all my years in software development I am now of the opinion that many are inefficient intentionally by design. Yes, the leadership team actually desires this! Many managers long for very large teams. Root cause appears to be Empire Building; a larger team brings the manager/director more power. Many resist promoting others that could potentially challenge them, and several times I have witnessed life being made difficult for quality individuals with the sole intention of forcing them off the project. As time progresses leadership weakens and it can decimate large companies, especially during tough economic times.
Obviously there is a massive productivity difference between the best and worst developers. That does not mean someone highly productive on Project A will immediately be highly productive on Project B.
A badly run project can cripple even the best individual’s ability to do great work. This is of far greater importance than bickering about if one developer is actually 10x or not. One great developer is just one great developer with a limited skill-set. The team wins the war, great developers are often decisive in key battles but they cannot win wars alone.
Developers have specialties. Personally I still struggle until up to speed with a new technology – it takes time and hard work to be ‘10x’ again with new technologies.