Terra.do, Part 2: Software Stacks in Climate
It’s been a while since the last post (more on that in a minute), yet somehow a bunch of you have stumbled onto this site in the meantime and, in what I can only assume was an honest mistake, subscribed to the newsletter. (I have a hunch a reference from the great Steven Zhang of ClimateTechList was responsible for several of you wandering this way.) So, for those who are new around here, let’s make sure you know what you’ve signed up for!
As noted in The First Post, I’m doing this for me, not for you. My goal is to learn more about climate change and its solutions, and to learn by working hands-on with data, as I’ve advised so many aspiring sports analysts over the years. I don’t promise it’s going to be exciting (my wife would guarantee you that it isn’t), and I don’t promise that the content will fit any sort of pattern or trend. It certainly won’t be regularly timed. I do this in odd moments between my top priorities (#1 family and #2 work), which arise sporadically at best.
That said, you, dear reader, can help me. Just knowing you are there, I am nudged to keep pushing, keep learning. If you have any thoughts, reactions, suggestions… I welcome them. If you learn something too, that’s a bonus for us both.
Since last time…
So, with that out of the way… why has it been so quiet around here? Well, since the previous post on the Bayou Energy Hackathon, I coached both two basketball teams, we saw family for the holidays, and my kids somehow passed around two different strains of the flu (of which I caught at least one). Oh, and for the first time in six years, I switched jobs. So, it’s been busy.
That doesn’t mean I haven’t been thinking about the climate, however. I picked up a new book by Hannah Ritchie, who was one of the inspirations for this blog. (I’ll have to share my notes from the book in a future post.) And, I completed the four-week Terra.do course Software Stacks in Climate Tech, which I will be writing about today.
Software Stacks in Climate Tech
This is the second course I took from Terra.do, with the first covering carbon accounting. The course description promised to cover “public climate-relevant data sources, energy modeling, and software/hardware interfaces”. If you have followed this blog, you have realized that public climate data sources and energy modeling have been central to most of my posts thus far. This was right up my alley.
However, I was almost scared off. I’m not a software engineer, so would I really meet the requirements for a course that is nominally about writing software? The course prequesites note that “Prior software engineering experience in Python is recommended but not required”. On one hand, my Python experience was very minimal. On the other, the course course was intentionally targeted towards not only engineers but also product managers and data scientists. Though I’m no longer an individual contributor, I felt like I could pass for a product manager or data scientist at least, so I pulled the trigger.
Course Content
The instructors, the husband and wife team of Jamie and Jason Curtis, have experience working as software engineers across a number of energy and climate companies as well as Meta and Microsoft. The course consisted of biweekly online presentations, supplemental reading materials, coding exercises, an optional hardware project, and a final portfolio project.
Week 1 - Introduction, Software x Climate Landscape
Week 2 - Public Data Sources, Energy Modeling
Week 3 - Hardware/Software Interfaces, Final Project Kickoff
Off Week (to work on final projects)
Week 4 - Final Project peer feedback and final presentations
Class time (1.5 hours, 2x/week) was reserved for recaps of the reading material, light overviews of the topics, a few group breakouts, and introduction to the assignments. As with the Carbon Accounting and Reduction course, most of the substantive reading material was freely available online, some of which I had encountered previously. As with the Carbon Accounting course, this curriculum points you to other resources that you of which you might not be aware and helpfully puts it all together.
Coursework
The course assignments were the real meat of the course, as you might expect from a software-focused course.
The challenge for the instructors was in appealing to a wide range of technical backgrounds. Our class was about 50% software engineers, with product managers and data scientists included in the other half.
The instructors addressed this variation by:
Providing well-commented, baseline code (mostly Python, with some SQL) for each assignment
Pre-loading the relevant data sets
Allowing “bare minimum” submissions (it is a voluntary, pass/fail course after all)
Leaning on Hex notebooks plus the Hex AI “Magic” feature to level up the less experienced programmers
Hex notebooks are analogous to Jupytr notebooks but with SQL and more UI elements, including data visualization tools. I had not used Hex before but found them suitable for this use case.
Regardless of your programming experience, you will get out of the course what you put into it.
If you wanted to skate by, you could simply change a couple of parameters in the provided template and turn it in. You could put in 3-5 hours/week on the course and pass. But, what’s the point of paying for the course if you’re not challenging yourself and learning?
If you didn’t have a strong Python programming background, you could lean on the Hex AI Magic to handle the first draft of your code or debug code that’s not working. Sometimes, I found this feature to be great; other times, it returned complex code that didn’t actually run or return what I needed. It has the potential generate new code from a text description, modify existing code to add a new feature, or debug existing code. The results weren’t always eloquent (sometimes there were cleaner solutions than it suggested), and sometimes they didn’t run without throwing errors, but with some patience for iteration and manual intervention, you could usually get it to work. This was an eye-opening tease of the future of programming (software engineering, data science, etc.), something I’ve taken with me to my day job.
At this level, you’re probably putting at least 8-10 hours/week for the course.
If you had a programming background and wanted to challenge yourself, the table was set for you. With relevant data sets pre-loaded, you could run in whatever direction you wanted, putting in as much time as you wanted.
Here’s a quick list of the assignments:
Assignment 1.1 - Intro to Hex notebooks, summary of student backgrounds
Assignment 2.1 - Electricity Demand and Generation, using the EIA’s API. I looked at the PJM balancing authority’s generation mix, which I have explored previously on my own.
Assignment 2.2 - Models of Rooftop Solar or Home Energy Usage. I modeled my home’s solar production using NREL data and the Python library pvlib. Pvlib shows great promise for projecting solar production based on the location, weather, and type, number, and orientation of the solar panels; however, in my case, the library seemed to be missing my specific LG solar panel model, and I ran out of time to modify the code to handle an array split between two orientations. However, it is something I would like to come back to as time permits, as it is closely related to other studies I’ve done here on Substack.
I can now see a direct line from this project to how companies like Aurora Solar and PVcase build their software to design solar arrays. I won’t claim to have professional expertise based on such projects, but I succeeded in learning enough about projecting solar production that I am capable of diving deeper into the subject further as desired.
Assignment 2.3 - IoT Data Logging. This was an optional hardware project where you could order weather and air quality sensors, assemble and connect them, and monitor the atmosphere around your own house. The data from all of the sensors was made available to the class for analysis for this assignment. Thin on time, I opted not to purchase the additional hardware. Unfortunately, I found the quality and sample size of the collected data was limiting, so it I didn’t get as much out of this assignment as the others.
Final Project - EVpocalypse
We had our own choice of a climate-related software project, either solo or (preferably) with a team. You are loosely encouraged to utilize some of the skills or data sets from the class, but otherwise the choice of topic is wide open.
I connected early in the class with Phil Li, a climate tech investor with a product background. We shared an interest in EVs and EV charging, which sparked some ideas for the final project. We connected with Bill Ferro of EVSession, a previous connection I’ve spoken with a few times. Bill was kind enough to share a sample of data and provide some guidance for our final project. Thank you, Bill!
We decided to explore the effect of a recent nationwide cold spell on EV charging. EV charging issues made national news in certain areas where travelers were stranded in the cold while waiting for a functional charger. We wanted to look into this further to see exactly what was happening.
Phil and I took a deep dive into Bill’s data and ultimately presented to the class in two parts: a case study focused on a specific Chicago charging station that was featured on local news, and a national study of the effect of weather changes on EV charging performance.
Our project was well received and was voted “most interesting” and second place overall out of our cohort of presentations. The positive feedback was rewarding, especially for a project where we just scratched the surface of what we could learn from this data. I’m now familiar with the EVSession data and some of the challenges of working with EV charging data more generally. Again, I felt like this project (combined with a previous connection I had made) opened the door for us into better understanding EV charging, where interesting companies and products are moving quickly to shape the future of transportation.
Takeaways
This course felt like a door-opener to a software engineer looking to dive deep into climate. If you lean fully into the assignments and had an inspiring idea for the final project, it’s very easy to see how you could walk out of this course with the beginnings of a climate software startup.
Admittedly, I didn’t take full advantage of the course due to limited time. In my case, I had to spend some time fighting with my Python code, which a more experienced engineer might have largely avoided. As a fully employed individual with a five-member family, it might have been more productive if the classes and assignments were paced at once per week (over 6-8 weeks), with more time between lessons to dig in deeper on the assignments.
But, I was exposed to new data sources, and I came away with portfolio-quality projects that I can build on in the future. Those are wins for me, and I’m glad I took the course. I’ll keep an eye out for more Terra.do classes up my alley like this one.
Building off of their flagship Learning for Action overview course, Terra.do is rapidly increasing the number of smaller courses they offer, covering different specialties. As someone already familiar with climate change and the climate tech industry and with limited available time, these shorter deep-dives appealed to me as an opportunity to build the more specialized skills in a shorter amount of time. Here’s a referral link for 20% off Terra.do courses, which gives me a partial credit on future classes as well.