The beauty of technology problems is that they are applicable in so many different fields, including daily tasks. Back in high-school, I used to deliberately leave some parts of assignments half-assed just so I would be asked to re-do them. I would always make sure these were sections that I was more more confident in my ability. It would always lead to instructors ignoring the parts I was less confident in their quality. Later on, I had my moment of clarity when I learnt about Parkinson’s law of triviality. It is a phenomenon that spreads as far as management, one among many. I cannot count the number of times I have abused this technique.
Of those problems that seem to persist in a cross-field basis, I have recently been guilty of one that tends to lurk under the radar. Let’s say an arcade owner has a problem with counting coins. He decides to employ ten people for $8/hour. He then struggles with the logistics of organizing the 10 people to finish the task in a timely manner. He goes out and asks his friend on the best procedures to organize 10 people in a factory line. He ends up with even more complicated situation after his friends mentions the fact that two five-person groups seem to work better than one ten-person group. He now has another problem on deciding on how to divide the group of ten into the best five-man packs.
Ignoring the terrible thought-out hypothetical scenario, the arcade owner is at fault for not realizing what problem he was solving in the first place. He needed to find the optimal way to count coins at the end of the work day. In the way he went to seek for help, he avoided to mention his primary problem. Alternatively, he needed to mention his coin-counting problem that led to his decision to hire ten people in the first place. His friend might even mention about the possibility of leasing a coin-counting machine, a much cheaper alternative used by all arcade owners.
Like any developer, I tend to scour online help forums. I cannot count the number of times when the first response to most questions is “What exactly are you trying to do?”. An old post from Usenet describes it as an XY-problem. In short, one wants to accomplish task X. He is not sure on the solution to X. So he comes up with a solution Y. He is not sure on the best way to implement Y. He asks for the solution to Y, assuming that by solving Y he will end up solving X. Those trying to help fail to understand why one would want to solve Y, usually because Y is a strange problem to solve. In the end, no one is usually happy.
I think it is a safe guess a good number of these questions were trying to obtain the file extension. Instead of directly referring to their main problem, they came up with a solution which assumes that all file extensions are three characters long (HINT: not true). The issue is so pervasive to deserve its own wiki with numerous examples.
In all this seemingly noob-bashing (and by extension self-bashing), I feel some of it is accidental. In the arcade owner example, he probably does not know that other arcade owners are faced with the same problem. Maybe he is the only arcade owner in the area. Maybe he is a new arcade owner without a clue on the best practices. While it is easier to blame the asker for their lack of knowledge, ignoring their position is equally unfair. It is too easy to forget the number of times we all assume our problems are unique. The main lesson should not be how to ask questions but rather most problems are not unique. Sometimes that lightbulb might just be a firefly.