Skip to content

Software Engineering Tips

Tips that I learn from doing a lot of side projects.

💡 In multi-layered architecture, clearly define the scope of each layers. Consider

  • What level of input sanitization and validation should be handled in each layers?
  • Which exceptions are thrown and handled by which layers? at which layers?

💡 Requirement specification prevents the development of unnecessary features, while system design helps avoid rework of existing features. The caveat is, you can't get them right because you will learn new things in the later stage of SDLC.

💡 Testing gives confidence in your new update but slow down velocity by twice or more.

💡 Deliver your MVP fast and fail fast. Think about scaling later.

  • MVP should be minimum, not your first release. Keep it light and don't think about engineering principles. Just get it out, test how features work out, and rewrite everything again.
  • Once MVP is good, implement CI/CD in your next release. It will allow to deploy new updates and revert quickly.

💡 People waste more time trying to not waste time. It's better to waste some time than not getting anything done. Just be reasonable by balancing business value with engineering practice.

💡 Document is useful only when working with large team. If you are in small team, don't worry about it.

  • It slow down development.
  • Instead write clean code and good comments.

💡 Lazy decision stacks together and come as a slow but big wave. You have to continously fight with lazy decisions if to maintain a level of engineering practice.

  • If you decide to be lazy twice, then accept it will need refactor in future.

💡 Structured configuration often comes in very helpful, than flat environment variables.

💡 Your application and docker image should be stateless. You have database and storage to keep state of your app. Only thing that is stateful should be cache.

💡 Be flexible. Accept that bad engineering design might be best design in a situation.

  • There are not many concepts that work for all.
  • Take a concept as one perspective instead of defined rule, including this very page.