Thread

As developers we have a tendency to project our experiences onto some general rules: static methods are bad, you must follow TDD, ORMs are shit, SQL is shit etc. but we often forget that developing software is very different depending on the constraints and goals. 1/8

While using feature branches and pull requests may not be the best idea in product development where time to market and fast iterations is the key, it is a great fit for open source projects. 2/8

While TDD will likely help you with better design and less bugs it may slow you down with a proof of concept that is meant just to validate an assumption. 3/8

While Go can perform very well and consume less resources it may take way longer to implement it in Go as your team is not skilled with it. 4/8

Just because microservices worked in your previous job it doesn't mean they are going to work in the new one if the new team is not skilled enough. 5/8

Microfrontends can perhaps serve well in well structured companies where teams are stable and their independence is the key but ask yourself first if your organisation is like that. 6/8

In general websites should work in every browser but maybe it's ok to support only one if it's an internal app used by 5 people in your company. 7/8

To summarize: the context matters, there are very few always applicable general rules. One of them is: keep it simple. 8/8