Why is it so important to ask questions correctly (i.e., set tasks)?
Because if the task is poorly defined, the performer may:
- Answer with disdain: “As requested, that’s what was done.”
- Get bogged down in the question and, spending a lot of time, find reasons not to do the task.
If the first point is clear, this behavior is common and predictable (work was done for show), the second case is rarer and has a stronger effect.
An employee was chosen based on their competence and ability to go beyond the ordinary to foresee potential problems with the chosen solution. However, this quality led to a deadlock. They were able to find so many blocking limitations that no OS would meet the criteria. Instead of an expected proposal, they received a long answer that:
- Java version X will soon be unsupported in that OS line
- The number of vulnerabilities is skyrocketing
- Here’s more information for you to consider.
This information was found from open sources. Well, what else can be offered by FSTEC as passing criteria and local security officers? In the end, the procurement engineer will decide which distribution will be in the environment and other environments.
Why did the task get stuck? Because I didn’t set it up correctly and handed it over raw (as “usual”). Like with AI, I didn’t form a clear prompt – i.e., limit the person’s areas of research. This can include compatibility with Nightmare and load balancers, kernel support for hardware, etc. Sometimes you just need to make a decision and take it into work, understanding that the allowable amount of time has been spent so it doesn’t cloud your eyes with unnecessary things. And therefore, it will be easy to part ways with the chosen solution in favor of an alternative.