How Software Engineers Can Reduce Their Carbon Footprint

Software feels weightless, but every query, API call, model inference, and stored byte eventually runs on physical infrastructure. That infrastructure consumes energy and requires hardware.

My original version of this article had a simple message: write efficient code and avoid wasting compute. I still believe that, but sustainable software requires more than micro-optimising functions. The largest improvements often come from architecture, workload management, and deleting work that should not exist.

Measure before optimising

A team cannot improve what it never observes. Start by understanding which workloads, environments, and usage patterns drive infrastructure consumption.

Cloud providers offer tools that estimate emissions associated with customer usage. For example, Google Cloud Carbon Footprint provides dashboards and emissions data for Google Cloud workloads. These estimates are not perfect measurements of every application, but they create a useful baseline.

At the software level, the Software Carbon Intensity specification provides a methodology for reasoning about emissions in relation to a system's functional output.

The goal is not to produce a decorative sustainability dashboard. It is to find decisions the team can change.

Eliminate idle and unnecessary work

The cleanest computation is the one you do not run.

Look for:

• development environments running outside working hours;
• oversized clusters and virtual machines;
• duplicate pipelines producing unused datasets;
• dashboards refreshing more frequently than decisions require;
• logs retained without an operational or regulatory need;
• abandoned storage snapshots; and
• scheduled jobs that nobody consumes.

Automatic shutdown policies, autoscaling, sensible retention rules, and ownership metadata can turn one-time cleanup into normal operation.

Move and store less data

Data movement has a cost beyond the network bill. Repeatedly copying large datasets, scanning unnecessary columns, and retaining every intermediate result all increase infrastructure use.

Data engineers can reduce that waste by:

• filtering and projecting data early;
• selecting appropriate file formats and compression;
• partitioning around real access patterns;
• avoiding accidental full-table scans;
• setting lifecycle policies for temporary data; and
• questioning whether another duplicate is operationally justified.

Duplication can still be the right architectural choice. The point is to make it deliberate and connect every copy to a latency, reliability, or analytical requirement.

Choose architecture before tuning code

Efficient algorithms matter, especially at scale. But optimising a function by 10% will not compensate for an architecture that performs the entire job 100 times unnecessarily.

Before tuning code, ask:

1. Does this work need to happen?
2. Does it need to happen now?
3. Does it need to process the full dataset?
4. Could one result be reused safely?
5. Is the infrastructure sized for normal demand rather than a rare peak?

This is where sustainability often aligns with cost and reliability. Fewer moving parts and less unnecessary work usually mean lower bills and fewer operational surprises too.

Consider where and when workloads run

Some flexible batch workloads can run in regions or time windows with a cleaner electricity mix. That decision must remain secondary to data residency, security, latency, reliability, and service availability.

Carbon-aware scheduling is useful when the workload genuinely has flexibility. It should not become an excuse to compromise user needs or compliance requirements.

Make sustainability an engineering requirement

Sustainable computing works best when it becomes part of ordinary delivery rather than an annual cleanup exercise.

Teams can add questions such as these to design and operational reviews:

• What is the expected unit of useful work?
• How will resource consumption scale with usage?
• Which environments shut down automatically?
• What data can expire?
• How will we detect idle or runaway resources?
• Can we measure improvement after the change?

The strongest sustainability work is often unglamorous: deleting a job, reducing a refresh frequency, right-sizing a cluster, or setting a retention policy.

Less waste is the practical starting point

Software engineers do not control the entire energy system, and emissions estimates contain uncertainty. We do control many of the workloads that consume infrastructure.

Start with evidence. Remove unnecessary work. Measure the result. Then repeat.

That is more credible—and usually more effective—than claiming that one clever code optimisation will save the planet.