Developers love to say "it's not a code problem, it's an infrastructure problem", and then hand it to someone else.

At Kate, alongside building our software, I also look after the company's IT infrastructure: networking, hardware, and making all the pieces of hardware and software work together. So when it's an infrastructure problem, it still lands on my desk.

That's been one of the most useful things I've done as a developer. It changed how I write software, how I think about failure, and how I explain technical problems to people who just want things to work. Here are the lessons that stuck.

Lesson 1: the network is a real thing, not a cloud icon

As a web developer, the network is mostly invisible. You call an API, it answers. When you're responsible for the network itself, you learn what's behind that abstraction: switches, cabling, Wi-Fi coverage, DHCP, DNS, firewalls and internet links that occasionally decide to have a bad day.

The biggest change for me was how I debug. Instead of "the app is slow", I now ask: slow for whom, from where, on which connection? Is DNS resolving? Is it one floor, one device, one network segment, or everyone? A clear picture of the path from the user's device to the server turns a vague complaint into a short list of suspects.

It also made me a more defensive developer. Code that assumes the network is always fast and always there is code that will eventually let a user down. Timeouts, retries and clear error messages stopped being nice-to-haves.

Lesson 2: integration is where the surprises live

Inside an application, you control the code on both sides of every function call. Integrating hardware and software is different. A device has its own firmware, its own protocol and its own idea of how things should work, and you can't open a pull request against it.

What helps:

• Read the manual first, and test with the real device early. The spec and the behaviour are not always the same thing.
• Put a thin layer in between. Same rule as with any third-party API: wrap it, so that when the vendor or model changes, one piece of your system changes, not all of it.
• Plan for the device being offline. Buffer, retry and log, so a temporary disconnect doesn't turn into lost data.

Lesson 3: if it isn't written down, it doesn't exist

This is the lesson I'd put on a poster. Infrastructure is full of facts that live in one person's head: which port goes where, which device has a fixed IP, which licence renews when, which setting you changed to make the printer behave.

Memory is a terrible database. Now I document as I go, not afterwards:

• A network map and a simple IP plan, kept current.
• An inventory of hardware and software, with owners, warranties and renewal dates.
• Short runbooks for common tasks: setting up a new staff laptop, adding a user, restoring a file.
• A change log. "What changed recently?" is the first question in almost every incident.

The test is simple: could someone else handle the common problems on a day I'm not there? If not, the documentation isn't done. That's also, by the way, exactly the same test I apply to a codebase's README.

Lesson 4: backups are a promise you must test

Every organisation "has backups". The real question is whether you can restore from them, how long it takes, and how much you'd lose.

The rule I follow is the classic 3-2-1: three copies of important data, on two different kinds of storage, with one copy off-site. Then I add the step people skip: actually restore something, regularly. A file, a mailbox, a database. Untested backups have a way of failing on the one day they matter.

This carries straight into software. Whenever I design a system now, I think about recovery from the start: what is the source of truth, what can be rebuilt, and what can't?

Lesson 5: access control is mostly about people, not technology

The technical side of access control is well understood: individual accounts, strong passwords, multi-factor authentication, least privilege. The hard part is the human lifecycle around it.

• Joiners: people should get the access their role needs, not a copy of whatever the last person had.
• Movers: when someone changes roles, remove the old access, not just add the new.
• Leavers: a clear offboarding checklist, done on the last day, every time.
• Shared accounts: avoid them, and where you can't, use a password manager instead of a spreadsheet.

It's the same thinking that goes into role-based access in the software we build, like Kate PMS. The difference is that in infrastructure, nobody writes a test that fails when an old account is still active. You have to make the review a habit.

Lesson 6: change one thing at a time

When something breaks, the temptation is to try five fixes at once. Restart the router, update the driver, change the setting, swap the cable. If it starts working, you don't know which one fixed it, and you've possibly broken something else along the way.

Debugging infrastructure taught me the discipline that also makes code debugging faster: form a guess, change one thing, observe, write down the result. Slow is smooth, and smooth is fast.

The short version

• Know the path from the user's device to your server.
• Wrap every integration, and plan for it being offline.
• Document as you go; test it by asking "could someone else do this?"
• 3-2-1 backups, and restore something regularly.
• Access control is a lifecycle: joiners, movers, leavers.
• Change one thing at a time, and write down what you did.

Have you ever had to wear the IT hat alongside the developer one? What did it teach you that code never did?