I’m late to the party on May’s T-SQL Tuesday, but thought it was an interesting enough topic to be worth a belated blog post. It’s about first technical jobs – hosted by Kenneth Fisher.
My first technical job was somewhat unusual. It was for a niche software company that made despatch software for taxi companies. It was a small company, but had the majority of the UK market as customers at the time, and offered 24/7 support, so was very busy. The company supplied their software, but also most of the applicable hardware – computers, networking, radio systems and mobile devices. I’d been a barman for the previous two years – I quit that job with the intention of going back to college to study some certifications to work in IT, but that fell through a day before they were due to start as nobody else wanted to do the courses, so they were cancelled. Out of necessity from suddenly having neither a job nor any educational funding, I hastily applied for a few tech support jobs, one of which offered an interview.
The interview was very informal. I was asked if I could take apart and put together a PC, which I could, though wasn’t made to prove it. And then some general Windows and hardware questions. The company was hesitant to hire me as I didn’t have a full degree – just a diploma in maths and computing – but I will have no doubt pleaded my case by telling them I’d started programming in BASIC while still in primary school, Visual Basic and C in my teens and spent a lot of hobby time since then messing about to various degrees with computers and coding – so I knew my way around Windows and software. I got the job, albeit on lower pay than usual given the lack of degree – and was given some thick printed-out booklets covering the ins and outs of their software, and every evening for the next few weeks, reading through those archaic texts was my life.
Fundamentally it was a tech support role. But what I had to support was where it got interesting – and challenging. First was the basic Windows kind of stuff – most customers had a mix of Windows Server 2003/2008 and WinXP, and we had the ability to remote into their sites to take control of the servers, so nothing too problematic there – but a handful of customers remained on DOS. Yep, DOS in…2011. This was the support call we dreaded. It meant no remoting, and having to talk (usually not very tech-savvy) people through troubleshooting via the CMD prompt and/or unplugging and plugging various serial cables to peform a physical DR switchover . Occasionally at 2am. That stuff was…character building.
Then there was the software on top. There was both a text-based, terminal style version, and a new GUI version. It was complicated software providing both despatching and accounting features, with extensive logging and hundreds of config flags hidden in the admin options that needed to be checked in the course of diagnosing problems. Fortunately, as well as the aforementioned manuals, there was an internal Wiki maintained by the developers documenting most of these config flags and processes, but this didn’t cover every new setting or, obviously, undiscovered bugs. We, the support team, added to this invaluable resource as we found new issues or new information about settings and processes.
Finally there was the hardware. Every taxi needed a device to communicate back to the office. At the time we were rolling out mobiles, but most customers still had radios. And thus I was introduced to the intersection of computers and radios – Moxa devices with Ethernet/Serial connections to link the server to the radio system. And radio comms logs in the software logging broadcast and received signals, retries, errors etc. Some issues we could diagnose ourselves, like areas of bad signal by piecing together radio logs with the map corresponding to different physical locations, but we also had a team of radio engineers we’d often have to take more complicated issues to.
It was a baptism of fire for a first technical job in many ways. Not only did we have to support typical Windows and networking issues, but also multiple versions of completely bespoke software, radio comms and accounting issues. For around a thousand customers, who each had their own unique configs, radio environments and incident history – and all depended on their software for their livelihoods. The team was small, and sometimes the phones would be ringing off the hook all day, especially around holidays when these companies were at their busiest. I had an extra challenge in that I had/have a mild stutter that, while not normally a problem, is worse on phones – so that was a case of adapt or die, quickly. Some of the customers, being external not internal, could be…well, rough around the edges would be an understatement. A few times I had threats someone was going to drive down and throw their system throw the office window. (they never did)
The on-call rotation, when I learned enough to join it, could be brutal. Sometimes we’d get a dozen calls in a night, and would turn up bleary-eyed at 8:45 the next day. The subsequent evening was almost always a total write-off – get home, sleep. I appreciated the extra money at the time, but it was the kind of sleep and health sacrifice only someone in their early 20s would reasonably choose to take!
Challenges aside, I’m forever thankful for that job (and for my bosses-to-be for taking the chance with me). We had good teams of people – the support team helping each other out massively – knowledgable old hands, had fun despite the challenges, and I got involved in things beyond application support – I’d completed my CCNA so I ended up doing a new standard router config, got involved in bug testing, and also picked up MySQL rollouts and support as I’d also been studying SQL. I learned a lot about how to communicate with non-technical people, manage expectations and deal with a very busy helpdesk by staying on top of the most important issues. Additionally, I got exposure to the fundamentals of software testing, the challenges developers face, and training new staff on the systems we supported.
I didn’t want to stay in a niche support role forever – and at the time, I saw the shadow of Uber looming on the horizon as an industry threat – so had explored both networking and SQL as progression routes, and ended up choosing SQL. After a few years I left the company, moving out of the trenches to a much quieter backend role supporting MSSQL-backed apps and subsequently into SQL/SSRS development and administration. It was the right move for me and I don’t miss the support life, but I will always have massive respect for tech support after being on the other side of the phone.