The speeches given by both David and Bob were inspirational, and of course, focused on learning. I say “learning” here, and not teaching, because both of their speeches emphasized that it wasn’t about them, the teacher, but about us learning to learn, and the wonderful things we had built as a result. For David, the speech centered around earning a student’s trust and getting them to realize their full potential. He did so by pushing us to our limits and then a bit past, not so far that we would break, but far enough to make us realize we had so much more in us than we realized. For Bob, he used the analogy of being a coach, finding what made each of us tick, what our strengths were, and leveraging those so we could build something great.

I have always thought that the most important thing I learned in college was how to learn. What are the resources at hand that you can use to learn something new? Find them and use them. Learning in college that someone is not going to spoon-feed you the answers for the rest of your life was a bit of a wakeup call. I can remember vividly when a group of students stood at the front of the classroom at the end of one of David’s lectures, after giving out one of his monster homework assignments that was surely going to take many many hours to complete by the Friday deadline, and a student said, “How do you expect us to do this and get an A when we have a full class load we are trying to get A’s in as well?” I don’t remember David’s exact response, but it was something like, “I don’t expect you to get A’s in all of your classes, I expect you to learn.” That was the moment when it clicked with me that we were there to learn to learn, not to get A’s.

The Builder’s Dread

The discussions I had with many folks this weekend inevitably made their way to AI and the use of LLMs, and specifically using Claude Code for coding among other tasks. Many colleagues of mine create software, so it was top of mind for many. The discussions were great. What can they do well? (create prototypes and UIs that are prevalent in the training data) Where do they fall flat on their face? (coming up with truly novel algorithms that are more than just reassembling known components) How expensive are they to use? (not that expensive, but token limits are getting reined in at many companies, and are going to balloon 10-100x when VC subsidies dry up) Are these models ethical to use? (varying opinions per domain with an uneasy ‘no, but…’ or ‘yes, but…’)

Then, many of the conversations veered into the dread people are feeling when using AIs. The majority of the crowd were engineers. Engineers are builders. We love to build. When we build a thing, we start with nothing, bring together materials and knowledge, and at the end we have something. That something wasn’t there before and now it exists. Ideally, it does something useful. And I think one thing people often forget is that the builder probably learned something along the way. For me, it was always the learning that was so much more rewarding than the thing I built. I suspect much of the dread people are feeling when using AI to create software today is the realization that they have stopped learning.

I wrote about this briefly in my Architecture of a High-Throughput Lab post in the section “The Teach-Lesson Skill.” For me, when I started using Claude Code, I was excited to learn the tool, so it didn’t really matter what I was building. But as I got more familiar with the tool and less learning was happening, I realized I was also not learning about the code I was creating with the tool. I could go heads-down for a day and have all of the functionality I was asking for in the code being produced, but I would have no idea how it worked, what algorithms it used, why it did what it did. I think this has changed a little bit with the output I have seen from Claude Opus 5, being a bit more verbose in explaining why it did what it did in a response, but it is still lacking.

You might ask, well why is Claude (or any other LLM) such a bad teacher? It’s pretty simple, you didn’t ask. Our prompts when iterating with Claude Code are usually of the form “write me this feature.” It figures out how and it writes it, with a minimal explanation of why, but it doesn’t have to be this way. Ask Claude to be a great teacher.

The teach-lesson Skill

I started using an addition to my CLAUDE.md file (basically the file that gets added to every prompt) when I want to learn as I go interacting with Claude:

Extract a key insight from a completed task and write a short teaching lesson. Use after finishing a non-trivial bug fix, feature, refactor, or investigation.

Eventually, this became a full fledged Claude Skill so I could describe when I wanted the skill to be used, more details on how the lesson should be structured, and how to save the lesson. Here is the full SKILL.md file from one of my projects where I have used this learning technique.

https://github.com/briangbrown/drumline-scores/blob/main/.claude/skills/teach-lesson/SKILL.md

name | teach-lesson

description | Extract a key insight from a completed task and write a short teaching lesson. Use after finishing a non-trivial bug fix, feature, refactor, or investigation.

Workflow

After completing non-trivial work (bug fix, feature, refactor, or investigation), extract one key insight — something you had to know or figure out — and teach it as a short, digestible lesson.

1. Decide whether a lesson is warranted

Write a lesson when the conversation involved:

• A non-obvious TypeScript, React, or Vite pattern you had to apply

• A math or algorithmic concept central to the fix

• A tricky architectural decision or tradeoff

• A subtle bug whose root cause is worth understanding

• A domain-specific insight about WGI scoring, percussion data, or CompetitionSuite parsing

Skip it for purely mechanical changes (typo fixes, renaming, trivial config tweaks).

2. Write the lesson

Keep it short — aim for under 30 lines. Use this structure:

# <Lesson Title>

**Why it matters:** One sentence on when this knowledge applies.

## The concept

Two to four sentences explaining the core idea clearly.

## In this codebase

A concrete code snippet or reference to the specific file/function where this appeared.

## Key takeaway

One crisp sentence the reader should remember.

3. Save the lesson

Get the current short commit hash:

git rev-parse --short HEAD

Save to:

docs/lessons/<lesson-category>/<lesson-topic>/<lesson-name>-<short-hash>.md

• lesson-category — high-level grouping (e.g. typescript, react, scoring, parsing, architecture)

• lesson-topic — more specific subject within the category (e.g. generics, hooks, wgi-eras, competitionsuite)

• lesson-name — kebab-case name for the specific lesson (e.g. cross-era-domain-normalization)

• short-hash — first 7 characters of the current git commit hash

Reuse existing category and topic directories where they fit. Create new ones only when no existing grouping applies.

4. Surface the takeaway

After writing the lesson, briefly surface the key takeaway inline in the conversation so it is visible without opening the file.

I did not write this file directly, mind you. I asked Claude to write it, and by telling it my goals of creating a lesson, I could learn from when it had created something non-trivial in an interaction. There are some key aspects of how this system works that make it an effective learning tool for me.

The Anatomy of a Lesson (and the Science Behind It)

Let’s take a look at a real lesson from one of my codebases as an example to see why the different parts exist. I will use this commit, which added input validation for a score parsing pipeline that fixed a security vulnerability I had surfaced during a security audit. The resulting lesson file looks like this:

Validate for the Sink, Not the Threat List

Why it matters: Any time you add input validation to the pipeline, the correct rule depends on where the value is used, not on a generic list of scary characters.

The concept

Dangerous characters are only dangerous relative to an interpreter. A backtick means something to a shell, ../ means something to a path resolver, < means something to an HTML parser — and nothing to anything else. So the rule is derived from the sink: trace where the value actually flows, then reject what that specific sink would misread. Validating against a generic threat list instead produces two failures at once — it misses the sink you didn’t think about, and it rejects legitimate data that merely looks alarming. The second failure is the expensive one, because false positives on valid input erode trust in the gate until people start overriding it.

In this codebase

Issue #137 asked for shell-metacharacter rejection in src/pipeline/validate.ts. Tracing the sinks showed the premise was stale: commit.ts and reportIssue.ts had already moved to execFileSync with argument arrays (#130), so no shell ever parses these strings. Running the proposed pattern /[`$\;|&<>]/ over the 90 archived show files rejected a real one — the 2021 championships, on the ensemble Bobby & Ben.

The sink that did matter was never mentioned in the issue. src/import.ts builds the output path by interpolation:

const showFileName = `${showData.metadata.id}.json`
const showFilePath = resolve(args.outputDir, showFileName)

resolve() happily walks out of outputDir, so an id of ../../../etc/ passwd [[note: I had to put a space between ‘/’ and ‘passwd’ because substack’s own input parsing will not let you add that string]] escapes it.

Key takeaway

Follow the value to its sink before writing the regex: the characters worth rejecting are the ones the destination will interpret, and everything else you block is just a false positive waiting to page you.

1. The Title

The lesson title, “Validate for the Sink, Not the Threat List”, basically something memorable that encompasses the lesson. This is important for retrieval, so your mind can find the lesson in the future, but I’ll talk more about this below when the lesson actually gets stored.

2. Why it Matters

The “Why it Matters” one-liner. “Any time you add input validation to the pipeline, the correct rule depends on where the value is used, not on a generic list of scary characters.” This is just simply saying that when you do input validation, it matters where that input gets used; not all of the possible bad characters or characteristics of the input that could ever possibly matter. It is a waste to filter out SQL injection attacks from an input string that will never get evaluated by a SQL engine. This Why it Matters one-liner helps the user feel motivated to learn the lesson and understand its importance to their work.

This parallels research by Hulleman & Harackiewicz, who ran a randomized intervention in high school science classes: one group summarized what they’d learned, the other wrote about how it connected to their own lives. “Connections of personal relevance were stronger than good grades for predicting interest in further science courses and future science careers.” (2009, Science).

3. The Concept

The core of the lesson, or “The Concept”. This is where the concrete thing that was done in their project is abstracted to a generalized concept that can be applied in future work. This is sandwiched between the Why it Matters and the concrete in this codebase section.

Educational psychologists Fyfe, McNeil, Son & Goldstone refer to this as “concreteness fading,” marrying the benefits of concrete and abstract materials. In this case, the user has just experienced the concrete in the change they just made and is being introduced to the abstract in “The Concept” (2014, Educational Psychology Review).

4. In the Codebase

The “In the Codebase” section is the connection to the concrete work that was done where this lesson applied. This relates to the theory of situated cognition, where human thinking and learning is connected to the physical context in which they happen. Not only the code itself, but the physical act of creating the code. This prompt helps the user recall not only where to apply a lesson, but when they learned it, reinforcing the lesson. In addition, every lesson written by this skill is project-based by construction. I have always found project-based learning to work well for me, and this seems to be backed by research as well.

Brown, Collins & Duguid argues that abstracting conceptual knowledge from the situation in which it is learned and applied limits its effectiveness (1989, Educational Researcher). Chen & Yang did a meta-analysis of journal articles published from 1998 to 2017, representing 12,585 students from 189 schools in nine countries and found project-based learning beat traditional instruction at d = 0.71 (2019, Educational Research Review). [I am not an expert on effect size and statistics, but I guess d = 0.5 is considered a moderate difference and d = 0.8 is a substantial difference.]

5. The Key Takeaway

The key takeaway is a kind of “retrieval handle” in my mind. It is written as a rule I can apply next time. It is also the same text that is written inline at the end of a conversation with Claude. So, for this example, Claude wrote at the end of its turn:

Key takeaway

Follow the value to its sink before writing the regex: the characters worth rejecting are the ones the destination will interpret, and everything else you block is just a false positive waiting to page you.

Saved to docs/lessons/security/input-validation/validate-for-the-sink-not-the-threat-82a282c.md

This lets me make a note that a lesson was written, see a kind of teaser of the lesson, and gives me an easy path to dive deeper into the lesson if I want. I can then make a choice: do I already know this lesson well and can probably skip reading the details, do I want to dive deeper into the lesson now, or do I make a mental note and move on with the work at hand, potentially returning to the lesson in the future.

Building a Taxonomy of Knowledge

Where the lesson is saved is more important than the name of the lesson. Or maybe, you can think of the directory structure as just part of the fully qualified name. If you look at the Skill, it says to save to:

docs/lessons/<lesson-category>/<lesson-topic>/<lesson-name>-<short-hash>.md

The other key is the instruction:

Reuse existing category and topic directories where they fit. Create new ones only when no existing grouping applies.

This introduces a two level hierarchy that is a simple taxonomy for these lessons. Category and topic are just two different words for a group in this case, and I wasn’t particularly clear as to what they should be, and it doesn’t really matter. I don’t know what the taxonomy is going to be ahead of time because the space of the lessons can be vast, and certain parts may be much more dense than others. I also didn’t want to use tags because I wanted a tree that was easily browsable after the fact. There seems to be research that creating a nested hierarchy like this improves recall, and that an expert categorization by concept vs. a surface-level novice grouping is better for problem solving.

Bower, Clark, Lesgold & Winzenz gave people word lists either in random order or arranged as a nested hierarchy; recall from the organized version was two to three times better (1969, Journal of Verbal Learning and Verbal Behavior). Chi, Feltovich & Glaser had physics novices and experts sort problems into groups. Novices sorted by surface features whereas experts sorted by underlying principle. In this case we are the novice and Claude is the expert. The study implies improved problem-solving efficiency with the expert categorization (1981, Cognitive Science).

The trailing -<short-hash>.md in this case -82a282c.md gives you the ability to look up the commit associated with the lesson with git show <short-hash>. This is, of course, redundant because you can look at the commit for the file in the GitHub UI, but it is a shortcut for you to get to the original work. This allows you to expand the “In this codebase” section to be the full context of the change, including any links to bugs being fixed or features being added.

Lastly, the trigger for this skill is important.

Extract a key insight from a completed task and write a short teaching lesson. Use after finishing a non-trivial bug fix, feature, refactor, or investigation.

There is then a more detailed description as Step 1 of the Skill saying if a lesson is warranted and an explicit instruction when to skip it:

Skip it for purely mechanical changes (typo fixes, renaming, trivial config tweaks).

The big thing here is to not fire on every trivial change that Claude commits to the codebase, otherwise I would stop reading the lessons. If you see an alert on every turn, you will learn to dismiss it: cookies anyone?

Where the System Falls Short

There are lots of things this system doesn’t do. The current skill creates a great set of project focused lessons that would be good to read or re-read to learn some key concepts used in the codebase. But, reading isn’t retrieval. There seems to be clear research that supports being tested beats re-reading when it comes to maximizing retrieval.

Roediger & Karpicke showed recall-tested students outperformed restudying students after a delay of a week, even though the restudiers felt more confident (2006, Psychological Science). Dunlosky et al. rated ten study techniques and found only two of high utility: practice testing and distributed practice; rereading scored low utility (2013, Psychological Science in the Public Interest).

From my own experience, I have yet to go back and extensively study these taxonomies, as they have built up in my other projects. I definitely feel better as I am going along, learning concepts as they appear, but I am not sure that if someone asked me about one of them I could perform with high recall. I would definitely know where to look to retrieve the information, which is definitely a start. One of the other things the system could be extended to do is perform a scheduled retrieval of a new lesson to facilitate distributed practice.

Cepeda et al. synthesized 254 studies and found distributed practice reliably beat massed practice. The specific optimal study gap varies with the test delay, but optimal long-term retention benefits greatly from study sessions spaced a day or more vs. crammed practice (2006, Psychological Bulletin).

All of this research comes with caveats in that they were all conducted on human learners in labs or classrooms on verbal or mathematical material, none of it on a developer working with Claude. But it seems plausible that some of these mechanisms transfer. When I use the Skill, it definitely makes me feel more connected to the work. Whether or not I am actually learning more remains to be seen. The jury is still out if an AI tutor can overcome the economic dilemma posed in Bloom’s 2 Sigma problem, but it seems very promising.

Taking this back to where we started this post, I talked about two great professors I had at university who were experts in getting their students to learn to learn. They were only able to do it because their techniques were rooted in building trust with their students. I’m not sure I’m there yet with Claude, but maybe this is a start. I just wish Claude would invite me over for a homemade pasta dinner or a hike in the mountains. Maybe someday.

Brian Brown

PS Just to be clear, the subtitle of this post is a joke. Claude is still far from replacing the incredible professors I had at CU. Just imagine Claude trying to fold all of those little tortellini.

References:

Bower, G. H., Clark, M. C., Lesgold, A. M., & Winzenz, D. (1969). Hierarchical retrieval schemes in recall of categorized word lists. Journal of Verbal Learning and Verbal Behavior, 8(3), 323–343.

Brown, J. S., Collins, A., & Duguid, P. (1989). Situated cognition and the culture of learning. Educational Researcher, 18(1), 32–42.

Cepeda, N. J., Pashler, H., Vul, E., Wixted, J. T., & Rohrer, D. (2006). Distributed practice in verbal recall tasks: A review and quantitative synthesis. Psychological Bulletin, 132(3), 354–380.

Chen, C.-H., & Yang, Y.-C. (2019). Revisiting the effects of project-based learning on students’ academic achievement: A meta-analysis investigating moderators. Educational Research Review, 26, 71–81.

Chi, M. T. H., Feltovich, P. J., & Glaser, R. (1981). Categorization and representation of physics problems by experts and novices. Cognitive Science, 5(2), 121–152.

Dunlosky, J., Rawson, K. A., Marsh, E. J., Nathan, M. J., & Willingham, D. T. (2013). Improving students’ learning with effective learning techniques. Psychological Science in the Public Interest, 14(1), 4–58.

Fyfe, E. R., McNeil, N. M., Son, J. Y., & Goldstone, R. L. (2014). Concreteness fading in mathematics and science instruction: A systematic review. Educational Psychology Review, 26(1), 9–25.

Hulleman, C. S., & Harackiewicz, J. M. (2009). Promoting interest and performance in high school science classes. Science, 326(5958), 1410–1412.

Roediger, H. L., & Karpicke, J. D. (2006). Test-enhanced learning: Taking memory tests improves long-term retention. Psychological Science, 17(3), 249–255.

@Last Software

Before I dive into Google I guess I should start with this shirt I received at @Last Software, the makers of SketchUp in December of 2005.

I was the last software engineer to get hired by @Last Software in December of 2005, soon before the company would get acquired by Google. @Last Software made a 3D modeling tool called SketchUp. Though the original audience for the software was architects for early phase design, it was starting to gain momentum in many fields wanting to do early phase rapid prototyping and modeling. When I started working at @Last, I joined a sub-team working on a new 2D page layout companion to SketchUp called LayOut. The team was small, only 4 engineers at the time. I had never developed software professionally as my primary job. I had never written a line of C++. I had never created so many null pointer exceptions in my life. I was off to the races and this shirt turned out to be the first of many.

A quick aside about these t-shirt photos. I took a photo of the fronts and backs of all of these shirts on my bedroom floor by the light of the exterior window. They didn’t look great. It turns out wearing many of these for longer than my kids have been alive has left them a bit worse for wear. So in an effort to spare you the pit stains, I used Gemini to spruce up the photos and return the shirts to their original glory. I hope you don’t mind the AI touch up.

Push Pull

This shirt is actually what prompted me to write this post. Last week I decided to clean out my drawer of T-shirts, but I thought it would be fun to wear each one of the shirts in my drawer before I truly retired them from rotation (I ended up not wearing them all, there were just too many). I received this shirt around January of 2006.

This shirt was designed by the Japanese reseller of SketchUp. They came up with these two little characters called Push and Pull named after the infamous Push/Pull tool in SketchUp. SketchUp had the ability to push and pull faces on 3D models in a way that no other software at the time could achieve. It was a truly innovative feature of the software, contained in one of the original SketchUp patents (US6628279), that was later emulated by many 3D modeling tools.

Doolittle

In March of 2006, Google acquired @Last Software for the purpose of having a path for users to create textured 3D models of buildings in the world and import them into Google Earth. Up until that point, Google Earth only had some rough stacked gray 3D boxes for buildings in the product. To commemorate the occasion, we all received this shirt.

In tiny print, under the text “@Last we can do something about all those gray boxes”, was the word Doolittle. At Google, and I’m sure many companies, there was a codename for every acquisition and divestiture to keep the information from leaking, and the SketchUp acquisition’s codename was Doolittle.

Google SketchUp

In January of 2007, Google launched Google SketchUp (Free) and Google SketchUp Pro 6, which included LayOut version 1. I had been working on LayOut for the previous year since I was hired.

I remember much consternation about the name of the product at this point. Many people from Google, including Marissa Mayer if memory serves correct, wanted to name the free version of the product to something more functionally aligned, like Google 3D Modeler, to go with Google Photos and Google Docs, which were also being created at the time to replace Picasa and Writely. Luckily for SketchUp, the name lived on building a brand that many still associate with Google vs. its current owner Trimble.

There were many other Google SketchUp shirts that I have since lost to the ages, but I always thought this one was fun.

The back of this Google SketchUp shirt was made by mirroring an artificial skyline of 3D Building models people had made to be included in Google Earth. The free version of SketchUp had quickly reached millions of users and at the time was the most widely used 3D modeling software in the world.

Google 3D Warehouse

One of the visions that helped drive the acquisition of SketchUp was the idea of a 3D Warehouse. An online repository of 3D models of all kinds of things from buildings to people, bolts to airplanes, user contributed 3D models of anything you could imagine. Quickly after acquisition, work started on the 3D Warehouse, which was fully built on a Google tech stack in 2006 as a collaboration between a couple engineers in Boulder and a few experienced engineers in Mountain View that were part of the Google Earth team. I was only tangentially involved at the time, but I would later contribute and manage that team. Soon after the launch, we got this shirt.

I loved the tagline on the shirt. All the 3D you need (and plenty of stuff you don’t). The Google 3D Warehouse quickly became the world’s largest repository of 3D models. Users could freely upload and download 3D models of anything you could imagine. The 3D Warehouse lives on today at Trimble with https://3dwarehouse.sketchup.com/ and it is funny to see that many of the test files I uploaded over the years are still available for download.

Google Building Maker

We really wanted to scale up the amount of 3D buildings in Google Earth, and it turned out that one of the most challenging aspects of creating high quality models was getting photos for texturing the building and getting accurate measurements and location information. Google started acquiring aerial photos—including oblique imagery—around 2008 for Google Maps, and with the help of an engineer who had created a photogrammetry tool called Canoma before joining Google, we created an online photogrammetry tool called Google Building Maker.

Though Google Building Maker was released in 2009, I think this shirt was given out at one of the Supermodeler conferences, like the one in Barcelona Spain that was held in 2011. The back of this shirt featured a simplified map of the world, which annoyed map geeks like myself to no end because of the complete omission of the Mediterranean Sea and other water bodies making Europe, Africa and Asia merge into one amorphous blob. Google Building Maker was near and dear to my heart because I think it was the first product and team that I built from the very beginning until launch and ultimately deprecation.

Siggraph

One of the things I really enjoyed doing at Google in the early days was attending conferences. Siggraph is the premier computer graphics conference, and from 2006 to 2011, I think I attended every year. I can remember being in Boston, San Diego, LA, and Vancouver. Google would always give away t-shirts that were highly coveted by attendees, which meant standing in a huge line spanning the conference floor. Luckily, as employees, we got one as well.

I wore these two shirts a LOT over the years.

Geo Eng

For my entire tenure at Google, I was in the Google Maps organization. More specifically, I was in the Geo Engineering organization working on the data side of things.

This shirt was given to all of Geo Engineering in 2009 when Brian McClendon was the Director of Engineering and later our VP. I had a very brief stint, maybe 3 months, that I reported directly to Brian between some reorgs. I wasn’t completely sure on the timeline, so I looked on his Wikipedia page, and sure enough, Brian’s photo is this one:

As the years went by, the flow of t-shirts started to slow a bit, but they were definitely still a big part of the culture.

Google Boulder Office

For my nearly 20 years at Google, I was always in the Google Boulder office. We started as the SketchUp team after the acquisition of about 60 people. All of Google was about 6500 people at the time. Now the Google Boulder office is over 2500 people!

The identity of the office was definitely something special. Nestled in front of the foothills of Colorado with a beautiful view of the Flatirons, as was depicted on our office t-shirt, we definitely prided ourselves on a good work-life balance and a passion for the outdoors. I remember that this was about the time when branding was coming down hard on using the Google logo in an unofficial capacity on internal branded shirts and hearing things like, “the Flatirons were too close, there needs to be white space.” and “You can’t put Boulder next to the ‘g’ like that.” We did it anyway.

Boulder Geo Team

I remember getting this Boulder Geo Team shirt the year after the Great Flood of 2013 in Boulder. The image showed the Google Maps pin, as was typical of many Geo t-shirts. There was the Street View peg man floating in a raft down the Boulder Creek and the Flatirons in the back. The team had grown to maybe 50 or so people then.

SkySmart Team

In about 2014, we created a team that was tasked with finding useful information from aerial and satellite imagery. We were using machine learning techniques and working with a sister team doing the same type of work with Street View imagery called the StreetSmart team. Logically, we would become the SkySmart team. We actually had an old friend of mine design the logo which was supposed to be a top down view of buildings, roads, and some connected poles. It was vaguely in the shape of a brain with a nod to the machine learning work we were doing and the research team we were working with, Google Brain.

I loved this shirt. One, it had a cool logo, and two, maybe more importantly, it was one of the few long sleeved Google shirts I ever had. SkySmart eventually became Geo Machine Perception when it merged with StreetSmart. Later we became Geo Machine Intelligence when we moved beyond just vision signal processing.

Google Ireland

There was this classic Google Maps shirt that had the Google Maps pin, and it simply said “I am here” underneath. The first time I traveled to Ireland was for work in 2018, and was given this shirt from the Google Maps team in Dublin, Ireland.

“Tá mé anseo” is Gaelic and roughly translates to “I am here.” I ended up traveling twice to Dublin for work, and both trips were fantastic. Guinness really is better in Dublin. I surprisingly didn’t get many other Google shirts from my international office travel, but I sure did enjoy my trips. All told, I traveled to over 20 different offices in 7 countries, and I wasn’t one who traveled much for work.

Women@BLD

Women@Google is an employee resource group at Google empowering women in what is historically (and still) a male-dominated field of software. Women@BLD is the Boulder chapter of that group. In 2018, I was invited to a day of content celebrating International Women’s Day, which I attended and got this shirt.

I remember wondering what people would think the first time I wore this shirt to the office, and I almost didn’t wear it. But then I remembered a friend of mine, one of the founders of the Women@BLD chapter, saying something along the lines of, “The first step is to show up.” I put it in my normal rotation soon after that, and it was one small way for me to show up as an ally.

Google Boulder Field Day

The folks in the Boulder office were always coming up with fun events for the office like holiday parties, summer picnics, and recently, the Google Boulder Field Day. This was an office-wide event where everyone was randomly assigned a team color and competed in all kinds of events, from traditional races to paper airplane throwing contests. It was a super fun way to get to know some of my fellow office mates and generally have a great time.

One cool thing they did was keep you on the same team from year to year, adding new people to random teams as they joined each year. I remember participating in 2022, 2023, and 2024. In 2024 our team, Team Blue, won it all and walked away with the coveted Golden Crocs trophy!

There were many other t-shirts over the years, but these were the ones that lived on in my drawer until this week. 20 years of t-shirts, 20 years of memories. It was surprisingly emotional when I stacked all of the shirts up and threw them in the trash (typically I would have donated these, but they were just too worn out).

For my Google friends out there, I would love to hear your t-shirt story, and if you have any corrections on the details, dates and otherwise, I would love to hear them and fix this post.

Brian Brown

PS This is a bit of a non-sequitor from my last few posts on coding with AI. I have taken a bit of a coding break over the summer to spend more time traveling with the family, but will get back to it once the kids are back in school soon, so look forward to some of those posts in the future.

So, how did it go? Great! I’m as happy as I’ve ever been, and that’s not just the fact that I’m returning from a great vacation, but because returning from a great vacation no longer means dragging a jet-lagged brain back to the office. Instead, I can relax, go to the climbing gym this morning with my daughter, watch the World Cup with the family, and take the time to write this post. Of everything that has been great about this last year, having the time to say yes to things, or no, for that matter, has been the greatest gift of retirement. I wrote about that much more extensively in my post about Time Wealth, and it definitely still holds true today.

A former colleague recently told me they accepted a new position at Waymo, and had a few weeks to dive into some personal AI projects. I have been doing the same, and told them to enjoy it, but I also said to prioritize spending time with family before getting back to the grind.

What I realized over this past year is that now I really have no excuses. It is easy when you’re working to say, “I just don’t have time to fit that in”. I don’t have time to go to the gym, hang out with friends, go to my kid’s concert, visit family, or go out on a date night with my wife. Things are so busy, not to mention not having the energy. That is just not the case when you have Time Wealth, but you still have to make it happen. It’s easy to make excuses, but don’t fall into that trap. Make the time to do the important things, you know what they are, whether you are retired or not.

Top Questions People Ask

These are the top questions people ask me when I tell them I am retired, after the initial shocked look on their face and the wheels turning in their head trying to figure out how old I am:

• How is it being retired?

• Do you get bored?/What are you going to do with all of your free time?

• How much does health care cost?

• Congratulations, how did you pull that off?

• Are you retired retired, or are you going to get another job?

All good questions and other than the first one, these were some of the key things I had to answer for myself before retiring.

The Reality Check: How Does It Actually Feel?

How is it being retired? Well, depending on who I’m talking to, I usually say, “Great! It turns out not working every day is fantastic.” I then talk about how having the time to choose what I do every day has been really nice, and the increased level of engagement and presence I am able to experience with others is even better.

The Myth of Boredom: Filling the Void

Do you get bored? No. Not at all. I often say, “The days seem to go by so fast—between climbing three days a week, pickleball on Wednesdays, kids home from school in the afternoon, all of their events in the evenings and weekends, and coffee and hikes with friends. The week fills up.” There is an endless list of possible things to do. I personally have not found it hard to fill the time, or intentionally not fill the time and just make some space.

Just a quick aside about the use of the emdash in the last paragraph. One, I don’t naturally use emdashes in my writing, because my grammar skills are poor and I never use them in my casual tone of writing. Two, people now associate the emdash with AI written text, which I minimize the use of in my writing. But, my editor (aka. my older daughter, aka. “The comma queen”) says I should use them where appropriate, so there you go.

The Elephant in the Spreadsheet: Healthcare Costs

How much does health care cost? For a family of four, the answer is: a lot. We buy a plan from the Colorado Health Exchange, and it is definitely an expense that requires you to account for in your retirement budget. We pay $2,150/month for health, dental, and vision for our family of four. It is a lot, but one thing I have noticed when people ask me this question is that they expect me to say a lot, they don’t expect me to say $2,150/month.

Many people I have talked to say something like “I would retire tomorrow if it weren’t for health care costs,” but when I ask them “how much are your health care costs going to be,” they shrug and say they haven’t actually looked at the details. Look at the details! It is just another line in the spreadsheet and you can figure out exactly how much it is going to be.

The Mechanics: Luck Meets Simplicity

Congratulations, how did you pull that off? A couple of things. First, be fortunate enough to work at Google for the past 20 years when GOOG has averaged an annual return of 20% over that period, and have a large part of my compensation coming to me in Google stock. Second, live a simple life. The second is much more important than the first, but I am not going to deny that the first made things happen earlier than later.

The “R” Word: Am I Really Done Working?

Are you retired retired, or are you going to get another job? I’m retired retired. At least for now ;) As of today, I am not planning on going back to work in the traditional sense, but who knows. I hope to live for another 40-50 years, and a lot could happen in that amount of time. The world of software engineering is completely changing, and I find that fascinating. Getting my hands dirty with Claude Code has been really fun, and working on a real project using these new tools has allowed me to contribute in a meaningful way. I am watching closely how things progress, but I wouldn’t call that working. I have no desire to go back to the day-to-day grind of meetings, performance reviews, and status updates. I have graduated from that world, and I don’t plan to go back.

Bugs in the System: What Needs Fixing

What didn’t go well, or at least what would I like to improve? With all of the good that this last year has brought, there are still things that could be better. I’m still trying to be better about not using my phone so much, especially around my family. I disabled Facebook and Instagram on my phone in an effort to reduce mindless scrolling, but now I find myself scrolling on the Google feed or New York Times instead.

I did some fantastic work setting up some serious automation systems so I can write prompts that ship fixes from my phone! The problem now is that I can now fix code from my phone, anywhere, anytime. The temptation is just as bad as doomscrolling, or playing a video game, but worse because I justify doing it as being productive when I should be paying attention to my kids in the living room or going on a hike.

One goal for this past year was to have more friends over for dinner parties. I didn’t meet that goal, but am going to put more effort into making it happen this year. I still would like to spend more time with my extended family so I need to dedicate more time to that.

The Highlight Reel: Year One Wins

Things that I enjoyed the most over this past year:

• Pickleball on Wednesdays with my wife Stacy. This is a new thing we can do together every week and it is great exercise. Double win!

• Going climbing three days a week with my younger daughter and with many climbing friends. I enjoyed it because it is a great shared time we have together with a common interest. It has been great seeing her confidence grow over this past year, taking on challenges she would not have thought possible a year ago.

• Watching my older daughter perform at many concerts and competitions throughout the year. Between marching band, winter percussion, percussion ensemble, symphonic band, small ensembles, and piano, it has been fantastic to be able to be at almost all of these performances and see how much she has grown musically and as a leader in all of these groups.

• Coffee and hikes with friends. It has been so great to connect with so many folks on a much deeper level. Some are growing new connections, some are rekindling old ones, but all are much more engaging than anything I have had in the past.

• Having the time to go skiing many Fridays this winter with friends. I got 10 days in, which is the most I’ve skied in a season since I was a kid. Even with the worst snow in Colorado ever, it still made for some fantastic Fridays.

Skiing with friends at Arapahoe Basin

• Traveling with family. Having dedicated time together in places away from the distractions of home is so rewarding. Whether it was a 3 week camping trip where we really got to unplug, a backpacking trip with my daughters and my brother, squeezing in a trip to Ecuador over Christmas, or our recent two-week trip to visit family in Austria and Czechia. The time spent with family was so much fun. It is especially rewarding seeing things as if for the first time through your kids’ eyes.

Looking ahead to my next year of retirement, I am going to continue what I have been enjoying and put in more effort on the things that I want to improve. I plan to write a post dedicated to some of the time I have been spending coding over the last few of months with a couple friends on a startup project. It has been really rewarding in different ways than many of my other activities, but deserves its own deeper dive.

Surveying the family, the general sentiment is that things went pretty well over this past year. My younger daughter gave the deeply insightful comment: “It’s nice.” I think she gets her deep level of emotiveness from me. My older one said I should stay retired because it seems like you are getting to do some fun things. I agree.

Brian

Phase 1 (Feb 21–27): The Guardrail Era – Teaching the Bot to Behave

After the initial migration on day one, it was time to start making changes, adding some basics like testing, break down some of the monolith, and start learning the basics of how to use Claude code. I quickly set up Cloudflare Pages to host the application which has super nice GitHub integration, so every push to main would trigger a prod build and automatically push live. I had never used Cloudflare Pages before, but I asked Gemini what I should use for a free host that I could add simple user authentication to and it happily gave me a step by step setup guide.

One of the things I quickly realized is that Claude was going to need some guard rails on how to operate in this project. I learned with a quick back and forth to Claude that the way you do this is by adding a CLAUDE.md file to describe things like the the overall project goal, the tech stack for the project, development commands like how to build, the repo layout, style guidelines, and maybe most importantly: what NOT to do. I remember looking at some CLAUDE.md example files on the web and thinking it was going to be a daunting task, but then I remembered I was working with the most powerful coding AI ever and just asked Claude to write a high quality CLAUDE.md file based on the current repo. It did a great initial job, and with a couple of follow up prompts, I had checked in my first CLAUDE.md. I would later see this file grow and evolve over the coming days and weeks, finally shrinking it down to just the essentials as I factored out what didn’t need to be there.

Very quickly, after having Claude do a couple of commits without tests, I let it know that tests were required. It updated the CLAUDE.md with the Vitest and my test first expectations and from then on, tests were written, run, and made green with every commit.

After that minimal initial setup, I was off to the races, prompting Claude to fix bugs, add features, perform refactors, all without actually writing a single line of code. The prompts were coming fast and furious.

That first week, I spent a lot of time watching Claude work. It was interesting to see what it was doing, what it was “thinking”, and how it solved problems. With the default permissions settings, Claude asks you every time it executes a command other than an approved tool (like Read, Grep, or Glob) so you end up clicking 1. to approve commands as they run. After a while of being interrupted every few seconds, you move to autoaccept edits, which approves edits to your files in the repo, but you still have to approve shell commands. You can add patterns to an accept and deny list so things are autoapproved. This works okay, but there are all kinds of complicated compound commands that will not get approved and require constant attention (more on fixing that later).

The other big thing I learned this first week was plan plan plan. The better you are at describing what you want from Claude before it starts writing code, the better it will do. This is completely true in software engineering in general. The temptation for all software engineers is to jump in and start coding. Even for reasonably small things you should have Claude write a plan, because it is so easy to do. The result is a mini-design (or big design) with the step-by-step tasks to turn it into reality. You can either say, “Write me a plan to …” or switch to Plan mode. Even if you don’t read the plan, the result is better code.

That first week, I saw a ton of changes in the repo. I went from the initial port to having a progressive web app that works well on mobile and desktop, added Light/Dark theme support, improved data visualizations and 3D navigation controls, created a YouTube review crawler and linker, refactored and rearchitected the whole application twice, created a weekly GitHub report generator, and added sharable URL support. Lots of progress big and small. In that first week, I had 79 commits in about 5 days of work committed directly to my main branch.

Phase 2 (Feb 28): The Great Inflection – Shipping Code from My Phone

At this point, I got a little tired of babysitting Claude for everything, and it had only been a week. I thought, wouldn’t it be cool if I could just describe a feature or bug in a GitHub issue and have Claude go fix it? I started by doing things manually. File an issue. Tell Claude to fix the issue. Commit the fix. This basically just moved my prompt from the command line to the issue. This was actually an improvement in reproducibility and understanding, because I could go back and see why something was changed, and so could Claude. But in the end, it was still a bit manual.

Coming from the internal tool-chains of Google, I would have reached for Borgcron at this point, but in the real world, GitHub Actions are the logical choice. I asked Claude, “Can you set up a GitHub Action that will trigger on bugs labeled bug and autofix, spin up a container and have Claude fix the bug and create a pull request for me to review?” It created this:

name: Claude Code Bug Solver

on:
  issues:
    types: [labeled]

jobs:
  solve-bug:
    # Trigger ONLY if the issue currently has BOTH the ‘bug’ and ‘autofix’ labels
    if: >
      contains(github.event.issue.labels.*.name, ‘bug’) &&
      contains(github.event.issue.labels.*.name, ‘autofix’)
    runs-on: ubuntu-latest

    permissions:
      contents: write
      pull-requests: write
      issues: read

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
          token: ${{ secrets.GITHUB_TOKEN }}

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: ‘24’

      - name: Install dependencies
        run: npm ci

      - name: Install Claude Code
        run: npm install -g @anthropic-ai/claude-code

      - name: Configure Git identity
        run: |
          git config --global user.name “github-actions[bot]”
          git config --global user.email “github-actions[bot]@users.noreply.github.com”

      - name: Fix bug with Claude Code
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          claude --dangerously-skip-permissions \
            “Fix bug #${{ github.event.issue.number }}. Follow the ‘Fix Bug Workflow’ in CLAUDE.md exactly.”

It worked. At this point I could file an issue. Mark it with labels ‘bug’ and ‘autofix’. This action would trigger, opening a fresh container on the cloud, run Claude with the fix bug prompt, fix the bug, and create a pull request that I could then review.

🤯

I later tweaked this to be able to choose which model (Opus, Sonnet, Haiku), deal with duplicate runs by using concurrency groups, and automatically request a review. Soon, after setting up this autofix bug loop, I tested out filing a bug, marking to be autofixed by Claude, watched the Github Action spin up a clean container, ran Claude Code to fix the bug, and a pull request was created and sent to me for review. I looked at the diff on my phone, opened the running dev build to verify the fix, clicked approve, merged the pull request, deleted the fix branch. In 1 minute and 58 seconds I was looking at the completed fix already pushed to prod, ALL FROM MY PHONE 📱🤯 !!!

One thing you might notice is that with this loop you are back to using your ANTHROPIC_API_KEY, which as I said in my last post, is much more expensive per token than your pro or max subscription. This is true, but one thing I noticed is that the cost of fixing bugs or adding features through the issue loop is much more efficient. I think this is because every run starts from a clean slate empty context and reads just what it needs to get things done. With fewer tokens being sent back and forth to/from the API it is much more efficient. That being said, you can actually have the best of both worlds.

Pro-Tip

Anthropic has an official GitHub Claude Code Action https://github.com/anthropics/claude-code-action that has the ability to set up these types of automation loops out of the box AND they allow you to use a long live OAuth token that is associated with your subscription login. I highly recommend this! The nitty gritty details on the setup are here: https://github.com/anthropics/claude-code-action/blob/main/docs/setup.md but look out for CLAUDE_CODE_OAUTH_TOKEN and using claude setup-token to create your long lived (1 year) OAuth token. The other nice thing about the official Claude Code Action is that it has all the patterns described for handling triggering on issue assignment (vs. label assignment), or @claude mentions if you want to use different triggering patterns. And in the end, just tell Claude to use the Claude Code Action with a link to the repo and it will read the docs for you and do the right thing.

With the addition of the automated AI fix bug loop, I started using it to fix bugs and create new features. With that, I moved away from direct commits on main to everything being developed on a feature branch, creating pull requests, and merging those back into main once reviewed. This is, of course, a well-defined development pattern, but it is easy to ignore it when you are in solo dev mode. Everything is so much more visible using feature/bug fix branches and much more stable.

Phase 3 (Mar 1–7): Decomposing the Brain – The Power of Agent Skills

As I became more familiar with how Claude was working in the codebase, I realized I could get it to focus on the right things if I started removing some cruft that had built up over time in the CLAUDE.md. If you try to shove everything you want Claude to know in the CLAUDE.md file, it has to reason about what is the most important thing to prioritize and what applies with each interaction. A pattern that has emerged that has proven to work well with most AI agents is called “progressive disclosure”. It’s like instead of loading all of the entire 500-page car manual into memory all of the time, just having the 10-page index and being able to look up the section on how to change a tire when you have a flat.

Enter Agent Skills! Agent Skills are a structured standardized way to perform progressive disclosure with AI agents. They work especially well for a procedural (step 1, step 2, step 3, etc.) process that may or may not involve code/tool execution. For me, the best candidates were my bug fix process and my feature creation process. The basic idea of a skill is that there is a short skill manifest (Level 1) that describes to the agent when the skill should be invoked and then a more detailed section (Level 2) with all of the steps of how to execute the skill. There is even a third level that optionally can include more details that get loaded as needed. All of the information in Level 1 gets loaded into the agent context all of the time, so this should be lightweight, but gives the agent the clues it needs to know when to invoke the skill. If it decides to load the skill, it loads up Level 2 and possibly Level 3 as needed.

Once I understood how Skills worked, I extracted my bug fix process, create feature process, and my create lesson process into skills. This shrunk my CLAUDE.md from 350 lines to 170 lines, streamlining the context for every interaction with Claude. Skills also have the nice ability to be called explicitly so I can say, “/fix-bug #123” to Claude and will start fixing it immediately.

The Lessons: The Teach-Lesson Skill – Retaining My Human Edge

I noticed after working with Claude for a week that I felt like I wasn’t really learning anything about the codebase itself. Sure, I was learning a lot about how to use Claude, how to use GitHub Actions, setting up Cloudflare, and using Codespaces. I was learning a lot, but if someone asked me “how does your application actually work?”, I feel like I only vaguely understand some of the low-level details. In some ways this is fine, but in others, I felt like I was losing some of the joy I get from understanding how things work. After discussing this over coffee with a friend of mine, I was inspired to write something into my CLAUDE.md that would help build up my mental wealth and keep me from feeling like just a button pusher.

The teach-lesson skill has a description:

Extract a key insight from a completed task and write a short teaching lesson. Use after finishing a non-trivial bug fix, feature, refactor, or investigation.

What this skill does is writes a mini lesson about some key insight it had when making a change. The lesson consists of a title, description of why it matters, the concept, an example for the codebase or a reference, and then a one-liner key takeaway. The skill writes these into the repo’s docs/lessons/… as <lesson-category>/<lesson-topic>/<lesson-name>-<short-hash>.md. By telling it to use a lesson category and topic, it has started to form a lightweight taxonomy of lessons for the codebase that I can go back to and learn about how some of the less clear or more nuanced things work in the codebase. I have found it a fun way to stay engaged. I also have a periodic job that creates a nice high-level index page that pulls all the one-liners together under the taxonomy for easy browsing.

Even with the increased process, lessons, testing, etc. I was able to achieve a peak throughput day that week of 45 commits across 11 PRs, including a complete migration to the UI framework shadcn/ui.

The Financial Reality: Economics of the Agent

I wanted to take a look at what it would cost to sustain this type of development going forward, so I looked at a pretty detailed breakdown of where I was spending money and how it could be optimized.

The first thing I looked at was my GitHub Codespaces usage. I spent about 65 hours over this 17-day period running a 2-core machine.

In terms of cost this ended up being free, but only because this period happened to space a month’s boundary. A free GitHub account gives you 120 core-hrs of compute a month or 60 hours on a 2-core machine. If you bump that up to a GitHub pro account for $4/month you get 180 core-hrs of compute a month or 90 hours on a 2-core machine.

As you can see, the GitHub costs for me during this time were dominated by the Codespaces Compute costs. These costs are relatively minimal and completely avoidable if you are doing local development.

Likely the more interesting costs to look at are those for using Claude Code itself. As I said in my last post, the most economical choice is to buy a subscription based on your usage vs. using an API key. You can see below my API key cost per/day and then the steep decrease once I transitioned to the subscription cost. Of course, it is a tradeoff of pay as you go vs. a flat subscription fee, so there is that use-it-or-lose-it pressure, but the cost difference is something like 36x per token.

Once all was said and done, extrapolating those first 17 days out to a monthly cost of $133.50/month. The extrapolated costs look like this:

I think once things settle in, my costs will look more like the high throughput setup below. Note that this is still mostly a single agent at a time or possibly 2-3 agents going in parallel some of the time. I think it is completely possible to get up and running on a $20/month Claude Pro subscription. If you go that path, you are likely to hit token limits if you have sessions that last more than 1-2 hours. If you are coding ~2hr/day for 30 days you will stay right at the 120-hr core hour limit for the month on Github free.

Reflections: What Worked and What Didn’t

I was very impressed with what I could produce in a couple of weeks all while on a steep learning curve of how to get the most out of this new development setup. In the end, after 17 days, I had made 282 commits, fixed 48 issues, netted 32K lines of code, 8K lines of docs, and 34K lines of config.

There was a very tight correlation between commits and tokens and a much looser correlation between lines and tokens. I think over time I have become much more efficient using Claude to get things done by getting the minimal set in Claude’s context to get the work done. There is still a ton to learn here to make this more efficient.

Interesting Patterns to Highlight

1. Velocity didn’t drop when process was added. Feb 23–24 averaged ~22 commits/day direct to main. Mar 2 had 26 commits via PRs. Mar 5–6 had 28 and 45 commits respectively. Structure enabled more throughput, not less.

2. The “teaching” loop. Writing lessons after learning something (7 lesson commits in the period) kept me more engaged and via CLAUDE.md updates improved Claude Code’s future suggestions. A human-AI knowledge flywheel.

3. Progressive automation. Manual fixes → autofix bot → autonomous bot PRs → batch issue filing from eval. Each layer reduced human effort for the next layer.

4. The 3D zoom feature. Claude tried 3 times to fix the zoom-to-cursor feature. I manually fixed it the next day in one commit. Some things are still tricky for AI (geometry/interaction code).

5. Claude is superhuman. 45 commits across 11 PRs in a single day: full shadcn/ui migration, eval harness, custom scripts for annotator features. Only possible because the PR-per-phase pattern lets me review/merge in rapid succession.

6. Issue usage evolution: Early issues were micro-bugs (favicon, shadows). By Mar 6, issues became structured eval findings (7 crawler bugs batch-filed from precision/recall data). Issues evolved from “things I notice” to “things the system detected.” Claude is really good at writing detailed issues. This is a great hand-off mechanism between Claude with a full context to a fresh Claude with a clean slate.

7. Three commit author personas emerged: Brian (architecture, features, integration), github-actions[bot] (data sync, autofix), claude[bot] (autonomous bug fixes). The codebase became a multi-agent project. It was actually all Claude, just different commit patterns.

Conclusion - The stats are impressive but the learning was even greater.

I had a blast those first few weeks. If anything, it was sucking me in too much. I definitely have to balance the excitement of time spent developing and my other activities. I noticed that, even though this didn’t displace other activities like climbing, skiing, pickleball, and coffee with friends. It did start filling up all other available time.

Observing where I had arrived in my AI-assisted coding journey at this point, I would say I was Stage 5 (CLI, single agent. YOLO. Diffs scroll by. You may or may not look at them.) on the stages of AI-Assisted Coding from Steve Yegge. Stage 5 is using a single agent and basically accepting everything it creates without intervention. I started in those first few weeks to push into Stage 6 (CLI, multi-agent, YOLO. You regularly use 3 to 5 parallel instances. You are very fast.), but if you don’t have a large enough project, you start to step on your own toes, or more appropriately: the agents start stepping on each others’ toes. I think stage 7 makes your brain melt. It is interesting to see these stages, because you really don’t want to live in a couple of these stages, as they probably lead to madness.

Next time, I will talk about how I set up my new Macbook Pro for local development and how that required a change to leverage containers locally. In many ways getting the local setup working smoothly was more difficult than the cloud setup. For now I hope folks are having as much fun leveraging these new tools as I am.

Brian Brown

I posed these questions at the end of my last post:

1. Should I use a fully integrated AI coding IDE like Cursor, Windsurf, Github Copilot, Firebase Studio or Antigravity?

2. Should I go to a full agent based workflow like Claude Code, Codex CLI, or Gemini CLI?

3. Should I go fully cloud native in the browser and keep using my 5-year-old Pixelbook or get a brand new Macbook Pro M5 Max in a couple weeks and run all my compilation locally for maximum efficiency and power?

My decisions given a lot of feedback and my own research were:

1. Skip

2. Claude Code

3. Macbook Pro M5 Pro (just released last week)

Skip the IDE, Hire the Agent

AI-assisted IDEs seem great and all, but if I’m reading the tea leaves they are just a stop gap to get us from traditional IDE-based software development to AI agent-based software development so why waste my time. I already know AI-assisted IDEs work well. I used them at Google. I’m sure they have gotten quite a bit better, but hey, time to move on.

Claude Code seemed to be the obvious winner in terms of what people are using most successfully (at least 2 weeks ago), what you all have told me, and what the leaderboards (at least for coding models) are indicating. Of course Claude models (primarily Opus 4.6 and Sonnet 4.6) are not the same thing as Claude Code, which is an agentic, terminal-based AI coding assistant that uses Claude models to do its work, but we will get into the details of that later.

Codespaces - A 5-Year-Old Chromebook’s Best Friend

Macbook Pro M5 Pro was not a requirement to get this all going, in fact everything in this post was actually done using GitHub Codespaces, which is a hosted development environment in the cloud. The Macbook Pro is for future work and it is still in the mail, so I will have to talk about that in a future post when I start playing with that new hardware, but I’d be lying if I said I wasn’t tracking the FedEx truck with my new M5 Pro.

So I thought I would go through my setup process a bit for those interested to let folks know how easy this is all to set up and talk about what I learned along the way. For those that never see software development as being in their future, I would just say that this stuff is so easy to set up and there are many many non-coding applications that it might still be worth a skim.

Also, for motivation from last time, I was trying to get past the following limitations I ran in to with Gemini Canvas:

1. Challenge to pass relevant context to your prompt in a consistent and easy way.

2. No real version control system for code or test framework.

3. Code generation recreates the entire app most of the time making things slow.

In the end I found that #1 is actually the new challenge of AI-assisted software development. These models are amazing and they will do what you tell them to do, but you have to tell them exactly what to do, and this is the context challenge. There are some very cool ways to do this right (we’ll talk about Agent Skills in a future post) and Claude Code definitely makes this much much easier.

To address #2, there isn’t really much new here other than to use a source control system, and the obvious choice for most people is GitHub. You can do some super powerful things once you have a repository in GitHub. Not sure how to set one up? Just ask your favorite LLM (ChatGPT, Claude, Gemini, etc.) how to do it and it will give you step-by-step instructions (there are two by the way). Create a GitHub account and click the green “New Repo” button. But really, use an LLM. Here is the actual prompt I used:

Ok, so I want to set up a new GitHub repo for the pickleball visualizer code that I have developed in Gemini Canvas. Give me the step by step details to accomplish this from the GitHub web UI. Tell me what I should name everything. Any specific settings I should use as I eventually want to set up GitHub Codespaces and Claude Code in the dev environment. Let me know what directory structures I should use etc. pull all that together into a detailed plan I can step through in order.

Honestly, the hardest thing with the previous step will be: what do I name my repo? Make it short, memorable, unique, descriptive, general enough, but be specific. Also, you never want to rename a repo, so good luck (j/k) . You can rename a repo, you just never really want to. This will get your repo up and running and probably start you down the path of configuring how Claude is set up with a CLAUDE.md file. Don’t worry too much about this yet, Claude can help you create your first CLAUDE.md so maybe wait a second. A CLAUDE.md file gets put into the context whenever you run commands with Claude Code.

Measure Twice: Prompt Once

To address #3, we need a process for incremental code development. This is fundamental to software development in general. You need to be able to make incremental progress and keep improving on what you had before. This is accomplished with a source control system, which you now have, and a basic strategy for committing code to your repository without breaking what you already have. This is true whether or not you are using AI, but with AI you need to have reliable ways the model can verify that it hasn’t broken anything and that progress is being made in the right direction. This is mostly done by having a robust test suite. Luckily, AI is really good at writing tests, so you just need to ask and then tell it to build and test everything before it tries to commit any new code.

There are a whole series of best practices that are rapidly evolving on how to get the most out of your AI assistant, but if you decide to use Claude Code read https://code.claude.com/docs/en/best-practices. I learned some of these along the way, but they are neatly in one document here so that’s worth checking out.

OK, this is where Claude Code comes in and where the real fun begins. I’m going to stop describing in detail at this point how everything works in my specific setup, because your setup is probably different. I went down the path of using GitHub Codespaces which is a great way to get up and running quickly. It works from anywhere with an internet connection. It works on my five-year-old Chromebook, because all you need is a browser. It doesn’t matter what OS you are running. Codespaces spins up a virtual machine in the cloud for you running a package with all the dependencies you need for your repo and VSCode installed for your IDE.

Again, I just asked Gemini how to get this stuff all up and running, and it gave me step-by-step instructions. One recommendation is to not just follow them blindly, because sometimes it would recommend slightly dated ways of doing things and lead you down a bit of a windy path when there might be a newer more straightforward way of doing things. Or go old school and read the Claude Code docs on how to get up and running.

API Credits vs. Subscriptions: A $100 Learning Curve

So this is when I take a quick detour to talk about billing. Claude Code is not free. You have to pay for it and there are two main ways to do that. One is by buying API credits and the other is by buying a Claude subscription plan. I made the mistake of buying $100 worth of API credits to get started and later realizing that the Max 5x subscription plan made the most sense for my usage patterns. It wasn’t until last night that I figured out how to configure GitHub actions (automated triggers) to use your Claude subscription to run Claude Code in fully-automated headless mode. This is a bit of a game changer because it turns out the subscription can be up to 36x cheaper per token than using API credits.

My recommendation to you if you just want to try this out for the first time is to spend $20/month for the Pro subscription plan and you can bump it up if you start hitting token limits, which you will if you are using Claude Code in earnest (a couple hour coding session with Opus). If you are using this for real development workloads then get the Max 5x subscription for $100/month. If you are trying to build your Gas Town rig where you have agents running agents who need agents to keep them on task then get the Max 20x subscription for $200/month.

OK, so at this point I have a code repo that’s more or less empty except for some boilerplate files and my one Gemini Canvas file I was trying to migrate. I have Claude Code installed in my GitHub codespace. I have my API keys all set up (I was using API credits at this point). Because I’m using Codespaces I had to set API keys as secrets in the Codespaces secrets settings in GitHub (again just ask your LLM of choice for the steps). My first prompt should have been something nice and small, but I decided I would just go for it so this is what I did:

The YOLO Prompt: Do all the things!

Here is the very first prompt I gave to claude:

I am migrating a prototype from a single file into a Vite TypeScript architecture.

Please read the `canvas-raw.html` file and break it apart into our project structure:

1. Extract any hardcoded CSV strings like DEMO_CSV about the paddles and save them into `data/paddle_specs.csv` in the appropriate format. Make sure it gets loaded appropriately.

2. Extract the styling and overwrite `src/style.css`.

3. Extract the HTML UI skeleton and overwrite `index.html` (ensure the Vite `<script type=”module” src=/__u/bbrowncolorado.substack.com/&#8221;/src/main.ts&#8221;%3E%3C/script%3E%60 tag exists correctly or remains intact).

4. Extract the core logic, convert it to strict TypeScript, and save it to `src/paddle-viz.ts`. Please generate proper TypeScript `Interfaces` for the paddle data (e.g., swing weight, twist weight, core thickness, etc.).

5. Update `src/main.ts` to import the logic from `paddle-viz.ts` and initialize the application.

6. Once you are done, delete `canvas-raw.html`.

Please check for any TypeScript errors and fix them before finishing.

I would later learn that this was actually pretty ambitious and that I should have been running in plan mode to have Claude create a plan, save that, then execute the steps in the plan in small chunks. But heck, I was so excited, so YOLO!!!

It started cranking… and cranking… it was reading the existing code, building a plan, figuring out what all of the technologies were shoved in canvas-raw.html (which should have actually been named canvas-raw.tsx), learning about typescript, tailwind css, react, recharts, reading docs, searching for examples, writing files, loading dependencies, writing tests, setting up build aliases and tests aliases, and on and on and on. This is where coding agents differ greatly from a stand-alone LLM that you ask to write code. The agent can run tools, spawn other background agents, probe your server, and write incredibly complex inline Python scripts that it shoves in a shell command and actually gets all of the command line escaping correct.

Note that this is not a totally hands-off experience. By default Claude will start asking you, “Can I run this tool?”, “Can I run that command?”, “How about this one?”, and so on. You will find yourself hitting “1. Yes” over and over and over. You can hit 2. to allow it to always have permissions to run the command, but with so many slight variations this doesn’t always solve things. These permissions get written to a file and are an allow list and deny list of commands that do or do not need your approval. In the end I felt like this:

Hitting the Token Ceiling

At some point I started getting concerned when I saw warnings from Claude:

Claude’s response exceeded the 32000 output token maximum.

LLMs have a context window that is a certain length and it is measured in tokens. You can think of these as words, or a little shorter than a word. Opus and Sonnet models in the 4.5-4.6 timeframe have a standard input context window of 200,000 tokens and an output window of 64,000 tokens. For cost, latency, and maybe performance reasons Claude Code sets the limit to 32,000 tokens for output even though the underlying models can do more. You can change this limit up to the underlying model max of 64,000 like this:

export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000

I did this, but now am much more efficient with the way I work with Claude Code, so I’m not sure if it was entirely necessary. Like I said before, managing what is in the context window of the model is basically all you care about and getting really good at getting the right things in and the wrong things out is what it means to be a great AI assisted developer.

The Result: Broken Styles and Automated Miracles

Finally after I saw the final output ✻ Crunched for 47m 42s, and I hopped over to https://platform.claude.com/ to see how many API credits I had burned through, $6.04. I looked at all of the files in my local copy of the repo and saw that there was a server running with a port forwarded so I could just click on the link to open it in my browser. I was thinking to myself, surely this didn’t work. Surely the app will be broken or it will have some weird UI problems or something. So I clicked the link with much anticipation and there it was. BROKEN!!! Well, the page loaded, but it looked like all the CSS had not loaded correctly so all the formatting was completely broken. I sighed.

OK, let’s see if it can fix itself. I gave it my second prompt:

Check why the tailwind css isn’t working.

This is a terrible prompt. I didn’t really tell it what to do. I didn’t tell it what I was observing and what I expected. I could have done better, but Claude didn’t really seem to care. It started doing some wild things. It probed the running server, somehow figured out that the CSS wasn’t loading properly, wrote some crazy custom shell scripts to search through a bunch of the build artifacts and logs looking for missing CSS names, looking at the code, comparing that to the live CSS, looking in the logs again, back and forth and back and forth. It would try one thing and that would fail, then another, and another. It wasn’t working, but it did not seem deterred. About 30 minutes later it just finished. It said it fixed it, that some of the CSS wasn’t getting generated correctly with the tailwind tool.

I didn’t really believe that it was going to work at this point, but I clicked the live server and there it was. It worked. It worked perfectly and looked identical to what was in my original prototype. All the UX worked, the colors were identical, style exactly the same, all the data loaded, everything just worked. Now on the backend I had a code repo with ~15 files and all the underpinnings of a real react app. I was off to the races.

Here is Claude Code’s initial session summary after performing the first few prompts that included the initial migration.

Total cost: $15.87

Total duration (API): 1h 18m 39s

Total duration (wall): 2h 34m 12s

Total code changes: 1930 lines added, 124 lines removed

Usage by model:

claude-haiku-4-5: 71.4k input, 5.2k output, 269.5k cache read, 112.2k cache write ($0.2647)

claude-sonnet-4-6: 695 input, 223.7k output, 7.0m cache read, 1.0m cache write ($15.60)

I would later learn I should have been using Opus for something like this, but I had no idea what I was doing at the time. I also should have been using branches and pull requests instead of having Claude just committing and pushing to main, but that all didn’t really matter to start. I had my first port. It had only taken about 3 hours to go from having just a single file prototype to a code repo in GitHub, a running development environment on Codespaces, and a ported application that was running on a dev server. I was off to the races.

Lessons Learned: From Sandbox to CLI

Here is a quick summary of what I learned on day one:

The Sandbox vs. The Agent: Lessons Learned

• Primary Vibe

  • Gemini Canvas: “Make me a toy.”

  • Claude Code: “Build me a system.”

• Development Flow

  • Gemini Canvas: Vibe Coding—High-speed, low-rigor prompting in a chat window.

  • Claude Code: Agentic Coding—A “Plan → Execute → Verify” loop with a terminal-based partner.

• Context Management

  • Gemini Canvas: Limited. You often have to re-paste instructions or hope the model remembers previous turns.

  • Claude Code: High. It consumes the entire repository and uses a CLAUDE.md file for project-specific rules and “skills.”

• Scalability

  • Gemini Canvas: The Wall—Things get slow and “forgetful” once your app grows past a few hundred lines.

  • Claude Code: Professional—Handles 2,000+ line migrations and complex, multi-file architectures with ease.

• Troubleshooting

  • Gemini Canvas: You describe the bug; the LLM tries to guess a fix based on the code it sees.

  • Claude Code: The agent actually probes the running server, runs shell scripts, and reads local logs to find the root cause itself.

• Source Control

  • Gemini Canvas: “Copy-paste and email a link.”

  • Claude Code: Full GitHub integration with branches, commits, and PRs.

• Cost

  • Gemini Canvas: Free (usually included in your standard Gemini Pro subscription).

  • Claude Code: Variable. It can be $15 for a “YOLO” migration using API credits, or pennies if you’re on a Max subscription plan.

I am now three-ish weeks into using Claude Code so this post is a bit behind, but I am really blown away. I have been having an absolute blast trying out these tools and getting all kinds of automated workflows up and running. I was going to make this post all about the first two-three weeks, but I think it is just too much for one post. I’ll save that next set of insights including a detailed breakdown of usage and costs for the next one.

Brian Brown

PS Next post, I’ll go into some more detail on typical usage and costs for me as a retired guy doing some coding on the side.

I just had one simple question, “What pickleball paddle should I buy?” How hard could that be to answer? It turns out to be much more complicated than I thought.

OK. It has been 9 months since I left Google and it is time for me to get out from under the rock I have been living under and see what the hell has been going on with the AI coding revolution. I’m kind of surprised it has taken me this long, but trying to answer my pickleball question I got nerd sniped into writing a data visualizer for pickleball data, and that led me down this rabbit hole. Before I begin, if you are interested in pickleball you should check out Johnkew Pickleball on YouTube. He has fantastic pickleball paddle reviews all backed with real data from his basement pickleball paddle testing lab.

As you might imagine, I have many friends who are still actively developing software either at Google or newly free from the Google toolchains, so it’s not like I am completely unaware, but until you experience these things firsthand—it just isn’t quite the same. It turns out a lot of things have changed in the past year and continue to rapidly develop, but from what I have read and heard from friends, we have passed a tipping point where we have moved from the majority of developers not having embraced using AI assistive tools to the majority of developers using AI tools day to day. With that in mind I wanted to document my journey through taking a simple project from vibe coding in Gemini Canvas to a more professional AI driven development workflow modeled after some newly evolving industry standard practices I have learned from friends and colleagues.

At first I thought I would document the journey and then write a post about the full journey, but that would probably be way too much stuff to pack into one post. So instead, I am going to post as I go along and maybe your feedback will shape the direction I take on this path.

The Mini Primer: How the AI Overlords Build Apps

For my non-technical friends, here is a mini primer on AI code generation. AI code generation tools use Large Language Models (LLMs) to generate code based on an English language (actually any natural language) prompt. LLMs have been trained by “reading” all of the code in the world to find patterns and predict the next word (or code) to output based on your prompt input. There are of course much more sophisticated explanations of how it all works, but in the end the model has learned a bunch of stuff by reading things on the internet, you provide it some context through a prompt and uploaded files, and it outputs a response in this case code you can run.

Five-Minute Magic: The “Wow” Factor of Gemini Canvas

Let’s start simple.

Gemini Canvas.

1. Go to the site https://gemini.google.com/

2. Click on Canvas under Tools.

3. Prompt Gemini to make an application that does whatever you want.

I think step 3 might actually be where many people get stuck. What do I actually want? This is where the real work is done. I just read an interesting Vibe Coding post from Cassie Kozyrkov who was a statistician for a long time at Google. Her post dives deeper into “How to Know What You Want.” This is where a lot of the real work is done, diving deep into ideas and coming up with compelling solutions. It turns out there is no magic bullet here, but it is where you can let your creativity and imagination take over.

Great, so then you did 1, 2, 3 and you’ve got yourself an app that does the thing you asked your AI overlords to build for you.

My initial reaction to this was, WOW!!! Gemini had just created an interactive web application in Javascript using the React framework and it looked pretty good for the first go. There were some minor UI bugs like overlapping labels, but for the most part things just worked. The CSV upload mechanism and parser worked, the selection UI updated all the data fields, the custom SVG renderer of the paddle updated based on different paddle characteristics. I was impressed, and most of all, I spent about five minutes crafting the initial prompt describing what I wanted. The model probably took about 5 minutes to churn on the code and output this result.

My initial prompt looked something like this:

(I uploaded a sample CSV file with all of the column names set and some sample data with the initial prompt.)

I didn’t really know it at the time, but this is when I started down the vibe coding rabbit hole.

I had an initial prototype in minutes. Enough to hook me in to wanting to go a bit deeper. It was fun. It was exciting. It was 9:30 pm and I was about to stay up late (for me).

Lost in Translation: The Language of Bugs

So I had some bugs I wanted to fix. Overlapping labels in the UI. I tried things like, “Fix the label for the paddle height so it doesn’t overlap with the dimension line” That worked. Later I would just say things like, “Fix all of the labels in paddle UI so they maximize visibility and minimize overlap.” That would mostly work as well though sometimes you would get some weird results. Sometimes I wouldn’t really know what words to use to describe the thing I wanted fixed so I would flip over to the code tab, find the UI element I wanted fixed and use the name the LLM had given it. This worked, but felt like it was breaking my flow. Thus began my learning process of describing what I wanted with enough specificity, but balancing that with making more general statements so I didn’t have to prompt every tiny incremental change.

I have learned from my “pro” friends that you get past this by feeding guidelines to your LLM either by writing a UI style guideline in this case or referencing one that is already written. This is a pain to do in Gemini Canvas, because if you add this to your prompt at the beginning it works for a while, but then forgets. Alternatively you can prompt it every time, but this is tedious.

Gemini Canvas Limitation - Passing relevant context to your prompt in a consistent and easy way.

The Churn: One Step Forward, Two Steps Back

Sometimes when prompting to fix a bug or add a feature, things just break. You then have to prompt to fix the thing that broke. I found that sometimes a fix I had prompted to fix a couple of turns (back and forth with the LLM) ago just disappears in the latest version. This can be super frustrating because you often don’t notice until the change has gone by for a while then you are not quite sure what or when it broke. In traditional software development this problem is mitigated by using a version control system for your code and by having a testing framework to make sure things don’t break unexpectedly.

You can kind of mitigate this in Gemini Canvas by clicking the “share” link which generates a snapshot of the code that is shareable with others. Unfortunately this loses all of the back and forth with the model and just copies the code. I did this as a pseudo version control system, emailing myself a link (I could have used a doc) with a change description like, “Ridge regularization for inverse stability”.

To get around the lack of testing framework, it is possible to have tests embedded into the application that get run and throw errors during compilation. If they throw errors during compilation, they can be recognized by the model and fixed without prompting, otherwise you have to run the tests from the UI in the application and manually feed back (copy and paste) errors to a prompt to get fixed. This works but is pretty tedious.

Gemini Canvas Limitation - No real version control system for the code or testing framework.

The Token Crawl: When Magic Gets Slow

When you start out with your initial prompt everything seems great. You put in a short prompt and the LLM outputs a few hundred lines of code. It takes a few minutes, but you just went from nothing to something and it feels like magic. Then you just want to make a tiny fix. Change the color from blue to red. Move this button. Change this text. It seems small, but depending on what’s happening in the model things can get really slow and as your application gets bigger and bigger things get slower and slower. This is because for the most part the model is outputting the entire application every time you go back and forth with a prompt. In my experience with this project, sometimes there is some optimization and large chunks of the app that are unchanged are output very quickly, but other times things stream out line by line, token by token and it can get really slow, 5, 10, 15 minutes slow for seemingly small changes.

There isn’t much of a mitigation for this in Gemini Canvas other than to keep your application small and focused. You can prompt the model to simplify the code or modularize the code which may help a bit, but as your application gets bigger things just keep getting slower.

Gemini Canvas Limitation - Code generation recreates the entire app most of the time making things slow.

There are of course similar offerings from OpenAI, Anthropic, and Microsoft in this space and surely many others. Anthropic was first in this space with Claude Artifacts in June 2024 with wide availability in August 2024. OpenAI followed with ChatGPT Canvas in October 2024. Microsoft has Github CoPilot Workspace which is a bit more advanced and integrated with a full-fledged development workflow introduced in April 2024, but isn’t quite the same and uses OpenAI and Anthropic models under the hood anyway.

I’m not sure if these other offerings have similar limitations or not, but based on the way they are structured these are likely to be challenges for at least Claude Artifacts and ChatGPT Canvas.

Success Without Mastery: The Prototype Payoff

In the end I was able to create a pretty cool pickleball paddle data visualizer that runs on desktop and mobile. It calculates a similarity score to find similar-performing paddles potentially for a much cheaper price. There is a really cool 3D point cloud visualizer that shows similar paddle clusters which makes exploring the data super fun for real data nerds. And maybe most importantly I learned a ton about how to develop prototype applications with Gemini Canvas and some of its limitations.

Time from first prompt to my latest version spanned 4 days and I probably put in 8-10 hours of actual work. Was it faster than a traditional coding session? Definitely. Do I now know how to program in React? Absolutely not. Will this thing stand the test of time? Nope. Did it serve its purpose of exploring a bunch of ideas quickly? Yes.

Breaking Out of the Sandbox

So, what’s next?

Well I think it is time to move on from Gemini Canvas and move to a more professional AI assisted development workflow. There are a bunch of open questions:

1. Should I use a fully integrated AI coding IDE like Cursor, Windsurf, Github Copilot, Firebase Studio or Antigravity?

2. Should I go to a full agent based workflow like Claude Code, Codex CLI, or Gemini CLI?

3. Should I go fully cloud native in the browser and keep using my 5-year-old Pixelbook or get a brand new Macbook Pro M5 Max in a couple weeks and run all my compilation locally for maximum efficiency and power?

There are so many new development workflows possible with an infinite combination of tools, but based on some feedback from friends I will likely move slowly toward something that looks a bit more like the professional workflow described here, but I would love to hear from anyone that has an opinion on this. What have you experienced and what direction would you go?

Brian Brown

PS. When I shared this story with a friend they asked, “but have you chosen a pickleball paddle?” Well the answer to that is no, not yet. I will keep you all posted. Pickleball has been one of the fun things I have started doing more of with my wife after we retired. It has been the source of some really fun times and now a reason to start coding again.

Everything is new again. With the new perspective of being retired even things that I have been doing for years are feeling new again. In the past, meetings were routine and a chore. Now they are a joyful time to connect with friends, share stories, and enjoy each other’s company.

It has been nearly 9 months since I retired and left Google for this new world and I can’t believe how quickly the time has flown by. My days have been filled with the newness of it all and for the most part I am absolutely loving it.

With the kids back in school, in fact now a semester has already passed, I have found a new routine for myself and the family. Engaging with the kids with their school activities has been with an energy that was lacking in the past. Excited to watch the marching band play at competitions and football games. Orchestra and band concerts during the week were a highlight not a challenging time to schedule around.

Climbing at the gym has been gaining momentum and a rhythm from once a week to two. And from two to three. Climbing with my friends, my daughter, and random strangers. Reconnecting with Yoga after many years away.

Escaping the Expert’s Trap

My kids often give me a hard time for wanting to be the ‘expert’ in the room. But lately, I’ve been trying to be the one with the most questions rather than the most answers. Embracing the ‘I don’t know’ has turned my world into a playground again. It has been a shift for me when many things I was working on at Google I was considered an expert to today where most things I am a humble beginner. I have always loved to learn new things and build expertise, but embracing the beginner’s mindset in everything in my life with this new found perspective has been a special and exciting time.

Skins, Sastrugi, and the Struggle at 11,000 Feet

This past week I went backcountry skiing for the first time in my life. A couple of months back I was talking to a friend about going on a hut trip and how fun that experience was. I knew that I would enjoy a trip like that, but lacked the experience and gear to make that happen. So I scheduled a day in January with a guide to learn how to backcountry ski. As the day approached, I was excited to learn about the different gear, skis, bindings, and boots used for backcountry skiing. I rented the equipment I needed the night before our day out and I asked as many questions as I could think of to the ski techs at our local shop going over putting on skins, changing from walk mode to ski mode on the bindings, how to clip in, how to clip out, how to swap modes on the boots. There were so many new things that it was overwhelming, but exciting. I would soon learn that it was way easier clipping in and out of my bindings in my basement on the flat carpet than it is on the snowy side of a mountain at 11,000 ft..

Hiring a guide to learn something new is definitely my new favorite way to start diving in. Expert teachers are such amazing people bringing their deep expertise and passion for a subject, making it a joy to learn. I met my guide Andrew Megas-Russell in Estes Park the morning of our day out to do a quick run down on gear and get all packed up for the day. I definitely geek out on gear so it was fun to see all the things Andrew brought for the day as a guide above and beyond what you might bring as a recreational skier. The biggest difference between resort skiing and backcountry beyond the ski setup was all of the safety gear we brought, namely a shovel, probe, and avalanche beacon.

We headed into Rocky Mountain National Park for a day of skiing in the backcountry, and when I say skiing, I really mean hours of skinning uphill and a small fraction of that coming back down. It was super fun even with pretty bad snow conditions. Apparently Colorado is at 62% of the median snow pack for this time of year, which is the worst snow pack on record. I learned how to make progress uphill on skins, AVA turns, kick turns, traversing a log “bridge” without falling into a creek, what sastrugi is (wind-swept, wave-like ridges of snow that look beautiful but feel like skiing over a frozen corrugated roof) and how to ski it, and most challenging of all: clipping your toe in while on the steep edge of a snow covered mountain. Once we skied back down from the 2,500 ft we had skinned up, we spent some time learning about how to use avalanche beacons, probes, and shoveling the hard icy snow.

I can’t say the skiing was amazing, but the challenge of the day and all the incredibly interesting new things I learned made for a fantastic day. Skiing on hard packed and icy snow on jelly legs was the challenging reward for my beginner’s experience. The slog of the uphill flew by as we reminisced about climbs on the Diamond. My one and Andrew’s 15+. It was great to talk about shared experiences while forging a new one.

Shoshin and The Art of Not Knowing

I guess one insight I have had in these last 9 months is that you can be a beginner, open your mind to new things and learn, on anything in your life, whether it is truly new to you or something you have been doing for years or your whole life. This insight and the concept of the beginner’s mind of course is not new. You will find it in the teachings of Zen Buddhism called Shoshin dating back to the thirteenth century. That power to open your mind as a beginner would is completely up to you.

Brian Brown

P.S. For a good book recommendation from a friend on the topic, check out “Beginners: The Joy and Transformative Power of Lifelong Learning“ by Tom Vanderbilt.

The Challenge: A Cabin in the Woods and a Need for Power

A good friend of mine decided to buy a piece of land in the mountains of Colorado last year. She has dreams of building a house there to retire in, but for now she has built a tiny cabin. The views from her cabin are absolutely amazing. Hillsides of endless evergreen trees, rocky outcroppings of granite, and mountain streams in the canyon below. The cabin is remote with a windy steep dirt road to the edge of the property. Needless to say there are no utilities at the property. No sewer. No gas. No electricity.

At the beginning of the summer when my friend asked me to help with her cabin solar system I knew it would be a fun project. I have always been interested in solar systems ever since I studied them in my undergraduate classes in Architectural Engineering. I had taken a class on Daylighting where we had calculated solar models for buildings and I had studied electrical systems for buildings, but that was 25 years ago! This would be a perfect opportunity for me to dive deep into small solar systems where I can learn something new, taking on a tangible engineering problem to solve my friend’s power problem.

The Blueprint: From Blank Page to System Diagram

So, where to begin? Staring at a blank page can be a bit daunting and scary. The possibilities are endless, but the number of questions to be answered seem endless too. Now was the time to embrace the beginner’s mindset. Be curious and start learning. I started where many people would start these days. I went to Google and typed in “how to build a solar system for a tiny cabin.” And just like that, I was off to the races. YouTube videos, blog posts, manufacturers websites, the amount of information was seemingly endless.

I have to confess that I wasn’t completely starting from scratch. I have a small solar system on my camper and over the years, I have had to figure out how it works, and it turns out that a solar system for a camper and for a tiny cabin are very similar. One of my favorite YouTubers that talks about building solar systems and different components for solar systems is Will Prowse. His YouTube channel and his website https://www.mobile-solarpower.com are great resources for learning how to build budget-friendly small solar systems.

While this wasn’t a software problem, my engineering background kicked in. I approached it like any large-scale system: define the requirements, research the components, and design the architecture before writing a single line of code, or in this case, crimping a single wire. And like any good problem, it has probably already been solved before, so to bootstrap the design for my friend’s solar system, I started with Will’s 400W solar system design and went from there. It turns out the most complicated thing for me to figure out was all of the right wire thicknesses and fuse sizes. In the end, it took me a couple of days of work to go from Will’s design here:

To my design here:

Other than all of the work to size all of the wires and fuses, I needed to get the exact components to order and find the actual retailer that supplies them. As a side note I learned how to use Google drawings to make this pseudo-wiring diagram with all of the pictures of the components so I would know exactly how to assemble things when it came time to build it.

The Build: From Diagram to Done

It turns out there are quite a few components required to build even a relatively simple solar system like this. I had 23 different components on my bill of materials spreadsheet—not to mention a couple special tools like crimpers for the solar connections. Once we ordered all of the components, I preassembled everything in my friend’s garage to make sure we had everything we needed. It took about a half a day as I unboxed everything, checked that it all connected correctly, and that things actually worked. Of the things we ordered only one component, the battery shutoff switch, was the wrong size and didn’t fit. We ordered a new one that was the right size and problem solved. Everything was looking good in the garage, but the big test would be installing it all in the cabin and powering up her fridge and Starlink internet.

On the day of the install in September it took about an hour to drive up into the mountains where I met my friend at her cabin. It was a gorgeous day with cloudless blue skies. A great day for some solar power! I unloaded my car with all of my tools for the day then surveyed the area inside and around the cabin. After taking in the absolutely gorgeous views from the deck there was only one thing left to do. Build the thing!

Right off the bat, one of the most nerve racking parts was drilling a hole in the side of the cabin to run the wires from the exterior solar panels to the interior components. Turns out there’s no undo button when using a 1” hole saw. Luckily I measured twice and cut once as they say.

I started work assembling the various components onto a plywood board in the corner of the cabin, using my diagram as a guide. Spending the time creating this detailed diagram really paid off for me to not make many mistakes during the install. Parts were coming together. The satisfying click of the solar connecters as I plugged in the solar panels. The whirr of the drill as I fastened the components to the board. Things were humming along.

There was one point when I connected the solar panels and was testing the solar charge controller and it wasn’t working. My heart dropped for a moment. What could it be? All this planning, all this work, how could it not be working? Let me just say that after looking at my wiring diagram and tracing all the wires I had connected, red is positive and black is negative. If you remember one thing when dealing with electrical systems, that is a good one. After a quick swapity swap and reconnecting of a couple wires the moon icon turned to a sun and we were back in business! I had to do a couple modifications on the fly to make sure everything would fit together physically, but other than that there were no major roadblocks.

In the end it took a bit longer than expected to install. It always does, but the components fit together relatively well. One thing that was a bit tricky was getting the wire lengths just right without making custom length wires, which requires cutting and crimping your own connectors, which I decided not to do.

The first thing we ran on the new solar system was her portable 12V refrigerator and then later her Starlink setup. When my friend clicked the power button on the fridge and the lights on the display blinked on, I knew we were in business. It was really cool to see everything come together in the end work as it was designed.

The Payoff: More Than Just Watts

Folks that have been following along with my newsletter may remember my post about Time Wealth and the framing from the book The Five Types of Wealth. One of the other areas of wealth that I had identified to investigate and grow was Mental Wealth. As Sahil Bloom put it in his book, Mental wealth is built on three key pillars, Purpose (a guiding vision), Growth (a hunger for change and learning), and Space (creating time and stillness to think and recharge). This pillar of growth is something that really resonated with me when I read his book.

I definitely grew my knowledge here of solar systems and it was really rewarding to be able to build this solar system for my friend who now has power because of it. Breaking down a complex problem into simple steps and solving them until you have built something in the real world is really rewarding. The hands-on nature of a project like this is so satisfying and contrasts with the virtual world where I solved problems for so many years at Google. I can remember times where I was in the flow state and the outside world disappeared as I was drawing the wiring diagram, sizing wires and fuses, getting the details just right. This flow state is something I often felt when coding, building systems at Google and it was great to rediscover that feeling again, not in front of the keyboard, but on the floor of a cabin with a pair of wire strippers in my hand.

Though learning was central to this project, I definitely felt an extra level of joy in leveraging my skills, both old and new, to help a friend. This act of service provided a clear sense of purpose, another pillar of Mental Wealth.

Conclusion: The Power of Lifelong Learning

In the end, my friend’s cabin now has a small 400W solar system powering her refrigerator and Starlink, but this project’s true value was much more than the power it brings. The confidence, knowledge, and satisfaction gained is worth so much more than the dollars saved. I am excited to continue to find ways to grow my mental wealth and find purpose in life through projects like these.

Stay curious, solve new problems, and create tangible value in the world.

What’s a new skill you are curious to learn just for the joy of learning?

Brian

PS: Sorry, not sorry, for the big gap in posts. I’ve been enjoying life and doing things. Though it does feel great to get another post out there.

What is my purpose now? For anyone leaving a long held career this question looms large over many of us. This is the underlying question, or the “question behind the question” as my old manager at Google liked to say, when someone asks me, “What are you going to do now?” I realize now that finding purpose was one of my biggest fears going into retirement. It is such a big open question that stands out from all of the rest of my fears, but doesn’t have a clear path to resolution. In fact, I didn’t even list finding purpose on my list of fears when we were planning for retirement I think because I didn’t know how to name the fear. My wife and I wrote down things like losing our identity, perception of friends and family, having enough to do and filling our days, but to my surprise I didn’t explicitly say I was worried about finding purpose. In the end, I am not much of a worrier. So maybe a better word would be fear.

Searching for Clues in the Wisdom of Others

I have been thinking about purpose more and more now especially after finishing The 5 Types of Wealth (specifically the chapters on Social and Mental Wealth). I need to come back to some of the tools presented in that book to explore deeper on what motivates me and are my true core values. After finishing that book I read Siddhartha by Hermann Hesse upon the recommendation of some friends. It is a fantastic book that follows the life journey of a boy finding his purpose in the world. Lots of layers to unpack there, but my one line takeaway was that not all you learn in life can be taught or maybe said slightly differently: wisdom comes from the experiences you live. I think there is a deep comfort in that, knowing that the path you take, no matter where it leads, is the right path, because of all that you will learn along the way.

After Siddhartha I read Everyday Dharma: 8 Essential Practices for Finding Success and Joy in Everything You Do by Suneel Gupta. It was a bit of a western introduction to the concept of dharma which is rooted in Hinduism, Buddhism, Jainism, and Sikhism. In Hinduism dharma is partially your purpose, but also how you express it in the world. It was a great reminder that finding one’s purpose is not enough, you also have to act and express that purpose in the world for others to benefit.

When I was still at Google, I attended a leadership summit for the Google Maps organization and Suneel Gupta (brother of Sanjay Gupta) was one of the speakers. His stories were incredibly engaging, which is no surprise being that Suneel’s dharma is rooted in storytelling. I had purchased Suneel’s book back then, but it just now got to the top of the book queue a couple of weeks back.

Suneel covers many ways to explore your dharma, which are incredibly multifaceted and deserve much deeper study. I found the quote which he paraphrased from the Bhagavad Gita “better to live your own dharma, even if you fail, than to live someone else's perfectly" to be particularly profound.

An Engineer's Guide to Not Knowing

I recently listened to a Hidden Brain podcast episode Wellness 2.0: Who Do You Want To Be? where the host Shankar Vedantam interviews psychologist Ken Sheldon about his recent book that studies the science of figuring out what you want. I found the portion where they talk about the process of figuring out what we want in life and it's analog to an artist's creative process really resonated with me. The basic premise is that we often follow a process of deliberation where we ask ourself a hard question consciously, then move into illumination where we step away from the problem because the answer is not obvious and let the question marinate as it were in our non-conscious mind and at some point we have an ah ha moment. Then we take that idea to the verification phase where we test to see if that idea was a good one. If this three phase process is what is happening with me, I am just in the early illumination phase where I have asked the question, “What is my purpose?” out in the world and I am opening myself up for ideas to explore.

This second phase is very different from what I am used to as an engineer. I am used to breaking problems down into smaller manageable chunks and working my way methodically through their solutions. Not that these things are easy, but they are done consciously. In this other paradigm, which Ken Sheldon calls Self Concordance, the middle phase relies heavily on your non-conscious mind to reveal your deeper values to you. The podcast mentions leveraging tools such as mindfulness meditation to achieve these revelations. I have heard from many friends who are in a similar phase of life, learning to move from a world focused on extrinsic motivators (money, status, power) to intrinsic motivators (enjoyment, value alignment, positive relationships), that this practice has been hugely helpful for them. I am definitely looking forward to diving deeper in this space.

Purpose in the Present Moment

So, what is my purpose? In short, the answer is: I don’t know. Or at least, I don’t know yet. I know that right now my family and friends are the focus of a lot of my energy. I know I want to be a great Dad for my kids, a great husband for my wife, and a great friend for my friends, new and old. I know that I want to learn more about myself and the world I live in. I know that I am in a transition and the path is not clear. I am holding that uncertainty and giving myself space to accept what is coming next.

As I sit looking out over the lake in Maine, I feel my purpose in this moment is to enjoy the beauty of this world. Listen to the rain drops falling lightly on the roof at camp. Listen to the hummingbirds hum at the feeder. Sit with the silence.

So as people continue to ask, “what are you going to do now?” I am setting aside the engineer’s need to have a well defined solution and am embracing the creative process of illumination. I realize it is ok to answer, “I don't know.” The answer isn’t on a well defined timeline and I am learning to be ok with that.

Brian

PS For those of you who have navigated this transition, how have you found comfort in the phase of not knowing? I’m learning the wisdom here comes in shared experiences and I would love to hear yours in the comments.

Looking back there were many many decisions that led me to the realization that I could or even wanted to retire early. As I reflect on them a bit deeper I do see a pattern emerge and that is simplicity. Many of the decisions I have made in my life have made it simpler. And many of the decisions are about the things I decided not to do or the things I decided not to buy that had a big impact on my ability to be here now enjoying a quiet morning during the week without the stress of heading off to work.

Foundations of a Simple Life

Probably the biggest decision I made early on that set me down this path was choosing to go to the University of Colorado at Boulder for college. It is a great school and as a Colorado resident in 1996, it was a school that my parents could afford to send me to. This meant that when I graduated in 2000 I had no debts and a solid engineering degree that would open many doors for me.

A byproduct of being at CU was meeting my future wife our freshman year in the dorms. I remember awkwardly buying her flowers and asking her out. She was the smartest person I had met, she listened to cool punk rock music, and she wasn’t too sure I was going to be the love of her life. When we both graduated, she moved away to take a job with Intel and I stayed at CU to pursue a masters. One semester in, I knew I didn’t want to spend any more time away from her, so I left my master’s studies (much to my mother’s chagrin) and moved into her apartment in Arizona (much to her mother’s chagrin). This ended up being a great decision, because a year and half later, we were married!

After a couple of years in Arizona, my wife's job was going well at Intel, but my job didn’t really have a long term future as I was doing technical sales for a lighting sales agency. We decided to move to Georgia for a new job for me doing optical design work at a lighting manufacturer that was more aligned with my undergrad degree in Architectural Engineering. My wife took a leap of faith that she would find something that would work for her, which she did making the move from semi-conductors to pharmaceuticals.

We spent a couple of years in Georgia, which was great, making new friends and enjoying our work. We were glad to live somewhere away from where we grew up. Different culture, different climate, different politics, but there was something that started to pull us back toward Colorado. Our parents would come visit occasionally and we would travel back to Colorado for the holidays, but it definitely made it hard to also have time for vacations as young professionals with limited vacation time.

Returning Home and Starting Anew

After a couple of years in Georgia we decided to try and make our way back home to Colorado. I had been writing software for a while since a consulting gig I landed one summer in college and more recently in my job writing optimization algorithms for reflector and lens design. A friend of mine I had been working with in Georgia moved back to Colorado to work at a company making 3D design software called SketchUp. He recommended I interview there, which I did and landed a job. My wife got a job shortly thereafter at a pharmaceutical company in Longmont. Three months after I was hired at @Last Software the company was acquired by Google!

When we moved back to Colorado, we had to decide where we were going to live. The first year we rented a townhome so we could figure out where we wanted to be. The main choices were somewhere in Boulder close to my work, somewhere in Longmont close to my wife’s work, or somewhere in between. In the end we decided to optimize for commute times, 5 min for my wife and 20 min for me, cost of housing, and most importantly for local schools. We were thinking about having kids and we really wanted to be within walking distance for our kids to go to a local public school. My mom was a public school teacher for many years and my wife and I had always been big proponents of public schools. In the end we chose a house in Longmont 5 minutes walk from the local elementary and middle school, 5 minutes drive to my wife’s work, and 100’s of thousands of dollars less than a house in Boulder.

Over the years, many of the decisions we have made have been to simplify our life or at least to keep it simple. Sometimes simple also means living well within our means. Sometimes simple means minimizing wasted time. Choices like only buying a new car every 10-12 years. Choices like buying a home just big enough for our family but not any bigger. Choices like not buying a mountain cabin (though I have been very tempted). Choosing the less expensive place to live, not moving to Mountain View, where maybe I would have more opportunity with Google, but at what cost?

I can remember agonizing over where we were going to send our daughter for day care when she was first born. We all want what's best for our children, but I feel like this is where businesses and society in general try to capitalize on the fears of young parents that are emotionally vulnerable. The stress of finding a place that is best for your child, within your budget, in the right part of town so it doesn’t add considerable time to your commute. Figuring all of this out while my wife was very pregnant and we were about to be brand new parents. In the end we chose a place that wasn’t the closest to us, or the farthest from us, or the most expensive, or the least expensive. It was a compromise, but one that considered all the factors including our time.

The Counterintuitive Path to Wealth

There have been countless choices over the years where my family and I have chosen to keep things simple. We have chosen to be relatively frugal. Spending money on experiences not things. We have tried to resist falling into the vicious cycle of wanting what others have. The bigger house or nicer car or fancy watch. There is always a bigger boat as they say.

This is nothing new for anyone who has read any financial success books like the Millionaire Next Door. Very early on in my early 20’s I read Smart Couple Finish Rich with my wife where this concept was introduced. It comes up in every happiness related book I have read since and was covered deeply in the Psychology of Money which I discussed in my post ‘Why Now?’ The concept is of course much older than any of these books. Hedonic Adaptation, the notion that people tend to return to relatively stable happiness after major life events, good or bad, was published in a paper by Philip Brickman and Donald Campbell in 1971.

These teachings go much further back than the 70’s though. Christianity has deep teachings against covetousness and encouraging contentment and gratitude. Stoicism promotes a form of detachment from external desires. Buddha’s philosophy of non-attachment is a key Buddhist teaching as a way to avoid a primary cause of suffering and the middle path emphasizes balance to avoid the extremes of indulgence.

Simplicity as a Superpower at Work

In my career at Google, I tried to keep these philosophies in mind. I almost always said yes to growth opportunities when they came my way, but not always. I would try to consider the consequences of taking something on, knowing that it may cause more stress or mean more work. Early on in my career at Google, before I had kids, time was less of a concern and I felt I could really grind things out when needed. There were late nights for launches or the occasional weekend on call. But even with that, pretty early on I started to set very strict boundaries for myself. No email or calls after 5:00. Never work on Saturday or Sunday. The rules were simple.

These boundaries made things simple for me and were a key to my success. They helped me prevent burnout. They forced me to be more efficient. By protecting my time, it forced me to ruthlessly prioritize and to empower my team so I could delegate. Over time this forced me to build a great leadership team. One that respected these boundaries as well.

The Sum of Simple Choices

Striving for simplicity in our family’s lives has been one of the key enablers for retiring early. It has led to achieving financial independence at a younger age. It has not only made me happier, but it has given me the space to appreciate that happiness every day. And I guess I didn’t quite hit my original retirement goal of 45 (I was 46), but it was close.

Just because these decisions made things simple does not mean they were easy. Ending a promising master’s program, or moving across the country without a job lined up, or completely changing career paths were all hard choices, but they simplified our lives, clearing away future complexity, allowing us to focus on what mattered most.

Do you have any big decisions coming up that may lead to increased complexity in your life? Think two or three steps into the future and see where the decision might take you. Is that where you want to be?

Brian

PS I haven’t always made decisions that lead to simplicity. At one point at Google I stepped up to build a team in India. Luckily for me, before I was able to hire anyone, the COVID pandemic began and we abruptly canceled that expansion. If I had managed that team there would have been many late night calls and trips to India. I have had smaller versions of things like this over the years that were unavoidable. Recognizing them and figuring out how to simplify things in the long run has always helped.

The time is now!

A Note from My Former Self

About a year ago, the family was hiking in Golden Gate Canyon State Park in Colorado, which is a little over an hour from our house. As we hiked a five mile loop in the park we saw some great backcountry sites about two miles in that we thought would be a really nice destination for an intro backpacking trip. Not too far from the trailhead. Beautiful location with lots of wildflowers and wildlife viewing. I snapped (clicked?) a couple of photos of the sites we liked so I could remember them for some future date when I’m trying to decipher the info on Colorado Parks and Wildlife website. Thank you former self for this forethought.

In May this year, I booked us a spot based on my photos from last year and locked in our dates. I asked my brother if he would like to join because my wife couldn’t make it and he said yes. Two adults and two kids would make for more reasonable gear distribution in the packs, and I was pumped to have my brother along. The last time we had been backpacking together was on a more ambitious trip 13 years ago over Pawnee Pass, which is on the continental divide.

My brother and I have been backpacking together multiple times, but many of the trips were when we were much younger in Boy Scouts. My dad was always there as well and these are definitely some of my core memories in my childhood. I was looking forward to creating some of those memories with my own kids.

Gearing Up for Connection

It turns out, I love gear. I love backpacking gear, climbing gear, and camping gear. I love to read reviews, compare the weight of the Jet Boil MiniMo stove (415 grams) to the Snow Peak Trek 900 Cookset and GigaPower Stove (250 grams). Sometimes it gets a bit much for my family. They ask things like, “Why are you looking at a puffy coat? You already have five!” Well first off, I think they are right that I do currently own five puffy coats, but one is for really cold winter days, one is for fall, one is for warmer winter days and “nicer” occasions, one is for camping (gets smoky), and one (Montbell Ultra Light Down Jacket) is for backpacking. And what I would really like is one with a hood. I don’t have any puffy coats with hoods right now. But all the best gear in the world is useless if you just let it sit gathering dust in the basement and don’t get out there and use it.

Needless to say I have a spreadsheet with all of my backpacking gear with type, specific item, weight, whether it is optional, if it goes in my pack or wear it, if it is a good weight or a bit heavy, whether you carry it all yourself or split with a partner. There are estimates of the overall pack weight without food and water. There is a food tab with a meal plan with calorie estimates to make sure we have enough food, but not too much.

For the three to four weeks leading up to our trip my younger daughter and I went to REI to scope out the latest dehydrated backpacking meals, which are getting surprisingly good these days. We picked up some miscellaneous things we didn’t have enough of like insulated lexan mugs, and utensils, but surprisingly (or I guess not) we didn’t have to get much. It turned out that between my wife and I we had six backpacks capable of carrying a couple night backpacking load. And yes, five of them were mine, but who can pass up buying an ultralight GoLite frameless backpack when they are going out of business? You can’t get that pack anymore!

I may have been more excited than my daughters when it came to packing, but as they helped organize things and look at all the equipment we were bringing I could see a glimmer of excitement starting to grow. We laid out all of our gear in the basement making sure we each had headlamps, sleeping bags and pads, the right clothing, and food. We were checking things off the list as they went into their packs. Finding the right pack that fit well. Adjusting the straps to be just right.

Into the Backcountry

We met up with my brother on a Saturday morning and packed up the car with our backpacks having already done most of the hard work the days and weeks before. All we had to do now was get to the trailhead and enjoy our three days in the mountains.

It was a couple of miles hike from the trailhead to our campsite. The slow uphill was accompanied by good conversation between my brother and my two daughters and I. It was definitely a new experience for my youngest to carry a nearly 20 pound pack on her back, but she and her sister had little trouble making their way up the trail. There were beautiful wildflowers along the way and the weather was sunny but not incredibly hot with the elevation of 9000’.

We found our site right where we expected and quickly set up tents in the space allotted. My younger daughter and I had practiced setting up the tent the day before so we made quick work of it. After getting our tents all set up with sleeping bags and pads, we had the task of finding a water source to fill up all of our water bottles. The ranger at the visitor’s center had told us of a spring around the trail about a half a mile away, but I had remembered one much closer to our site from our hike a year ago so I was hopeful to find it again.

My daughters and I loaded up all our empty bottles and our water filter in search of the spring while my brother stayed at camp. We headed up the trail, but no more than 20 feet later, the nearest spring I had remembered was there off the trail flowing well. I started filling the water pouch of our Sawyer Squeeze water filter ready to filter about 128 oz of water. As I started squeezing the first batch of water into one of our Nalgenes nothing happened. No water came out. A sinking feeling came over me. I had not tested the filter since I had used it last summer. The one failure mode for a Sawyer Squeeze is that it can get clogged, requiring you to flush the filter in the opposite direction of the normal flow. This requires a big syringe. This big syringe was sitting in my basement with all the gear I did not bring from our final packing the day before.

After much squeezing we were able to get a few drops to come through, but at that rate it would take hours to fill a 32 oz bottle. So we went back to camp and while we were sitting around someone was always squeezing. We also knew that for all of our meals we were boiling water anyway so we could just boil them for a bit longer to make sure they were free of bacteria. After my oldest daughter got a full water bottle out of the filter an hour or so later we came up with the hanging filter idea. We hung the bag and filter from a tree with a bottle below and watched drop by drop the bottle getting filled with no effort. It was slower, but at least we didn’t have to squeeze anything.

Having used the first 64 oz of unfiltered water, I walked back to the spring to fill up another water bladder and found another family filtering water for their weekend stay. I was envious of their brand new Katadyn Hiker Pro Microfilter that the man had got for Father’s Day this year. He was effortlessly pumping away filling a huge water bag. When I told him our predicament he said to bring over a few bottles and he would fill them up for us. Two minutes later we had 64 oz of freshly filtered water. Between the kindness of our newly-met camping neighbors and a little bit of creative problem solving, we were well on our way getting over our water woes.

The rest of the backpacking trip went off without a hitch. Our gear was working great. We boiled water for our meals on my brother's MSR Jet Boil clone which was super efficient. Rehydrated Chicken Pesto pasta wasn’t too bad and the girls Santa Fe Style Chicken with Rice & Beans was even better. While we were prepping dinner the first night, we saw a moose walk up the hill on the other side of the trail from us. Our after dinner walk was cut short when we saw two moose right next to the trail and when we tried to take a path around them we weren’t able to give them quite the space we wanted so we turned around.

We all got a reasonable night's sleep though I think I woke up every hour to roll over on my inch thick inflatable mattress. I definitely have gotten soft over the years sleeping on my cushy memory foam mattress in my camper.

The next day was full of hiking, moose and wild turkey sightings, all kinds of wild flowers, but best of all some great quality time talking with my daughters and brother. The slow moments on the trip—getting an arm around the shoulder from my daughters or recalling a great memory with my brother may have been my favorite parts. We spent time reading, scrambling around on rocks, playing tic tac toe in the dirt, throwing the rock in the circle, and other random made up games to pass the time.

The last night brought thunderstorms and a couple of hours of rain, but nothing our tents and a pair of earplugs couldn’t handle. I fell asleep quickly and slept better than the night before. The next morning we had our standard breakfast of oatmeal with walnuts on top. We packed everything up quickly and everything was already dry from the night before. The hike out was a breeze as it was all downhill and in 50 minutes or so we were back at our car driving home.

The Real Takeaway

A week out from our trip, I have had time to digest the experience and check in with the family to see how it went. Everyone had a great time and would love to do it again. More importantly for me is that I planted a seed and am happy I didn’t let yet another summer pass by without introducing my daughters to the joys of backpacking. We will definitely do it again.

That backpacking trip I had been putting off and not making time for, I finally made it happen. So what is your backpacking trip? What’s that thing you have been wanting to do, big or small, that you have been putting off? Take this as your sign, the time is now!

Brian

The Cult of “Busy”

I used to try to optimize every part of my day, especially at work. Efficiency was the name of the game. If you can do more things in less time you are more valuable. Your output to input ratio is high. You exceed expectations. You get things done. You are a super star.

There are tons of books about this topic of time and productivity. Atomic Habits is the latest book I have read on the topic. I just finished the Time Wealth chapters in The 5 Types of Wealth and Four Thousand Weeks is sitting on my nightstand. They all come at time with a slightly different angle, but in the end they are the same. Time is finite in your life. You don’t know exactly how much time you have, but about 80 years +/- 20 years is about it. 4000 weeks is about 80 years, thus the book title. Then if you bring in the calendar work week constraints you only have 40 hours to do work things in a week give or take.

We all know this. There is nothing new here. Except for me, with this transition into retirement, the equation has changed and I think it is changing something in my brain.

In the past I always optimized everything I did for time efficiency. If I was doing a task, I wanted to do it as quickly as possible and in the best way possible. If I was driving somewhere, I used Google maps. I chose the fastest route. If there was a couple minutes faster route, I would take it. Dare I say, I might even open Waze to get a faster route?

When was the very last moment I could leave to get there on time? When was the first moment I could leave wherever I was when I was done to get to the next thing? Checking my watch, estimating transit time, how long will it take to get this or that task done. Pack it in, add it to the calendar, squeeze it in, busy, busy, busy.

How are you doing? Good, busy, but good. Lots to do. We wear “busy” with a badge of honor.

Embracing Flexibility

Now, things are different. Very different.

Now I have flexibility. I have so much more control of what I schedule in the day. This is great. I can do the things that I want when I want. That part was expected. What wasn’t expected was how I engage with other people when I am doing something. Part of my mental energy in the past was spent thinking about what I was going to do next, when I needed to leave, and what I needed to have ready. Now I don’t need to spend energy on optimizing so I am more fully engaged and present. It isn’t that I don’t schedule things, I do. I just schedule a longer slot so I don’t have to worry about the time.

Coffee with a friend in the past: if I scheduled something like that at all, it might have been 30 minutes or at most an hour. Now, schedule 2 hours and if we meet that long, great, I’ve got the space. Going to a friend's house for dinner or having friends over I used to always think, oh we need to get home so we can get to bed, work in the morning. Now, we just go with the flow and see where the night takes us. Traveling down to Denver for a concert, oooh that's late, not sure if I can make it. Now, let's do it!

The removal of time pressure has made things more enjoyable and I feel more engaged than ever. In the past I was always thinking, is this the absolute best thing I could be using my time for in this instance? And if it wasn’t, I would get a bit annoyed or frustrated. Now that pressure is off and I can find enjoyment in almost anything I am doing.

The Unseen Stress of Optimization

I never really thought that I was stressed that often when I was working. I now realize that this constant time pressure was a form of low level stress on my life that was always there. I had got so used to it I didn’t recognize it as stress. I can tell you that now it is gone I feel much better.

I’m sure folks are thinking, great Brian, if I could just retire then I can deal with this time pressure, but until then I guess I just have to deal with it. I don’t think you need to retire to deal with this potential source of stress. Just understanding the stress is there might be enough for many folks. Schedule less things, make more space, you might need a break more than you thought. Try scheduling a block of “un-optimized” time for just thinking, having a conversation with your spouse or a loved one, or just take the scenic route home. I’m learning that the first step isn’t finding more time, it’s reclaiming the time you already have.

Measuring the Shift to Time Wealth

In The 5 Types of Wealth, there is a wealth assessment you take at the beginning of the book. When I answered the questions on Time Wealth last week I scored a 16 out of 20 (higher is better), which I think is pretty good. I also answered the questions as if I would have a year ago and scored a 8 out of 20. Not good. It was the lowest dimension.

I want to unpack all of the dimensions of this wealth score at some point, but of all the dimensions, Time Wealth was the most dramatic shift from pre-retirement to post-retirement. This didn’t come as a surprise. I knew I would have the opportunity to do new and different things that I didn't have time for before. That is true. What I didn’t expect, and what I am really excited about, is that the flexibility and decreased time pressure has made everything I am doing so much more enjoyable and engaging.

For anyone out there in the working world, is there anything you have found that has helped you better manage your time, not so that you can pack more things in, but so that you can be happier and engage more with the people that are most important to you?

Brian

The Plan

About six months ago, we planned a three-week camping trip through southwest Colorado's mountain towns, state parks, and national parks. Booking each of the nine campsites meant getting up early every couple of days to reserve spots as they became available six months in advance, as they fill up quickly after they come available. We had spreadsheets detailing amenities, maps of routes and points of interest, and meal/grocery plans.

With my new found freedom from work I was able to spend even more time than usual getting the camper ready for the trip and getting my new car set up for the road. It was nice to be able to do little projects during the middle of the week like installing a new brake controller on my car, installing a new charge controller and solar panel on the camper, and getting a new lithium battery all connected.

With a last flurry of packing and loading the family was ready for a three week adventure we were all extremely excited for. After an early Wednesday lunch we were off into the mountains of Colorado for what would turn out to be one of our best vacations in years.

Camping

Growing up I had always gone camping with my dad in the Cub Scouts and the Boy Scouts. It was something I really enjoyed. Being out in the wilderness away from the city. In the early days I always camped in a tent and when starting camping with my family we were in a tent too, but as we and the kids got older we decided to get a camper trailer which has led to many more days in the mountains for which I am grateful.

Looking back I realize that most of my camping trips were filled with friends and family. On this trip I was joined by my wife and two daughters. Later in the trip we would connect with some long time friends to finish off the trip together.

Our first stop on this trip was at Lake Dillon Reservoir at Heaton Bay Campground. It was a beautiful spot near the water. Trees surrounded our campsite. There was a view of Greys and Torreys Peaks in the distance. There were blue herons nesting a five minute walk away. This camp site had everything! Except for one thing. Wi-Fi.

Oh no, how am I going to do my Duolingo lesson for the day? How do we check the weather? What if I get a message from my friends? These were all questions asked on the first day of our trip. I had spotty service at best and the kids had nothing. We were going to have to quickly come to terms with this new reality.

It wasn’t long before the kids were off bird watching in the forest. Finding a trail that traversed the peninsula of our campground. Building a fire for s’mores. Reading a book before heading in for bed for the night.

Even on the very first day the forced time away from technology and being physically together as a family was fantastic. Hours spent bird watching the blue herons and osprey on the first two days was one of the things my daughters most enjoyed on the trip. And I loved it too. Hiking around with the binoculars trying to find a better view. Counting the nests we could see. Trying to take photos through the binoculars with our cell phone cameras and partially succeeding.

I wasn’t surprised that the kids quickly adapted. Our forced close quarters led to other great things like a whole lot of reading time. We played Uno many nights around our tiny table in the camper, keeping track of our score night to night which led to the kids in the afternoon asking “Can we play Uno tonight?”

This time together sharing experiences was definitely strengthening the bonds we have in our family and I had no doubt it was aided by all of us being disconnected from the endless online time syncs we are all susceptible to at home.

Human Connection and Happiness

If you believe the findings from the 80 year Harvard Study of Adult Development, the longest study on human happiness, it is clear that close relationships, more than money or fame, are what keep people happy and healthy throughout their lives. Many of the findings are captured in the book, The Good Life, and similar themes in the famous book, Bowling Alone.

Building and strengthening these connections is something I know that I will need to focus my energy on now and in coming years. As an introvert, building new connections definitely does not come easy for me, but strengthening the connections I do have with family and close friends is where I plan to start. This 3 week camping trip was definitely a good dose of connection building, making dedicated time to be with friends and family face to face in real life, unplugged sharing experiences we remember for a lifetime.

I am currently reading The Five Types of Wealth, and as I do my own initial assessment on where I could potentially increase focus the dimension of Social wealth is definitely popping out as one to dive deeper into. Social wealth in this framework refers to the strength and breadth of one's social connections and relationships.

The third week of our trip we connected with some long time friends that we have camped with many times before. It was so fun to see our kids connect, playing games that they had invented on previous trips (Smash Ball), and telling wonderful creative stories around the campfire. The level of creativity you see from the kids when they have such limited resources, but the free form time to just create is so fantastic. If you ever happen to run into a two foot tall blue stuffed giraffe named Jerry who loves to take questions, his origin was on a whole other 3 week camping trip in the Pacific Northwest that will have to be left for another time.

Reflections and Takeaways

Throughout this entire trip I decided to keep a daily journal. At first it was focused pretty mechanically on when we woke up, what we ate, where we went, but as the days went on I saw that I got a bit more reflective on the time we had had together with family and friends. In one of my last entries I was reflecting on what we were missing from home and talking to my daughters about what they were missing. I wrote,

“My daughter asked what I am most looking forward to at home and I said the climbing gym. I think that is two fold, both getting back to climbing and the friends that are there. She then said, ‘but what about things in our house?’ and I said I already have what I need in the camper, a bed, a refrigerator, a bathroom, a shower, a stove. Pretty nice. I do miss my espresso machine. My AeroPress coffee just isn't the same. Maybe I can get some better beans next trip.

She said, ‘What about your family? You didn't mention your family’. I said of course that is the most important part. That is why I don't feel a huge pull to return home because I am with my family. And after three weeks of being together, at times in really close quarters in the camper that is my favorite place to be.

Family and friends. Old and new. That is definitely the most important thing above all.”

You don’t have to take a three week camping trip with family to disconnect. It can be in much smaller chunks in our day to day lives, but if you can make the time “10 out of 10, would recommend” as my daughters like to say.

Brian

PS. If there was one thing I was not excited about returning to, it was being more connected. What ways have you found works for you to disconnect, big or small? I do things like try to put my phone away in the kitchen so I’m not tempted to jump on it at any time, but inevitably it makes its way back to the coffee table, where it is now as I write this post. I would love to hear what works for you all.

At the beginning of 2024 I was feeling like my personal fitness was not quite where I wanted to be. My weight had crept back up to 175 lbs, I wasn’t eating as well as I had been in the past, and generally I was feeling a bit blah in terms of my strength and fitness. Luckily for me, my wife likes to buy me a new cookbook every Christmas and this year she bought Love & Lemons Simple Feel Good Food which is a great cookbook with vegetarian and vegan meals. Mind you I am not vegetarian, but I love to cook new things and this was a great catalyst to getting more plants in our diet.

In addition to eating well I knew I needed to get back on the fitness train and start working out more. Going to the gym to work out isn’t super motivating for me, but I do rock climb so going to the climbing gym to climb is motivating. My wife on the other hand loves to do 30-45 minute HIIT(High Intensity Interval Training) style workouts at our house. It turns out for me, having a partner who pushes you a bit at home and a sport you enjoy out of the house are a big help in increasing motivation.

For the first couple of weeks in January things were looking good. I was exercising 5-6 days a week and cooking and eating really healthy meals. Things were great. Until they weren’t. Later in January I felt like I was really having to push myself and my motivation was starting to wane. I needed something more to keep my focus, I needed something bigger, I needed a Big Hairy Audacious Goal (BHAG). [Read all about the concept in depth in Jim Collins book Built to Last]

At that point I decided I was going to climb Longs Peak. I see Longs Peak almost every day from my house. It looms large at 14,259’ (4346 m) and can be seen along the front range in northern Colorado. Many people hike to the top of Longs Peak via the Keyhole route, but ever since my friend John told me that people climb the front vertical face called the Diamond I have wanted to climb it. I remember when I first heard about these routes over 15 years ago how impossible they seemed to me, but now somehow they seemed achievable.

That next day after internally making the decision to climb Longs somehow things were different. I hadn't told the world about this goal yet, heck I hadn’t even told my wife. I can remember Stacy asking me if I wanted to work out with her that day and initially thinking no, but then getting an image of the Diamond in my mind and thinking if you are going to climb that mountain you need to work out today.

Yes. Yes, I am doing this. There were times when I was working out trying to push out those last few reps where I wanted to give up and that image of the Diamond would pop into my mind and I pushed just a little bit harder. There were times when I would be at the climbing gym and ready to head out when that image of the Diamond would pop into my head and I would do one more route, or two or three.

For a couple of months I kept this decision to climb Longs Peak to myself. It was enough to motivate me internally, but as time went on and as summer was approaching I knew I would have to start telling people, not to mention find a climbing partner who would be willing and able to complete this climb with me. At this point I was scared. Scared of what people would say, scared of the reactions I would get, but most of all scared that if I told people and then I backed out I would be seen as a failure. I didn’t want to fail, but I knew if I didn’t try there was no way I would get to the top.

OK, I wasn’t ready yet. I was going to wait a little longer before telling the world and do some things that would bolster my confidence that this whole thing would be possible. I had been climbing in the gym more and more 2-3 times a week, but mostly bouldering. I knew I needed to get back outside on the rock to get in better climbing shape outdoors so I went out to Eldorado Springs and climbed Rewritten with my long-time climbing partner Julius in April. On the upside I felt great and the gym climbing strength seemed to transfer pretty well, on the downside I realized I had not been on any serious climb outside since long before COVID almost 7 years before! The other bad thing was that Julius took likely the worst fall I had ever seen on our descent coming down a gully when a 5 foot tall boulder he was standing on let loose. I was hoping it was not a bad omen of times to come. Luckily Julius recovered relatively quickly, but it was definitely a narrow miss.

In June I got out for some more trad climbing in Eldo once Julius had recovered, leading Wind Ridge, Calypso, and Reggae which all range from 5.6 - 5.8. I felt solid on them which was good, but still a far cry from climbing any route on the Diamond.

I still knew I wanted to brush up on my technique and gear so I decided to learn from an expert and signed up for the Learning to Lead Trad class by the Colorado Mountain School in July, 2 months away from the target climbing window for Longs Peak. I remember Julius asking, “Why are you taking the class?” and feeling like I was reading The Complete Idiot's Guide to Rock Climbing and then going to ask him if he wanted to climb the Diamond with me. In the end the climbing class was a great refresher on trad gear placement and some belaying techniques. If nothing else it was a good reinforcement that I had not forgotten everything and gave me my first opportunity to tell my instructor that I wanted to climb the Diamond this summer and him not looking at me like I had two heads.

I had internalized something that I had not felt for a while. I was a climber. Climbers go to the climbing gym 3 days a week, not 2. Climbers take their climbing shoes with them when they go on business trips and climb at the local gym to get an extra workout in. Climbers ask their friends, and just as importantly they ask you, to go climbing with them on Friday’s before work to get in an extra climb. Climbers eat healthy so they build strength.

Climbers climb Longs Peak.

I was starting to feel really good both physically and mentally about this new identity. It had been 7 months on this journey and I felt stronger climbing than I had in years, maybe ever. I had lost 30 pounds and was working on building up more muscle and cardio endurance. My confidence was really starting to build.

At this point I was ready to tell more people I was going to climb Longs Peak and ask Julius if he would go with me to climb the Casual Route on the Diamond. I don’t actually remember exactly when I asked him, but I think I had been hinting that I wanted to climb it that summer and he was probably telling me about some wicked hard climb he had done the weekend before while we were eating lunch in the office. He was game, which I took as a good sign being that we had done some routes together over the previous couple of months together.

As I told more and more people about my goal it felt like it was becoming more and more real. I was starting to log more hours on hikes in July, building up some cardio and leg strength for what would be a long day of hiking. At the end of July I went to the Longs Peak trailhead at 6:00 am on a Tuesday and hiked up to Chasm Lake. From there you can see the sheer 1000’ vertical face of the Diamond looming large above the lake. It took 1 hour and 45 minutes to get to the lake and there was another hour of rock hoping to get to the base of the climb at the North Chimney, but I was feeling good about my pace. I knew I would need to come back another day to see what the hike to the base of the climb would look like.

It was August and climbing season for the Diamond, which is a tight 6 week window from the end of July to the beginning of September. Any earlier and there is still snow melt and ice, any later and you risk a snow storm. In between is the sweet spot of relatively dry conditions with the exception of typical afternoon thunderstorms, which makes things dicey when you are above the treeline and the lightning rolls in.

The Route

Now, along with continued physical conditioning, was the time to do a whole lot of planning. What would I pack? When should we leave? What day should we go? What did the weather look like? Where exactly was the route on the way up and on the descent? Luckily there are some absolutely amazing resources for all of this, most namely Steff Abegg, who’s Longs Peak Beta page is absolute gold. Steph has climbed the diamond 32 times as of last count and is an absolute beast!

The route we had chosen to climb on the Diamond is called the Casual Route. It is the easiest technical route up the Diamond at a rating of 5.10a. The climb itself is 7 pitches from the Broadway Ledge up to Table Ledge which is at about 13,700’. To get to Broadway Ledge we decided to take the most common approach which is to climb up a 5.5 3 pitch route up the North Chimney, which would be easy if not for the fact that the rock is absolutely horrible and loose causing almost continuous rock fall potential.

To get to the base of the North Chimney is an approximately 3 hour hike from the Longs Peak trailhead, the first 1:45 on good trail and the last 1:15 rock hopping around the Chasm Lake Cirque.

Once you reach the Table Ledge you can either rappel back down the way you came or traverse the skinny ledge to the skyline where you pick up Kiener’s Route which is a 4th class climb to the summit. Getting down from the summit you have many options, but the two main choices are descending the hiking trail of the Keyhole route or taking the Cables Route down which includes two rappels. We would choose the Cables Route because we have the gear and it saves time. At that point you are at Chasm View and have to make your way back down to the Boulder field and hike 5.5 miles back down the mountain to the Longs Peak Trailhead.

All in all the route is about 13 miles round trip, 4,800’ of elevation gain, and 10 pitches of technical climbing. It would be by far the biggest climb I have ever attempted in my life.

Ripple Effects

I got in a couple more training hikes including one to the base of the North Chimney recording a GPS track that we would use to navigate the boulders in the dark on summit day. At this point I was feeling the ripple effects of having this clear goal that I had put out there. I was connecting with my friend Thomas on training climbs and my friend Tommy on training hikes. The three of us got in a great training hike the week before what would be our summit attempt day. I felt like I was being supported by a team of friends who knew I had this big gnarly goal and wanted to see me succeed.

It was getting close to the end of August and I could feel the time pressure of the closing climbing season. There had been some bad days with serious thunderstorms so we were waiting to choose a final climb day. As I looked at the weather for the following week, it looked like a good day on Tuesday. It was the first clear day in a while and there were not many after. On the one hand it could be busy, because everyone else like us had been waiting for that weather window, but on the other hand if we waited any longer we might miss our opportunity all together. So that Sunday Julius and I decided that Tuesday, August 27th, 2024 would be our summit attempt.

And so the night before we were going to make our attempt. I sent this one message to Julius.

His thumbs up response was all that I needed to know it was on.

Summit Day

1:45 am: Right on time Julius and I met in Lyons to jump in one car to drive up to the Longs Peak trailhead.

2:27 am: We start the hike from the Longs Peak trailhead via headlight in the pitch black.

4:34 am: We make it to Chasm Lake at a great pace and fill our water bottles in a small stream from the lake.

5:34 am: Arrive at the base of the North Chimney. Right on time as we just see first light on the horizon. There are headlamps in the distance from parties behind us.

6:01 am: Julius is leading up the first pitch of the North Chimney after traversing 20’ of icy snow using our nut tools as makeshift ice axes. There are two parties ahead of us and two behind. The rock is still ice cold and my fingertips are numb making it hard to tell if you have good purchase on the rock.

7:32 am: On Broadway ledge at the base of the Casual Route. Thank God! The North Chimney was as scary as people say it is, especially with two parties above us and loose rock crashing down. The echoing cracking sound the rocks make when tumbling down the narrow climb was a bit terrifying.

And now we wait… and wait… and wait some more. There are two parties ahead of us so we can’t really move until they are off the first pitch. The weather forecast today is perfect so we decided to stick it out, knowing that this may turn into a long day. The party directly behind us ends up deciding to bail, and the other party is climbing D7.

On the upside, while we were waiting I saw another party pop up from the North Chimney, low on Broadway. It was a woman and a man and they were moving very fast. I looked closer at the women who looked strangely familiar. And then it clicked. I yelled, “Hey are you Steph?” She looked up at me and yelled back, “Yes.” I smiled and yelled back, “Thanks for all the beta.” and all of the other climbers within earshot cheered. Every single one of us on that mountain owed Steph Abegg a bit of whatever success we had that day. (Steph’s D7 Trip Report)

The sun was starting to warm us now and feeling was returning to our fingers. We were ready to start the climbing on the Casual Route.

9:23 am: I finished leading the first pitch, which felt great. And then we waited some more, chatting with the party above us.

10:11 am: Julius begins to lead pitch 2. The climbing started to get harder here with the 5.9 finger crack pitch.

11:57 am: I finished leading the pitch 3 traverse. It was a bit airy, but fun. I was feeling amazing. Weather was perfect even at this point when we went into the shade. We put all our layers on and we were good to go.

1:04 pm: At the top of pitch 4 and Julius is leading like a beast. At this point Julius decides it is time to pass one of the parties ahead of us that is struggling.

2:29 pm: Hanging out at the top of pitch 5 on a comfy belay ledge. Starting to get a little chilly in the shade and the fact that we are at about 13,500’. At every belay as we waited I kept saying out loud how amazing the climb was. I was in awe of the beauty of the views.

5:10 pm: I just finished leading the last pitch (7) which is the traverse to Table Ledge. I look back over to Julius and he gives me a reassuring wave and thumbs up. He had led the crux pitch before this which was the hardest on the route. To our dismay, there was water flowing down the finger cracks leading into the squeeze chimney, which was also completely wet inside. I guess it was fitting because you had to do a sort of frog leg maneuver to squeeze yourself up and out onto the face. At that point, pull the crux move at 13,700’ and boom pitch 6 was complete. I was thankful I was not leading that pitch.

Now all we had to do was traverse over to Kiener’s Route, scramble to the summit and descend the long way back to the trailhead.

6:21 pm: We are almost to the top of Kiener’s when you have to make a couple of climbing moves at 14,000’ which was a bit taxing and exposed, but this would be the last of the technical bits of the day.

6:48 pm: We are at the summit!!! We find the survey marker and snap a photo. The sun is getting a bit low for our liking, but luckily the weather forecast was spot on and we have absolutely clear skies. The 360 views were absolutely amazing.

We are alone on the summit of Long Peak. I am feeling the joy of the moment, but we know that we still have a long way to go to get down.

7:28 pm: Julius gets tied in to the first rappel on the Cables Route. We start to rappel just as the sun is setting. The view is absolutely breathtaking.

7:57 pm: We make it down the rappels and are at Chasm View. We look across to the Diamond and see the party we passed just finishing pitch 6. I am thankful that Julius made the call to pass. They were rappelling back to the base of the Diamond that night, we would not have had that option.

11:46 pm: The hike down was long, my legs were burning and each step at the end was taxing, but in the end uneventful. As extreme exhaustion begins to set in with bleary bloodshot eyes we make it safely back to the car.

Car to car took us 21 hours and 19 minutes. We were exhausted.

We drove back home and when I crawled into bed that night I had been awake for over 24 hours straight.

The day was epic.

Reflections

Looking back on that day now I realize how much having that incredibly difficult goal helped me achieve so much more than climbing a mountain. The process of working toward that goal was so motivating and changed how I ate, how I exercised, how I pushed through my fears and maybe most importantly how I started to strengthen the relationships I have with my friends and loved ones. The person 8 months before that felt blah about their physical health and strength was a distant memory when standing atop that 14,259’ summit.

I am looking forward to setting more audacious goals in the future that will help guide me in retired life, but right now I am just being open to what those new goals might be.

What goals are you working toward? Is anyone looking to climb a mountain either literally or figuratively? I would love to hear about your journey and how the power of setting big goals (or small ones) have helped you in your life.

Brian

PS. I want to explicitly say a huge thank you to all of my friends and family who made achieving this goal possible. Specifically I would like to thank John for sparking this idea in me so many years ago, Thomas and Tommy for climbing and hiking training partners, LR and Nick for motivating me in the gym to climb harder, and my wife Stacy for supporting me and the family as I was off training at odd hours and getting me on the path of better nutrition and fitness. And last but certainly not least Julius for being my climbing partner on Longs Peak. I will never forget this adventure that we got to experience together.

Monday:

I woke up early (6:00 am) excited to get going on the first week of retirement and I felt great. My wife was not super pleased with my chipper good morning as this was still her last week of work. I read a bit, which I don’t normally do in the morning (finishing up Stranger in a Strange Land). My todo list was already growing and this was just day one. I had to do some errands, picking up food for my daughter's birthday party this weekend, got gas and a car wash, and went by the bank.

I met an old friend for coffee at a local coffee shop and it was great to connect. We talked a lot about the “Why” of deciding to retire. We also talked about the impact of AI on how we work and some of the tools that we have been playing with. There is a lot to unpack there and an exciting area I want to dive deeper in myself.

Had lunch with my wife, which is pretty typical for a Monday as I am usually working from home. Went on a walk, also normal. Once I got back I set up a laptop in my office and hooked it up to a big monitor so I could get a new productive space going. I’m sure this is something I will revisit as I want to do some development for fun and will need to get a new setup. I would love to hear from folks in the comments on what they are doing for dev environments these days. Laptop vs. desktop? Linux, Mac, Windows? What IDEs are people using now? I really want to check out Cursor, but maybe I should give Firebase Studio a try. I’ll be on the YouTubes to figure that out.

After I got my makeshift laptop setup going I started researching health care! Not the most fun thing, but I needed to get that going as coverage from Google only goes through the end of May. After the kids got home it was a pretty normal night, cooked dinner, had dinner with the family, watched some SNL, read with my younger daughter, and read a good essay from the former CEO of Wealthfront that a friend from work shared on transitioning from working.

Tuesday:

Pretty low key day, but a good one. Rainy outside so I didn't really feel like going out much. Worked on investigating health care for a while longer. Still haven’t made a final decision. Played the new Indiana Jones and the Great Circle game on PS5 which just came out recently. It was fun to sit down and have some time to play a game.

In the evening I had a great time watching my older daughter perform with the jazz and concert bands. It was cool to see her drum set skills on display and reflect on how far she has come in just four years.

Wednesday:

Taking advantage of being able to do what I want now during the day mid week I went to the climbing gym for a couple hour bouldering session. Sent a couple of routes I had failed on Sunday so that felt good. Was climbing with a friend who is recently retired, a year in after a long teaching career. He said it took him a while to get over the weekend mentality and wanting to pack it all in, which I am definitely still feeling.

A bit of anxiety when seeing goog drop 8% in a day over news from Apple using AI search results. Still need to minimize our Google exposure.

On the upside I got a new car today. 🙂 Looking forward to taking it into the mountains very soon.

I spent a large chunk of the evening researching brake controllers and what I will need to do the install so I can tow our camper with the new car. Maybe I’ll do a post on that in the future.

Thursday:

Observation from the morning is that my calendar is starting to get booked up, but all with things I want to do, not with things I have to do. Coffee with friends, climbing class next week, concerts for the kids, ... Only three weeks until we leave for our three week camping road trip in Southwest Colorado.

Had a great morning of coffee with a friend and then we just walked around downtown for a couple hours talking about how the heck you retire young and how to shift your mindset from the wealth accumulation phase of life to the wealth distribution phase of life. Gorgeous weather today!

Ran some errands around town. It turns out going to Target in the middle of the day on a Thursday is great.

The evening was a really special orchestra concert for my younger daughter. It was her last concert of the year, but sadly it was her director’s last concert as well. After a 30+ year career in music education she is retiring and this was her final concert. She is an absolutely amazing teacher who has really inspired my daughter and so many students to really thrive playing music with friends. I am so proud of both of my girls' musical journeys so far.

Friday:

Woke up refreshed! Had breakfast with my older daughter before she headed out for her second AP test of the week. She said she rocked her AP Stats test yesterday. I’m proud of all the hard work she has put into studying for these classes.

Sent out my newsletter for the week (will save this one for next week). I have been receiving some really great feedback from folks appreciating the emphasis on prioritizing family and that it is really resonating with folks. I appreciate the feedback as it definitely helps with the motivation to keep writing, though I am definitely learning that this is just as important for my own learning and self reflection as anything else.

I spent the rest of the morning with an old friend that I had worked with for many many years at Google. We met at the Trident in Boulder and chatted for over an hour over coffee. It felt like 10 minutes. I am absolutely loving these coffee chats, reconnecting with old and deepening connections with new friends. I am a deep introvert, but these one to one connections are bringing me joy and connection that I feared I could lose not being in a work environment. I know it will take effort and energy to keep these going, but I look forward to doing it.

Met up with my wife at a new, for us, pizza place in Boulder called Fringe, which was delicious. Did I mention it is her last day at work as well! I am so excited to be able to go on this “graduation” from work, as she likes to call it, together.

To finish off an awesome week Stacy had a going away party with folks from her work at Sanitas brewery in Boulder. It was great to see some old friends I had worked with on SketchUp almost 20 years ago! It was great to celebrate Stacy with so many of her colleagues and friends. I even ran into one of my former colleagues from Google and got to meet her dad who was in town for her siblings CU graduation.

Looking back on the first week of retirement I would say 10 out of 10 would do again. It was wonderful to connect with multiple friends, go to two concerts of the girls, and celebrate Stacy. I could see even in this one week a bit of letting go. There are so many opportunities to explore and adventures to be had.

In the end I guess I was surprised how easy it was to let go of the daily work routine and move into this new one. The week was surely unique, but hopefully not atypical of many exciting weeks to come.

Brian

The answer for me was actually pretty simple. Family.

I want to spend as much time with my two daughters before they graduate high school and leave the house. I want to have the flexibility to go to every school event. Take a month to go on a Colorado camping road trip this summer. Go hiking with the kids on a random Wednesday morning. Volunteer at their school. Go to every concert, every awards ceremony, every parent teacher night.

I want to be there for all the things.

It took me a while to realize the urgency of now. I read Die With Zero by Bill Perkins. It was a kick in the pants. One of the things discussed in the book was looking at your life in chunks of time, five or ten year chunks. I chose five and thought what will happen that's significant in my life in the next five years? Both of my daughters will graduate high school. Move out of the house! My mom will turn 80. Bam! It hit me like a ton of bricks. Am I spending enough time with them, can I be more present, what about this summer. What if I take the whole summer off? And next summer? How about the next 5 summers?

I started thinking about all the things that I wanted to do and how work was holding me back because I didn’t have enough time or sometimes energy to do them. So after a while of brainstorming all the great things I could be doing with my life I started to think…

After reading Die with Zero this led me down the path of reading a series of books that all contributed to how I was thinking about my life.

The next book I read was The Psychology of Money by Morgan Housel. This book really helped me with changing how I was thinking about and getting more comfortable with moving from the wealth accumulation phase to the wealth distribution phase, and that it was much much more than money and financial stability. It was really a great book about why we think about money the way we do and that it is a very different experience for everyone.

After The Psychology of Money I read Infectious Generosity which is written by Chris Anderson who is the head of TED. It was a great dovetail with The Psychology of Money and got me starting to think even deeper about a giving mindset and how to change your view from a wealth accumulation view of the world to a time and money giving mindset. Definitely some really interesting ideas in that book and one that I look forward to returning to now that I have a bit more time on my hands.

The next book I tackled was The Top Five Regrets of the Dying by Bronnie Ware. This was definitely the most emotional of the lot and reinforced the sense of urgency I was starting to feel after having read Die With Zero. The stories give you a sense of what is really valuable in people’s lives when things come into focus with the acute time pressure of being on death’s door. And it turns out no one, not a single person, said I wished I had worked more.

The last book I read was Taking Stock by Jordan Grumet who was a hospice care doctor. This book was a bit of a mix of Bronnie Ware’s book and Morgan Housel’s book. The biggest thing I think it added to the others were some really good exercises at the end of each chapter that help you more deeply explore many of the questions that come up when thinking about retirement. Specifically for me the questions around finding purpose after work was a big unknown for me, and still is, but the exercises started to help me explore what mattered for me.

I read all of these books in 2024 and that set me on the path toward retirement. I had read some retirement and financial related books before these and there were some after, but these were definitely a turning point for me in my thinking. There was much more to do between reading these books and retirement, but I was well on my way to answering the question of Why Now? And for me, the answer was family.

Brian

Monday:

I usually work from home on Mondays so I had a pretty regular day with my last weekly staff meeting. I packed up my computer and monitors from home and got them ready to bring into the office on Tuesday.

Tuesday:

I brought in my computer and monitor from home to drop off then headed over to the University of Colorado campus to do a guest Q&A for an undergrad Human Computer Interaction class. We discussed everything from interviewing at Google to the impact of AI on the software engineering discipline. The students had great questions and it is always energizing being on campus again.

Wednesday:

Had a 30 minute virtual going away video conference call for all of the folks that are in other offices that wanted to say goodbye. It was really special to see folks that I have worked with over the years. Many shared stories of early memories and how I would be missed. Though virtual going aways are always a bit awkward, it was touching to hear from so many long time colleagues.

Thursday:

Finished the day with an in person going away party at the Rayback in Boulder. This has become a bit of the Sports Page of Boulder for the number of Googler going away parties it has hosted over the years.

Friday (My last day at Google):

This was it. Final day. I started the day with an early morning climb with Thomas to start things off right. I went into the office, which I don’t always do on Friday’s, but hey, thought I should on the last day. Read my last few emails. Got approval for my last CL, removing myself from the geo/OWNERS file (after Yatin had me clean up a couple things “while I was in there”). Didn’t really have anything else on the schedule other than a nice final lunch with former teammates, one last free latte, and needing to drop off my badge and laptop. The question was how can I get from where I need to drop off my badge to where my car is parked without a badge. Thankfully Melody was in the office on Friday.

Leaving the office was emotional. “The Google Office” was a special place. And I mean it more than just the Boulder office I just left, because I have been in many buildings there. If you ask any Googler that has traveled to any Google office in any city around the globe, they have had the same experience as I have where they walked up to the door and looked down at that badge reader glowing red on top, swiped their badge and the light turned green, stepping inside into a familiar and comforting world of The Google Office. I will miss that welcoming feeling of being a Googler. And as I stepped out that door, I left The Google Office behind.

The drive home was emotional.

19 years and 53 days. 2,806 CLs, 65 unique direct reports, 9 managers, 6 different buildings (all in Boulder), 75 trips to Mountain View, … And just like that, it was over.

Brian

It’s a profound moment, stepping away from a place and a role that has been such a significant part of my life. I'm immensely grateful for the challenges, the growth, and especially the people I had the privilege to work with.

Now, I find myself navigating a different kind of map – the transition into retirement. It’s a landscape filled with excitement for what lies ahead, mixed with the healthy unknowns that come with any major life change. It feels a bit like stepping up to the base of a challenging Colorado climb – you’ve prepared, you’re excited, but you also know you won’t figure out the precise route until you get going.

So, what am I looking forward to on this new trail? Definitely more time exploring the incredible Colorado outdoors that I love – hiking, camping, and finding new routes to climb. More space to be curious, learn new things, and simply be. But most importantly, more precious moments with my wonderful wife and two daughters.

Consider this space, Changing Coordinates, my digital basecamp for sharing this journey. I plan to write about:

• Navigating the shift from a demanding tech career to retirement.

• Reflections and lessons learned from my time in software engineering and leadership.

• Adventures (and misadventures!) in the mountains and beyond.

• Exploring new interests and figuring out what’s next.

If you’re curious about life after big tech, the retirement transition, leadership insights, or just enjoy tales from the Colorado trails, I’d be delighted if you’d subscribe and join the conversation.

Thanks for reading, and I look forward to sharing what’s around the next bend.

Brian

Leave a comment

Subscribe now