A lot of the text is good advice for any project, not just programming. Whatever you’re working on, if it’s meaningful, should have a simple and definite scope, and clear priorities. Even it’s something like oil painting, pepper breeding, or a cardboard war tank for your cat.
A few additional tidbits. Not contradicting the text itself, but things people often get wrong about this sort of advice.
Constraints are advantages
Only to the point they force you to prioritise. You can’t really give someone raw dough and say “we were making bread under a time constrain”.
Ignore feature requests — don’t build what users ask for; understand the underlying problem instead
This does NOT mean “be an assumptive piece of shit”. You do not know what the user “wants” or “needs”, nor you should lie you do. It means instead you should look at what your project does versus what it should be doing, see if they mismatch, and address that mismatch.
Ship early, ship often — a half-product that’s real beats a perfect product that’s vaporware
This does not mean “user time is worthless trash, might as well use those things as unpaid beta testers”. Or “it’s fine to release broken shit”. It means instead “be reasonable with your expectations of perfection, and take diminishing returns into account”.
A lot of the text is good advice for any project, not just programming. Whatever you’re working on, if it’s meaningful, should have a simple and definite scope, and clear priorities. Even it’s something like oil painting, pepper breeding, or a cardboard war tank for your cat.
A few additional tidbits. Not contradicting the text itself, but things people often get wrong about this sort of advice.
Only to the point they force you to prioritise. You can’t really give someone raw dough and say “we were making bread under a time constrain”.
This does NOT mean “be an assumptive piece of shit”. You do not know what the user “wants” or “needs”, nor you should lie you do. It means instead you should look at what your project does versus what it should be doing, see if they mismatch, and address that mismatch.
This does not mean “user time is worthless trash, might as well use those things as unpaid beta testers”. Or “it’s fine to release broken shit”. It means instead “be reasonable with your expectations of perfection, and take diminishing returns into account”.