There are techniques and ideas born in different areas that can eventually find their way into programming.
For example, Lean Software Development came from the Lean Manufacturing which is said to have been derived from the Toyota Production System. It's the base for the whole movement of creating only the minimum amount of functionality when building software in order to avoid waste and (by consequence) unnecessary complexity.
Programming makes you think. Makes you reason logically about how to create a working product and makes you build empathy in order to write a code that can be understood by other programmers. It's very easy to build something small but it's very difficult to build something big.
Asking the right questions, to yourself and to other people, is a fundamental skill to be able to build something big and seamlessly. Those questions can come in the form of "why" in order to clarify requirements and prevent Over-Engineering or they can help to investigate the root cause of a problem. In the end, there's probably more value in having the right question than knowing the right answer.
There's more value in having the right question than knowing the right answer, for that the right answer can be the answer to the wrong question. And that's useless.
There's no universal way to come up with the right question because each circumstance is unique. It’s a type of Tacit Knowledge, which means that it cannot be easily taught (as in a book).
It’s possible to argue that the "right question" can be subjective and two people can come up with different definitions of what a right question is. It’s even possible that two highly skilled individuals can come up with two different right questions that are worth pursuing.
I believe the example below can show the fundamentals of this principle. It's a hypothetical (but pretty common) scenario, where a team wants to find ways to make the project better:
The last question poses something interesting. If the goal of the company is to make money, and the price paid for the engineers to reduce the amount of gzipped bytes is bigger than the price paid for serving a few dozens of bytes to all user requests, then it might as well be a wasteful thing to optimize for.
Of course, there are other right questions that can come up which could change the decision or at least raise some interesting discussions:
The investment could be worth it. But again, as long as the cost outweigh the benefits.
Sometimes, like in the optimization example, coming with the right question doesn’t require a lot of effort. It requires effort to look for data that can answer those right questions and allow to move forward into new questions. Despite the speed or size of the step, having the right question can, at least, point the development to the right direction.
We should always move forward, one step at a time. What matters is not the speed, but the direction.
In the "The Hitchhiker’s Guide to the Galaxy" fiction series, there’s a huge supercomputer called Deep Thought. It was built for the purpose of providing the “Answer to the Ultimate Question of Life, the Universe, and Everything”.
When the answer was calculated, it was the number "42".
However, nobody understands what "42" means. The reason why the answer is meaningless is that the beings who instructed Deep Thought didn't know what was the right question in the first place. The number 42 comically shows that having an answer is not enough to have something useful.
Maybe investing additional effort into the journey for the right question can be worth it.
Even if it turns out to be a waste of time, at least you have wasted that time in the question before starting to build the answer.
Without the right question and jumping straight into the answer, you might as well be wasting a lot more of your time.
Let's not do that.
Create your free account to unlock your custom reading experience.