Green Coding: can we really code in an eco-friendly way?

A click, a page load, a calculation — at the level of a single user, it seems insignificant. Yet multiplied by billions of server requests, this ordinary gesture becomes an energy torrent. Green coding offers an alternative path: a more mindful, resource-conscious approach to development. Engineers see it as an emerging discipline, while sceptics call it a marketing illusion. Who’s right?

Green coding: between idealism and technological reality

From sustainable code to conscious code

Green coding did not emerge from a marketing slogan but from a slow conceptual evolution. Its roots lie in three converging movements: Green IT, which seeks to reduce the environmental footprint of infrastructures; Clean Code, focused on readability and maintainability; and the Low-Tech movement, which values frugality and technological sustainability.

At the crossroads of these influences, green coding repositions the developer as an agent of digital sobriety — not merely performance.

Its foundations rest on three interdependent pillars:

• Performance, aiming for efficient use of computing power, memory, and I/O.

• Sobriety, prioritising functional simplicity over feature overload.

• Software durability, ensuring longevity and reducing costly rewrites.

This triad is not just about optimisation — it’s about redefining the act of coding: finding a balance between technical precision, environmental awareness, and a realistic view of digital impact.

Yet, the term “green” in a world driven by data overconsumption and computation power remains paradoxical. Digital technology promises immateriality but relies on very tangible foundations: cables, servers, rare earths, electricity.

An oxymoron, in short: coding “green” within an inherently energy-hungry system.

The environmental footprint of code: where does digital pollution really hide?

Digital pollution doesn’t stop at visible machines. It seeps into every stage of the software lifecycle — from development to decommissioning.

To develop is to consume: every build, every unit test, every staging environment activates servers.
To execute continues that consumption: energy use depends on queries, calculations, and code complexity.
To maintain requires ongoing resources: updates, backups, logs, monitoring.

Three major areas concentrate most emissions:

1. Data centres, which host and run applications — cooling alone can represent up to 40% of their total electricity use.

2. User devices, often overlooked, but major contributors to carbon emissions due to hardware renewal.

3. Data transmission networks, whose exponential growth drives energy use linearly upward.

And the source code itself? Though seemingly immaterial, it directly influences these flows. Bloated or overly complex code, or one dependent on heavy libraries, increases execution time, server calls, and CPU demand.

Conversely, a lean, well-structured codebase — free of unnecessary dependencies — lowers CPU load and energy expenditure.

Thus, the way code is written acts as a subtle but measurable lever of digital sobriety.

What green coding is not: debunking misconceptions

Green coding is not just about compressing images or improving page load speed. A fast website is not automatically eco-friendly — an aggressive optimisation engine might enhance perceived performance while increasing client-side CPU load.

Likewise, ultra-minified code doesn’t guarantee overall efficiency: functional logic or call structure can offset those gains.

Paradoxically, slightly larger but better-architected code can consume less energy during runtime. The true impact lies more in runtime behaviour than in raw file size.

Finally, one must recognise the developer’s limited role in the energy chain. Infrastructure choices, cloud providers, update and storage policies all extend far beyond the code itself. Green coding is a targeted contribution — not a complete solution.

The limits and controversies of green coding: between pragmatism and utopia

The performance paradox: more optimisation, more complexity?

The pursuit of perfect energy efficiency sometimes leads to the opposite of sobriety.

Every performance gain stimulates demand, accelerates usage, and shifts energy consumption elsewhere — the well-known rebound effect in energy economics. Optimising code to the extreme can reduce energy per request but multiply requests, interactions, or client-side load. Step by step, local improvement becomes global overconsumption.

This dilemma extends to the triad of speed – accessibility – sustainability.
A highly dynamic, visually rich site boosts engagement but strains CPUs.
A minimalist, static interface eases machine load but risks reducing user experience quality.

The most striking example lies in machine learning and so-called intelligent systems. Training a language model or predictive AI can require thousands of GPUs running for days or even weeks.

For comparison: a single training session of a large-scale model can emit as much CO₂ as a transatlantic flight.

This algorithmic complexity, designed to improve efficiency, actually increases energy consumption. “Smart code” often ends up heavier than traditional code — due to dependencies and complex computation pipelines.

The blind spots of green code: hardware, storage, and obsolescence

Green coding often focuses on software design while neglecting the physical foundation of digital technology.

Each software optimisation runs on ageing hardware, often struggling to keep up with constant updates. This software-induced obsolescence — triggered by unmaintained dependencies, deprecated APIs, or ever-heavier frameworks — accelerates hardware disposal.

In other words, “modern code” can prematurely retire still-functional machines.

Then comes the cloud vs. edge computing debate.

Cloud computing centralises maintenance and shares resources but requires constant data transfer to data centres.
Edge computing, on the other hand, processes data closer to users, reducing network load but fragmenting computing power.

Neither approach is entirely “green”. The optimal choice depends on system topology, data volume, and user location.

Finally, data storage remains the great blind spot of green coding.
Unpurged logs, forgotten caches, duplicated databases, and redundant backups form a dormant mass of energy-hungry bytes.

The cost of this inertia is massive. Today, data itself, not code, represents the primary source of digital energy waste.

The ethical and socio-economic dilemmas of green coding

Green coding has a cost.

Time spent auditing, measuring, and refactoring adds to project timelines. Carbon measurement tools are still rare, and specialised profiles — sustainable DevOps engineers, eco-design experts — remain scarce. The ROI of sobriety is slow to prove, especially in fast-paced, profit-driven environments.

Moreover, there’s often a gap between talk and action. Many companies showcase “responsible coding” without tangible metrics.

Ethically, another challenge arises within tech teams: how to avoid green moralising — the sense of being guilt-tripped into coding “clean”?

Software sobriety cannot be decreed. It must be taught, tested, and shared. It requires cooperation, not guilt.

The goal isn’t to impose ecological virtue on developers but to foster a technical culture where every coding decision consciously carries an energy dimension.

Towards a more sustainable digital ecosystem: the role of developers and the community

Educate, raise awareness, build culture

Green coding won’t thrive without transmission. Collective initiatives are already paving the way: Green Code Initiative, which pools energy analysis tools; Code Lutin, supporting open-source eco-design for over twenty years; and Boavizta, publishing public references on digital environmental impact.

These projects act as catalysts — structuring research, democratising measurement, and enabling a more sustainable yet ambitious form of engineering.

Certification programmes also help foster this culture:
NumEcoDiag for environmental analysis of digital services, and RGESN (General Framework for the Eco-Design of Digital Services) for public compliance.

Such frameworks standardise practices and encourage companies to embed sustainability into their quality processes.

From isolated practice to collective commitment

Coding sustainably is no longer enough; sobriety must be embedded into product culture and technical governance.
No application is neutral — it results from trade-offs between business goals, user experience, and infrastructure.

Therefore, sustainability is not an individual effort but a team strategy.

Truly sustainable projects rely on shared responsibility.
Developers, designers, DevOps, and Product Owners act together: designers limit visual excess, DevOps monitor deployments, developers optimise code. Even clients contribute by accepting simplicity as a value, not a compromise.

Open source also accelerates this shift.
By sharing libraries, benchmarking transparently, and reusing tools, teams avoid redundant work. Less reinvention, more collaboration.
A sustainable ecosystem thrives on this collective logic: well-tested, documented, and lightweight code benefits everyone.

And tomorrow? The radical paths toward truly sustainable code

Some approaches push the boundaries even further.
The concept of Slow Code embodies this idea: coding deliberately, thoughtfully, where every line must justify its existence. This philosophy promotes functional restraint and simplicity as levers of innovation.

Ephemeral architectures extend this concept — activating computing resources only when needed, as seen in serverless environments.
Less constant execution, less wasted energy.

The rise of Green AI follows a similar philosophy.
Research labs are building lightweight, compressed AI models trained on smaller yet higher-quality datasets. This approach values relevance over scale.

It opens the way to frugal computation, capable of solving precise problems without consuming terabytes of data.

And finally, a radical question emerges: should we code less?

The notion of a post-digital future, where we reduce software production instead of optimising it, is divisive.
It challenges the very purpose of development: should we keep creating endlessly, or sustain what already exists?

Coding green - with lucidity

Green coding goes beyond mere optimisation.
It invites us to rethink the purpose of code, the value of computation, and the developer’s role in the global energy economy.
In this sense, it acts as both an ethical and technical catalyst — a way to unite performance with awareness.

The goal isn’t perfect “green code” but measurable, shared progress.
Every lighter build, every deleted request, every meaningful refactor contributes to a more sustainable digital world.

Ultimately, sobriety must extend beyond code — to infrastructure choices, product design, and user habits.
Only then will digital technology stop pretending to be immaterial and become a truly controlled space once more.