From the Mind of Trevor Stone

TLDR: Please email your senators and email your House representative and ask them to support the BAAJA permitting bill.

Summary: The Bipartisan American Affordability and Jobs Act, a large bipartisan bill focused on permitting energy projects, is being considered in the Senate soon, and the House by the end of the year. The bill puts deadlines and procedural requirements on federal processes around permits, while requiring community engagement and preserving laws that protect the environment. The law is technology neutral: clean energy projects and fossil fuel projects both benefit. Despite helping some fossil fuel projects, the bill is still expected to be a big climate win because most new projects use clean energy, and because the bill's electric transmission provisions will enable renewable energy supply to connect to electricity demand, which is crucial for a green transition. The bill is a compromise between Republicans and Democrats through several years of careful negotiation. As with any compromise, both sides have parts they get excited about and parts that they don't love. Despite the negatives, Congress should pass this bill: a better deal isn't likely to happen, and the solution to a permitting process which is too slow isn't "wait several years to fine-tune the fix." Don't make the perfect the enemy of the good. Urge Congress to pass BAAJA.

For folks who are interested in learning more about the 400+ page bill and its affects, I've summarized several topics, including concerns and reasons some people oppose the bill. Those who want to nerd out even deeper are encouraged to read the Bipartisan Policy Center's section-by-section analysis. My friend Daniel Palken dove deep on the Volts podcast if you're up for listening to a 2-hour conversation. Curious where a member of Congress or an advocacy organization stands on the bill? See the BAAJA tracker. The Columbia Center on Global Energy Policy has a great interactive timeline for typical energy projects under the status quo and with BAAJA.

Why is permitting important to the climate?

Permitting is important in the fight against climate change because we need to build low-carbon energy and transportation systems to replace the polluting systems we have today. Over the last decade wind, solar, and batteries have become cheaper sources of electricity than natural gas. This cost advantage is a big win for clean energy: rather than relying on regulation to limit fossil fuels, the natural inclination of economic players will be to buy the cheaper resource. 92% of energy projects installed last year were solar, batteries, or wind! The problem is no longer incentivizing clean energy projects, it's now building clean energy projects fast enough to keep up with demand. The federal permitting process has become a big barrier to that clean energy buildout: it often takes four years to get a permit for a project, and a lawsuit about a bureaucratic technicality can derail the whole thing up to six years later, well after construction has begun. BAAJA sets time limits on the permit process and 5-month deadlines to file lawsuits, which creates a timeline a developer can plan around. This streamlined process doesn't change what kinds of projects are allowed to be built: if a project shouldn't be built because it runs afoul of environmental laws then it will still be denied a permit. By having a predictable process with deadlines, federal agencies can approve good projects faster and also deny bad projects faster.

The impact of permitting and economic incentives on clean energy deployment can be seen in Texas. In a state that's legislatively hostile to climate change concerns, rapid development of wind and solar energy has made it the state with the most renewable energy on the grid. These projects are generally deployed on private land and ERCOT (the Texas grid operator) has a low-bureaucracy process for connecting to the grid and a robust wholesale power market. Texas regulators didn't have to be convinced of the environmental and social benefits of clean energy: market forces and geographic advantages made it an easy choice.

Why transmission permitting is especially important

While the slow permitting process currently impacts both clean energy and fossil fuel projects, transmission line permitting is an especially large problem for renewables. Utility-scale solar and wind projects can only be built in open land where there's ample sun and wind, like the American midwest and southwest. These ideal clean energy locations are often far away from large industrial and population centers that need lots of electricity, so new high-voltage power lines need to be built, and existing power lines need to be upgraded. A large wind or solar project can get permitted and ready to provide electricity in four or five years, but it often takes well over ten years to permit and build a long-distance transmission line. With American electricity demand growing 1.7% per year but transmission deployment growing only 1% per year, the natural outcome is rising prices. BAAJA has several provisions which will let America build more transmission faster, enabling clean energy to connect to the grid and out-compete natural gas:

• Deadlines on filing lawsuits cut several years off the timeline, and help electrical generation projects know there will be a line to connect to.
• If a state government doesn't act on a permit application, FERC can take over the process. The current process requires getting state and local permits everywhere the transmission line passes through, but a state that's neither generating nor consuming the electricity doesn't have a lot of incentive to act on the request. This "federal backstop" authority is estimated to save more than five years for a typical long-distance transmission project. Incidentally, FERC already handles permitting for interstate natural gas pipelines, so it's currently easier to build a polluting natural gas power plant next to Chicago and send send gas there from North Dakota than to build a wind farm in North Dakota and send the electricity to Chicago.
• FERC will also coordinate and require inter-regional and intra-regional transmission planning. The American electrical grid is managed by several independent regional transmission organizations and independent system operators. Anyone familiar with organizational dynamics can predict that these organizations have tended to be more focused on transmission projects within their own borders than electric lines which can share power between regions. This leads to higher electricity prices (a region can't import low-cost wind and solar energy from another region) and reliability challenges (Winter Storm Uri famously took out power in much of Texas, even though neighboring states had excess capacity they couldn't transfer).

What laws and regulations are changing?

The need for permitting reform is driven by six decades of incremental complexity and bureaucracy that has built up around important and well-intentioned laws. BAAJA creates deadlines for processes required by those laws, and sets clear paths in the court system for challenges, simplifying a corner of the judicial world that's kind of ossified into a tarpit. Current laws generally don't provide a cause of action for a legal filing, so environmental lawsuits generally go through the Administrative Procedure Act, a general-purpose and slow-moving law. BAAJA sets timelines, judicial guidelines, and makes changes to the following laws:

• NEPA, the law requiring federal agencies consider effects on the environment and requiring environmental assessments and environmental impact statements. Under BAAJA, NEPA still requires agencies consider the environment in their decision, but tries to prevent environmental analysis paralysis. The judicial reforms also limit the remedies: if a court finds a technical problem with a permit, the problem is referred back to the agency to fix the permit rather than cancelling the whole project. Lawsuits can still stop a project if the federal agency's decision was "arbitrary and capricious," the developer engaged in fraud, etc.
• The Clean Water Act changes in BAAJA limit the reasons a state can deny a permit to direct pollution concerns, along with some other changes. This prevents states from using CWA permitting to achieve climate targets or apply a more holistic view of water systems. It also prevents the EPA from vetoing a permit in some circumstances, but still requires involvement from the Army Corps of Engineers.
• The Endangered Species Act consultation with the Fish and Wildlife Service can be performed by a state wildlife agency instead of the federal government under the law, if they prove they can do a good job. It's not clear how many states will take this opportunity, but they might have a better understanding of local animal populations and habitat.
• The National Historic Preservation Act Section 106 requires federal agencies to evaluate permitted projects' impacts on historic properties. This involves consulting with state and tribal historic preservation offices to identify affected properties. BAAJA would limit this scope to direct impacts: a transmission line miles away from a historic building couldn't be denied because it affects the viewshed of the site. It also limits the scope of review to the parts of a project the agency controls: a federal loan guarantee for a wind project on private land wouldn't need to investigate whether the farmhouse might qualify for the National Register of Historic Places.

Why permitting reform makes energy more affordable

Since electric utilities are generally local monopolies, state Public Utility Commissions review proposed rate changes to ensure increases are due to actual increased cost. When more low-cost renewable electricity is available, a PUC can push back on a utility's proposed rate increase due to rising natural gas prices. The transmission planning process in BAAJA also lets those cost savings flow around the country: a PUC can tell a utility they can't charge customers to build a new expensive power plant when they could import cheaper electricity from a neighboring region. The bill also gives FERC the authority to prevent utilities from building more deluxe infrastructure than needed in order to make more money from a guaranteed ROI rate.

The impact of data centers on local electricity prices has also become a hot topic recently. Data centers bring high demand for power, and when demand grows faster than supply, prices go up. BAAJA requires utilities to charge data centers for both their use of existing infrastructure and the additional costs for a utility to build new infrastructure to handle the load. (Current rules only allow utilities to charge for one or the other.) This has been described as requiring data centers to pay more than their fair share and will avoid households subsidizing data center power. With bipartisan opposition to data center buildouts and big tech, this is both good politics and good economics.

Why do some groups oppose BAAJA?

While the bill has received broad support from many climate groups, some environmental groups have opposed BAAJA. These groups have legitimate concerns: the bill is a compromise, and will lead to some fossil fuel projects getting built which could otherwise be delayed or stopped under the status quo. I think of this opposition as stemming from three types of objections: technical, philosophical, and political.

• Technical objections are about specific parts of the bill and their likely impacts. Groups raising these objections may support a more efficient permitting process, but are concerned that changes will result in specific types of harm, such as changes to what can be denied under the Clean Water Act. These are important concerns, and some groups make different judgments about whether the tradeoffs are worthwhile. I specifically want to highlight technical objections related to NHPA Section 106 consultations. This part of the bill has faced opposition from groups like the National Congress of American Indians and the National Trust for Historic Preservation, both of which represent groups involved in the project consultation and review. This is somewhat different than opposition from environmental groups who advocate or litigate for or against a permitted project, this is opposition from people doing the work of making sure a proposed project gets permitted in a way that won't cause harm. I think this is also an area where BAAJA advocates have less expertise: lots of clean energy policy wonks and advocacy groups have studied NEPA and environmental laws and deeply understand the proposed changes, but a lot of these folks readily admit they're not experts in archaeology or historic preservation. When the Senate takes up BAAJA there will be a "manager's amendment" which is expected to create some technical changes to the NHPA sections, but the details are not yet public.
• Philosophical objections include the belief that we shouldn't support any policy which benefits fossil fuel development. These groups might support a bill which improves permitting only for renewable energy and transmission, but can't say yes to something which will benefit oil and gas in the short term. I respect the values of care and purity driving these groups, but I'm not persuaded that the tradeoff isn't worthwhile: the status quo has already allowed widespread fossil fuel development, and keeping the status quo in place will only delay the timeline for clean energy to replace dirty energy. There are also what I might call existential objections by groups whose whole modus operandi is using the current system of environmental laws and regulations to challenge and delay development projects. BAAJA will significantly weaken the strategy of using lawsuits and administrative procedure to make projects so long and uncertain that developers give up or don't try. Since this is the main activity some activist groups do, their organization might not survive. While this strategy has had some success at blocking environmental and social harm, it also tends to favor the status quo, and the status quo is a world of increasing climate change that will cause widespread environmental and social damage. The status quo permitting process has been used against clean energy and transmission projects as much (if not more) than dirty energy projects, leading developers to design projects to avoid federal permitting if at all possible. As a result, although more than 20% of land in the continental US is federally owned, only about 3% of renewable energy generation is on federal land. And while a lot of that land is inappropriate for development—we shouldn't build a wind farm in a wilderness area—there is an awful lot of non-sensitive BLM land in the arid west that would be a great home to the energy of the future. I would love to see the environmental movement pivot from trying to block anything that changes the current world and instead focus on co-creating the world we want to live in.

The political case to hold out for a better deal also runs into practical challenges. Congressional staffers are a limited resource, and many of them on the EPW and ENR committees have spent a majority of their working time in the last two years on this bill, building on two years of work by ENR staffers on the previous permitting bill. The four Chairs and Ranking Members of these two committees were the key negotiators of the bill; next year those positions are likely to rotate and the new committee heads and their staff will need to come up to speed on the issues, and will bring their own priorities. (The current gang of four includes Senator Whitehouse, who's been perhaps the biggest climate champion in the Senate in the past decade, but he probably won't be the Chair next year.) Even if Democrats had the votes for a better-deal bill, it's unlikely it would get passed until the end of 2028, and might well get vetoed by Trump out of spite if nothing else. If Democrats achieve a trifecta in the 2028 election, a permitting bill would still take a long time to craft, getting enacted in 2030 at the earliest. The solution to the problem of not building clean energy fast enough is not to wait four years to craft rules for maximum velocity. That's enough time to build several big solar and wind projects under BAAJA and complete the transmission planning for the electrical grid of the 2030s. Don't make the perfect the enemy of the good. The Senate should pass BAAJA this year and the Democrats can use their majority position next year to craft new legislation to tackle other important climate and environmental challenges rather than trying to solve the same problem every two years.

• Political objections come from groups who support many parts of BAAJA, but are arguing for a "no" vote this year. These voices, including climate activist Bill McKibben, see likely big wins for Democrats in the midterm elections and are urging the party to turn down BAAJA and hold out for a better deal in the next Congress. While the instinct to try for a better prize after winning is understandable, this is unlikely to be a successful strategy for several reasons. First, a permitting reform bill will need at least 60 votes in the Senate due to the filibuster, and President Trump will need to sign it. Even a huge blue wave next week won't lead to 60 Democratic Senators, so a new permitting bill will still need to have Republicans at the negotiating table, and they will insist on many of the same provisions that left-leaning groups are worried about. At the end of 2024 the GOP House decided to wait for a better deal on a smaller permitting bill; in this Congress they got more Republican priorities but also more Democratic priorities. Neither party is expected to accept less than they've been able to negotiate so far if we do it all again. Trump is also less likely to veto a bill coming from a Republican majority, particularly since part of the BAAJA deal is that the Trump administration will unblock several wind projects that it's kept in administrative limbo. Some political objections have also come from groups worried about giving the Trump administration any further legal tools, since it has a track record of skirting the spirit and the letter of the law: better to wait until a Democrat is in the White House before legislating they say. BAAJA is designed to push back on this style of administrative shenanigans; if BAAJA had been in pace in 2025 it would have been easier to challenge the executive branch's unfair treatment of wind energy, so why not make it active in 2027 rather than waiting for it to limit a Democratic administration's hand?

  Finally, most durable legislation is bipartisan. Democrats were able to pass the Inflation Reduction Act (the largest climate funding bill in history) in 2022 with a slim majority, then watched much of it get repealed in 2025 with the One Big Beautiful Bill because Republicans didn't have a stake in the IRA. A bipartisan compromise bill that sticks around for decades will do more for Democratic priorities than a perfectly crafted bill that only survives for three.

If you've made it this far, congratulations on your long attention span! Please remember to email or call your senators and your your House representative now; the Senate is expected to start voting on the 9th or 10th. Also don't forget to vote by Tuesday. Happy Halloween!

While refactoring some Advent of Code infrastructure I took another look at my 2023 day 1 program in sed. The problem involves turning strings like pqr3stu8vwx and treb7uchet into 2-digit numbers (38 and 77). My solution turned each line into a number prepended with a +; I then passed the results a calculator with a zero pending (| xargs expr 0). I decided to get rid of the calculator and use sed to do the sum, the challenge being addition in a language without arithmetic. I worked out a solution using base-one numbers that can be applied to any problem where you need to add numbers, but all you have is regular expression replacements. With a little work it could be adapted to subtraction and probably multiplication.

The key concept is to represent numbers a bit like Roman numerals, but without the fives and the “one before”. Each letter represents a power of ten, and a number is represented by the count of each letter times its power-of-ten value. 1234 becomes DCCBBBAAAA: one thousand (D) two hundreds (CC) three tens (BBB) and four ones (AAAA).

The first several lines of the script transform a line into a 2-digit number.

s/[^0-9]//g
s/\([0-9]\).*\([0-9]\)/\1\2/
s/^[0-9]$/&&/

It then repeats the digit in the tens place ten times, so 23 becomes 22222222223. It next replaces each digit with an equivalent number of As: 23 is now 23 copies of the letter A. This string is then appended to sed’s hold space with the H command.

s/^\([0-9]\)/\1\1\1\1\1\1\1\1\1\1/
s/9/AAAAAAAAA/g
s/8/AAAAAAAA/g
s/7/AAAAAAA/g
s/6/AAAAAA/g
s/5/AAAAA/g
s/4/AAAA/g
s/3/AAA/g
s/2/AA/g
s/1/A/g
H

After processing all lines, the length of the hold is now the answer to the puzzle, so we just have to convert it to a base ten number. This is done by repeatedly replacing groups of 10 letters with the next letter: 10 As (1) becomes a B (10), 10 Bs becomes a C (100), etc. The answer 54321 is now EEEEEDDDDCCCBBA. For sake of brevity, this code snippet just goes to five digits (ten thousands), but the linked code can handle any 64-bit answer.

g
s/\n//g
s/A\{10\}/B/g
s/B\{10\}/C/g
s/C\{10\}/D/g
s/D\{10\}/E/g

Like many things in math, zero is still a problem. If the answer were 1024, the pattern would just be DBBAAAA: one thousand (no hundreds) two tens and four. The next step finds the end of each power-of-ten position and inserts a comma, then inserts a 0 between each pair of adjacent commas. DBBAAAA becomes D,,BB,AAAA and then D,0,BB,AAAA. This is done twice because substitutions are applied to non-overlapping patterns, so the first pass turns ,,,, into ,0,,0,.

s/^E*/&,/
s/.*,D*/&,/
s/.*,C*/&,/
s/.*,B*/&,/
s/,$/,0/
s/,,/,0,/g
s/,,/,0,/g

Finally, each letter repeated x times is replaced by the digit x. Commas and leading zeroes are removed and the answer printed. TADA! Addition without arithmetic operators.

s/\([A-Z]\)\1\{8\}/9/g
s/\([A-Z]\)\1\{7\}/8/g
s/\([A-Z]\)\1\{6\}/7/g
s/\([A-Z]\)\1\{5\}/6/g
s/\([A-Z]\)\1\{4\}/5/g
s/\([A-Z]\)\1\{3\}/4/g
s/\([A-Z]\)\1\{2\}/3/g
s/\([A-Z]\)\1/2/g
s/\([A-Z]\)/1/g
s/,//g
s/^0*//
p

Postscript: the commas-and-zeros part wouldn’t be required if we used Chinese numerals rather than a positional number system. DDBBBBAAAAAAAA (2048) would be converted to 二千四十八 (“two thousand four ten eight”). In fact, the intermediate letter representation could be skipped, with each line turning into a sequence of 一, and groups of 10 characters iteratively upgraded through 一十百千万. The groups of powers-of-ten would then be turned into one-to-nine while keeping the power character, with the trailing 一 trimmed (“eight” not “eight ones”):

s/\([一十百千万]\)\1\{8\}/九\1/g
…
s/\([一十百千万]\)\1/二\1/g
s/\([一十百千万]\)/一\1/g
s/一$//

Postpostscript: In 2023 I solved this puzzle with two sed scripts. The part 1 script turned the mix of letters and digits into two-digit numbers, the part 2 script turned named numbers like one and nine into digits, the output was then piped to part 1. I wanted to consolidate the two into a single sed script, so I needed to know whether I was in part 1 or 2. My first approach was to add a __part2__ line to the top of the input (echo __part2__; cat $inputfile | sed -n -f day1baseone.sed) and put the word-transformers in a block matching from that special line to the end of the file:

/__part2__/,$ {
s/one/o1e/
…
}
/__part2__/d

But then I realized I could use the b branch jump to go inside a block that never matches an input line, like using goto to jump inside a C if statement.

!{
:part2
s/one/o1e/
…
}

Now the only difference from the shell is sed -e 'bpart2' to perform the jump when running the second time.

Burning Man is rightly famous for massive sculptures, colorful mutant vehicles, and camp infrastructure built to withstand harsh elements. But sometimes it's the small gifts and mundane work that really hits the spot in Black Rock City.

And thus I find myself up past 1am the night before I drive to Burning Man, cutting paper and laminating cards to help people learn the phonetic alphabet and radio jargon. Burning Man packing panic isn't just runs to the hardware store to get a new impact driver; it's also runs to the office supply store because you ran out of printer toner.

I arrived in Amsterdam two weeks ago to an afternoon of occasional drizzle, followed by a downpour as I wandered around Haarlem, discovering the sleeves of my raincoat had lost their waterproofing. But dry weather followed this xeric Coloradan and Europe experienced a heat dome for the next week and a half. Temperatures were only in the 80s Fahrenheit, but humidity made the days somewhat unpleasant. Most buildings in northern Europe don't have air conditioning, so even going to sleep could be a challenge.

After a particularly sweaty experience dragging 60kg of suitcases through three train stations and over the bumpy cobblestones of Antwerp in the intense heat, I had the excellent foresight to have booked a tour of Antwerp's underground canals, a delightfully cool (if somewhat stinky) tour. Three days later I telished in the cool and moist cellar air (full of high quality brettanomyces) of the Oud Beersel lambic brewery. My "bike to the forest and play ham radio" plans were also nicely timed to cool down with assistance from shady trees.

It's back to cool-with-rain this week, bookending my remarkably dry jaunt in Benelux. I'll be flying home tomorrow, and hopefully Colorado got some precipitation while I was away too.

Driving on the left side of the road was easier than I expected it to be. Sitting on the right side of the car, staying to the left of the road was natural and I didn't have any relation to target the wrong side in a turn. Remembering that the turn signal was to the right of the steering wheel took conscious effort though, so there was a lot of unnecessary windshield wiping. Sitting in the passenger seat on the left side of the car didn't evoke "I should be driving" reflexes, but did provide the useful service of warning the driver about the edge of the road, since many South African highways have narrower lanes than the American standard, and shoulders are a luxury.

I found that one out the hard way on a pass into the Great Karoo. In the wind I pulled over for incoming traffic and quickly heard the tire hit dirt. I steered back onto the pavement and heard the thumps of a flat tire. When we pulled the wheel off we found not only had the jagged eroded edge of the asphalt punctured the tire, but the impact had also crushed the rim. Fortunately our destination of Graaf-Rienet is the biggest town in the Karoo, a region famous for eating tires. The Toyota dealership was able to order a rim for next-day delivery and one of several tire shops had the size in stock.

South Africa is a car country, but it's also a walking country. Given its level of development I'd expected to see a lot of mororbikes, recalling memories of "whole family on a scooter" from China and Central America. But other than ubiquitous delivery guys with boxes on the back in Cape Town, I only saw two motorcyclists; one was performing the impressive feat of carrying a surf board. Bicycles also seemed limited to exercise rather than commuting, though given the state of the shoulders and sidewalks I don't blame folks for not biking.

Despite the dominance of cars, South Africa is not yet a place where everyone can afford a car, and society hasn't built in the assumption that everyone's got one. 15-passenger white vans (kombis) are ubiquitous. Folks stand at the side of the highway, hitchhking with a 50 Rand bill in their hand: hoping to get a ride from anyone, white van or not. Cape Town is full of Uber drivers, almost never more than two minutes away in the busy part of town. Our fastest pickup was an Uber parked across the street from our coffee shop. There's also a lot of walking in South Africa. Many places have a formal town (probably whites-only during apartheid) where most of the jobs are, and a township or informal settlement down the road. Township residents walk the mile or two each way to work. Pedestrians also have a sense of entitlement, waking part way into the street despite oncoming traffic and making casual crossings in traffic that would be dangerous in most American cities.

Another unique feature of South African car culture is the parking attendants. Small parking lots and even single city blocks have people standing by, pointing drivers to an open spot and helping them back out, hoping for a tip. Some will even wash your car for you, though with full-service gas stations everywhere I've never had a cleaner windshield. I think the attendants' main value is serving as a deterrent against break-ins, and it wasn't clear to me if they're officially organized or if they just buy a high-vis vest and claim a block.

Other pieces of car culture familiar to Americans were missing. Bumper stickers don't seem to be a thing. I only heard two cars bumping big stereo systems, and flashy mods were totally absent. Kombi vans didn't have any personalization or decoration, a disappointment for anyone who enjoyed taking a bus in Latin America. This lack of flash in autos might be due to high theft rates: a Cape Town ham told me someone broke his window to steal a Baofeng radio on the passenger seat, a $25 value. In America the joke would be that someone left a Baofeng on the seat and came back to a smashed window … and a second Baofeng.

The day before I left on a road trip last month I booked my hostel in Cape Town. When I arrived today they asked my name, scanned my passport, let me put my bags in storage, and said to come back at 3pm to check in. I went on a lovely aimless wander through town and returned to the desk. I wasn't on the list of people checking in today. The attendant poked through his computer and said I'd reserved in March, but the email they sent bounced and the number I registered isn't on WhatsApp[1]. I looked at the event I'd created in Google Calendar and saw I'd written "Check email or call to confirm." I'd assumed they were going to send an email during South African working hours, then promptly forgot about this TODO item during a week on the road. Oops.

Fortunately, traveling to Cape Town is more like my memories of Central America and not like modern Amsterdam, at least in shoulder season. I was able to find another hostel with an open room for a week just four blocks away. As expected, dragging my three heavy bags along the sidewalk was workable but not a lot of fun.

Speaking of my three heavy bags, before I bought my Turkish Airlines ticket I noticed their baggage page said carry-on bags are limited to 8kg. I'd never seen or heard of a carryon getting weighed, and it sounded like something a budget airline like Frontier or Spirit would do, not a flag carrier set on making Istanbul one of the busiest airports in the world. A quick Internet search found some Reddit threads with anecdata of cabin luggage not getting weighed, so I bought the ticket and mostly forgot about this limit. When I arrived at DEN (3 hours early, thankfully) the Star Alliance agent told me to weigh my carry-on first. Uh-oh. My clever packing plan had been to put my whole portable ham radio backpack in a wheelie bag, plus a change of underwear and some card games and small electronics in a big pocket. I knew this would be way more than 8kg because I'd tested the backpack radio kit on a short walk and it's heavy. (I have a lighter option, but I'm worried I'll need 45 watts to get my signal somewhere with enough hams to chase me for the magical 10 QSOs POTA target.) Fortunately there are luggage scales around the corner from the check-in counter, so I spent 45 minutes experimentally moving about 23 lbs from one suitcase to my two checked bags (each with about 5 lbs of spare weight) and my backpack, which has a width-expanding zipper. The next agent cheerfully weighed my exactly-8kg bag and checked my two exactly-50kg bags and handed me a baggage tag for my backpack without visually inspecting that it was clearly too big to fit under an airplane seat. As soon as I was out of eyesight I moved my camera bag, card games, and pockets full of granola bars back to the carry-on, knowing the gate agents have better things to do than weigh everyone's bags before they get on the plane.

I'm now going to be super aware of any objects I acquire on this trip. I'll obviously eat all the snacks, and gifting a lot of metal buttons will clear up some weight. But I'm also going to receive gifts, plus my AfrikaBurn shirt and hat. Hopefully my last lodging has a bathroom scale… or the CPT ticket agents are more chill.

8 kilograms is remarkably light for a carry-on. I was down to a mostly-empty backpack, a medical infejection pen, a folder with a dozen pieces of paper, and a fluffy pillow. I don't think I've ever had a bag this light on a plane, except my return trip from China when I put an erhu in a cardboard box in the bin. My empty suitcase probably weighs a kilo on its own. The rest of the flight experience was fine, but needing to leave a big void in my carry-on makes me not want to fly Turkish again. My lithium batteries aren't allowed in checked bags, so it makes no sense to require me to put them under the seat in a backpack while packing bulky light items like pillows in a hard-to-reach spot. Judging by the amount of space in the overhead bins they made a lot of money on extra bag fees, though perhaps they lost out on selling extra freight space.

[1] In much of the world, WhatsApp has largely replaced the open phone system because Wi-Fi and mobile data are cheaper than SMS, particularly internationally.

My funemployment priority last fall was getting a heat pump installed before the end of the year so I could take advantage of the Inflation Reduction Act's tax credits, before Trump's One Big Beautiful Bill increased taxes on energy saving systems. As a perennial procrastinator I managed to get everything in under the wire, wrapping up a week before Christmas and just a few working days before the end of the tax year. Despite IRS deadlines being the spark to get my butt into gear, by far the largest savings came from Xcel Energy's incentive programs. I saved $2,000 on my taxes on the heat pump and $1,000 for improving insulation, but Xcel gave a $6500 rebate on the heat pump, a $3000 rebate on insulation, and a check for $2500 because I did three efficiency projects in a year. So if you're considering energy efficiency upgrades to your house, don't let the death of tax benefits dissuade you: you might still be able to get it installed at a significant discount.

For anyone interested in a home energy project, step one is to get a home energy audit. Xcel offers these at reduced cost: I paid a little over $100 for an expert to spend a couple hours at my house identifying thermal leakage, checking furnace combustion, measuring air-changes-per-hour (which is the main way your house looses heat), and he probably installed at least $100 worth of free LED lightbulbs. This audit also unlocks the Xcel rebate program. It was scheduled about a month ahead of time last year, so get on it early. While you're waiting for that to happen, talk to a free advisor at Go Electric Colorado who can talk in depth about home electrification and efficiency options, navigating rebate programs, and providing a neutral assessment of project bids. One important thing I learned from the energy audit was that Xcel will only give a heat pump rebate if the insulation project happened first; otherwise they assume the heat pump system was oversized. It's also crucial to use companies on Xcel's approved vendors list; otherwise you won't get a rebate. I went with Independent Power for the heat pump project; they were great to work with, and had a lot of experience in the HVAC space. I also had a good experience with Elephant Energy and would definitely recommend them; the main reason I didn't choose them was crew availability before the end-of-year tax deadline. Bestway Insulation had the lowest of three bids, but also did the most thorough job on the free estimate visit, and were able to schedule on short notice. "This is an Eloy job," the estimator said as he squeezed himself out of my crawlspace. "We've got a guy who's really short and skinny. He says 'I was born to either be a jockey or work in crawl spaces and attics.'"

I was looking forward to comparing this winter's energy bills with last year's to get a sense of return on investment. Unfortunately, Colorado kinda forgot to have a winter this year. On the Front Range we basically got one snow storm per month from December through March, and much of the rest of the time was often T-shirt weather, with late March spending a week in the high 70s and low 80s. So aside from a week of Stock Show Weather, the new heat pump hasn't had a whole lot of work to do.

Comparing the unseasonably warm months of November-ish to January-ish, our natural gas usage was cut by a factor of about 10 (just hot water and cooking now), while electricity use doubled (the heat pump was working hard during the single-digits cold snap). The unseasonably warm February-ish increased electricity use by 50 to 60% over November-ish, and gas usage remained decimated. The November-ish bill was about $150 for electrical and $130 for gas. January-ish was about $310 for electrical and $25 for gas; February-ish was about $220 for electrical, $30 for gas. Taxes and other adjustments are included; $7 and $11 are fixed costs for just having service. Febraury's weather was more similar to November's, so this suggests our overall energy bill is similar after the change, given fixed per-unit utility prices.

This is a bit surprising, since with a conversion rate of roughly 29 kilowatt-hours per therm, our total consumption of units of energy dropped by more than half. Electricity is currently billed higher than an equivalent kWh of gas, and a kilowatt-hour of gas burned at a power plant delivers less than one kWh to your meter, of course. This does highlight that the time horizon for a payoff for energy efficiency projects is long-term; before the project I'd estimated perhaps $30 per winter month in savings, which will take more than a decade to overcome the price differential of maintaining the gas furnace status quo. This is one reason energy efficiency tax credits and rebates are important: it's a significant up-front capital cost borne by the consumer with a slow pay-out and the public receives some of the benefits through reduced energy demand. However, market forces may act in my favor: I expect natural gas prices to increase significantly over time (with a lot of short-term spikes too), while deployment of renewables—which have nearly zero operating cost. If Xcel's gas rates rise faster than their electrical rates, I'll break even on the project sooner. (There is, however, a Jevons paradox risk that expanded cheap clean energy will induce demand for electricity, keeping prices high. This is one reason I support carbon pricing in addition to renewable buildout and transmission expansion.)

There are some non-financial benefits of this project, too. I wanted to get a heat pump in part because my house didn't have air-conditioning. Our cooling tools are a swamp cooler and an attic fan, which has been pleasant on warm days but it has trouble keeping up in the heat of summer. A heat pump provides both heating and cooling through the same mechanism, just running in reverse. Insulating the attic and crawl space has also been a big win: when days are sunny to warm up the house (thanks, sun porch!) and nighttime temperatures are in the 40s the heating system often doesn't seem to come on at all, with the house cooling down to the thermostat's room temperature by the time the sun comes up. This was particularly useful handy when Xcel cut power for 20 hours on the final day of the heat pump install; the thermostat around 70 when I went to bed and had only dropped to about 65 the next morning. The air-sealed crawl space also means the bathroom tile floor isn't so chilly on bare feet headed to the toilet in the morning.

The heat pump is also a lot quieter than the gas furnace was. A heat pump can run at slow speed to pull latent heat inside from the outdoor air, then blow that air into the house to keep it a consistent temperature. A gas furnace must periodically start a fire, then blow a bunch of air that's significantly hotter than room temperature around before dousing the fire and waiting for the house to cool below the thermostat setting. The furnace cycles and air movement was pretty noisy, with an air return vent in our living room. Getting warm air meant it was harder to hear the radio, or we'd turn up the TV. Now I often don't notice the heat is on unless I step over a vent. I do sometimes miss the very-hot air rising from the floor, though. When you come in from a cold and wet snow adventure it's nice to be able to temporarily turn the thermostat up one or two degrees and then stand over a vent to quickly warm up. When I was a young kid, my mom would turn on the furnace when I got out of the bath and have me lie next to the bathroom floor vent with a towel over me while she narrated my adventure as a cloud rising over the Pacific and blowing east, dropping rain on the mountains. I also used to wake up in the morning and lie next to the long register in the living room and marvel that I could hear my parents through the duct work in their bedroom downstairs. The efficient "maintenance warm air" from the heat pump doesn't give quite the rosy feeling. Fortunately when the sun's out I can use our sun porch when I want to emulate a heat-seeking feline.

The radio frequency spectrum is organized in bands (ranges of frequencies), with each band dedicated to one or more radio services (purposes and licensing systems). For example, U.S. broadcast radio is in two bands: the AM broadcast band is from 535 kHz to 1.705 MHz and the FM broadcast band is from 88 MHz to 108 MHz. (Here's a nice chart.) In many radio services, each frequency is assigned to a specific station in a specific area. For example, KOA in Denver is the only station allowed to transmit on 850 kHz with significant power at night in the continental US, and in the daytime in most of the western US.

The amateur radio service (ham radio) doesn't assign frequencies to specific stations. Amateur bands are open to anyone with an appropriate license, and it's up to amateur operators to avoid operating on a frequency that's already in use. This is normally fairly straightforward: listen first, then ask if anyone's using the frequency, then you can call CQ (ask people to call you). High frequency radio waves have a limited range though, and also a short-range "skip zone" where they can't be heard. So sometimes two people are calling CQ on the same frequency, but can't hear each other. I occasionally run into this situation with single sideband: one station in Florida and one station in Georgia might both be seeking contacts. If their timing is such that I can make out which is which by the sound of their voice, I can sometimes work both stations and tell them that another station is on the same frequency.

I've been practicing Morse code lately, and while some operators have a distinct "fist" (keying rhythm), often the only way to tell the dits and dahs of two transmissions apart is by the signal strength, if that. Today in the weekly K1USN SST slow speed contest I was listening to several rounds until I worked out the operator's callsign before calling them. An exchange is information given by the two parties in a contact. If K1USN is calling CQ and W1AW contacts them, the full sequence would be something like

CQ SST DE K1USN
W1AW
W1AW GA WATSON MA
TU WATSON HIRAM CT
TU HIRAM ES 73

with DE short for from, ES for and, GA for good afternoon, TU for thank you, MA/CT are state abbreviations, and 73 stands for kind regards, end of conversation. After a few passes, I'd written down W6RIF, called him, and got his exchange as WARREN IL (Warren in Illinois). I said TU WARREN TREVOR CO and moved on. I typed up my log file at home and ran it through a script I wrote to double check callsigns and states against the FCC database. I was surprised to discover that W6RIF is named Reed and lives in Virginia; neither the names nor the states sound similar in Morse code. I was pretty sure I'd copied the callsign correctly, and I relied on my phone to pick up the name. I searched QRZ for several variants with wildcards in various places, none of which turned up a more promising operator. I tried searching QRZ for just warren but in a hobby dominated by old white guys, there are a few thousand. I recalled finding a text file of SST operators and their exchanges, only one of whom is Warren from Illinois: KC9IL. I could confuse IF for IL (L and F both have three dits and a dah, with the dah one position different), but it's implausible that I misheard KC9 as W6R; none of those letters sound like the other. I had the insight to check the Reverse Beacon Network where people run software to automatically spot (announce that they heard) stations calling CQ in CW (Morse code) or digital modes. I looked up both callsigns, and saw they were both calling CQ on the same frequency in the same time range. It's possible that both of them responded to me at the same time, but I only picked up Warren's exchange. Maybe I ended up in both of their logs. I'm surprised they didn't notice each other on the same frequency: Virginia Beach and Chicago are far apart to be well out of the skip zone on 20 meters, but close enough to have a clear signal.

High frequency and medium frequency amateur radio is a curious hobby. In an era where you can place a phone call or send a short message to almost anyone on the planet for cheap, hams have to concentrate to pull out callsigns, names, and other details in the spaces between simultaneous transmissions, over atmospheric noise and static from thunderstorms, and signals fading in and out. Before I got my General class license, I was curious why someone would do this. The answer: it's fun in part because it's hard to communicate. It's a bit like a game of chance, strongly influenced by skill and appropriate use of technology.

Last December was the 11th annual Advent of Code programming event. Each day a new puzzle is released. The puzzle describes what you need to compute, provides an example input and output, and provides participants with a personal input file. After figuring out the answer for your input file, a second part of the puzzle unlocks, generally with a tougher or more involved version of the first part. The big change this year was only 12 days of puzzles, rather than a full 25-day advent. There was also no global leaderboard, because people were expending immense amounts of angst about people using AI to solve puzzles in a few seconds.

In the previous five years I've used AoC to learn a new programming language: Kotlin, Raku, Elixir, Julia, and PostScript. This year, I wasn't getting inspired with a single language I wanted to spend the month learning. I also thought I would be driving across the southwest and might end up programming on my phone at a campsite in the desert, so I started looking at languages I could edit and run in a Linux terminal on my Android phone without a huge install dependency. This led me to the theme of glue languages you might already have on your system. While most of them needed to be installed on my phone, the idea was that glue languages like AWK or jq are designed to be written quickly without too much typing, and don't need a memory-intensive compilation process. I've used a lot of these glue languages before, but I often find myself cargo cult programming and not really understanding the language's conceptual framework. For example, I used AWK for 20 years before I realized it could do something more than "print the Nth column of a space-separated input."

The glue languages theme worked out pretty well. I didn't end up programming on my phone (though I did a little shell exploration on my phone while riding transit), and instead spent the first week solving problems on my Chromebook in the living room of a youth hostel in San Francisco, where "Let's find something hacky that will solve things in an amusing way" was still a good fit. Thanks to funemployment I had plenty of time in October and November to build my standard "runner" infrastructure in several languages I wanted to use, which stretched some of my standing runner design choices. "Read the file, break into a list of lines, and pass the list to part1 and part2 functions" is, er, awkward in AWK, and neither Jsonnet nor jq can measure time.

Languages and Thoughts

AWK: day 5, day 7, day 12

AWK is a simple language for transforming text—particularly multi-field delimited text—frequently used when sed would be too painful. The general structure is "run this block of code when the current line matches this pattern," it automatically converts between strings and numbers, and it's got global variables so you can accumulate results and print them at the end. In recent years I've written some AWK code that's more complex than "print just the second column of ps", so I thought this might not involve as much language learning as I like to do in AoC, but AWK is just so good at what it does that it seemed prudent to build some runner infrastructure so I could whip a quick program out and go to bed. I did end up learning some things about AWK arrays, and I think the day 7 solution is kind of elegant.

dc: day 1 and day 6

dc is a stack-based "desk calculator" from back when people had reverse-Polish HP calculators on their desks. It's one of the oldest Unix programs (predating the C programming language), and writing code for dc feels a bit like writing in assembly. It's got two data types: numbers and strings. 256 memory registers are available, each identified by a single character. The registers are themselves stacks. Operators are one or two characters and spaces are only required to separate number literals, which is reasonable for arithmetic like 1 2 3 4*/+ but challenging to read for something like [la1+sa]sz, which is "store a macro in register z that increments the number in register a." My practice with stack programming in PostScript last year was helpful, but programming in dc is still a bit of a mind twist. Fortunately the f operator prints the stack, so it's easy to try out part of a program and see what effect it has on the stack. Since dc doesn't have a "read from standard input" operator, I used sed to turn my input file into a dc program, with macros declared at the start and a few print operators at the end. After my trip I discovered that dc is still under active development, with GNU dc gaining r and R operators to rotate several items on top of the stack. I'd used these in my program, but the macOS version on my 11-year-old Mac Mini hasn't upgraded yet, so I worked out how to implement top-3 rotation manually: [S1S2S3L2L1L3]sR [S1S2S3L1L3L2]sr.

gvpr: day 8, day 11

gvpr is an "AWK-like" language for processing graphs in Graphviz format. The dot and neato tools are very handy for visualizing your input file in AoC problems that can be represented as a directed or undirected graph. I became aware of gvpr on day 25 when I solved the main part of the problem by staring at a graph, and then wanted code to determine the size of graph subcompoents. The concept of "AWK for graphs" is appealing, but the execution is pretty painful. You know you might be in trouble when half of the time you Google for something about the language one of the top hits is a forum post titled I'm trying to use gvpr. Is that a mistake? with project devs basically saying "yes, it's poorly designed." I felt a weird sensation of writing code that looks at first like it's AWK, but as I got into details, it started to look more like programming in C. Sharp edges included a lack of safe defaults for missing attributes, awkward naming (which end of an edge is the head and which is the tail? the answer may shock you!), functions that don't respect variable scope, and the inability to use the AWK-like matching constructs if you build the graph programmatically rather than piped in as DOT. Oh, and it's kinda slow (or I could only figure out how to write an inefficient version for day 8).

jq: day 3, day 4

jq is a terse language for processing JSON input, in the tradition of tools like sed and awk. I've used jq a lot in recent years—it's great for playing with new APIs or pulling the one piece of data you need from a JSON download—but I still felt like I didn't entirely get it, particularly in correctly working with nested array data. jq is a functional language structured as pipelines, and if there's one thing a functional language loves it's small programming puzzles. On day 3 I got twisted up and spent a bunch of time banging my head on incorrect approaches. Day 4 I'd already solved inefficiently with shell pipelines, so it was a matter of functional translation and then recursive iteration. The language is still a little brain-twisty, but I think I've got the hang of it now.

Jsonnet: day 10

Jsonnet is a different purely functional language for transforming JSON input. It's inspired by an internal configuration language at Google, having removed some features that are widely considered a bad idea. Jsonnet is lazily evaluated and allows for infinite data structures: you can have an infinite array, but if you only ever access a few specific elements it won't try to figure out all the other values. It's written declaratively, and allows prototype-style inheritance: "make an object like that one, but override this property." Contrary to many of my former colleagues, I happen to enjoy the internal config language, and "find an excuse to use Jsonnet for something clever" was one of the reasons I chose to focus on glue languages this year. Part 1 of day 10 seemed like a good fit for Jsonnet's ability to make inferences, but I thought up an overcomplicated approach and kept overflowing either Jsonnet's internal stack or the underlying Go maximum stack size, depending on just how I ended up with excess recursion. I switched to Go (a language that's efficient and good at making coding mistakes obvious) and solved part 1, but then got stuck on part 2 for a couple weeks of trying to re-learn linear algebra. I still wanted to work out a Jsonnet implementation, but didn't want to figure out how to do recursive lazy matrix reduction on immutable objects, so I was pleased to read through an excellent tutorial on a bifurcation approach which reduced the problem search space in ways I was grasping for but couldn't figure out the first time. It still took some careful work to get this to work in Jsonnet, including discovering the undocumented tailstrict keyword and figuring out how to structure a tail recursive function with lazy evaluation and multiple if clauses. I fortunately chose to implement this on my Mac which had the Go Jsonnet implementation rather than the original C++ one on Debian-derived Linux. The Go interpreter finishes in a tedious minute and a half but the C++ interpreter gets completely stuck, as far as I can tell. (One downside of a lazy functional language is that the "print a debug message" function only outputs after the recursive function it wraps finishes, so "where is my program getting stuck" is tough to figure out.

Lua: day 10

Lua is a small language designed to be embedded in other programs that need an interpreter for user-written code. After two weeks of day 10 and linear algebra as my white whale, I finally got my Go implementation working. The code was full of failed attempts and half-commented-out functions, so I decided to transcribe the working solution to Lua and clean up the original Go later. I'm really glad I didn't try to do the whole month in Lua: it's got just enough to be a real language, but not enough to be very productive. Lua's only compound data type is the "table," an array that can have strings or numbers as keys. I've used languages like this before—PHP arrays are also "indexed arrays or hash maps" and JavaScript arrays are technically objects with indices as string property names—but this gets extra awkward in Lua. Integer indices are treated specially, so if you want to use it as a sparse hash map with numeric keys, you might not get all your data back when iterating. Object orientation is available, but if you want to use an object as a table key you need to go back and forth with string conversion, which gets slow. The standard library has a few useful string functions, but misses a lot of really handy utilities that you'd find in a language like Perl, Python, or Ruby. If "write your vimrc and plugins in Lua" is the compelling reason to switch to Neovim, I'll stick with Vimscript.

Perl

Perhaps the pinnacle of glue languages, Perl was the first programming language I ever got comfortable with. In high school and college I really enjoyed writing Perl code, and the quirky community around the language. In the last two decades I don't think I've edited a Perl file, but I've used it for plenty of one-liner scripts at the command line. I wrote a runner script for Advent of Code in Perl, but didn't end up using it this year. I was struck with how clunky some things felt. A simple Perl script is really slick at doing something for each line of all input files, but treating each argument as an independent list of lines—and reading stdin if no files were specified—was surprisingly verbose. Needing to explicitly use a reference (pointer) to pass a list as an argument (rather than having an operator to explicitly splat a list into multiple arguments) also felt awkward coming from any other programming language.

Ruby: day 12

Ruby was clearly inspired by Perl, but brings a strong object-oriented philosophy and borrows heavily from the functional programming community. This is a questionable inclusion as a "glue language," and many companies run multi-million user websites with just Ruby. But like other glue languages it's got functions to simplify common tasks, easy string processing, and a quick iterative development cycle. I wrote a bunch of Ruby a decade ago as part of a replacement for a Burning Man system, but then abandoned that effort. I had Ruby in my toolkit in case I encountered something that was going to be complicated, and when I read day 12's space packing puzzle while still exhausted from day 10, I decided I needed a language with a full suite of composite data types. The puzzle has a trick that I found distasteful: the example input is really hard, but if you add the right check the actual input is easy. I spent a long time trying to come up with potential optimizations and shortcuts for what I recognized was an NP-complete problem, but the code always seemed to run for an unreasonably long time on the example input. Once I realized the input trick (some lines were getting processed a lot faster than others), I got grumpy and posted a couple cheeky implementations in other glue languages. A couple weeks later I came back to the problem, since I had been enjoying trying to optimize the placement of puzzle pieces on a grid, and the ASCII art output was fun to look at. After some time learning to use the Ruby profiler, I ended up with a solution that only takes about 3 minutes on the example input, though it does leave out one axis of permutations that could in theory find a solution. Coming back to Ruby a decade later, I still like the language. It's got a few sharp edges, but I think it's still a good language to have in your toolkit. The irb interactive environment has also gotten really nice, providing syntax highlighting and autocomplete despite Ruby's very-dynamically-typed nature.

SQL (spatial): day 9

SQL is the world's most popular database query language, and there are several folks who use it to solve all AoC problems, though sometimes things get pretty awkward. The last couple years at work I spent a bunch of time working with spherical geometry, and got to know the ST_ (spatio-temporal) functions of the Simple Features standard. Google's SQL dialect and systems support these, and I even wrote a SQL function to compute the angle of the sun at the start of each GPS track in our dataset. I hadn't played with other spatial databases, though, so I bent my "you might already have installed" theme and my "standard library only" rule a bit and installed PostGIS for PostgreSQL and SpatiaLite for SQLite. When you've got a geometry library at hand, this puzzle is quite simple :-) Runtime is kinda slow, since it's doing a cross join of every point in the input. It's also important to remember that the "S" in "SQL" stands for "Structured" and not "Standard", so I had to write the query twice: SpatiaLite doesn't consistently follow SFS naming. My first attempt at day 9 was a fun use of ImageMagick a glue tool for image processing, but creating a 100,000 pixel square image (10 gigapixels) and taking slices of it was not a task my old Mac Mini was up to. I also tried using rsvg-convert in the hope that staying in vector space for image slicing would work, but it seemed to be rasterizing as well.

Z shell: day 2, day 4, day 6, day 12, and runner infrastructure for niche languages

I've been using zsh as my login shell for more than a quarter century, but I still need to look at the man page whenever I need to do something more complex than a foreach loop. Day 2 was solved entirely with zsh builtins. Day 4 launched a pipeline of 6 commands within a loop, using head | tail | cut | tr | xargs printf to extract 3x3 sections of a grid. This took 45 seconds to run on part 1 (and 12 minutes on Android: forking a process is expensive, kids!), so I switched to jq for part 2. Day 6 used a grep | cut | pr | sed pipeline, but the loop didn't have as many iterations, so it wasn't untolerably slow. The use of dc in day 6 was just so I could be cute and not do arithmetic in the shell.

Go: day 10

This definitely doesn't count as a "glue language that might already be on your system," but it's my fallback for puzzles where I get stuck or my approach is too slow in an interpreted language. Day 10's second part requires finding the minimum number of steps to reach a goal in a rather large possible search space. I experimented with a lot of approaches to reducing the search space, and took advantage of Go's treatment of fixed-size arrays as value types to optimize performance as much as I could. Most of my approaches were some variant of "keep a priority queue of states to explore," and memory use would often grow to tens of gigabytes. Some of the lines in the input could reach a solution pretty quickly, and other lines were amenable to different approaches to space exploration. I kept a cheat map of the answer for lines I'd previously found, which let me run my program for several hours on lines I hadn't yet solved, then stop when it hit a troublesome line and try a different approach without spending hours redoing old work. Running for days is a clear sign that I didn't have the right solution, but "find a solution and then optimize" is usually a good strategy. In the end I only had half a dozen unsolved lines out of 191, but those didn't seem amenable at all to any form of state-space exploration. In the solutions thread for another day, I saw a tangential reference to day 10 as a system of equations and said "Of course!" I'm not very good at recognizing linear algebra problems, and very shaky at writing code to solve them. One challenge for linear programming in Advent of Code is that everything is an integer (and in this problem, no negative numbers), while most matrix solvers assume real numbers. Over the course of a couple days I re-read my linear algebra textbook and Wikipedia pages about Gaussian elimination. I adapted it to an integers-only system of linear equations implementation, but still got hung up on some of the inputs because the scalar factor between two rows would result in non-integer values somewhere. Through more Internet research I learned that integer linear programming (rather than the more general linear programming) is what I was doing, and wound up writing code to compute the Hermite normal form, though I then realized that making full use of the HNF matrix would get complicated. I also tried Octave and Scilab (two open-source Matlab-like languages) which count as more "glue-like." Octave refused to do matrix solving on integer-typed data. I found a library for Hermite computation for Scilab but decided that path was getting too complicated and went back to writing Go code. Eventually I realized that I could produce a triangular matrix by just repeatedly subtracting rows with a value in the column; eventually it'll end up with 1-1=0 to eliminate a cell. This finally got an answer to the whole input with just a few minutes of runtime, and later profiling and tweaking got it to the 2-digit seconds range after realizing I could swap column positions and reduce the number of free variables. I definitely spent way too much time on this bugbear of a problem, but it at least it was educational, and I'm funemployed with lots of time.

Languages I wanted to try

I've encountered a few glue languages that looked pretty interesting, but I didn't get a chance to try them out. dt is billed as "duct tape for your Unix pipes," clearly a glue language. I'd encountered it last year when researching stack-based languages; unfortunately the Nix packaging system wouldn't compile on my old Mac, so I gave up on the install. Clearly it's not yet at the "might already be on your system" level. I've seen someone (turns out to be the language's maintainer) in the r/adventofcode subreddit solving all problems with the m4 macro language, which I've mostly encountered as "the language used to generate your Sendmail config file." I spent some time reading an m4 language guide, and learned that doing math is complicated. I considered setting up in case there was a good text-transformation puzzle, but seeing that even loop constructs need a library I decided to save that bit of brain-bending for a future date. I also wanted to try Noulith, a language that wasn't actually written for the purpose of Advent of Code, but just as well could have been. I spent some time reading the docs while traveling, but didn't have time to get the interpreter set up to try it out. Maybe I'll give it a shot in 2026.

… and I just spent $500 at City Lights Bookstore.

Buying books and reading books are separate hobbies, as my coworker pointed out.

I signed my Google separation agreement today. I'd been sitting on it because one clause seemed a little weird, but I wasn't able to find any discussion of it. Most of the agreement is set up to limit future legal risk to Google based on my employment there, in exchange for paying me a bunch of money. For example, it says I won't sue them for workplace harassment or unfair labor practices I might have experienced there. But the no cooperation clause doesn't seem to be limited to just events related to my employment:

11. No Cooperation. Other than in connection with filing a charge or participating in any investigation or proceeding conducted by the Equal Employment Opportunity Commission, the National Labor Relations Board, or other comparable federal, state, or local agency, or under a valid subpoena or court order to do so, or otherwise as permitted by applicable law, you will not counsel or assist any attorneys or their clients in the presentation or prosecution of any disputes, differences, grievances, claims, charges, or complaints by any third party against the Company, Alphabet Inc. or any Released Party. For attorneys, nothing in this Section (No Cooperation) will restrict or limit your right to practice law or represent future clients, as described in the state bar rules of professional conduct of the state in which you are licensed to practice law (“the Rules”); provided, however, that you must honor all of your other continuing ethical obligations to the Company and the Released Parties under the Rules, including as to client confidentiality and privilege. Notwithstanding the foregoing, consistent with applicable law, nothing in this Agreement prevents you from disclosing the facts or circumstances underlying your claim or action for sexual assault, sexual harassment, workplace harassment or discrimination, the failure to prevent workplace harassment or discrimination, or retaliation for reporting or opposing harassment or discrimination.

This stands in contrast to the cooperation clause, which follows next and is specifically tied to topics "that relate to matters within your knowledge or responsibility during your employment with the Company."

12. Cooperation with the Company. You agree to cooperate with the Company regarding any pending or subsequently filed internal investigations, litigation, claims, or other disputes or legal proceedings involving the Company that relate to matters within your knowledge or responsibility during your employment with the Company. Without limiting the foregoing, you agree: (a) to meet with the Company’s representatives, its counsel, or other designees at reasonable times and places; (b) to provide truthful testimony to any court, agency, or other adjudicatory body; and (c) to provide the Company with notice of contact by any adverse party or such adverse party’s representative except as may be required by law. The Company will reimburse you for your time at a reasonable hourly rate and other reasonable expenses in connection with the cooperation described in this Section.

To my non-attorney reading, the no cooperation clause attempts to prohibit me from assisting an attorney with a lawsuit regarding facts which occur far in the future from now. For example, if ten years from now I work at Acme Inc and am involved in a contract dispute regarding business conducted between Acme and Google it seems surprisingly restrictive to claim I can't work with Acme's lawyers on a lawsuit against Google just because I took an exit package from Google a decade before the matter in dispute arose.

Since this bug in the contract is hypothetical—I don't have any particular plans to get involved in a lawsuit against Google—it's not worth six figures to me not to sign the agreement, or to go track down an employment lawyer to explain why the paragraph doesn't work the way I'm reading it. If the issue comes up, I'll let the attorney who wants my input figure out what it means.

Two identical-looking envelopes came in the mail today from Health Equity/Wage Works. One contained information about open enrollment in Google's health plan. The other was information about signing up for COBRA coverage once the Google-paid insurance stops at the end of October.

(COBRA would cost a little over $2,000 per month in just premiums for the two of us. That's as much or more than the total estimated annual cost of marketplace plans we've seen. "You can keep your insurance when you leave your job if you pay the full cost" isn't a great deal when your employer used "we have fancy health insurance" as a way to attract employees.)

For many years, Googlegeist was Google's annual employee survey, asking about everything from productivity to feelings of inclusion. To make the survey as much of a census as possible, and thus have meaningful data at even the line manager level, Google leadership would make big and eye-catching gestures to encourage participation, from delivering cupcakes to the microkitchen with Googlegeist logos in icing to announcing they would dress up as a bear and ask a question at TGIF if their team had at least 90% 'geist participation. Googlegeist results drove real change; teams would form a committee to act on significant negative feedback, processes could change if "I'm not slowed down by unnecessary bureaucracy" or "Google is hierarchical in ways that affect me negatively" scored high enough in a team. Some of Google's early DEI work was driven by answers to the question "Google is a place where all types of Googlers can succeed," particularly when those results were sliced by self-identified race and gender categories.

In 2023, Googlegeist was changed from an annual survey to a weekly email, with two questions from the original survey presented weekly. This provides an ongoing "quick read" of employee sentiment, so leaders don't need to wait a year to discover their team isn't feeling productive. But it also meant that taking Googlegeist was no longer a shared cultural experience, something we were all doing together. Product area or team leads might share some Googlegeist results at a quarterly all-hands meeting, but we didn't have a company-wide TGIF devoted to how the company is feeling about itself.

Sometimes the weekly Googlegeist email timing has been pretty amusing, though. This week I was asked "Over the past month, my work gave me a strong sense of purpose." My work the past month has been (1) tell people that they're wonderful and I'll miss them after I leave Google and (2) volunteering at Burning Man to ensure people have a good time safely. So yeah, that's a pretty good sense of purpose. I think it asked the same question at the start of January 2024 when my work "over the past month" had been climbing volcanoes and swimming with manta rays and walking through botanic gardens in Hawaii.

Yesterday I announced that I am leaving Google through the Voluntary Exit Program offered to my division. I don't think I've cried this much in one week since I was a kid. I hadn't been intending to leave just yet, and I'm going to miss a lot of people and activity very dearly. But my tenure level means I'll get nearly a year's worth of salary to not work, which sounds to me a whole lot like a year of paid vacation.

I know that I was pretty well regarded at Google (I've made more memes than any human at Google, and I've got a colorful reputation in the Boulder office). But I didn't expect over 1,700 people to follow the link to my farewell essay in the first 24 hours. I've gotten dozens of email and chat and meme comment replies to my message, and my farewell message seems to have resonated with a lot of my colleagues. It makes me cry and smile at the same time.

When Google's first large-scale layoffs happened in January of 2023, I was pretty upset. All these people suddenly disappeared, and I couldn't say goodbye to them. And imagining what I would feel in that situation, I would be totally distraught to leave without being able to tell everyone what was on my mind and share a moment with each other one last time. I doubt I'd get a better opportunity to leave on a high note, so here I go into the unknown. In 2009 I quit my job with a plan to travel for the summer, which was a great experience. This time I haven't had any time to make plans beyond what I already had in place—I'm driving to Burning Man on what would be my last day—but after 15 years at a high-growth tech company I've got enough time to both plan some adventures and then have them.

As time goes on, I'll share some more reflections about my time at Google, the changing techno-social landscape, and whatever else is on my mind. For all the Googlers who are now following me via RSS, welcome to my blog and keep doing excellent work.

Most of this four-day weekend was devoted to bottling homebrew. Since yeast do the real work, most of the human labor in home brewing is cleaning. There have been four carboys sitting on the kitchen counter for four years and change because every time I would clean the kitchen on a Saturday with the goal of bottling on a Sunday, I wouldn't end up with the energy to follow through the next day. Then a week later, the kitchen would be dirty again, and it would be a month or two before there was time to consider the project again. Since this is the first Independence Day weekend in three years that we haven't gotten a shelter cat, we coordinated with Kelly's friend Jim to come over on Saturday to help. Having an external party deadline, plus two weekdays off work, helped motivate some house cleaning, and we were almost ready to go when he arrived.

The pending potables dated back to 2018. I made a cyser with apple cider from a community pressing that fall. I didn't really procrastinate on bottling this one: I siphoned out several bottles over time, but they all had too strong of an alcohol flavor that I like to describe as "The yeast are angry." I think this is due to fermentation at too high a temperature (my house doesn't have a great cool place), which releases a lot of unwanted esters. Advice from the Yeastherders Gatherum had been to just give it more time;. After six years on the counter, when I brought a bottle last year, it was really well received. Good things are worth waiting for.

While the cyser was in its early stages of aging, I successfully bottled at least twice. The straight cider from that year was bottled with no drouble. And the next fall I bought an all-grain system from a coworker. I made a dunkel weizen to learn how to do an all-grain brew, and bottled a month later. Awkwardly, I haven't done a whole grain beer since…

The bottling procrastination began with my red braggot misadventures in 2020. At the start of COVID lockdown I headed to the homebrew store for beer ingredients, figuring that being stuck at home would be a great opportunity to try some brewing. March and April 2020 turned out to be pretty distracting, and I didn't get around to cleaning the kitchen plus energy to brew until late May. I put the hops and red malt in the pot for half an hour, then discovered that my liquid malt extract had gone moldy while sitting around for two months. Not wanting to waste part of a brew, I switched my plan from a 50%/50% malt/honey braggot to a 3:1 or 4:1 mix with a little less volume and no aroma hops. 2020 continued to be distracting (remember doomscrolling?) so June rolled by without bottling, then July, and then the onset of "ugh, I cleaned the kitchen, I can't possibly accomplish anything else this weekend.

2021 brought a return to "go out in the world and do things. It was also a good year for apples in Boulder County, so I spent a weekend with good folks first shaking apple trees, then squishing apples. I got home Sunday night and put sulfites in five gallons of apple cider in a bucket and started a three gallon batch of cyser with a different honey. Monday night I pitched yeast in the cider, Tuesday we packed for Element 11, Utah's regional burn. Normally I would rack from the bucket to the carboy after a week or two. "We just got back from a Burn" is clearly not enough energy to clean the kitchen. The next weekend was also in energy recovery mode. And once again the cycle began. I finally had the time and energy to rack it to secondary two months later, probably on Thanksgiving weekend. And then I discovered that either the sulfites hadn't killed all the wild microbes, or the several inches of headroom in the fermenting bucket and a little unsanitary spot had allowed a significant layer of pellicle to form on top of the liquid. I was worried the project was ruined, but I racked it to a carboy anyway and planned to check the Internet for solutions. I put a quart of it in a separate bottle for investigation. I drank that over the ensuing weeks and it wasn't terrible, nor did I get sick. So now I just needed a plan for dealing with the pellicle.

2022 through 2024 continued to be distracting. I had a lot of vacation time saved up coming out of the pandemic, so I spent a lot of 2022 planning for, at, or returning from a fun adventure. In 2023 I got really into Parks on the Air, so any weekend with good weather was a lot more tempting to spend an afternoon playing radio than cleaning and bottling. 2023 and 2024's 4-day weekends in July were filled with Dead shows and new cats, and the November 4-day weekends had turned into "get ready for Advent of Code." I was at least responsible enough not to start any new homebrew projects while there were four carboys awaiting.

After twelve hours of moving fluids around, resterilizing equipment, and "relax, don't worry, have a homebrew," the complete bottle array looks kind of smaller than I'd imagined. The contents are pretty good, though. The previous night I racked the cider to the bucket, leaving the pellicle layer behind. I put a quarter teaspoon of potassium metasulfite in overnight, so hopefully that prevents anything from redeveloping in the bottle. The taste is quite dry and a little funky; it won't be to everyone's liking, but Jim liked it. The red braggot came out a dark amber, almost brown, with about 9% alcohol. It also left some interesting colors and shapes at the bototm of the carboy, and it's going to take several attempts to scrub the carboy completely clean. The 2018 cyser has mellowed pretty nicely and has a decent flavor, while packing a punch at 15% alcohol. The 2021 cyser is probably the best of the bunch: it started at 14% potential alcohol, but finished with 3% remaining: I used a British ale yeast instead of a wine yeast, so it can't hit ABV in the teens. This means it's remarkably sweet, preserving a lot of they honey flavor (though not so much of the apple). It also finished remarkably clear, a light gold color you can see through, while the 2018 cyser is a dark orange. I suspect the color difference is due to the honey: an American blend for 2021 and Brazilian wildflower in 2018.

Making mead with ale yeasts is something I'll have to pursue further. I'd been following the practices of other yeastherders and brewing with wine yeasts, which can generally process all the sugar you can pack in with honey. But a beer-strength yeast lets more sugars remain, better preserving the sweetness and character of the honey. Plus, I think there are more high-temperature ale yeasts than there are wine yeasts, for those of us without a cellar.