Here's a non-exhaustive list of rules of thumb I generally go by when it comes to software development:
-
Automate coding preferences with a linter
- Using something like Clang-Tidy in C++ will save a lot of developer time. It helps establish consensus among developers about good coding practices, reduces cognitive strain, saves time in pull requests, and ultimately avoids a bunch of errors way before they happen. Good practices evolve, and a linter can stay more current than individual developers.
-
Professional coding is a means to an end, accept imperfection
- Changing deadlines, rotating personnel, illnesses, market conditions, and more - all mean you'll never create the perfect app you envision. What matters is you deliver to the best standard you can with the cards you've been dealt.
-
You only know roughly what a successful app looks like, your users will confirm that for you. So release your beta version ASAP
- It's crucial to have a trusted group of beta testers. Remember, they are ultimately your boss, so make sure they're happy. Share with and listen to them keenly.
-
Only develop the bits where you add the most value. Remove, reduce, or outsource the rest
- Making a product is hard. The chances you're going to be better than the competition in every aspect is extremely low. By focusing on your unique strengths, you can identify your niche market. As you grow it will become more reasonable to plug your weaknesses. In the meantime use libraries, simplify the architecture, and reduce the product scope whenever you can reasonably do so.
-
A good team is greater than the sum of its parts
- If your team is happy, trusted, and can comfortably socialise with one another, you will develop a great product and enjoy the journey to get there. This resilience helps mitigate the impact of team member turnover, as knowledge tends to be shared more proactively.
-
There's no substitute for good developers
- No amount of documentation, automation, testing, or training courses will stop bugs from creeping in. If so, hiring developers wouldn't be necessary; rule followers would suffice. Coders need to understand context well, find simple/elegant solutions, work fast, and avoid silly mistakes.
-
Automate as much as you can
- That means testing, deployment, emails, notifications, builds, etc... Investing a few hours in automating a task that takes 20 minutes daily can yield quick returns.
-
Testing is extremely important, but know the limits and use them appropriately
- Not all tests are equal. Unit tests are quick to develop, but may not tell you if the whole system works. End to end tests give you confidence the whole system is behaving, but they are slower to execute. QA testers closely mimic real-world usage, yet they have specific usage patterns and may overlook various bugs. The ultimate test is giving it to the end user, but this can't be overused unless you want to annoy them. And most importantly, 100% passing tests never means 0 bugs.
-
Don't think too short-term, or too long-term: plan for the medium-term
- If you think too short-term, technical debt stacks up and coding becomes a nightmare very quickly. The product will descend into chaos. Focusing too much on the long-term can lead to your product becoming outdated, irrelevant, or even running out of funding. It will vary between products, and your financial situation, but think in terms of the next 6-12 months if you can, and err on a slightly shorter length of time if unsure.