This week was more about memorization. Mainly: phone numbers, key staff, and who does what. While all of this information can be found somewhere, the time it takes to find it versus the time to memorize it (which is shorter) makes the work worth it.

Once again, help desk is where I found the most … I’ll call it excitement. Two problems came up simultaneously, and neither of us (Medha and me) had any quick, complete solutions. The key in logging these problems is not just getting the facts, but asking the right questions to get the most useful facts. The worst case with this is when a user leaves early — you can’t get facts from someone who isn’t there. A key to ensuring that doesn’t happen: make sure you prioritize people who seem in a rush.

Earlier, when I stated the importance of remembering who does what, I also found a good reason for that. When the help desk makes problem reports, they also assign the reports to the right people based on the problem. This step saves time, for faster resolution of problems.

A reason for logging every problem is that we may not know every factor that goes into a solution. Full disclosure: I originally loathed having to log every single problem we run into. However, by shortcutting to a quick solution, we might miss something important that would have otherwise remained hidden, and that could cause major issues. A key example: Migrating emails from stonybrookmedicine.edu to stonybrook.edu — this can be done easily, but will this take into account HIPPA regulations? Best to keep a log and ensure full compliance.

On Sunday, I was surprised to find I would be doing almost all opening procedures. It’s not difficult, but being put on the spot always gives me a little jump…and I learn that way, since it’s a change from the normal. After that, just content, nothing new in terms of a walk-in.

To summarize what I learned this week: giving time to check the books is actually worth it, rather than solve first then ask questions later. When you work for something much larger than yourself, there are many people with a stake in how you represent the bigger picture, and any error reflects on all. Avoiding errors keeps the system reliable, which is an optimal choice between reliable, timely, and correct solutions versus sporadic, instant, and wrong solutions.

Please forgive the clichéd title – I normally prefer not to use the word “thing”, but in this case, I saw the benefit of the commonplace idiom as worth using.

My 2nd shadowing week has started, and here I immediately see the benefit to shadowing during a busy shift. The simple fact that more people are walking in and out of the site causes more issues that I wouldn’t learn by asking questions to pop up, and I can see how a current senior consultant would handle such issues.

To be concrete: normally, when I learn, I jump to whatever is on my mind. However, when trying to learn set procedures, such a disorganized way of learning would not facilitate retention of everything. Because I see that now, I fully respect being taught in a set order, then dealing with oddball questions, so (a) my notes are neater, and (b) there’s a rhyme and reason to what was learned.

UPDATE: Much has been learned! In my first hour at the Teaching Learning Lab, I saw a typical hour working at the Help Desk. This entails much of what I saw previously (answering phones/chats/emails and walk-in requests), but much more frequently. Rather, the big addition to my set of knowledge was the TLT Media Lab, which I never knew existed until now (probably because it wasn’t on the TV’s around campus).

 

(Source: http://it.stonybrook.edu/services/teaching-learning-lab)

Headed by Paul St. Dennis, this lab focuses on anything multimedia: poster printing, video/audio format conversions, and gamification of class content.

In addition to this, I learned that mysbfiles can act as a static HTML webpage server, if HTML files are placed in the right folder. This is useful for web workshops for the general campus, especially those without Sparky accounts (or Linux navigational skills, which should be another workshop).

As for how this affects my view of being a Senior Consultant, I once again see how the world of DoIT is a large place that I only know surface details about. While my decision on whether to want to be a Site Manager or Help Desk consultant is unphased, I see that both positions are equal in effort needed, but different in what kind of effort and the result achieved. Site Managers learn to manage and schedule other consultants, but Help Desk consultants help all people in being better users of existing technology.

My shadowing hours started out rather confusingly. I originally wanted a 9-11pm shift to better fit my schedule, and to have more time dedicated to one purpose. However, I have decided after my first two hours with Helen (learning about the Help Desk) to move one of those hours to the middle of the day, so I can see how to handle live support issues.

As for the two hours I was learning from Helen, I saw far into how the help desk works. In a nutshell, I learned the method in which TLT provides help for users: by phone, chat, and email. I listened in on a phone call about a class not appearing in a user’s Blackboard, and the solution was simple: wait 24 hours. Another support request came from a user via email about Print From Anywhere. Lastly, I got to personally test how the chats work: a user can log on via the Need Help link on the desktop, and be connected to a Help Desk consultant. The system then proceeds exactly as an Instant Message session would.

The most important part I learned was our issue tracking system. While solving a problem for a user is part of a senior consultant’s duties, another is ensuring there are logs of these events. Footprints (by Numara) is the system we use for that. To me, it is much like a KB (Knowledge Base) article I would find for Microsoft products– a way of saving a problem and a known solution, for ease of solving it later. I also learned how to sort emails about issues into their respective categories, and how that ties in with Footprints.

I also learned about transferring phone calls, because of a question I asked about how the phones work. Even though only 3 phone lines were available for use, I was able to successfully transfer a call from one room to the next.

Considering all of this, I believe the most important concept I learned is if I wish to know how to use a system, I need to ask about all of that system’s use cases to understand everything.

In site managing, I learned about basic procedures in running a SINC Site, and learned more about the larger organization I work in– specifically, the faculty that support those SINC sites.

As for what I learned in how I act, I see now that while it is not necessarily as important to memorize every detail, ensuring professional conduct and knowing when the details are important, as well as where one can look up those details, is even more important.

Last week in the internship, we received a generalized presentation about externships from Urszula Zalewski. The reason I say generalized is because there were differences in the presentation in how we would be evaluated compared to directions received previously. As an aside, I realized in my first math class here–Linear Algebra–how important generalizations are, and how easy they make explanations of many similar things, so I was used to that. Back to the internship, we learned we have a Faculty advisor and a Supervisor for this course, and the differences between their functions. Essentially, the first helps and second ensures we are learning. The point is to be able to keep track of our progress.

A large part of the presentation was about the differences in formal and informal communication, from a business perspective. An example that stuck out to me was the use of personal cell phones. I had originally been under the idea that if a phone is used for work purposes, that should be legitimate. While sometimes valid, that isn’t always the case. After asking other people I knew that worked, I came to this general conclusion: you should be able to ‘get a feel’ for if something is permitted. As an alternative, asking directly is always a possibility. Essentially, a phone could be used if the purpose is obvious, such as taking a picture of a problem or for note-taking. However, if there is any doubt to that, best to not bother with the phone.

The reason I stress on this technicality is because I enjoy the strictness of formality seen in mathematical proofs (in some cases), but most systems are not so formal, for ease of understanding. The grey areas must then be filled in by questions or from experience. This is true for anything.

I’ve asked myself this a dozen times. As a developer, it wasn’t the first thing I’ve always thought about, but fixing problems is. Problems themselves appear in all areas—even in the systems of the support teams. From working at TLT, while I’ve enjoyed my experiences with everyone, I’ve found there are a few confusing parts to it, and I asked myself: what is the best path to fix such confusions? Here I am now, in this internship.

Today, I’m learning to use WordPress more as a user, than just as an admin. There’s a difference: Admins might make a dozen ‘hello world’ posts, but not any real content, just tests. Once the tests are done, they’re gone. Users are the ones that find the real problems, those that crop up after days of perfect functionality. With me having seen both positions, I can see the bugs from a user’s perspective, then immediately think on how to get it fixed.

A senior consultant must do exactly that: be a scout for problems that only users would see, and get them fixed through the correct channels. That experience would come from having been in the user’s shoes at least once.

A concrete example of these abstract problems I reference: simply finding a way to remove the comments link. A simple solution: On the post edit page: Screen options at top > Check discussion, then uncheck allow comments in the ‘post box’ (the CSS name for those boxes with options). As a developer though, my first thought is to lookup how to disable the PHP code that affects comments. This is simple enough, but (a) no user should be expected to do that, and (b) I don’t have permission to do that here, not being an admin anymore. I instead learned to search as a user would, and found the screen options trick.

Ironically, such a procedure leaves more questions: why was this hidden? Rather than a UX-design argument which I would prefer not going into, I will simply say that most options up there are not everyday settings, and to save screen space, hiding them is a viable option.

The lesson here: For each different perspective seen, a new problem and old solution may arise, always along with more questions.