Tim Chase on Nostr: nprofile1q…6eyyt nprofile1q…eqvjw Things that have gone well: - optimize code for ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqhxf96n4sv94q46mrk29xquqwewwecl2083f9r5wdlnl5erc5nf7qf6eyyt (nprofile…eyyt) nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqz0ln8zjc4rvdqn257wg82n7ecpnfkgcpl50e4tscvyg5j7kwgf0syeqvjw (nprofile…qvjw)
Things that have gone well:
- optimize code for readability first. You revisit both your own and others' code far more than you want to; this can entail good code architecture and keeping things fairly DRY (and understanding when code-deduplication is detrimental rather than productive)
- don't chase the latest and greatest—the ol' reliables (SQL, vanilla JS, Python/Ruby, Linux/BSD, standard library) work quite nicely with less churn
- use a good distributed version control like git, fossil, or mercurial (svn is passable if you absolutely must, but so many places just version in .zip files or VSS or the like)
- use good version-control practices. Atomic per-concept commits with useful descriptions, not commits that touch lots of unrelated things and "asdfg" comments
- avoid proprietary tech if you can—they'll raise prices, change terms & conditions, drop features, or otherwise take their roadmap where the money is, not where your roadmap is
- similarly, on-prem architecture gives a lot of benefits for known loads (see recent DHH articles) and also keeps things within your roadmap not theirs
- include security & accessibility in product designs from the start. It's MUCH harder to retrofit them in later in development
Things that have gone well:
- optimize code for readability first. You revisit both your own and others' code far more than you want to; this can entail good code architecture and keeping things fairly DRY (and understanding when code-deduplication is detrimental rather than productive)
- don't chase the latest and greatest—the ol' reliables (SQL, vanilla JS, Python/Ruby, Linux/BSD, standard library) work quite nicely with less churn
- use a good distributed version control like git, fossil, or mercurial (svn is passable if you absolutely must, but so many places just version in .zip files or VSS or the like)
- use good version-control practices. Atomic per-concept commits with useful descriptions, not commits that touch lots of unrelated things and "asdfg" comments
- avoid proprietary tech if you can—they'll raise prices, change terms & conditions, drop features, or otherwise take their roadmap where the money is, not where your roadmap is
- similarly, on-prem architecture gives a lot of benefits for known loads (see recent DHH articles) and also keeps things within your roadmap not theirs
- include security & accessibility in product designs from the start. It's MUCH harder to retrofit them in later in development