A lot of software development requires more than just you. Your code has to be readable by others. So you often have to add comments, use standard conventions, and even use standard styles of coding for a particular problem. So a lot of the time, you are required to use conventional ways, just to facilitate software development.
Another issue is just plain practicality. It's very easy to write code that produces errors. So in practice, it's much quicker and more reliable, to use existing practices that others have already found to be highly reliable.
So for these reasons, it really is much safer, and quicker, and generally much, much easier, to rely on Sensors for most programming tasks.
HOWEVER, programmers write programs, and by definition, programs are objects that can do a particular task, as many times as one needs, whenever one needs, and can be replicated to any other computer or situation which requires the same task to be done, and provides the same resources as the original. So once a task has been programmed once, technically, it need never be programmed again. Accordingly, programming is always pushing the envelope. Programmers are often being asked to do what they have never done before. So, although Sensors make more sense to use in general, it is frequently the case, that the task being asked of one, is a task that no-one has really seen before. Sometimes, no-one has a clue on how to do it. Other times, Sensors have a way of doing it, but only by using a lot of methods, that in total, will take ages.
That happens a LOT of the time, maybe 20% of the time. So then, you want an intuitive.
Another problem is tech support and debugging. Quite frequently, clients report bugs that seem quite elusive to track down. Normal methods of tracking down the error in the code, seem to not work at all. Other times, even when the error is identified, the particular problem cannot be fixed easily, and can seem to require months of work. In both situations, programmers are faced with a problem that their existing knowledge doesn't cover. Someone then has to come up with a whole new way of identifying the problem, and/or a whole new way of identifying the solution. To do that quickly, you usually have to have an intuitive feel for what is the right direction to go in. This also is not the majority of errors. But it happens a LOT, maybe 30%, and then, you really do NEED an intuitive.
Us intuitives are a hindrance most of the time in programming. But when we ARE useful, we're almost indispensable, because the Sensors really are totally out of their depth, on those problems.
That's what I found, anyway. Employers put up with all sorts of things from me, because when they did need me, no-one else could do the job at all.
