Klint: Let’s begin with awareness. How can developers learn about the climate impacts of their code?

Niki: Start by picking your metrics. Carbon footprint and energy use are very closely linked to sustainability. Energy consumption is what we see most often, but carbon is the most impactful. Cost is a good proxy metric since reductions in cost are often linked to reductions in resource utilization. Kepler and Scaphandre are good tools for measuring software energy use. Also, the major cloud providers have carbon dashboards. But there's generally a lag of up to a few months between usage and reporting, so those dashboards are better for long-term trends than immediate usage.

Tejas: I'll echo what Niki said about cost as a good proxy metric. Software that is expensive to run tends to be bad for the environment. The other thing to look at is the performance of your code. Performance can mean a lot of things, including how fast it runs and the resources it uses. FlameGraph is a good tool to see the "hot" parts of your code: The parts that aren't performing so well and are likely consuming excess resources.

Arne: If you don't have a background in energy, Green Coding Berlin has a few helpful resources. There is a free course from the Hasso Plattner Institute University at Potsdam University that covers fundamentals like greenhouse gasses, what CO2 is and why it’s emitted, and how tech fits in. There is also the Green Software Practitioner course from the Green Software Foundation. It only takes around 20 minutes, but provides plenty of additional information, such as how energy is calculated and what things like a “kilowatt hour” are. It gives you a more in-depth appreciation of what the various terms and metrics mean.

Green Coding Berlin also develops the Green Metrics Tool, which performs code analysis to measure the energy/CO2 consumption of software architectures. You can use it to create badges for your website and GitHub repository, which allow you to be transparent about your software's carbon usage.

Klint: What are some of the most energy-intensive things that developers should stop doing? The low-hanging fruit, if you will?

Arne: I come from a web background, so my focus is on web optimization. Performance optimization tools like Google Lighthouse can help identify inefficient parts of your web application that simultaneously slow your site down for users and waste energy. There could be low-hanging fruit there. Also, optimize your images: The less data you're sending over the network, the less energy you use.

Tejas: The most common issues are in how we write code. Loops are a big factor. If you write a lot of loops and jumps, you're likely unable to use caching to reduce the number of times different processes run and make your code more efficient. For example, event-driven architectures are generally better than polling-based architectures that have endless loops waiting to receive events.

Artificial intelligence is helping the world, including fighting climate change, but we need to be mindful of the impact and ensure we are using clean energy sources to power it. So we have to think about what problems best benefit from AI, where the energy used comes from, and which problems might be more easily solved with simpler algorithms.

Some other low hanging fruit is "dead code"—code included in your application but not used. It still consumes memory, thus wasting resources. Most IDEs have pretty good tools for finding and removing dead code, so there's no reason not to root it out.

Niki: Just as you should turn off lights when you leave a room, you should turn off your development environment when you're not using it. It's easy to leave old test environments or experiments running long after you've stopped using them. Holly Cummins has a great talk where she explains the concept of"zombie clusters" or "zombie VMs." Delete these or at least shut them down when you're not using them. It is also a good idea to do scheduled deletions, labeling strategies, and other FinOps techniques. Another thing you can do is make sure your cloud workloads are running in regions that supply green energy, when possible. The WattTime API and Electricity Maps can help with this.

Klint: What role does language and stack choice play? I've seen claims that building software in a more efficient language like Rust is beneficial for the climate. But how big a difference does that really make? Are there more important considerations?

Arne: You're probably referring to a study that found that compiled languages like C and Rust are the most energy-efficient, and that scripting languages like Python and Ruby use far more energy. For example, the researchers found that Python uses around 75 times the amount of energy that C and Rust do. Based on that, it looks like it's a no-brainer to use C or Rust. And while the study is well-designed in terms of comparing each language running the same algorithm, it doesn't account for the lifecycle of an application. For example, how much time and energy you spend building and maintaining an application, not just running it. Another issue that Python programmers will bring up is that NumPy and many other important libraries are actually written in C, so the most computationally-intensive parts of an application will actually be running in C. It's just the "glue code" written in Python that's less efficient. The study doesn't account for that.

Tejas: Right, it's not exactly an apples-to-apples comparison. All else being equal, use the language closer to the metal. But it's not always practical to use C or Rust for every problem. More than just your language choice, your choice of optimization flags has an environmental impact. Where you run the code and whether or not it uses renewable energy probably matters more than anything.

Niki: I would say picking a language is an important part of workload-level optimization. For example, Quarkus is doing a lot around writing greener Java applications. But the language is just one part of the stack. Large-scale optimizations might be more impactful than workload-level optimizations. Infrastructure-related cost savings can be a great way to pitch sustainability to your managers. If your organization can shut down a whole server rack, or a whole Kubernetes node in a data center, it can save money, energy, and carbon. The Green Software Foundation maintains a list of green cloud patterns that can help to reduce the carbon intensity of your infrastructure.

Klint: How can developers move beyond individual decisions and help make their teams more energy-efficient as well?

Tejas: Build sustainability into your CI/CD pipeline. Many existing performance tools can be integrated into CI/CD pipelines today. For example, you could use the GreenFrame GitHub Action to check your code's carbon footprint and reject a build if the footprint is too large. More tools are in development. You can also explore new programming languages. For example, EnerJ is a language and framework that helps developers optimize code for energy efficiency.

Arne: Green Coding Berlin also makes a tool for analyzing the energy usage of CI pipelines themselves. We're focusing on GitHub Actions first.

Niki: I recommend looking into serverless functions and GitOps. Serverless functions only run when they're called, so they're not sitting there wasting energy when they're not in use. GitOps, meanwhile, helps with observability and monitoring the resources running in your infrastructure. To get started with GitOps, you need to map your entire system infrastructure, so you end up with more visibility into what is running. You're less likely to lose track of things. GitOps can also help automatically turn off test infrastructure when it's not in use since it gives visibility of the desired state of your infrastructure. For example, you can create policies and labels that indicate how long different development environments need to exist. You can also use tools like KubeGreen to automatically scale down Kubernetes resources outside of working hours in your development environment.

Developers can also advocate for sustainability in their teams and departments by pushing to include environmental sustainability in your product roadmap, your sprints, and your company's values. Again, there's a strong overlap between sustainability and cost controls. Finding and eliminating redundant workloads or unused clusters saves both money and energy.

Arne: Adding on, we’ve found that people are confused by what various metrics mean, so it can help to provide your team with easily understood metrics. We like to use the Software Carbon Intensity specification. It offers a number that makes sense to people, like how much carbon a single API call costs. That makes it easier to reason about the impact of different products and features. You can also use these metrics in marketing. For example, if you reduce the amount of carbon a product uses, you can advertise that fact.

Klint: Any other thoughts or tips?

Arne: Here in Germany we have a sustainability certification program called Blue Angel. Its "eco-labels" generally apply to hardware and other physical products, but last year KDE Okular became the first piece of Blue Angel–certified software. Green Coding Berlin and the KDE Eco program are working on bringing eco-labels to more software. We have certifications and labels for other things in software, like SSL, so why not sustainability?

Niki: The Green Software Foundation is doing really interesting work in this space. They have a podcast called “Environmental Variables,” if you want to learn more. I recommend the episode on how legislation will impact software and sustainability, especially in Europe and the U.S., where there’s a lot happening.

Tejas: I always advocate for the use of energy-efficient devices. Also, try to fix existing devices instead of replacing them, because most of a device's carbon footprint is generated before it's ever in your hands. Finally, put some plants in your workspace to absorb CO2 while you code.