4 ms·
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 v
by partycoder 10y ago
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.
- qznc 10y agoThe 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.
- caconym_ 10y agoDid you only read the bold text? This is very different from "duct tape programming": > When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change
- partycoder 10y agoGiven the fact that duct tape programming is what the majority of people do nowadays, I would be more explicit about what an "easy change" means.