Your IT Guy Is Not a Software Developer

In 2005 I worked for Nokia. Nokia dominated the mobile market back then, and the moment I told someone where I worked, a phone came out of a pocket.

Bluetooth won't pair with the car. The ringtone stopped working after the last update. All the photos are gone, can you get them back? I was working on telecom infrastructure — the equipment carrying their calls, not the handset in their hand. I spent a good part of that decade handing phones back to people with a shrug and an apology.

Twenty years later I tell people I'm a software developer, and the phone became a printer. Or a Wi-Fi router that "isn't giving the full speed." Or Excel doing something that Excel has always done. Nothing changed except the object being held out.

At a dinner table this is harmless and mildly funny. It stops being funny when a company makes a hiring decision on the same assumption — and companies do, in both directions, constantly.

Two professions, not two flavours

IT keeps the systems you already have running. Software development creates systems that don't exist yet. That's the whole distinction, and almost everything else follows from it.

An IT team owns the network, the servers, the laptops, the backups, the user accounts and permissions, the licences, the email, the firewall, the antivirus, and yes, the printer. Their day is interruptions. Something broke at 8:40am and the office can't work until it's fixed. A genuinely good IT team produces a strange kind of output: nothing happened today.

A software developer takes a business process that currently lives in someone's head, a WhatsApp group and four spreadsheets, and turns it into a system. That means requirements, data modelling, architecture, code, testing, deployment, and then years of changing it as the business changes. The output is the opposite of invisible — something exists now that didn't exist last quarter.

IT is judged on what didn't happen. Software development is judged on what appeared.

Different work, different training, different temperament, different way of measuring a good week. The overlap is that both groups are comfortable around computers, which is roughly the same overlap a surgeon has with a pharmacist.

"We have an IT team" is not "we can build software"

This is the version I meet most often, and it always starts reasonably.

The company needs an internal tool. Something to track service requests, or approvals, or stock across two branches. There's already a technical person on payroll — he set up the network, he knows every machine in the building, he wrote a script once that renames files automatically. So the project lands on his desk, because who else would it land on?

Six to nine months later there is a half-finished Access database or a PHP page on a server under someone's desk. It works, mostly, for the three people who learned its quirks. It has no specification, no tests, no documentation, and no second person who understands it. Meanwhile the network guy has spent nine months being a mediocre developer instead of a very good IT engineer, and the password resets have been piling up the whole time.

To be clear, this is not about IT people being less capable. Some of the sharpest engineers I've worked with came out of infrastructure, and a few of them made the move into development properly and became excellent at it. But they made a move. They studied, they built things badly for a while, they got reviewed by people who knew more. It's a career change, not a Tuesday.

The honest cost of the internal-build shortcut is rarely the salary — it's already being paid. It's the nine months of delay, the second job nobody is doing well, the key-person dependency, and the rewrite you'll commission later anyway, at which point you pay for the software twice.

And a software company is not your IT department

The reverse is just as common and I'm on the receiving end of this one.

We sign a project to build custom software. Somewhere around week three the questions start arriving: can you set up the new email accounts, can you look at the Wi-Fi in the back office, we're buying five laptops which ones should we get, the accountant's Windows licence expired. Small things, and we help with small things — but it's not our profession, and being polite about it doesn't make us good at it.

The expensive version is a company that lets its IT support go because "we work with a software company now." Nobody is patching servers. Nobody is testing whether the backup actually restores. Nobody notices that four ex-employees still have active accounts. Then somebody in accounting opens the wrong attachment, and the people who find out first are the ones who built your application and have no mandate, no access and no tooling to deal with it. When I wrote about the Lebanese breaches back in May, the conditions that made them trivial were nobody watching, no patching schedule, exposed admin panels and passwords set once and never changed. That's the boring, unglamorous side, and it has an owner or it doesn't.

My team can build you a system that runs your entire operation. We will not know that your domain controller has been unreachable for eleven days.

How to tell which one you actually need

You don't need to understand either profession to route the request correctly. Four questions do most of the work:

1. Is the thing broken, or does it not exist? Broken is IT. Doesn't exist is development. This one question sorts about 80% of requests.
2. Would solving it permanently mean writing something new? If the fix is a process, a screen, a report or a rule that has to live somewhere, that's development.
3. Is the complaint "we can't get to our data" or "our data is wrong"? Can't get to it is IT. Wrong is almost always a software or process problem, and copying it to a faster server won't help.
4. Would you describe the pain as "slow" or as "manual"? Slow is usually infrastructure. Manual means a human is doing something a system should be doing.

The one that genuinely lands in the middle is integration — the ERP not talking to the e-commerce site, the accounting package not seeing the warehouse. That needs a developer to build it and IT to give it somewhere to run and credentials to run with. Those projects go well precisely when both sides are in the room and badly when one of them is asked to cover for the other.

Most Lebanese SMBs have neither. They have "the guy"

Everything above assumes you have an IT department and a development partner, and are just sending work to the wrong one. Most small and medium businesses here have neither.

What they have is "the guy" — a nephew, a supplier's technician, a cousin who does websites. He installed the point-of-sale, he set up the router, he built the Excel file everyone depends on, and he answers about half the time. Since 2019 this got worse for reasons nobody needs explained: budgets shrank, good people left for the Gulf, and one affordable person covering everything looked like the only realistic option.

I understand how businesses ended up here and I don't think less of anyone for it. But it is worth being honest about what it is. One person at 40% capacity on two professions is not a cost saving — it's a deferred bill, and it comes due on the day the shop can't invoice.

The fix isn't hiring two departments. For a company of fifteen people it's usually a small IT support contract for the keeping-things-running half, and a development partner brought in per project for the building half. Two clear owners, neither of them full-time, and a phone number for each that isn't the same number.