r/talesfromtechsupport

Hi r/talesfromtechsupport,

Early in develoment, I came here while building a game called I.T. Never Ends about working the night shift in an increasingly impossible IT department. People in this community offered feedback, shared the tiny details that make a support story feel painfully real and reminded me that reality usually writes stranger tickets than I ever could.

Those conversations helped give I.T. Never Ends its texture. The game begins with familiar work: answering support requests, filtering spam, routing cables and debugging network traffic. From there, the company becomes less explainable. Coworkers behave strangely, office equipment develops opinions and HR becomes worryingly interested in the printer.

The finished game contains 100,000+ words, 100+ endings and entirely hand-drawn and painted art. It launched today after eight months of solo development.

I wanted to return and thank the community that helped while the project was still finding its feet. Your feedback and stories genuinely mattered, and some of the game’s best details exist because experienced support people told me when something felt true and when it did not. Also a lot of your storioes from the previous thread made it into the final game - all of them with custom drawn characters. so there's colleagues with reddit-shirts and reddit-problems in the game. Thanks to you guys!

TL;DR Today I learned that some SiriusXM devices are serious about their NTP servers.

Help Desk let me know that one of our vendors was having an issue getting a radio set up at one of our provider locations and needed a hand. I used to work for this particular vendor and the guy needing help was a former colleague (henceforth VendorGuy) so I was more than happy to help.

I called VendorGuy up, found out that the device in question was a Grace Digital SiriusXM SXBR3 and then proceeded to battle with the fact that the device was physically connected to the network switch, showed the proper network info acquired via DHCP, and was pingable yet still stubbornly insisted that it had no network connection. This did appear to be true as our firewall logs showed no dropped traffic originating from the device's IP.

I had a hunch we might be missing something so I hopped on our firewall's CLI and ran a tcpdump filtering for the player's IP address and had VendorGuy reboot the device. Sure enough, I saw traffic, NTP traffic, to be precise. Which we block by default and do not log, so that explained why I didn't see the traffic. Apparently SiriusXM devices (these ones, at least) give up trying if they can't establish connections to pre-programmed NTP servers. Once we allowed that device's NTP requests out, then rebooted it to force reconnection, we were in business.

VendorGuy got the device hooked up to its amp and the PA system, there was music again and subsequent rejoicing. VendorGuy and I exchanged pleasantries and went our separate ways until the next issue comes to bear.

Sometimes students come to our tech support desk saying they need help installing software. Usually that is no big deal . . . except when the student pulls a completely new laptop out of its box, a laptop that has never even been turned on. That student has NO IDEA what they are asking us to do.

Student: I just want you to install this one program.

Tech: Sorry, it is no longer just a matter of installing one piece of software. We need to get this laptop through the setup screens, setup the Microsoft account, and likely run through some system updates, before it even lets us install that program. This could take a few hours.

We can and do assist with these projects, but we prefer to have an appointment for something this big.

I do tech support at a college. As is common in tech support roles, we get many calls that are completely unrelated to tech support (because tech support apparently handles everything), and so we need to redirect them.

===
Example 1:

Sometimes people argue and insist that we should fix the issue. If it involves the website in any capacity whatsoever, then obviously tech support should fix it.

Me: You need to talk to enrollment (or financial aid, or bursar, etc)

Student: “But this is a tech issue. . . “
- “But when I hit the Confirm button, it does not work. Shouldn’t tech support fix this?”
- “But I get a restriction error when I try to sign up for this class.”

Me: We cannot fix this. You need to speak with [fill in blank]

Student: “But this is a tech issue”

(around again we go)

In tech support, we are very careful to stay in our lane and not try to assist in issues that are outside our department because of the risk of giving wrong answers on issues in which we have not been trained. Problems that appear to be tech issues to students are often cause by problems in their records, holds on their account, etc, things other departments handle.

===
Example 2:

One of my pet peeves is how people respond after they ask for a phone number. Suppose they need the phone number to the Bursar office:

Student: What is the number?

Me: 555 . . .

Student: Hold on, let me get a pen.

Me: [eyeroll] (Then I must start over and give the number again)

….

Seriously? Why would you ask for a phone number, if you are not ready to write it down? It happens all the time.

​

Following on from my previous tale about installing servers on cargo ships, there was another vessel from that period that deserves its own story.

The Iron Chieftain.

She was a bulk ore carrier running the Newcastle, Sydney, Wollongong and Whyalla route, and by this stage I had become something of an unwilling specialist in installing IT infrastructure on large lumps of steel that stubbornly refused to remain in one place.

The first ship install had involved frantic planning, missing equipment, improvised engineering, international waters, customs officials and the threat of an unscheduled voyage to Venezuela.

By the time I got to the Iron Chieftain, though, I had the process down to a fine art.

Server. Check.

UPS. Check.

Switch. Check.

Communications gear. Check.

Workstations. Check.

Test.

Synchronise.

Sign-off.

Get off the ship.

Four hours, maybe five if something went wrong.

I had spare cables. I had spare powerboards. I had spare adapters. I had tools. I had documentation. I had learned and remembered the most important lesson from the earlier deployments:

Assume everything you have been told about the ship is wrong until you physically see it yourself.

But...there was one thing I still hadn't learned.

Never underestimate a Ukrainian captain at lunchtime.

The Iron Chieftain's senior crew were Ukrainian, including the Captain and CHENG, and the CHENG immediately demonstrated that he belonged to the same school of maritime engineering as the Chief Engineer from my previous adventure.

For those unfamiliar with the term, CHENG means Chief Engineer.

In my experience, the Chief Engineer aboard a ship is the person responsible for keeping several thousand tonnes of complicated machinery alive while surrounded by salt water, vibration and people asking why things aren't working.

They are, therefore, remarkably practical individuals. Sometimes aggressively practical.

Need power somewhere?

Run cable.

Something in the way?

Move it.

Can't move it?

Cut it.

Need a hole through a steel bulkhead?

There are probably many formally approved maritime engineering methods for creating one.

This CHENG had a preferred method and it was also the fire sword, or, as other people insist on calling it, an oxy-acetylene cutting torch.

I would point at the place where I needed to route a cable.

He would look at the wall.

Then at me.

Then back at the wall.

There would be a brief pause while some internal engineering calculation occurred.

Then: FWOOM.

Problem solved.

Hole.

I had reached the point where this barely concerned me anymore.

My original reaction to seeing someone attack part of a ship with an oxy torch had been something along the lines of:

“Should you be doing that?”

By the Iron Chieftain installation, my response had evolved into:

“Can you make it about five centimetres further to the left?”

Experience changes a man.

The install itself was almost disappointingly uneventful.

Everything arrived on schedule. The server powered up. The network behaved. The workstations connected. The communications link worked. No computers required emergency resurrection. Nobody had forgotten to mention that a critical workstation had been broken for six months. There were no nearby engine-room fires and, most importantly, nobody threatened to take me to South America.

For once, I was actually ahead of schedule.......and this should have concerned me.

Around lunchtime, the Captain appeared and invited me to eat with him and the senior crew.

Now, there are certain invitations in life that are technically optional but, in reality, are not optional at all.

When the Ukrainian captain of a bulk carrier invites the visiting IT engineer to lunch aboard his ship, you do not say:

“No thanks, I brought a sandwich.”

You go to lunch.

So I went to lunch.

And lunch was excellent.

Proper cooked food, generous portions and the sort of hospitality you tend to remember years later.

Then THE bottle appeared.

Vodka.....proper Ukrainian Vodka. The kind with a capital "V".

I was offered a glass.

This presented a minor professional dilemma. On one hand, I was technically still working.

On the other hand, I was sitting at the Captain's table, surrounded by Ukrainian officers, and the Captain was holding a bottle of vodka.

I considered the options.

There was really only one.

I accepted the vodka.

One glass.

Perfectly reasonable.

A toast was made.

We drank.

Then another toast was made.

Apparently, Ukrainian maritime tradition contains significantly more things worth toasting than I had previously realised.

Second vodka.

Still fine.

Lunch continued.

Conversation continued.

Third vodka.

At some point, I became aware that the bottle was spending an unreasonable amount of time near my glass.

Fourth vodka....or was that the fifth?

Now, I should clarify something.

These were not what an Australian publican would politely call a “standard drink”.

There was no carefully measured 30 ml nip being poured from a bottle fitted with one of those little plastic spouts.

The Captain's approach to alcohol measurement appeared to be based primarily on direct eye contact and optimism.

Eventually, lunch finished and I politely thanked the Captain and officers, returned to the equipment and completed my last checks.

The server was operational.

Communications were working.

Data synchronisation was successful.

Documentation was signed.

Job done.

Four hours, exactly as planned.

I packed my equipment and headed towards the gangway.

When I had arrived, yhe Iron Chieftain was tied securely to the wharf in Sydney Harbour. Sydney Harbour was calm. The weather was fine. There was absolutely no meteorological reason whatsoever for what happened next because somewhere between the Captain's dining room and the gangway, the sea state had apparently deteriorated dramatically.

The deck seemed to be moving. Not a lot, mind you. Just enough.

I adjusted.

The deck adjusted back.

.......Interesting.

I reached the gangway.

My legs, which had performed adequately when I boarded several hours earlier, had apparently suffered some kind of simultaneous mechanical failure.

Left leg requested movement.

Request timed out.

Right leg attempted to compensate.

Unexpected response from device.

Retry?

I grabbed the railing.

Clearly the ship was moving.

That had to be it.

It was a large bulk carrier.

Ships move.

This is basic physics.

Admittedly, it was tied to Sydney but perhaps Sydney was moving.

I began descending the gangway with enormous concentration.

One foot.

Step.

Other foot.

Step.

Hold railing.

Do not look like you have forgotten how legs work.

I would like to believe I maintained a dignified and professional appearance during this process. I have absolutely no evidence supporting that belief.

Eventually, I reached the wharf.

Solid ground.

Wonderful, dependable, non-moving ground.

Except it was also moving.

This was becoming concerning.

Obviously there must have been unusually heavy seas affecting the Port of Sydney that afternoon.

Extremely localised heavy seas.

Possibly restricted entirely to a radius of approximately one metre around me.

I made my way slowly towards the exit carrying my backpack and tools while concentrating very carefully on walking in what I believed was a straight line.

Behind me, several members of the crew seemed extremely amused and entertained by something but I never discovered what.

The server installation was a complete success and the ship returned to its normal Newcastle, Sydney, Wollongong and Whyalla run.

The CHENG got another opportunity to use his beloved fire sword.

The Captain provided excellent hospitality.

And I learned another important lesson to add to my growing list of rules for maritime IT work:

If the Chief Engineer says he can make you a hole, stand back.

If the Captain invites you to lunch, accept.

If the Captain offers you vodka, also accept.

But when the Captain offers you the fourth vodka or maybe a fifth?...

...remember that Sydney Harbour is apparently prone to sudden and extremely localised heavy seas.

Especially around the gangway.

---

I should probably say something about the Captain himself, though, because after all these years he is one of the people from that period I remember most fondly.

He looked exactly like the sort of man central casting would send you if you asked for an old sea captain.

Grizzled, weathered, white-bearded and carrying the unmistakable air of someone who had spent most of his life at sea.

It sounds like a cliché, but in his case the cliché existed for a reason.

He was dignified and friendly, but there was never any question about who commanded the vessel.

He carried his authority quietly and solemnly.

He didn't need to raise his voice or remind anyone that he was the Captain.

The way the crew treated him told you everything you needed to know.

And yet, to some random IT engineer who had turned up to install a server on his ship, he was warm, welcoming and generous.

He invited me to his table, fed me, talked with me and, admittedly, attempted to determine whether an Australian IT technician could survive Ukrainian quantities of vodka.

That lunch could easily have become nothing more than a funny story about me trying to walk down a gangway with malfunctioning legs.

Instead, it became one of those small memories from my career that has stayed with me.

I learned years later that he died of a heart attack in 2018 while bringing the Iron Chieftain into Wollongong and I was genuinely saddened when I heard.

Over the years I've worked with thousands of people, many of whose names and faces have inevitably faded yet I can still picture him sitting at that table aboard the Iron Chieftain.

White beard.

Quiet authority.

A meal in front of us.

And a bottle of vodka that seemed to possess an infinite number of servings.

I only knew him briefly, during a handful of visits to his ship, but I remember him with enormous fondness.

So wherever old sea captains end up when their final watch is over, I hope the seas are calm, the engines are running well, the crew knows what they're doing...

...and there is always another bottle on the table.

Fair winds, Captain.

At some point, someone had the bright idea to get my grandmother an iPad. Why? I don't know. She had enough trouble with the laptop someone had gotten her, although she did like being able to get pictures of her grandkids. Maybe we thought a tablet would be easier? Regardless, when we visited for the holidays, we asked her how she was liking her new device. She said she liked it well enough, but --

"Sometimes when I'm trying to read the news, it goes away."

What did she mean by it goes away? "It goes away." Like the screen goes black, the iPad is falling asleep? "It goes way." We weren't sure exactly what to do about this, but we thought about digging through the settings a little bit. I was in and out of the room as this was happening, so I'm not sure what the eureka moment was, but eventually someone found out the following:

The default Apple news app would send her a banner notification with a news headline and a couple lines of info. She would attempt to read the notification (slowly, since her eyesight was going), but wouldn't tap it. And banner notifications, if you don't interact with them for several seconds, retract back into the top of the screen after several seconds. So, when she was trying to read the news, it would, in fact, "go away."

We "solved" this problem by turning off notifications for the news app. After all, who wants to have the news jump out at you randomly during the day?