You raise a lot of great points. It's interesting, I've learned a lot about what works at scale when you have thousands of engineers and by practicing some of

You raise a lot of great points. It's interesting, I've learned a lot about what works at scale when you have thousands of engineers and by practicing some of those techniques on side projects I've learned what doesn't work when you have less than 10 engineers. > For instance, micro services and an extremely complex distributed architecture will add a lot of overhead and points of failure when a monolith is probably the best route when you have a few engineers. In a startup implementation speed is usually the most important aspect of your development project. Hacking usually trumps engineering in terms of value-add to your infant company. This is on point. The real question is -- will I learn the best technique for writing code in a monolith that lends itself to being converted to a microservice architecture.