Turn hard problems into easy problems, and solve easy problems.
This is a quote I use a lot. I think it’s a quote that seems brilliant when you already understand it, and seems confusing at best when you don’t (and the people who already understand it weren’t the ones who needed to hear it). So let’s unpack it.
A lot of times a problem seems very tricky, let’s take a toy example “A number multiplied by 31 then decreased by 19 then increased by the original number is 107, what is the number?” At first it may seem to be a problem for a math whiz, but once you know algebra any 8th grader can setup and solve: x * 13 – 19 + x = 107 thus 9″
If you can be the kind of person who does this in his/her head, or the kind of person who knows how to turn the statement into a basic formula and solve the formula, be the second one. Every time.
Okay but why?
Well, for one, almost all engineering problems get more complex with time. Every single feature, service, tool is it risk of needing enhancements in the future. What was once manageable will eventually become unmanageable, and the longer bad design stays the higher the cost of correcting it.
Another reason is that a solution decomposed into a few simpler parts has the benefit of being debuggable.
Additionally, a service that is composed of simple reusable, well-defined parts can often share those reusable parts (e.g. caching service) with other tools, or often simply already exist as industry-standard tools.