I learned in this internship with TLT to see myself through another’s eyes. This includes everything – the way I present myself, the way I carry out actions, how I carry out actions, and the like. I’ve changed as a result – rather than dealing with everything as if it was a computer science related problem, I can cater to any area without being disingenuous to another. Essentially, the way I handle computer science problems is to diagnose the system mentally and carry out the solution right then and there, but in a customer service setting, this mantra doesn’t work as well. I’ve been learning (slowly) to involve the user in this process, which creates a two-way street where learning can occur in any direction.

Going hand-in-hand with broadening my horizons in dealing with issues is to understand that my ways aren’t the only way to perform an action, and just because there’s documentation saying method X is better doesn’t mean that method Y is easier and quicker, and still gets the requested end result. In other words, this is another case I’ve learned to accept that methodologies can be a countably infinite space.

Working in a team environment has benefits, especially if the team is good. That’s the grand idea of good teamwork: If the team is enjoyable, work will get done faster and possibly be better. The key here: a good bit of humor. I learned this helping with Roth Regatta – a little humor goes a far way in keeping good spirits.

Overall, I would say this internship taught me how to think in a big picture view, from a reliability standpoint. In addition to making at least 30 new friends between the Senior Consultants and Interns, I really do believe I can continue making SINC Sites to be clean and efficient computer labs when necessary.

It’s been a good semester,

Frank Migliorino

This week, I gave a presentation with Glen Higgins on the Department of Information Technology for the TLT Internship. I prepared for this since February, but it doesn’t feel like that long since we spaced out the work so only a little had to be done at a time (with a possible slight skew towards April). Oddly enough, I just recently gave a presentation in my CSE 300 class – a class devoted to technical writing. The rule for the other presentation was to make an interesting talk that does not eclipse 10 minutes.  The TLT presentation was more about the visual aspect – make a website that is appealing to the eye and informative, but also keep to a 15-minute-maximum in the discussion. The major difference: I had much less time to prepare for the CSE 300 talk (which I decided to do about how technology tracks people everywhere), and the audience of the Computer Science talk was less … pressing than that of having your peers & friends, and supervisors watching in TLT. I did make some comparisons between the two, and got useful ideas.

The first: Content is king, but it needs to be worded in a way that hooks people, unlike certain kinds of academic writing. There needs to be an element of “that’s so cool” that comes from your voice, both content and diction. This is true for every presentation, and I’ve found the only way to do this is to actually create every sentence I’m going to say on the spot. It adds originality, and keeps the presentation fresh, and I’m not bound to a script. The trouble with this is losing my pointer to where I am in the presentation, which will inevitably cause a second of silence. Those get shorter each time I present. When I gave the salutatorian speech to my high school graduating class, I left the speech in note form so I can make the sentences naturally, as if conversing. This worked quite well.

The second: Presenting with a partner can make a presentation easier and difficult simultaneously. You only need to know half of the set of content to be discussed, but there needs to be a synergy between both people so no one gets cut off, and the talk is distributed evenly.

The third: Any talk needs to be adaptable. I’m actually borrowing this entirely from my CSE 300 class, where one of the recommendations is to structure your talk or presentation so  parts can be added or removed on the spot without breaking the cohesion of the content, and the main point. For example, when Glen and I presented on DoIT, I added the example about WolfieNet automagically (a term used in the Computer Science Jargon File to show a process works, without the low-level details) handing off connected clients to nearby access points when the client is moving to extol what WolfieNet does for the campus. This wasn’t originally planned, but it seemed a good idea at the time.

The last idea: Make sure the purpose is fulfilled; be it to inform, to persuade, or to teach—as long as there is a clearly defined purpose, a presentation may go well.

In addition, this methodology can work in a customer service oriented profession since if a conversation is made interesting, a user will feel personally helped, and thus be happier at the level of support given.

This week was more about being a good leader as opposed to solving the most questions or knowing the most about some set of tools. This makes sense: the set of tools I will work with is infinite, so it would be better to be someone who can adapt to any situation and most importantly stay professional. This is important to me because when a fully new problem appears my first instinct is to drop everything and think about that, learning from it. However, in a managerial role, one of the priorities is to ensure everything is at least working first, then solve a specific problem. This balancing act is what needs to be done with finesse.

The first shock to me was being told that multitasking, while you may appear to be effective at solving many problems at once, may make a person appear aloof from personally helping a customer, which is an unwanted result. Rather, helping each person one at a time and asking my team for help for other issues can ensure each person is helped with full attention. Not all people have the same personality, and there will be at least one person who does not like being one of a list of those being helped.

I can apply these lessons straight to my customer service skills – be more approachable and limit how busy I appear, as not everyone likes how that looks.

This week, I’ve learned that something that might seem simple on the surface can actually be a mess on the inside. As a first example, let me look at scheduling. From a computer science perspective, my first thought is to attempt to automate the entire process, but then I run into a problem. I have no idea what my script (a program that takes some inputs and makes outputs based entirely on the input without user intervention) is doing and who is assigned where, besides the end result. Furthermore the time I spend on making such a script might look like this web comic:

Source: https://xkcd.com/1319/

Essentially, the lesson learned here is that after a certain amount of time, I need to see how much I’ve progressed and ask myself if it was worth it. Granted, this is a lesson learned in a hypothetical context, therefore I do not know how far it extends.

Additionally, from all my experiences in TLT and working with people higher up in the hierarchy than myself, I’ve learned that making recommendations in service industries to the manager is often not a bad idea. I was recently able to give this confidence and push to some friends that wanted to make a statement about tea on campus, and they got immediate results by speaking up. I feel empowered that I’ve learned this from TLT, as opposed to my previous habit of ignoring the problem.

Usually, I pride myself on being able to fix some software problems, or sometimes hardware problems if and only if I’ve seen it before. Take, for example, a recent problem projecting a movie in the Auditorium in the SAC. When the movie was played, I noticed there were black dots crawling up the screen. I predicted this meant the movie would be in black and white when it should have been color, and exactly that happened.

How could anyone know that? Luck, I suppose. Two years ago, I had a TV Tuner in my computer and came across an odd bug where if the settings weren’t right, the exact same problem happened. Back at the SAC, I was unable to offer this fix since the hardware that caused it was not end-user configurable.

Jumping to TLT, I volunteered to attempt a fix for an A/V system in one of the SINC sites while on a shadow shift. While not the same problem as before, the cause was similar (and I only found this out after reporting the problem): a control system not accessible to the end-user (Consultant or Professor) had frozen and required an administrative reboot.

At face value, problems like this make me feel inadequate since I can’t fix them in 5 minutes. However, thinking about it more, I can see some valid reasons for needing the wait time. The first and foremost one is safety of the system: if anyone could configure these low-level components, there would be problems every hour. The problem statement is: “I need a system that lets the end-user switch projector inputs such that (a) the projector will always cool off if necessary, and (b) the end-user can’t break the system.” Thinking from a whole university perspective, I see that the best way to solve that is to use something that works most of the time and is secure, and for the few deeper problems that happen, allow for the extra response time.

I myself take this policy when administrating other computers—the principle of least privilege. It keeps systems secure, and as an on-call admin, that’s one of the best solutions you can have (meaning less support calls).

My original thoughts before the Thursday of the 9^th week were that Help Desk might be less taxing than Site Managing. I have been proven wrong. Rather, that is dependent on how much help is needed at the time. Taking 2 calls and helping someone in person, for example, is difficult in any light. For myself, still getting the hang of doing this takes time.

In terms of helping users, I make sure I make a distinction between helping professionally and personally. For example, when I help a friend understand content in a course, I can explain things colloquially and be fine, but this is not right in a professional environment. This is—I believe—the area I most have to work on, since I always help people as if they were classmates. In a professional environment, I can’t make assumptions about what the other person knows.

I figured this out when taking a call about Digication – the other person was a student, so I’ll say I got… lucky using my old ways. Another user, however, was not. I changed the way I attacked the issue at hand such that all parties understood and were on the same page, and successfully resolved the issue. The main point here: Adapt and overcome, solve each problem in the way that gets the fastest and best solution.

Another aspect I’ve learned about myself: I usually generalize each (computer) problem I face so I know how to solve all issues of that type later. Usually I keep that to myself. While shadowing, I spoke the reason out loud, and didn’t realize it was never seen from that angle before. This might lead to TLT being able to provide that same generalized solution now. Another key point: Speak your mind, if it’s something relevant, not mean, and possibly new—you never know who knows what.

However, at the same time generalization is nice, it can’t be taken for granted. Often, if I taught something, I do it differently each time so I personally see the differences and can adjust as necessary. A catch with this I didn’t think of: Now there’s x people knowing Method α and y people knowing Method β, which doesn’t help for standardization. A stronger reason of teaching Method α each time is that statistics can be done for every time that method is taught, and there’ll be a stronger case on what needs to be changed, based on averaged feedback.

Spring Break gave me time to think about everything in college so far (a lot of time). I got myself to ask questions of what I want to see from myself in a year, and I came to this answer:

I want to make a difference for the better in my environment.

Let this be broken down. I need to carry myself such that I am 100% open to suggestion and change to further enhance the Stony Brook experience for everyone involved. This doesn’t involve just making sure people know about services offered here, but to make those services enticing and useful to learn. As a (contrived) example, take printing at Stony Brook. In the basic form, one needs install software, then print normally. This isn’t very new, however. What is new is being able to print from just making an email. The spark of attraction: This can be done from a swipe on a phone. As I see it, removing the bulky hardware here has made an old idea new.

These kinds of ideas that haven’t been tested before are the ones that need to be spoken, since simply keeping something operational will not magically summon ideas. Thought needs to go into that. Granted, these thoughts can be as simple as ‘I wish I could do X’. A concrete example: (a) wanting to go to a Student DoIT Advisory Board meeting, and (b) offering an idea like ‘there should be more accessible power outlets so people can charge on the go’. Even though I had to modify my schedule and move a shadow hour around, I believe that was worth doing, since offering (hopefully) new ideas up the chain can only help.

That was just my Monday.

Tuesday (3/24) was a day I was excited for since the 3^rd week of classes—it’s not every day you get to interview the CIO of your school, Cole Camplese. The short version: From that interview, I learned the how of future-sight. Cole is a visionary, and good at it. The idea isn’t just to make an infrastructure work to specifications, but to envision what people want before they even know what that is. This extends into most problem domains, and that to me is the foundation of the ability to critically think on a new level.

The basic routine for any shadowing shift is get there, learn something about a work responsibility, then go on my merry way. Rather, the interesting parts are the questions by end-users. The goal of TLT, as I see it, is to assist and help users (students and professors) such that the tools we offer are useable and aren’t hinderances in their intricacies. The means to that end are having the help desk create documentation as well as general support, and the site managers to assist students in real time, in person. For each generation of new consultants, the task is to (a) teach previous solutions to common problems, and (b) get new ideas on how to better educate the community on these complex tools (like EchoCenter and the instructor’s version of Blackboard).

I thought about this as I was telling my father what my job was like, and realized a simple way to summarize it is this:

We take a complicated system and bring it to a small number of configuration options so everyone can use it well enough, as my father does with boats.

Given the difference in expertise here (mechanics vs. software), I ended up making the exact same simplifications I would have made explaining these websites to end-users, but on a large enough scale so the big picture can be seen. At that point, I believe I saw exactly what I would be doing as a senior consultant.

This also makes sense from my last experience with help desk on Thursday – mostly no calls, but in the last 15 minutes there were two, and one was from a professor about a specialized application for her classes that Stony Brook provides.

The point I run towards here is that professors are given large amounts of tools to educate with, but these tools themselves are much more complex than the students’ versions. As a student, you just see an upload assignment here button, but the professor needs to

• Add the assignment and points
• Configure when it appears and disappears
• Configure a ‘late’ deadline
• Add links in the announcement page (optionally)
• Attach any needed directions

If a professor also does research in a field far away from computer science and just started teaching, the time needed to remember these steps might be too much. That’s why we have a help desk — to make quick work of a confusing system.

This week was interesting at best. As opposed to what I’ve learned, I’ve taken more of an opinion in how I learn it. For example, I find myself preferring to prove that I can do something to skip learning it, since the proof is faster and easier. By proof, I mean showing my mentor how to do the task at hand. Of course, the quick tricks I learn (e.g. that https://my.stonybrook.edu redirects to the Stony Brook EPO) are welcome. Effectively, I’d rather learn something myself, on my own so it sticks (or have an instruction manual), versus being told. The act of doing it makes me remember what to do.

This method has its problems though—I still must say what I’ll do to my mentor in case I am wrong. This I like about mentoring: It is a method whereby you can learn in your own style without respect to formalities, at least till the end. The relief of pressure lets me feel safe about my decisions, knowing I have time to improve them.

Now for something much more important from this week: timing and memory. I do many things in a day and often jump between 3 or more within an hour. Being accustomed to this, I need a second system (web calendar) to help me track where I am. Unfortunately, this system is not perfect if not kept up to date, and can cause me to not be on track. Up until this week, I had an assertion that mostly correct is a good trade off to ensure each task is done well.

This assertion is incorrect.

I’ve learned this the hard way many times, and yet still think it true. However, recent events have shown me this is not the case, and I need to be more redundant in checking my plans for a day. Redundancy is good when used to detect errors, not a waste of time.