A question with an awkward answer
Software has no exhaust pipe, so it is easy to believe it has no footprint. It has. Every request runs on servers in data centres that draw electricity, and the devices that use them draw more. The question is whether the efficiency of the code you write changes any of that in a way worth caring about.
The honest answer is: sometimes a lot, often a little, and rarely where people first look.
Where the energy goes
Software's climate impact comes from three places. The first is the servers and networks that run it, which consume electricity and require cooling. The second is the devices people use, whose manufacture carries significant embodied emissions, often more than their running cost. The third is the carbon intensity of the grid supplying the power, which varies widely depending on how electricity is generated.
Notice that code efficiency touches only the first directly. A wasteful application can force more servers to run and more data to cross networks. It can also make users' devices work harder and become obsolete sooner, as bloated software demands newer hardware.
When efficient code matters
Efficiency has the largest effect when work is repeated at scale. A tiny saving per request is trivial once, and meaningful when multiplied by millions of requests, or by a job that runs continuously.
Some practical cases:
- Hot paths and batch jobs. Fixing a slow query or an accidental loop that runs against every row is usually good for speed, cost and energy at once.
- Idle waste. Servers kept running at low utilisation use a surprising share of their peak power. Right sizing, and shutting down environments nobody uses overnight, often saves more than code tuning.
- Data movement. Sending large payloads, uncompressed images and chatty API calls costs energy in the network and on the device.
- Background work. Polling every few seconds when an event would do keeps hardware busy for nothing.
The convenient truth is that most of these also cut your cloud bill. Efficiency and cost usually point the same way, which makes it an easy argument to win internally.
When it matters less
Rewriting a working system in a faster language to save carbon is rarely justified. The embodied cost of engineering time and disruption can outweigh the saving, and a rarely used internal tool will not move any total.
Much of the footprint is decided higher up. Where you run workloads, and how clean the local grid is, can matter more than micro optimisation. So can the choice of how much to compute at all: training or running very large models for a task a simple rule would handle is an efficiency choice before it is a code choice.
We should also be careful about claims. Published figures for the emissions of particular applications vary with methods and assumptions, and precise numbers should be treated with suspicion unless the measurement is clear.
What a sensible team does
Start by measuring, because intuition about energy is poor. Track CPU utilisation, memory and data transferred for your busiest services, and cloud provider tools can estimate emissions, with caveats.
Then pick the obvious targets: the heaviest workloads, the idle environments, the oversized instances and the wasteful data transfer. Fix those first.
Finally, make efficiency part of ordinary design review, as you would security or cost. Ask what a feature does at ten times the volume.
A proportionate view
Efficient code is worth writing, mainly because it is cheaper, faster and kinder to older devices, which in many markets matters a great deal. The climate benefit is real but usually modest in any single system, and it is largest where scale or waste is large.
Treat it as good engineering with a useful side effect, not as a substitute for the bigger decisions about where and how your software runs.