While the author is known (technical coach at Facebook, creator of XP software methodology), I sort of disagree.
You can follow this guide and still be a low value programmer. This guide won't take you to mastery level.
And, there is also a sense of irresponsibility around one item: "easy changes". Easy changes as in, duct tape programming? That's pretty much turning your project into a Jenga tower... you add your "easy change", that incurs technical debt, fix a problem... but lower productivity for following changes. Also sets a bad example for other people to follow.
The step before the "easy change" is "make change easy". This usually includes refactoring and paying off technical debt.
Anecdote from one great programmer I know: When he fixed a single bug, it often came split into multiple commits. First, a few commits refactoring and cleaning up things. Then one tiny commit fixing the bug. Finally, one more commit removing now-obsolete stuff.
You can follow this guide and still be a low value programmer. This guide won't take you to mastery level.
And, there is also a sense of irresponsibility around one item: "easy changes". Easy changes as in, duct tape programming? That's pretty much turning your project into a Jenga tower... you add your "easy change", that incurs technical debt, fix a problem... but lower productivity for following changes. Also sets a bad example for other people to follow.