People don't want to buy a quarter-inch drill. They want a quarter-inch hole!
A few years back I worked at a relatively small startup, with about 6-8 people on the engineering team. Smart coworkers, extremely high level of code quality, everyone eager to help each other out, basically everything an engineer could ask for.
But the most important lesson I learned from working at this place was "always be questioning".
My CTO at that time, was not just the smartest person I've ever met (with an absurdly high margin), but was also one of the most pragmatic engineers I've had the chance to work with. For every single decision we had to make as a team, which involved putting a sizeable chunk of our engineering resources to use, we had to handle the following three questions -
- Do we need to do this at all?
- If we do, why? How does this affect the product?
- Is there something easier we could work on that produces a similar result?
This was not a compulsary exercise. It wasn't as if all of us in the meeting room had to go through these questions one by one and agree on answers. But it was just something implicit that we had to keep in mind.
And in cases where working on something would lead to developers getting excited (turns out one of the major reasons a developer would solve a problem is not just because they need to, but because they want to), he would make it a point to calm them (us) down and make sure we're not losing track of the bigger picture.
It turns out that by answering just these three questions, you not only make your life much easier, but you also save your company a ton of time.
1. Do we need to do this at all?
Sometimes, problems are not worth solving. Or in other words, problems are not worth you spending your time on, for a variety of reasons. It could be that it's not affecting enough customers, or it's a nice-to-have and your customers won't cancel their subscription if you didn't implement this feature, or something else.
As Patrick McKenzie says, your job as a developer is not to write code, but to solve problems. As a developer, most of the time you're surrounded by other developers. In such cases, it's easy to lose track of the bigger picture. And when that happens, you might end up working on something which doesn't need to be solved. This counts as a waste on almost all kinds of productivity metrics.
When you ask whether we need to do something at all, you gain perspective. You understand that the thing you're being asked to do might not need to be solved at all, or at least not in the near future.
2. If we do, why? How does this affect the product?
Identifying the origin of a problem is a critical skill. Some problems need solutions as soon as possible, while some others are symptoms of something else entirely. In such cases, it's better to dig a bit deeper to find out what the root cause is and work on that instead.
If you can identify where exactly a problem is coming from, and what does the user really want to do when they're asking for something, it becomes easier for you to make sure that you're solving the right problem and it does have a sizeable impact on your product.
3. Is there something easier we could work on that produces a similar result?
Edmond Lau, in his book The Effective Engineer defines a metric called "Leverage", which is directly proportional to the impact and inversely proportional to the time investment.
In his equation, if you can decrease the "time" investment, but keep the "impact" more or less constant by working on something else that produces a similar result, you would be able to achieve similar-ish results in less time.
I find this an extremely effective framework using which feature development work should be evaluated before starting implementation.