About Irfan Bhat

How I got here

I came to servers the way a lot of developers do: something I had built stopped working, the hosting support reply was not going to solve it, and I had to learn enough Linux to find the cause myself. That turned out to be the more interesting half of the job.

Working in technical support has shaped how I approach development more than any framework has. When you spend time on the receiving end of "the site is down", you learn quickly which shortcuts cost someone else their evening, undocumented deploys, backups nobody tested, a cron job that fails silently. It makes you build differently.

What I do at ElySpace

My current role at ElySpace covers technical support and development. In practice that is a mix: diagnosing problems for customers, administering servers and hosting environments, and building and maintaining application code.

The support side keeps the development side honest. You find out very quickly which of your assumptions about how people use software were wrong.

How I think about the work

Most of what makes software reliable is unexciting. Naming things clearly. Writing down how the deploy works. Testing the restore, not just the backup. Choosing the boring technology that the next person will recognise.

I am wary of complexity that arrives ahead of the problem it solves. Kubernetes for a site with two hundred visitors a day, a microservice split before the monolith hurt, a rewrite because the codebase is unfashionable rather than because it is failing. Every one of those has a real cost and an imagined benefit.

The corollary is that I will sometimes recommend against work I could be paid for. If managed hosting suits you better than a server I would maintain, I would rather say so than sell you something you will not look after.

Working from Kashmir

I am based in Watergam, in Baramulla district, and most of what I do is remote: for clients in Srinagar and around the valley, elsewhere in India, and outside it. Almost none of this work needs anyone in the room. Code, servers and DNS do not care where you are sitting.

What being here does change is the practical detail. I keep IST hours, which overlaps a full working day with the Gulf, most of Europe by afternoon, and the early part of the US East Coast. For anything time-critical (a migration, a cutover, an incident) we agree the window in advance rather than discovering the gap halfway through.

Connectivity in the valley has improved a great deal, but I do not pretend it is uniform. For work where an interruption would be expensive, I schedule the risky part when I can be certain of the line, and I keep out-of-band access to any server I look after so a bad connection at my end is never the reason yours stays down.

If you are local and would rather meet, that is straightforward to arrange in Baramulla or Srinagar. It is rarely necessary, but for a first conversation about a larger piece of work it is sometimes the fastest way to establish whether we are a fit.

Outside the brief

I read a lot of post-mortems. Incident write-ups from teams operating at scale are the fastest way to learn failure modes without personally causing them, and they are usually more instructive than any tutorial.

I also spend time on the accessibility side of frontend work. It is the part of web development that most reliably gets dropped when a deadline tightens, and it is one of the few things where doing it properly benefits people who would otherwise simply be excluded.