This post is for my past self — but you'll find it useful.
- Never assume you know best (or better) because you don't: there is always someone with more experience than you.
- Try to understand the other person's point of view, regardless of their perceived skill level: you'll learn something or become a better teacher (by understanding how someone less experienced thinks about a problem).
- In a new codebase, don't try to change anything before understanding why it's there and how all the parts fit together.
- What you are building is not worth anything unless someone uses (or pays) for it.
- Corollary: Letter of intents, or the more common "I'd use (or buy) that", are not worth anything.
- Ideas are not worth shit.
- Never assume you know the problem domain.
- Grasp the problem domain before building any abstractions.
- Pasting code around is fine, especially if you don't have anything working yet. After that, if you find yourself pasting more than a few lines in a few places: consider building an abstraction.
- You don't need to type fast.
- DRY, YAGNI, SOLID, and others are not complete nonsense, but they are often misquoted, misunderstood, and often too general to be useful: don't follow programming principles for the sake of it.
- Good code is code that you can pick up after a year with little friction.
- Corollary: use a boring build system
- Corollary: use a boring language
- Corollary: use a boring framework
- Corollary: use a boring CI/CD pipeline
- Corollary: don't rely on proprietary software (especially if it's VC-funded) for critical parts of your development pipeline.
- Corollary: use Nix (I use Nix btw).
- Architectural Decision Records will be immensely useful if (or when) your software becomes legacy. If what you are building is meant to be short-lived, don't bother.
- Be aware of the Bus Factor.
- Don't pursue code coverage for the sake of code coverage.
- Only test things that might break or would cost a lot to your business should they break.
- Test features, not internal behavior.
- Start with test or code first, it doesn't matter, but write the least possible amount of code before finding a good conceptual model for what you are trying to work. Alternatively, whiteboard can do+ wonders.
- You need to learn how your tools works to get better. You'll also be faster if you know how it works.
- Learn RegEx but never use it for something important.
- Programming is not software development. A great programmer can be a terrible software developer.
- Learn to search.
- Don't assume you can't do something. Try to build it first. You'll likely fail, but you'll learn valuable things along the way, especially navigating uncertainty.