A website once reduced its cloud bill after an engineer found a job that was processing the same data over and over.

The fix was tiny.

The environmental benefit was tiny too, at least for one application.

But I liked the story because it exposed something software hides very well: code consumes physical resources.

Servers use electricity. Networks move data through equipment. Storage systems keep disks and chips running. Phones spend battery power decoding images, running scripts and talking to distant services.

Software feels weightless because users cannot hear the data centre.

The electricity bill still exists.

Green software is partly the practice of remembering that.

Efficiency became uncool for a while

Computing power became cheaper and easier to rent.

That was wonderful for software development.

It also encouraged a certain laziness.

Why optimise a slow job when another cloud instance can be added? Why delete old data when storage is cheap? Why compress a file carefully when broadband is fast?

At small scale, these choices barely matter.

At enormous scale, repeated inefficiency becomes infrastructure.

A function wasting one second is nothing. A function wasting one second billions of times is a fleet of servers doing unnecessary work.

Performance engineering and environmental efficiency often point in the same direction.

Do less useless computing.

Very complicated idea.

Data transfer is not free

The internet feels instantaneous, which makes data movement easy to ignore.

A website loads several megabytes of images, scripts, fonts and analytics on every visit. Millions of visits turn that into substantial network and processing activity.

Reducing page size can improve load time, lower mobile-data use and reduce computing work across networks and devices.

Users notice the speed.

The infrastructure notices the smaller workload.

This is especially relevant in places where connections are slow or energy-constrained. Efficient software is often more inclusive software.

A lightweight page works better on an older phone.

Sustainability sometimes looks exactly like good engineering.

AI makes the energy question harder to ignore

Training and running large AI models requires significant computing resources.

The exact energy use varies enormously by model, hardware, location and workload, so I am suspicious of simple claims like “one AI question equals X household activity.”

Reality is messier.

The broad point stands: bigger models and more inference require more computation.

That creates an engineering question.

Does every task need the largest available model?

Probably not.

A small model may classify a simple document perfectly well. A cached answer may avoid repeated generation. Local processing might make sense for certain tasks. Batch work can reduce overhead.

AI teams are learning the same lesson web developers learned earlier.

Capability should match the job.

Carbon intensity changes by time and place

Electricity grids are not equally clean everywhere or every hour.

The mix of solar, wind, hydro, nuclear, gas, coal and other sources changes with location and demand.

Some computing work can move.

A flexible batch job does not necessarily need to run at 2 p.m. today. It might run when cleaner electricity is more available or in a region with a lower-carbon grid, assuming latency, privacy and cost allow it.

This is called carbon-aware computing in some circles.

It sounds complicated.

The idea is ordinary scheduling.

Do flexible work when the physical system can support it more cleanly.

Not every workload is flexible. Emergency services and interactive applications cannot wait for a windy evening.

Batch jobs often can.

Hardware life matters too

Software decisions affect hardware replacement.

A new operating system may require more memory. A website becomes so heavy that an old laptop struggles. A mobile app stops supporting devices that remain physically functional.

Sometimes these changes are necessary for security or new capabilities.

Sometimes they are consequences of software bloat.

Extending hardware life can avoid the environmental cost of manufacturing replacement devices. That makes efficient, long-supported software part of sustainability.

Developers rarely control the entire product lifecycle.

They do influence whether a simple task requires a machine twice as powerful as five years ago.

Performance budgets are not old-fashioned.

They are discipline.

Storage loves to become permanent

Companies keep data because deleting it feels risky.

Logs, backups, analytics exports, old media, temporary files that became permanent through neglect.

Storage is cheap enough that cleanup projects lose priority.

Then years pass.

Keeping data has energy and hardware costs. It also creates privacy and security risk.

If the company does not need detailed logs after ninety days, perhaps do not keep them for seven years.

Retention should have a reason.

This is one area where sustainability, privacy and security align beautifully.

Delete useless data.

Three teams become happier.

Developers need measurements, not guilt

I do not think software engineers should feel personally guilty every time a server executes a loop.

That is not a useful management system.

Teams need measurements.

Which services consume the most compute? Which workloads run unnecessarily? How much data moves? Which environments stay idle? What is the relationship between customer value and resource use?

Cloud providers increasingly expose energy or emissions information alongside usage data, though methods and detail vary.

Use what is available.

Optimise the large waste first.

Spending two weeks reducing a tiny service by three percent while an abandoned cluster runs continuously next door is sustainability theatre.

Priorities matter.

Users should not carry the whole burden

Technology companies sometimes tell users to make environmentally responsible choices while designing services that autoplay video, refresh endlessly and encourage device replacement.

Users have responsibility.

Companies have more control over the system.

Default settings matter. Efficient codecs matter. Data-centre design matters. Hardware support policies matter.

If sustainable behaviour requires every customer to open an advanced settings menu and disable five features, adoption will be limited.

Good defaults scale.

That is true in security, privacy and energy use.

The greener version is often simply better

I like green software because the practical version does not require developers to become climate scientists.

Avoid waste.

Use the right amount of computing. Move less unnecessary data. Keep hardware useful longer. Delete information nobody needs. Schedule flexible work intelligently.

These choices often make software cheaper and faster too.

There will be trade-offs. Redundancy consumes extra resources but improves reliability. Encryption costs computation but is worth it. Backups duplicate data for a good reason.

Efficiency is not minimalism at any cost.

It is spending resources deliberately.

That tiny repeated job I mentioned was removed.

Users noticed nothing.

The cloud bill dropped.

Sometimes the best software improvement is work the computer no longer has to do.