DEV Community: Kate Pond

Sidewalk to Summit — build log

Kate Pond — Sun, 16 Aug 2026 22:10:12 +0000

A note before this starts moving:
Been quiet here for a few weeks — heads down building instead of writing about it, which is exactly the trap this devlog exists to prevent. So: catch-up first, then this becomes the actual habit. One running post, edited in place every time I do real work, newest bit on top. No pile of unpublished drafts allowed after tonight.

Aug 11–16 — Not a build week: fine-tuning the plan with Melanie

Build hasn't been happening because Melanie and I are fine-tuning the planning — a call to pressure-test the app's direction before more of it gets built. Nothing shipped, nothing to demo yet. Next real checkpoint with her is Aug 25.

The day after that call I flew to Amsterdam, already on the calendar and not exactly restful timing. So the last few days have looked like: read what got proposed while I was in transit, ratify or correct it, repeat, jetlagged. Slower than a build day. Still real work.

Aug 10 — A property test catches a quiet undercount; CI lands

Property testing wrapped up on the plan engine — recovery weeks, peak placement, taper. (Quick definition since it's not unit testing: instead of me picking a few example inputs by hand, the test throws hundreds of randomized ones at the code and checks that a general rule never breaks.) One of the new tests caught something I did not want to find: the function that estimates how many weeks a plan takes has been quietly wrong since the day it was written. It assumed the training ramp always grows at its fastest allowed rate. It never has — a decision I made weeks ago about how midweek sessions scale means a slower cap kicks in first, every time, not just on rare edge cases. It also forgot to count week one, which doesn't ramp at all. Both mistakes lean the same direction: undercounting. Which means a plan could get waved through as "fine" while quietly falling short of the fitness it promised to build. Not a fun bug to find. A good one to find with a robot instead of a knee.

CI also landed, finally: typecheck, lint, and tests now gate every pull request. It immediately found four pre-existing security holes in dependencies I didn't write, fixable only by a framework upgrade spicy enough that I'm sitting on it rather than clicking go. Also, two people submitted essentially the same CI pipeline within hours of each other — an outside contributor and a parallel session of my own — so I got to experience the mild chaos of reviewing my own duplicate PR.

Also also: a friend looked at the app and told me the background needed more personality. So she hand-drew one — mountain, stream, evergreens, a trail, a tiny hiker — and delivered it in person like an actual patron of the arts. I tested it behind a real plan screen before getting attached to it. Verdict: fun illustration, bad background generated from it. Filed as a decision, not shipped as a component. I'm going to speak to a designer friend to really help me come up with something great based on this concept.

Aug 2 — Eight tasks in four hours; the baseline rule that punished a beginner for being honest

Eight tasks in about four hours, which blows through my own "one task a day" rule badly enough that I'm not even going to pretend otherwise. Most of the deterministic plan engine got built in one sitting — effort math, baseline interpretation, feasibility, week generation, route matching — then I abandoned property-testing mid-task and built the intake form instead, because I wanted something real to put in front of Melanie Michaelchuk before Tuesday. The bill for moving that fast: five judgment calls are sitting in the decision log waiting on me to actually stand behind them, and if you'd asked me that night, I could not have defended all five off the top of my head.

Here's the one worth telling. The baseline test hike is supposed to size itself conservatively for someone starting from nothing, with a floor so week one never asks too much. For my most sedentary test persona, that floor turned out to be doing something sneaky: her own honest report of an easy walk landed below it, so the app quietly handed her a bigger test hike than she'd actually asked for. Then, because the rule reads a hard outing as proof she'd underestimated herself, one rough day out made her whole plan meaningfully harder — off a starting point that was already inflated. The weaker the user, the worse it got. That's precisely the opposite of what the rule was supposed to do, and I only caught it because I had Claude run one specific beginner's numbers by hand. Fourth spec bug in as many days, and every single one turned up the same way: not by reading the rule, by actually running it on a person.

Jul 29 — Paired with Peter, six tasks land; CJ asks for a plan and outranks my own gate

Peter and I hopped on a Google Meet, screen shared, and built for ninety minutes — him, me, and Claude, which I've decided officially counts as a mob. He's a friend volunteering his time, and he does DevOps professionally, so I'd sent him an infrastructure one-pager the night before specifically asking him to find the holes in it. Six tasks came out of that sitting: schema migrated, seed pipeline written, real data loaded (fifteen Washington trails checked against WTA's own numbers, eight urban hikes, ten stair spots, six workout templates), a soft-delete flag, and the app's actual first page — /routes, all thirty-three seeded routes with real computed effort, several honestly tagged "estimated" instead of pretending to be exact.

Then, separately, my friend CJ texted: he's through-hiking the Enchantments in a few weeks, could I build him a plan. That one text reordered the roadmap. I'd shelved the app's biggest feature — generating a route from wherever you actually are, instead of picking off a curated list — all the way out to a future version, even though it's the thing basically every doc I've written about this project calls the actual point. It got promoted on the spot. CJ needs a plan, not a map, so now it's: finish the core engine for him first, then build the location-aware stuff before any stranger ever sees this thing. First time an actual human has outranked my own plan.

Jul 25 — Domain picked, first deploy: it's live and does absolutely nothing

The empty scaffold is live on the internet. I picked the shorter of two subdomain options (life's too short to type the long one), pointed a DNS record at the hosting platform, connected the repo, and deployed. SSL just... issued itself. The site loaded with a padlock and the default framework starter page, and that padlock is currently protecting nothing of value whatsoever. The task was "every merge lands on a live URL" — and now it does. Same night the database got wired in too, health-checked against both local and production.

Going in, I'd pictured domain setup as roughly "making a subdirectory." It is not that. The registrar just holds a single DNS record pointing somewhere else entirely, and I don't actually know much about DevOps, which I felt very acutely tonight — double- and triple-checking every field before clicking anything, the exact caution I'd want from a contractor I'd hired to do this instead of me.

Jul 18 — Accounts night: the best spend cap is money you've already spent

Accounts night: hosting, database, and an API key, all set up in one sitting. One genuine decision fell out of it — the database provider locks in its Postgres version the moment you create the project, so production ended up dictating local dev's version instead of the other way around, which is not what the plan assumed.

Better find: my own build plan told me to set a hard monthly spend cap on the LLM API, "not just an alert." Turns out you can't actually configure that directly — but you don't need to, because new API accounts run on prepaid credit. So I bought $20 of it and turned auto-reload off. That's the entire safety mechanism now. If something ever hammers the one AI feature this app has, it burns through the credit and the API politely stops answering. No setting I could configure beats money I've already spent and can't spend again.

Jul 14 — Planning day becomes build day one

A planning morning turned into the first build day, which is how basically every ambitious plan I've ever made actually goes. The morning went into the knowledge base the whole build runs on: spec docs, security and UX guides, backlogs, a decision log. Biggest call to fall out of it: maps are back in the MVP after all, staged as a ladder from "show a curated map" up to the real location-aware route generation I actually want, with the scarier rungs deliberately parked behind real user feedback. Then, in the afternoon, the actual building started — repo scaffolded, running locally, contributor guide written.

Best part of the day: I was seriously about to plan out paying people to walk around cities counting staircases for me, mechanical-turk style. Then it turned out the city already publishes its maintained stairways as open data, and a mapping project already tags every staircase with a step count. The exact data I was about to pay strangers to go collect had been sitting in a public dataset this whole time. New rule: check if someone already did the work before you pay someone to do it again.

Sidewalk to Summit: reviving my founder-year idea by building it in public

Kate Pond — Thu, 06 Aug 2026 01:33:30 +0000

When I booked my 2025 hut-to-hut hike in the Austrian Alps, I looked at the daily distances, then at the elevation gain, and my honest first reaction was: oh dear God.

Here's the problem. I used to be a park ranger. Staying fit wasn't a goal I had, it was just what the job did to you. Then I became a software engineer, and now the job mostly does the opposite. These days, every time I want to do a big hike, I have to actually train for it. This is new information for my body and it is not thrilled.

And I don't like the gym membership fees. What I love is walking out my front door and finding out what's in my own neighborhood. That feeling of discovery is a big part of why being a ranger suited me, and most of why I want to see more of the world. But I didn't have a car, so Washington's trails, gorgeous as they are, were mostly out of reach on a weekly training schedule. So I trained the only way available to me: I wandered around my neighborhood and guessed. Was it enough distance? Enough hills? Should I be doing stairs? How many? Carrying what?

What I wanted was an app that would just tell me. This week, do this trail. Can't get to a trail? Fine: walk these four miles and do the water tower stairs six times. A plan that ramps you up a little each week, starting on your own sidewalk and ending at the summit you signed up for. (If you're already guessing where the app's name came from: yes, exactly.)

The eight months I didn't build it

I even had time to build it. I'd been laid off that February and didn't start my current job until October. Eight months. I called it my founder year, with some generous rounding.

I tried. First as a native Android app, where the maps ate me alive. Everything map shaped was either expensive or missing the API I needed, and I stalled out. So I pivoted to a circular economy app idea, partly because King County had grants and incubators for that kind of work. I spent months on business model canvases and persona research. At some point I caught myself writing a business model canvas and personas for the hiking app on the side, like a kid doing their real homework under the desk.

Then the eight months were up. I had a stack of research, a new job, and exactly zero shipped software.

I did the hike, by the way. It kicked my butt, even with the training I'd guessed my way through. Somewhere on the second day of switchbacks I remember thinking: I wish that app existed.

The lesson I actually took from those eight months: if you ask people whether they'd like your app, they say yes. That's not a signal, that's politeness. The only honest test is putting a real thing in front of real people and watching what they do. So this time, "send it to real hikers" isn't a hope. It's a numbered task in my build plan (T33), and it has a gate: it can't fire until the things first users actually need are live.

What I'm building

Sidewalk to Summit. You pick a goal hike, real or dream (yes, you can type in Kilimanjaro), tell it a little about yourself, and it builds a week by week ramp out of what's actually around you. Real trails when you can get to one. Urban hikes, neighborhood walks, and stair sessions when you can't.

And it'll find the stairs for you. This was my favorite discovery of the whole planning phase: Seattle publishes its maintained public stairways as open data. I was about to price out paying strangers to walk around counting steps, and it turns out the city already counted them. If you have a treadmill, you can tell the app that too. That's about the only thing it can't find for you.

The first real architecture decision happened before any app code existed: the math and the words are kept strictly apart. A deterministic engine computes every number in your plan, because a training plan that overprescribes can injure someone. An LLM writes the friendly explanation around those numbers, and it is never allowed to invent one. Building evals and guardrails for AI products is what I do in my day job, and this is the same discipline pointed at my own app: every numeral the LLM writes will have to trace back to the engine's output, and that rule will be enforced in CI, not in a code review comment. There's a whole post coming about this once it's built and defended by tests.

(Why "Sidewalk to Summit" and not the couch-themed name it started with? That's a story of its own. Coming soon.)

How I'm building it

One small task a day, 15 to 45 minutes (though some days I'm hooked on the vibe coding and run long). I plan, an agent writes the code, I verify. Plan, code, verify, repeat. (It's a cousin of the daily self-evals habit I wrote about here.) The planning lives in a knowledge base repo that is the source of truth: the specs, a decision log, the backlogs, and this devlog. The rule is one task per working day. Miss a day? Do that task the next working day. And the devlog is where I admit when I don't hold to it.

The method has to survive real life, because before this build is done it will cross an ocean with me. That's on purpose.

Why like this

My company is called The Pond's Edge, and the name is the whole thesis. Life thrives at edges. The pond's edge is where things grow and change and expand. Park ranger to software engineer was one edge. The edge I'm walking now is designing work around a life instead of the other way around: flexible hours, four-day weeks, living in other countries for months at a time. It's a constraint I'm engineering within, the same way the app has to work for someone with no car and no gym.

If this app succeeds, the win isn't downloads or revenue. It's proof that the working style works. That one small task a day, planned carefully and verified honestly, is a real way to build software and live on your own terms.

Follow along here: dated entries in the running devlog, standalone posts when something real ships.

The Promotion Doc That Writes Itself

Kate Pond — Fri, 03 Jul 2026 00:45:23 +0000

TL;DR: I set up a Claude Code skill that checks in with me about my workday, asks follow-up questions, and saves a structured markdown file I can use as promotion evidence. Here's why it works, and how to build one in about five minutes.

May 6th

On May 6th I had an energy level of 2 out of 5.

I got my Claude Certified Architect exam score back that day: 717 out of 1000. I needed 720. I missed it by three points.

Four lines down in the same entry, my manager had told me: "your leadership is being felt around Artium. You're making a good impact."

Here's the thing about that day: the bad number is vivid and self-evident. 717. Three points short. That number was going to live in my head rent-free for weeks. But the recognition? That quietly evaporates. Left to memory, May 6th is the day I failed the exam by three points. On the page, it's also the day my manager told me my leadership was landing across the company.

The entry keeps the thing I'd lose otherwise.

The Problem With Memory

I've been bad at this for years. At performance review time, I'd stare at a blank document trying to remember what I'd actually done. I'd come up with four things instead of forty. My manager would advocate for me based on what she happened to see, which was never the full picture.

The thing is, I did good work. I just didn't capture it.

A few years ago I tried to solve this with Google Forms, a structured form I'd fill out at the end of each day that fed into a spreadsheet. It worked, kind of. The data was there, but it felt like homework. The form didn't ask follow-up questions. It didn't notice when I was being vague. I had to go somewhere specific to fill it out. And when review time came, I had to go back somewhere else to compile everything, figure out what mattered, and assemble it into something coherent. The friction wasn't just the daily entry. It was the whole chain: capture, retrieve, synthesize, present. I was on my own at every step.

So I built something better.

What I Built

I have a git repository called daily_self_evals. Inside it, every workday gets its own markdown file:

entries/
└── 2026/
    └── 03/
        └── 2026-03-02.md

Each file has YAML frontmatter (date, day, energy level, tags) and sections for what I shipped, the impact of that work, wins, challenges I overcame, recognition I received, and what's next. Here's a representative example of what an entry looks like:

---
date: 2026-02-12
day: Thursday
week: 7
energy: 4
tags: [shipped, cross-team, recognition]
---

# Daily Eval — Thursday, February 12, 2026

## Shipped
Wrapped up the LLM observability integration. Multi-turn conversation
history is now captured and agent tool calls are visible for evaluation.
This had been a gap in the platform for a while.

## Impact
The team called it out as a major win in our retro. Other engineers
can now actually see what the agent is doing across a full conversation,
not just at individual turns.

## Wins
Got the company spotlight award today. Wasn't expecting it.

## Recognition
My manager flagged it in the all-hands. A few people I don't work
with day-to-day sent messages saying they'd been waiting for this.

The Skill

In Claude Code, you can build a custom skill: a saved workflow with a description that tells Claude when to use it. I built one for journaling, and the nice part is I don't invoke it with any special syntax. I just talk to Claude Code the way I'd talk to a coworker:

"Hey, let's make an entry for today."

"Can you record this win I just had?"

Claude recognizes that these match the journaling skill and runs it. (You can also invoke it manually with /daily-eval if you prefer typing a command, but I never do.)

When it runs, Claude first checks if an entry already exists for today. If it does, it reads what's there and asks what I want to add. If it doesn't, it starts fresh. Either way it appends and never overwrites, so I can log something at 2pm and add more at the end of the day, and it all lands in the same file.

Then it asks me questions, one at a time, conversationally:

"What did you ship or move forward today, even if it was small?"

"What effect did that have on your team or the product?"

"Did anyone thank you or give you good feedback?"

It's not a form. It feels more like a five-minute debrief with a colleague who's genuinely curious. When we're done, it writes or updates the file and tells me where it saved it.

Why the Conversational Format Matters

The STAR framework (Situation, Task, Action, Result) is embedded in the question flow without being named. When Claude asks "what effect did that have?" after I describe a task, I think harder. I give better answers than I would in a form. By the time I'm done, each entry reads like something I could hand to a hiring manager or drop into a performance review, because the prompts shaped it that way from the start.

What You Can Do With the Files

Everything is plain markdown with YAML frontmatter. No app. No database. No lock-in.

That means you can:

Export to Word or PDF: pandoc entries/**/*.md -o accomplishments.docx
Import the whole folder into Notion or Obsidian
Ask Claude to summarize three months of entries before a performance review
Paste any entry directly into a promotion packet or 1:1 doc
Push it to a private GitHub repo for a permanent, timestamped record

Because the YAML frontmatter includes structured fields like energy level and tags, you can also ask Claude to generate charts and analysis across your entries. Energy level over time. Which weeks had the most wins. How often you shipped versus how often you were blocked. The Google Forms version of this system fed into a spreadsheet that could do exactly this kind of visualization. The Claude Code version can do the same thing, just by asking.

One More Use: When Someone Asks You for Feedback on a Colleague

Peer feedback requests always arrive at the worst time. Someone asks you to fill out a survey about a teammate you worked closely with three months ago, and you stare at the form trying to remember anything specific.

If you've been logging your interactions, you don't have to remember. You can ask your journal: "When did I work closely with [name] and what did I notice?" You'll have the actual moments, the specific things that helped you, the friction you observed. Your feedback becomes something a manager can actually act on, instead of the generic "great to work with, highly recommend" that tells everyone nothing.

The record makes you a better peer, not just a better advocate for yourself.

How to Set This Up

You need Claude Code installed. Then just ask Claude to build it for you. You don't need to create any files manually. Open Claude Code and paste something like this:

"I want to set up a daily work journal to build promotion evidence. Create a ~/daily_self_evals/ project with a CLAUDE.md, an entries/ directory organized by year and month, and a global skill at ~/.claude/skills/daily-eval/SKILL.md. Give the skill a description so you'll recognize when I ask you to make a journal entry or record a win in plain language, and make it invocable as /daily-eval too. When it runs, it should check if an entry already exists for the target date before asking questions, ask one question at a time about what I shipped, the impact, wins, challenges, recognition, and what's next, and save entries as markdown files with YAML frontmatter. All entries should be appendable and never overwrite existing content."

Claude will handle every file. You just review what it built, open a fresh conversation, and tell it you want to make today's entry. (Skills load at the start of a conversation, so open a new one after setup.)

What Happens After a Few Months

I now have a body of evidence I've never had before. Specific accomplishments. Measurable impact. Quotes from colleagues. An energy rating that shows me my own patterns over time: what kinds of days light me up, what kinds drain me.

When it's time to make the case for a promotion, or find a role that's more interesting and pays better, I won't be starting from memory. I'll be starting from a record.

And on the days when I miss a certification by three points and want to believe the whole day was a loss, the record knows better.

One last thing: this system isn't finished. I keep tweaking the questions, adjusting what the frontmatter captures, experimenting with how I ask for summaries. That's part of the point. It's a tool I own and can improve, and the more I use it, the better I get at using it. The version I'm running today is better than the one I started with, and the version I'll be running in six months will be even better.

Inspired by Get your work recognized: write a brag document by Julia Evans, and my earlier experiment with Google Forms for self-evaluation.

Not Enough SMEs or Customers to Make Your Evals? Make Some!

Kate Pond — Thu, 25 Jun 2026 15:07:57 +0000

TL;DR: When you cannot reach real users or SMEs to build eval data, you can build realistic stand-ins instead. Gather everything you actually know about the user into a knowledge base, use Claude Code to synthesize personas from it, have the people closest to the user validate them, then turn the validated personas into agents that generate multi-turn conversations and edge cases for your eval set. The trick is grounding: a persona is only useful if it comes from real evidence and gets checked by someone who knows the user.

If you have been building with AI for a while, you probably remember when personas were how everyone learned to prompt. Something like:

You are Rob Pike, architecting a new service in Go. Be opinionated and concise, and explain the tradeoffs behind your choices. How should I structure the packages?

We all did some version of that.

Then the field kind of moved on. We still hand agents a personality here and there, but persona prompting stopped being the headline move. It started to feel like a beginner trick.

I think personas are coming back. Not for voice and flavor this time, but for something more serious: they are a way to manufacture a stand-in for a human you cannot actually reach. And it turns out that solves a real problem in evals.

The bind

Here is the problem I keep running into.

You need evals. Good evals need data that looks like real usage. And to make data that looks like real usage, you need access to real users or subject matter experts. But a lot of the time, you do not have enough of either, at least not yet.

Maybe the product is early and there are not enough users to learn from. Maybe your SMEs are real but hard to reach, the kind of people who do not have time to sit with you for a thousand test cases.

In my case it is often structural. I do consulting work, and a lot of the time we are building for a company that has its own clients. There is a layer between us and the people who will actually use the thing. I may never get in a room with the end user at all. That is not a budget problem or a laziness problem. It is just the shape of the engagement, and no amount of asking nicely changes it.

The reframe

You do not need real users to start. You need realistic ones. And realistic ones you can build.

The key word is build, because the difference between a useful persona and a useless one is where it comes from. A persona you invent out of your own head is just your assumptions wearing a costume. The whole thing only works if the personas are grounded in the closest real humans you can actually reach.

The method

Here is what I actually did.

1. Build a knowledge base. I create a repo and fill it with everything I have learned about the end user. Meeting notes from discovery calls. Transcripts, when the client is comfortable being recorded. Research I have done on my own from public sources. Anything that tells me something true about who this user is and where they get stuck. The point is to triangulate across sources instead of leaning on a single conversation.

2. Point Claude Code at it and generate personas. I use Claude Code to read across the whole knowledge base and synthesize a small set of basic personas. Not a chat window, a repo. That matters, because the personas are coming out of a curated body of evidence rather than one prompt and a vibe.

3. Have the client validate them. This is the step that does the real work, and it is the one I would not skip. I send the personas back to the client to correct, enrich, and push back on. Sometimes the client has a UX research team and real user data to check against. Sometimes the client just knows their customer in their bones from working with them for years. Both are legitimate. The human who cannot sit for a thousand eval cases can still look at five personas and say, no, this one would never do that. That validation is what turns the personas from my guesses into the client's real knowledge, captured and structured.

4. Turn the personas into agents that exercise the product. Once a persona is validated, it goes back in the repo and becomes something I can use on demand. I can tell Claude Code, use this persona and hold a multi-turn conversation with the chatbot the way this user would. Out the other side I get user-phrased turns, full multi-turn conversations, and edge-case inputs. Those become cases in the eval set.

I want to be honest about how simple this was. The first version was basic. I was not doing anything clever. And it still gave us genuinely interesting outputs, the kind of conversations and edge cases we would not have thought to write by hand.

Where this breaks

A validated persona is a proxy, not ground truth, and it is worth being clear-eyed about that.

The personas are only as good as the evidence underneath them and the client's willingness to correct them. If your discovery was thin, your personas will be confidently wrong, and a confidently wrong eval is worse than no eval. They will also tend to miss the genuinely weird stuff, the inputs no one anticipated, because they are built from what people already expect their users to do. Real humans are stranger than any persona you will validate in a meeting.

So I do not treat this as a replacement for real user data. I treat it as a way to start before you have it, and as a complement once you do. The day real users show up, you check your personas against them and find out how close you got.

Who should try this

If you are building an AI product and you are stuck on evals because you cannot get to your users yet, this is worth an afternoon. You do not need a research team or a big budget. You need whatever real signal you can gather, a place to put it, and a willingness to let the people closest to the user tell you where you got it wrong.

Start small. One knowledge base, a handful of personas, one validation pass, one multi-turn conversation generated from a persona you trust. See what comes out. You can make it fancier later, or you may find, like I did, that the basic version already earns its keep.

Now I am exploring whether the same personas can serve as a regression harness for product improvements. More on that if it pans out.

“Where Tech Meets Planet: A Quickstart Glossary for Climate Tech - Curious”

Kate Pond — Thu, 24 Apr 2025 05:13:12 +0000

🌿 Start Here: What Is Climate Tech?

Climate tech refers to technologies that reduce greenhouse gas emissions or help people adapt to the effects of climate change. That includes:

Software for tracking carbon emissions
Hardware like smart sensors or solar panels
Tools that help protect biodiversity and ecosystems
Platforms that connect people to climate action and jobs

But it’s not just for scientists or environmental orgs, it needs designers, devs, analysts, writers, community builders, and dreamers.

🧠 What’s That Mean? — A Tiny Climate Glossary

Carbon Accounting

Tracking how much carbon a product, company, or activity emits.

Think of it like a budget, but for the atmosphere.

Mitigation vs Adaptation

Mitigation = slowing down climate change (e.g. reducing emissions)

Adaptation = dealing with its effects (e.g. flood-proofing cities)

Regenerative

A step beyond “sustainable.” It means designing systems that restore, not just maintain.

Greenwashing

When something is marketed as eco-friendly... but it’s mostly vibes. Learn to spot it.

📌 Communities & Resources

Communities to Join

Job Boards & Learning

Want to listen instead?

Volts

🔍 Where Tech Meets Planet: Examples

Tech Skill	Climate Use Case
Backend Dev	APIs for emissions tracking platforms
UX Design	Interfaces for electric grid visualization
Data Analytics	Mapping climate risks by neighborhood
AI/ML	Forecasting wildfires or extreme heat
Storytelling	Helping people care, not just understand

💬 Let’s Connect

I used to be a park ranger. Now I’m a software engineer building systems that (I hope) make the world a little better. If you're curious, overwhelmed, excited, or unsure, I'm happy to chat.

🌱 Find me at The Pond's Edge
💌 Message me on LinkedIn