For more than three years I’ve been the person who gets called when a lecture theatre screen won’t connect, a teaching session is about to start, or a system goes down in the middle of a clinical day. I work as a Senior ICT & AV Technician at University Hospitals Coventry and Warwickshire, supporting clinical and admin teams across several departments.
That job is mostly about one thing: keeping technology out of the way so people can do their real work. And after enough tickets, you start to notice that many of the problems aren’t broken hardware. They’re process problems.
The problems behind the tickets
In a lot of support teams, requests arrive by phone, email and in the corridor. Some get logged, some don’t. Simple questions become hard to answer: how many issues came in this month, how long they took, which rooms keep failing. The fix for that isn’t another cable. It’s software.
So I started learning to build it. I took the ALX Foundation Program, which is built around hands-on projects, and Dr. Angela Yu’s Complete Web Development Bootcamp, which covers everything from HTML and CSS to JavaScript and deployment.
What I’ve built so far
- Alicia, a helpdesk prototype for logging ICT and AV issues, tracking tickets and reporting on resolution time.
- Dispenza, a medicine dispensing and stock tracker designed for clinics with unreliable internet.
Both are front-end prototypes. The next step is giving them a real back end, which is why I’m now learning Python, Django and MySQL.
What support work teaches you about design
The best tool is the one nobody has to call you about.
Support gives you a constant stream of feedback about what confuses people. Every “how do I…” question is a design flaw someone else shipped. When I build an interface, I try to answer those questions before they’re asked: clear labels, obvious next steps, and nothing that only makes sense to the person who wrote it.
It also teaches you to care about reliability more than features. In a hospital, a tool that works every time beats a clever one that works most of the time.
What’s next
I’m looking for a junior developer role where I can keep building practical tools with an experienced team. If that sounds like your team, get in touch.
All writing