I've been mulling over some disparate threads that have come together in a fun little experiment.

First, I have been searching for a project that uses satellite imagery.

Second, climate-tech is interesting to me. In the current AI zeitgeist, I don't hear much being done in the space. I'm sure there are some things going on, but it must be getting drowned out. In any case, I have my concerns about what AI means for our climate future (data centres, resource usage, etc.), and if I'm going to use it, I want to find ways that could be net-positive.

Finally, I've been thinking a lot about what can be collectively achieved in markets where people are traditionally isolated.

What came up for the last point was: residential solar panels.

Installing solar on your house​

I've been through the process of getting solar panels on my house. It's generally the same as buying any large-ticket item:

1. You solicit quotes from a number of vendors
2. They present extremely similar products, at similar prices
3. You pick one

To be fair, #2 comes with a bit more from higher-end vendors. They'll actually estimate your power generation by:

1. Finding your house on Google Maps
2. Overlaying models of their panels 'on' your roof. They try to maximize how many panels can fit, and take into account things like panel orientation, sun path, and tree cover.

Financing​

A quick word about actually paying for it.

At the time we were in the market, the government had an incentive program which included a 0% interest loan on residential energy upgrades.

We didn't find solar vendors to be particularly flexible with their prices, in part I think because they wanted to get the most from the incentive program.

That said, the program is a reimbursement, so we had to pay out of pocket throughout the install, and wait for the reimbursement well after the panels went on the roof.

Collective​

Reflecting on the process, I began to wonder what it might look like if the whole neighbourhood went in on upgrades at the same time. Perhaps we could have negotiated better deals if the installers knew that they would have locked-in sales for many houses at once.

That thought quickly went to - what if we could negotiate at a municipal level? What would it even look like?

Time to fire up Claude Code.

The map!​

(takes a while to load)

About the map​

This embed was generated by a python script - here's the general pipeline description:

1. Fetch boundary — Municipality polygon from OpenStreetMap via osmnx
2. Load buildings — Microsoft Canadian Building Footprints, bbox pre-filtered then clipped to boundary
3. Fetch irradiance — Monthly GHI/DNI/DHI, temperature, and wind speed from the NASA POWER climatology API (2001-2020 averages)
4. Compute generation — For each building: project to UTM 18N for accurate m² area, determine usable roof area, transpose irradiance to plane-of-array via pvlib, apply temperature derating, calculate annual kWh
5. Classify — High / Medium / Low based on generation and roof area thresholds
6. Visualize — Folium map with color-coded markers, popups, layer toggles, legend, and a collapsible summary panel; console summary printed to stdout

It's not perfect, but wow! I wasn't expecting to get anywhere close to making something like this. If nothing else, it could inform some napkin math about the energy potential if solar gets widespread.

The Estimation​

Energy Generation
Total	4149.4 GWh/yr

Plugging this into: https://www.epa.gov/energy/greenhouse-gas-equivalencies-calculator

Dreaming​

Right now, solar installs are just around break-even, maybe a bit better, depending on your utility company, if you were part of the incentive program, if you upgraded other components, etc. etc. Hardware prices continue to go down; there's probably a floor on labour prices to install panels - but if that shifted even just a little more into the "obviously a good financial decision", maybe people could adopt en masse.

Part of that process starts with ballparking what that future could look like!

From here, some ideas start to form for me:

• modeling what emissions impact battery install saturation looks like
• modeling system/install financials could look like
• starting conversations with politicians about a green future, and how we could incentivise adoption, or negotiate collectively

But that'll be for another time.

Why does a clock tick and tock?

This was a phrase I read in a short story that stuck with me. I had an intuition for what it might be, but I wasn't sure.

The short answer is that it's sound from an escapement, with different sounds being produced on the swing and return.

This made me wonder about different ticking patterns. 60 divides cleanly by 2,3,4,5, and 6.

How weird would it be to have a clock that accented the tick every 3 beats? Or 5?

So I vibed up this part-clock / part-metronome. It's not particularly useful, but I did enjoy staring at the patterns getting in and out of sync when all clock signatures were enabled. Also, there is audio as well, if you care to leave the volume on.

Interactive demo (click to start audio):

As you might be able to see with the timestamps, trying to get into a cadence for longform writing hasn't been working.

I have a lot I'd like to write about but there is a bit of friction.

I'm hoping that allowing myself (via use of arbitrary tagging) to post shorter, less polished notes, will grease the wheels and get this going again. Onwards!

Retention is a by-product of a long term investment in somebody. It's not something that happens right when someone has a foot out the door.

Here was the situation, from a few years ago:

An engineer on my team messaged me off-hours asking to schedule a meeting for the following day. Since the timing was odd, the request vague, and since I had some time, I offered to jump on a call immediately. They deferred and so we agreed to chat first thing in the morning. I was expecting a resignation letter to land in my inbox and a short conversation about 'timelines' and 'transition'.

The next morning, we get on a call.

Hey man, I just wanted to let you know that I've been talking to another company and they've made me an offer for 40k more than I'm making here.

Okay, wow. This may as well have been a resignation letter. There's no world in which I would be able to convince the company to part with that type of money for a counteroffer. That said, I figured that what might be happening is an attempt to get a counteroffer. You know, bump up the current salary by a bit.

I knew that if the number was closer, maybe we could do the dance. But this gap was too far to bridge, no chance.

On a personal level, I was thrilled for them.

That's huge, congratulations! You should take that. We thought you were good when we hired you, we love having you on the team, and clearly someone, some other company, saw that too. You're a great add to any team, so, congratulations.

I don't think he was expecting that.

As an engineering manager, you want to keep your team happy. And if your team's performing well, you want to keep the band together. But ultimately, each individual does have the ability to move to greener pastures and if that's legitimately the best thing for a teammate then I'm really happy for them.

Look, you're a big part of the team and it's gonna hurt. But on a personal level, you know, I'm proud of you. You should take that deal.

I also made clear that there would be no counter-offer. We're not gonna match it, there's no way.

But, as a courtesy, I did tell him I would ask, just to confirm. You don't get what you don't ask for.

As expected, my director said, "Yeah, that's not happening. Let me know when his last day is".

So, with the engineer having until the end of the week to accept their offer, all I could ask was for them to prepare their transition out.

At the end of the week, the engineer messages: "can we have another call?".

I've declined the offer.

My turn to be surprised.

I would love to know how you came to that decision.

I knew it couldn't have been an easy decision to make.

He shared that it came down to the position he held at our company. He was getting cool projects. He was working on tech he enjoyed. He also saw the path towards management/leadership, and that we had been actively working on that plan. There was more money elsewhere, but he would have been at the bottom of the ladder there, with less influence and responsibility that he craved at this point in his career. So, he stayed.

I think that about that a lot.

I've been on the other side of 'retention', and I know what it feels like to work at places where you feel valued, and where you don't.

That's why I think retention is a long term game. It's the culture that's built that surrounds the team. It's the interaction and the relationship that you have with your team. It's having a legitimate growth plan. Answers to: Where do I go next? How do I get better? What are you gonna do to help me get to my next career goal?

Those things matter and I didn't realize how much until that moment.

An engineering manager asked me, "What do you do when you notice that your team is shipping more and more bugs?"

"More and more of the work that's going out is coming back with regressions, with user complaints, with crashes, and the like. What do you do in that situation?"

As with most advice, the answer is it depends. You have to figure out what the underlying reasons could be, as well as the context in which they are happening. What we do know, is that humans are going to make mistakes. Programmers are going to ship bugs.

The first thing that's notable to me about the scenario is that there is likely a perception from leadership (or anyone above our protagonist) that there are increased bugs and they're more severe and people are complaining and so now it becomes a critical issue that needs to be investigated by the engineering manager. Fix your team!

Let's dive in.

Where do we start?​

So if we take it as a understood that people are going to make mistakes, and that bugs are currently in your production code, then where can we look to minimize the rate of occurence of these bugs? Here are a few I can think of:

• Gaps in testing and review: Most companies have automated tests, staging environments, QA, and so on. So these bugs are getting through each step!
• Shipping culture shift: I've found that teams tend to ebb and flow between "just ship it" and "everything must be perfect". Maybe the team (and company) is in the former mode.

Process​

Most companies have a code review process. At places I've worked, it looks fairly standard. Someone makes a change, someone different reviews it, approves it, and then it can go into main if the test suite passes. Usually it then gets deployed to a preview environment, where folks poke at it until it's deemed fit for production. At this point, take a step back and consider: if a bug getting through all of those layers, I don't think you can blame any one person or step.

Anyways, tactically it is very tempting to focus on each piece of the process. You might actually have major strides to gain there! Don't have a test suite at all? Adding one will help. Have one, but it's always flaky/red? Getting it to green will help. Etc. So definitely evaluate the process.

People​

Another aspect to investigate is the culture, pressures and health of the team. The human side of our development equation. This can be overlooked by the clear solutions we can make on the process side!

I'll start with pressures, since it might be the easiest to identify. You may have experienced some flavour of this: "Yeah, ordinarily we would [fix this first | test it more | etc] but we're shipping this because [of our deadline | we're going to land a client | etc]. Let's call it a 'known issue', but we'll come back to it later". Most often this is culture set from the top-down during sales pushes.

Now, sometimes this ship now, worry later vibe is actually the culture of the team. You might find this in younger companies, where iteration speed and the short feedback loop is paramount. For a company trying to mature as an engineering organization, this mentality can be hard to shake. Determine if your team's current culture is a product of one they've been used to, and if a tone shift is required.

Finally, reflect on the team's interpersonal relationships and role dynamics. Perhaps a senior engineer is getting their changes greenlit by juniors who are afraid to bother or challenge them. Someone could be letting a team priority slide while they work on an initiative that benefits them personally. In the worst (beyond rare, in my experience) case, someone could be actively trying to drive another person off the team by letting their bugs through.

Summary​

Ultimately, to generalize the problem, as an engineering manager you're trying to figure out:

• what the culture and health of your team is, and
• what processes exist to support them and what can be improved

in this case, within the context of code quality and delivery.

If you zoom out, From there, you can form a plan of action, and do the necessary expectation management and communication in every direction. This is a process that you can (and should) repeat over and over!