In part 1 of this 2 part blog we looked at some common engineering tradeoffs. But how might someone navigate these tradeoffs and build a model that works for their product? Here are some core concepts that can help along the way.
Tradeoff: a balance achieved between two desirable but incompatible features; a compromise. Schooling often promotes the idea that there is a right and wrong answer to questions… It does little to prepare us for how many times that there are multiple right answers and no definitive best path forward. In a time where we have unlimited information at our fingertips, you can throw a stone and hit a thousand people with an opinion.
Containers are nearly ubiquitous in software these days. Outside of abstractions like fully managed services (RDS, Dynamo, Cloud SQL), everything engineering teams are responsible for, mostly, land in containers. For many, deciding what platform to run those containers on is a burning question. Choosing the wrong container management solution can be a real headache.
The software engineering world has become a place where compute, storage, and availability have become the cornerstones of scale. As an industry and as individuals, we should stop to take a closer look at scaling the most important of all resources… our people. In this post I’ve modeled a team with 6 engineers, 2 Sr, 3 Mid, and 1 Jr. This team is getting 450 “units” of work done ( where a unit is just some measure of throughput ) per interval (2 months).
