There are so many factors at play in team and client environments, so the best benchmark to use is your own productivity as a programmer.
1. Solving problems for the Nth time instead of the first leads to substantial gains in productivity, easily 10X gains on your first attempt.
2. Architectural decisions add another multiplier on the above: picking the wrong database type, structuring and reorganising your models, spending time to design ahead vs coding right away, all can /10 or 10X your project easily from fixes and re-dos alone - combine both 1 and 2, and you have potential 100X gains.
3. Risk-distributing the project work: eliminating the worst 5% as the author says, and/or writing the most complex parts first to reduce risk of massive rewrites in case something doesn't meet expectations in its most critical functionality.
4. Having competent business requirements providers who won't move the ground beneath your feet. You can be 10X or 100X more productive when writing new code, and that much slower when rewriting someone else's bad decisions. It's no different than trying to build a skyscraper on foundations built for a garage.
Stack the above as A x B x C x D and you can see why you might be able to beat your past self 10X or 100X and more between projects. Having teammates who can beat you is even better if you can learn from them and accelerate your own progress by skipping time consuming mistakes.
1. Solving problems for the Nth time instead of the first leads to substantial gains in productivity, easily 10X gains on your first attempt.
2. Architectural decisions add another multiplier on the above: picking the wrong database type, structuring and reorganising your models, spending time to design ahead vs coding right away, all can /10 or 10X your project easily from fixes and re-dos alone - combine both 1 and 2, and you have potential 100X gains.
3. Risk-distributing the project work: eliminating the worst 5% as the author says, and/or writing the most complex parts first to reduce risk of massive rewrites in case something doesn't meet expectations in its most critical functionality.
4. Having competent business requirements providers who won't move the ground beneath your feet. You can be 10X or 100X more productive when writing new code, and that much slower when rewriting someone else's bad decisions. It's no different than trying to build a skyscraper on foundations built for a garage.
Stack the above as A x B x C x D and you can see why you might be able to beat your past self 10X or 100X and more between projects. Having teammates who can beat you is even better if you can learn from them and accelerate your own progress by skipping time consuming mistakes.