Principles
- No Ego-Driven-Development
- Absolutely nobody cares that you used a recursive descent parser in a pure functional immutable way in order to read a config file.
- If you want to show off your programming prowess, do not burden your team members with your unintelligible results. In the best case, you'll get push-back from team members that you should change it, resulting in double work. In the worst case, people actually believe you are a programming god and won't dare to question you.
- Also, you won't understand your own glorious creation a few months down the road when inevitably bugs arise and only you are the programming god that can solve them. Which you aren't.
- Don't abstract a future you don't know
- Don't design architectures or code for all the possible use cases that might arise in the future. You don't know the future.
- When you start duplicating code and it proves painful, abstract. Don't abstract just because you duplicated code once.
- Just because a framework, library, or ecosystem is old doesn't mean it is bad
- It means that it has stood the test of time and has seen a lot of usage.
- That cannot be said of the latest VC-funded micro-SSR-turbo-framework with Go-compiler-pipeline and flashy website.
- Tools are a means, not a goal
- It's super great that you are fluent in NeoVim and write tons of macros for it. Just learn it in your own time.
- Learn a tool that works for you and stick with it.
- Your identity is not your stack
- You are not a React dev, or a Rust dev, or a Spring developer. You are a builder.
- Learn the basics of what your new favorite framework abstracts
- When using full-stack frameworks with ORMs and SSR and whatnot, try to learn what they abstract. SQL? HTTP? Caching? Auth?
- Nothing has fundamentally changed in most foundations of software development. The new shiny framework is just a new iteration of the basics.
- You'll find out that most stuff is made complicated by frameworks precisely because they want to abstract every possible use case of every user in the future.
- Code will always be messy
- Even with guidelines and standards, code will be messy because we communicate messily.
- Learn to cope with messiness.
- Don't propose a rebuild because stuff is messy. You will create a new mess. Instead, tidy up when you can.
- Don't overinflate your scale
- Chances are your app is not Netflix/Shopify/CashApp/whatever. Solve the real problem in front of you, not the imagined future where your app scales to a billion users with a plugin system written in WASM.
- We are not in the 90's anymore. Hardware is fast. Fast enough for 99% of use cases.
- Rewriting is ego, not progress
- Wanting to do a rewrite is often ego, or insecurity, talking.
- If you don't understand a codebase, you also don't know what to rebuild.
- Instead, try to gradually fix the pain points.
- The 10x engineers on Twitter/YouTube/whatever
- If their livelihood depends on Twitter/Youtube/whatever, they have a different agenda than you.
- The "stack I am going to use for 'my next SaaS'" short is for clicks. Building one fullstack TodoList app isn't a SaaS.
- A SaaS is a multi-year commitment including maintenance and support.
- Learn to read documentation
- If you can spend 10 minutes vibe coding your way to a solution, you can spend 10 minutes reading docs and actually understanding.
- Reading documentation helps you understand the tool's intended use cases, limitations, and best practices. It will make you use the tool in a more efficient manner.
- If a tool or framework has crappy docs, it is a warning sign. Good documentation indicates a mature project with a community that cares about developer experience.