While browsing Twitter I came across the following tweet that resonated:

A common refrain I have is that the best engineers are not the ones that write the most code but are instead making decisions that reduce the amount of code that needs to be written in the future. This tweet speaks to that since very often an implementation will either be too simple to support a future use or be over-implemented to support a potential future use case. The truth is often somewhere in between.

That’s why business and commercial context is incredibly valuable to an engineering team and why, for the most part, the closer an engineer is to the problem the better the overall solution. This is also a big reason why startups can out-build larger companies. They have fewer layers of translations in between the problem and the product that’s meant to solve it.

The solution here is to eliminate as much friction between engineers and the problem being solved. The goal isn’t to understate the problem which will lead to an implementation that solves the immediate problem but isn’t flexible enough to grow with the problem opportunity. Similarly, overstating the problem will lead to an implementation that lacks flexibility due to its complexity.

This is very similar to Goldilocks and the Three Bears - the first approach is wrong in one direction, the second is wrong in the opposite direction, and the last approach is the one that’s “just right.”