@npub1hxf…mg8qu @npub1z0l…c30ke
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
