Software engineering is an activity to produce an output, to fulfill a "job to be done". Focusing on things with the bigger impact, and these change and are specific.
I know what "general" actions I would do if I were to start a new project based on pain points we have suffered through many projects, and that saved us a bunch of time and morale down the road:
- Include monitoring for errors and system's health, and analytics for user behavior: I shouldn't dig through logs to see an exception (Sentry). I should look at one dashboard and have an idea on which systems are up or down, metrics, load, latency, etc. (Prometheus and Grafana). I should know how users are interacting with the product, where they are failing and succeeding (PostHog).
- Add communication channels to interact with users into the product (issue template, Slack, something, email): asking users about which ways the product failed to solve their problem.
- Use a plug-in architecture in order to easily add and, more importantly, remove functionality easily. It makes testing ideas easier: easily introduce a feature, and as easily kill it without rewriting the whole codebase.
- Make functionality accessible through APIs (one guideline we have is that everything should be accessible through an API call). Have an SDK for the main language first to simplify this.
- Document everything. An issue is closed if there has been a test written for the bug, or it's documented somewhere so anyone has access to it.
- Align everyone: through written communication accessible anytime by anyone. Communication should tie objectives to actions and penetrate several abstraction levels and be consumable by advisors, board members, non-technical people, technical people. Call it "fractal communication" that still makes sense from any abstration level you read it. This enables everyone on the team to chime in at the abstraction level they're comfortable with. You write an email that ties objectives on say, revenues, in a language that speaks to some, and then tie it back to specific activities, an issue in the issue tracker, and a line of code, so that everyone sees how things fit together and are intertwined. Everyone knows what to do and why they're doing what they're doing. They can come up with ideas or correct assumptions or mistakes.
- Have issue templates for incidents, features, improvements, and bugs: this reduces the "activation energy" to writing good issues. It beats having a blank screen and reduces variance in issue quality.
These are just a few points.