photo credit: officemuseum.com

Although it was a giant telecom, Mike couldn't have imagined how huge "AQ&V" actually was. What seemed like miles of occupied cubicles stretched from wall to wall in labyrinthine passages. Weaving their way through aisles of well-dressed employees silently typing on their computers, Mike and his prospective boss arrived at a conference room and began their interview. It must have gone well, since Mike got a call with an offer on his drive home.

He'd be working for the major telecom's "network health" team. The goal was to build and maintain applications and reports so that the company would find out about outages before the customer did. At least in theory. Mike was particularly interested in the work since AQ&V was his ISP, and he knew all too well why they'd gained a reputation for terrible service. Most customers, Mike included, had learned that it wasn't even worth bothering to call and complain about outages anymore.

Razing the Farm

The most jarring thing about his first day on the job was the mysterious disappearence of the cubicle farm he'd seen just days before; the entire floor had been rearranged into a bullpen of desks, all facing the same direction. All of the dividers were gone, eliminating any false sense of privacy the employees might've had.

Also, for such a large company, the orientation process left a bit to be desired; specifically, an orientation process. Thankfully, that meant he didn't have to waste a day snickering at the usual sexual harassment policy videos, nor did he receive reams of byzantine paperwork to fill out, but it certainly would've been nice to at least learn where the bathrooms were.

Over the next few days, he met more people on his team. They were all working support, and all doing repetitive tasks using homegrown admin apps – one guy spent all day entering tickets, one gal spent all day generating reports, and others did things Mike couldn't even follow. Mike was taking a slow tour of the company as he moved from computer to computer based on whoever was out of the office that particular day. He was promised a machine of his own in two weeks based on AQ&V's proprietary concept of time. In Earth days, this meant 47.

Write-Only Trouble Tickets

The strange thing about the ticket system was that, while Mike met the guy who spent all day entering tickets, it seemed that no one was actually resolving them, at least not in any timely manner. In fact, everyone seemed invested in writing tickets, logging outages, and tracking uptimes, that it was a small miracle any time an issue actually got resolved. Mike saw an opportunity here – if the entry process was simplified, they could actually start resolving some tickets.

Mike watched over Robert's shoulder as he went to update one of their web apps. He ran a godawful Java application with a hideous UI to export data into a CSV, edited the third column of each row by hand, and then put that data in a MySQL database. Mike asked for the root password for the dev server, and within a few hours had set up a crontab that took care of that whole process by sending mouse clicks, keystrokes, and so on. It was only slightly faster than the manual process, but that didn't matter, as it eliminated the need for a manual process.

After that, he found another member of his team that was doing a repetitive task – another co-worker would open the ticket system, click through a few windows, paste some information from other internal systems (which was almost always the same except for a hub name and one-sentence issue description), record some data into a few different systems, create a spreadsheet, and attach a few screenshots, all the while juggling torches and yodeling.

A much more involved and tedious process called for a much more involved script. For a while it became an obsession of Mike's, to the point that he was interested enough to hack away at it while he was at home. He filled notepads and whiteboards with DaVinci-esque diagrams of the multi-faceted processes, roped in a bunch of different software packages, and by the end had... something. But it worked! The day after he'd finished it, he marched in to the office with a spring in his step. Logging into a neglected dev server, he got an invalid password error. Retyping it more slowly and deliberately did no good: the password had changed.

Focus on your Studies

When Mike checked his email, he learned that Dick, a manager in Florida under Wilson, had decided that the new policy would be that all server changes had to go through him, that Mike and crew don't get to log into the servers anymore, and that he needed a full list of requirements before anything could be changed. Mike went to Robert to complain, but was dismissed with a wave of Robert's hand. "Sorry, Mike, I'm up to my neck in tickets I have to enter."

Now, Mike could respect sensible processes most of the time, but this was a script that he'd worked on for a while that had a pretty involved setup. Lord only knows what dickery had to happen to get the script fully configured and working; it would need PerlMagick, a dozen or so Perl modules, Wine, xdotool, a VNC server, lots of config tweaking, the works. And Dick wasn't the kind of guy that would be able to piece it all together.

After not getting any help from Dick, Mike went to Wilson. "Oh, yeah," Wilson said, "I don't want to deterrence [sic] you from your script. I just want you to really learn the network."

"But this script will allow the team to spend more time on the network; that's exactly what I'm saying! It will quadruple productivity for Danny and Juan!"

"Yeah, but you should be learning the network..."

Try as he might, Mike was being stonewalled. He argued that no one could explain the network to him, as no one apparently understood the network anyway, but it fell on deaf ears. Worse, "learning the network" turned out to be code for "sit quietly with your well-dressed colleagues in the bullpen, entering tickets and logging outages."

Oh well, back to the job board, praying for the day that he can quit.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!