Perhaps the largest portion of any entry level IT work is solving problems not that people are unable to solve, but simply unwilling to try. This can be for fear, fear of harming their own equipment, fear of the complexity which IT work may entail, or lack of time to solve them. These problems are frequently problems the domain of which we are unfamiliar with - Things like how do I install the dictionary app on my blackberry, or How do I use my Samsung smart television. These user level tasks are designed by the producers of the domain - Application, Operating System, Hardware Device, website - to be discover-able by a competent user without to much fanfare - though there design is frequently imperfect , but as an IT, our familiarity with various other similar domains and the nomenclature of the domain enables us to solve these problems quicker than the user.
Other problems can be more complex - actual problems. Requests like “my favorite but obscure application gives error 12. Your familiar with this of course.” But of course, requests like these betray a fundamental lack of understanding of Information Technology. There is, of course, not an absolute error space of which “error 12” is commonly intelligible. There are millions of applications, and IT technicians cannot be familiar with even the most minute fraction of the application space. Here, we are forced to resort to a series of faith healer methods - there is little instrumentation available to actually understand what causes the problem in most cases. We are now speculating on the behavior of a computational process - a program - and have a complex heuristics based intuition that can sometimes result in a solved problem. With a debugger and symbols, or even more minor instrumentation like a **trace for windows, we could instrument the program, and understand the problem, but these tools are largely not in use by technicians.
This is still good news. This is is a simple case because of the the binary nature of the problem - either we fixed error 12 or we didn’t. We get immediate feedback on our handed down lore, our huertistic solution was or wasn’t effective. Ultimately, these kinds of problems are solvable, even if it means redeploying the application in a new OS install with new data.
But, there exists a large class of open ended problems where the faith healing methodology really becomes apparent. These problems sound like “My computer is slow”. Basic instrumentation for this problem exists - task manager, performance monitor - but these tools provide only an instantaneous snapshot tested in a context outside the users normal usage. While toolsets exist for more advanced instrumentation - Windows Performance Toolkit - in entry level IT these tools are largely not in use.
Instead a long check list of fixes perhaps related to the problem is applied. Things we swear are beneficial - even needed on some recurring schedule - things like defragmentation (on mechanical disks), virus scans, applying updates, OS integrity scans (SFC, DISM), start-up item checks, applying updates, which may or may not address the issue. Its a testament to underlying design flaws that such a faith healing methodology - applying a series of fixes that are not clearly causally related to an observable problem - actually works at all; Apparently, the same series of common problems occur again and again. Trying to explain to a customer casually why this elaborate ritual resulted in some their open ended problem being resolved can be impossible because the IT simple doesn’t know.
Techs frequently leverage conventions in combination with the series of generalized principals that make up our intuition to troubleshoot problems. For instance, we can frequently reset the user state of an application by finding its datafiles and removing them. These datafiles are often stored on the Windows Platform in the Application Data folder of the user profile, on the **nix platform in various dot directories.
Of course, programs are , usually, relatively deterministic, and there is some path through the code written on the disk that results in whatever problem is occurring, and with the correct instrumentation, a sufficiently advanced IT Tech / Developer could resolve the problem, but by in large, IT Techs are not leveraging this instrumentation, or in many cases even aware of its existence or the paradigm of computational processes running.
IT Techs are faith healers, riders of computational processes, controlling them though a relatively complex intuition of how sane programs behave, leveraging internalized paradigms and standardized platform conventions to solve problems across a broad application space. In some sense, you could say Techs work at a higher level of abstraction that of developers. Developers can see the internals of the program - why the the result occurs, traced through the global evolution of the process. IT Tech’s instrumentation doesn’t breach the black box of program with a state, we can’t see the internals, or evolution of a state, we are forced to troubleshoot at a higher level of abstraction.
Comments
Post a Comment