I’m traveling soon, so I had my Hermes agent set up a service to email my roommates when my plants need to be watered. Each plant has its own personality and requests watering in its unique voice, including the amount of water it wants, which measuring utensil to use, and a photo of the plant. Most of my plants need to be watered on a once-per-week cadence, so the service collapses them into a single digest when multiple plants need watering on the same day.

Before I handed the work to Hermes, I used Claude Code to spec out the idea and create the initial prompt. Hermes built the service from there. It sends emails through its dedicated Gmail address, and when my roommates respond with what they've watered, it updates accordingly. For example, you can say "already watered everything yesterday except the calathea and the laurel fig," and it'll acknowledge your message, send a reminder in a couple of days for the two you missed, and reset the clock for everything else as of yesterday. Hermes also tries to keep as many plants as possible on the same watering day. If most plants get watered the same day but a couple of them get watered a few days late, the service will request an early watering for those plants the following week, on the same day as the rest of the plants. If a specific plant isn't very moisture-tolerant, the service will skip a watering for that plant until it resyncs with the main once-a-week schedule.

I recently set up a Hermes Agent because I wanted to see what the hype was all about with personal AI agents. In a rare case where keeping old electronics worked out in my favor, I used my old college-era MacBook Pro. I must have been doing something weird with it when I last used it because there was no OS installed on the machine. For some reason, booting the Mac in recovery mode only allowed me to download macOS Mavericks, the OS the machine shipped with when it was made in 2014. From there, there was no option to update to a newer OS, despite the fact that the machine ran on Catalina when I abandoned it. I ended up downloading Ubuntu onto a USB stick from another device and installing the OS from the stick.

It took a bit more finagling to get the machine usable. The Linux keyboard shortcuts felt unnatural to me, so I found Toshy, a package that maps macOS keyboard shortcuts onto Linux. That made zooming around between terminal tabs a lot easier. The MacBook also had some weird network and heat issues at first while running Linux. Wi-Fi speeds were incredibly slow, so I had to install a new Wi-Fi driver, and I used Codex to write and test some custom fan logic so the fans would ramp up sooner in response to heavy CPU loads to keep the machine from overheating.

To get Hermes on equal footing with my other machines, I had it clone my cloud dev env repo and run all the same setup steps that project does when provisioning a new VPS. That gave the Hermes machine all the basic tooling I have everywhere else without me having to configure anything by hand.

So far I haven't used Hermes for much, but I did set it up with the LLM-memory system Honcho (by Plastic Labs), and it was cool to just message Hermes on Telegram and tell it to figure out how to set up Honcho. I've also been helping a friend set up a personal website, and when they sent me an email with some updated copy, I had a pretty cool moment just forwarding the email to Hermes and telling it to update the site accordingly.

Once GitHub auth completes (for the gh CLI), the VPS clones an explicit allowlist of my repos into the same grouped-parent worktree layout I use locally: a primary checkout plus a linked worktree for each unmerged remote branch. There's a land-task script available to agents as the single sanctioned path for merging PRs, and a prune-landed script removes worktrees and local branches once their PRs land.

I was initially motivated to set up this cloud dev environment for basic security reasons. I wanted to run my coding agents in YOLO mode and not think twice. If something goes wrong on the VPS, I can nuke it and replace it, or move it to a different cloud provider. I've mostly been using it for convenience though, SSH'ing in from my phone (using the Termius app) so I can work on the go.

One of the major trends right now in tech is that software is becoming highly bespoke, especially for the individuals using coding agents the most. But I'm not so sure that this trend will continue with cloud development environments. They will undoubtedly grow like crazy in the coming months, but their growth might have more to do with local hardware constraints than security concerns. If my main coding agent thread wants to spin up 100 subagents, I could hit the constraints of my device really quickly. But if the main thread is on a VPS that can spin up subagents in other VPSs, then the problem goes away. I think it's fairly likely that someone will figure out a way to productize this workflow in a way that's good enough for most developers. And many software businesses may be willing to pay for that product.

Shortly after launching this site, I grew frustrated with the framework I used to build it: Gatsby. The team behind Gatsby released v4 weeks after I finished the site, and migrating from v3 didn’t look simple. When I built the site, Gatsby and Next.js were the obvious choices for a pre-rendered React static site with blog posts in Markdown. Next.js also had SSR^[1], and according to NPM Trends, it had roughly four times the daily downloads of Gatsby. I didn’t view that as a decisive difference; since Gatsby felt slightly more geared toward pure static sites, I went with it. You can see the rest in the chart below. By today's numbers, Next.js is on another planet. That matters because code that gets used gets maintained. Gatsby's plugins eventually drifted out of sync with each other and with the core. Next.js was the better bet.

I kept telling myself I would migrate off Gatsby, or at least upgrade to v4, but I never got around to it. A few weeks ago, I transferred my domain’s DNS management to Cloudflare and decided to move from Netlify to Cloudflare Pages in the process. Cloudflare Pages requires Node.js v22. Gatsby v3 doesn't run on it. Claude upgraded the project to v5 (the latest version of Gatsby) and all its dependencies to Node.js v22 compatible versions in about 15 minutes.

Fast forward a couple of weeks, and I read A Desktop Made For One, in which the author notes that coding agents have enabled him to build custom software for nearly all of his personal computing needs. That got me thinking. Although I should have initially chosen Next.js over Gatsby for this site, Next.js is by no means the perfect fit for this site. It’s excellent for getting projects off the ground, but it does far more than most projects actually need. I didn’t just migrate my site from Gatsby to Next.js. Instead, I custom-built the specific functionality this site actually uses.

Here's what I did, roughly in order:

• Replaced miscellaneous Gatsby plugins (fonts, analytics, tweet embedding, SEO) with direct implementations.
• Replaced Gatsby image plugins with a custom pre-bundle pipeline built on sharp (the library behind the image plugins in Gatsby, Next.js, Vite, and Webpack), plus a custom React component to replace Gatsby's lazy-loading image component
• Swapped Gatsby's internal routing logic with React Router
• Migrated off Gatsby's GraphQL build-time queries with custom content injection
• Replaced Gatsby's MDX (Markdown w/ JSX) parsing with a custom script
• Decoupled entirely from Gatsby by migrating to Vite, which handles TypeScript transpilation, bundling, and the dev/build server

But then I asked myself: why stop there? Sure, Vite is popular, but do I really need it just for its "lightning fast HMR" dev server? If I were building an enterprise application, perhaps. But for a personal blog? No.

So I kept going:

• I replaced Vite with esbuild for transpilation and bundling, plus custom pipelines for CSS and MDX.
• Set up a custom Static Site Generation (SSG) script to run after the bundle (formerly handled by Gatsby)
• Set up code-splitting and link prefetching (formerly handled by Gatsby)
• Added caching for the image and content pre-bundle steps
• Simplified the project's linting and formatting config
• Ditched Bootstrap in favor of plain CSS
• Dropped the react-icons dependency and inlined the handful of icon SVGs the site needs.

Here's what my dependencies looked like before and after this project:^[2]

And here's what my scripts look like:

The net result is that I have more ownership over my site. Literally, it depends on less code that I don't own.

This project reminded me that coding agents are the ultimate abstraction. You no longer write the code; you simply define what you want the code to be. In the past, we reached for all kinds of abstractions because they reduced the cognitive load required to ship features. Now, we have coding agents. They render many other abstractions obsolete. The path of least resistance is no longer a thick wrapper around React. It's a spec — and an agent that implements it.

This project barely scratches what coding agents can do. Yet, it may be a preview of what is to come: more custom-tailored code that's resilient to the drift of dependencies that reinvent themselves or go unmaintained. On the other hand, none of us know what the future holds. In coming months, we may find that this kind of work is merely tinkering. Junior engineers and non-technical builders are having great success shipping fast with coding agents. Unencumbered by mental models of how things ought to be, they simply trust the LLM. That may matter more than the stack.

Notes:

1. Gatsby supports SSR now as well, since v4.

2. The one thing I dropped in the process is the site's PWA setup for offline reading, formerly handled by gatsby-plugin-offline.

For very wealthy buyers, the $750k cap is a problem. If you want to buy a $10M house with a $2M down payment and an $8M mortgage, interest on less than 10% of the loan is deductible. But, for cash-rich buyers, there's an easy way to recycle this debt into a fully deductible form, even for your third, fourth, or fifth home. First, use delayed financing, meaning you buy your home in cash, then mortgage it. Take the funds from the mortgage and invest them in equities (or other securities), and now, for tax purposes, the full value of the mortgage is considered a margin loan. Interest on margin loans is fully tax deductible.

Voilà. You have successfully recycled your debt. The same strategy can be used when doing a cash-out refinance. If you invest the cash, then interest on the new mortgage is fully deductible, no matter the size of the loan.

I built a simple tool here that shows how much you stand to save over time by debt recycling your mortgage. At the moment, it's just a static site. If it gains some traction I'll add accounts, with the ability to save and share plans.

Because most mixed-use multifamily sales are valued in a similar fashion to one another, Bowery's web app has a good deal of automation built in for generating these reports, and its appraisers can complete appraisals on these properties more efficiently than its competitors, leading to higher operating margins. But just as turbo-tax loses its edge as an individual's taxes become more complicated, Bowery's appraisers are less efficient when using the web app to appraise different types of properties. The same problem exists for properties outside of the New York metro, where local business practices and state regulations require different types of information in a given appraisal. Some properties, such as marinas and golf courses, are appraised infrequently enough that there is little value in creating new features to speed up the appraisal process for these specific property types within Bowery's web app. On the other hand, there are key growth opportunities in efficiently appraising common property types such as warehouses and office buildings. Furthermore, we want to enable appraisers across the US to appraise properties on the app as easily and efficiently as appraisers in our home market of New York.

To lay the groundwork for this business objective, I recently lead a project to make Bowery's web app more flexible for different property types and new geographies. The work addressed the fundamental unit of an appraisal: square footage. As it turns out, different properties types and different regions of the US call for different methods of measuring square footage in an appraisal. The standard way to measure it in a mixed-use multifamily is with gross building area (GBA), which is the sum of the footprints of each story of the building. The footprint is calculated from the exterior walls of the building, so GBA is strictly greater than the inhabitable interior area of any given building. Other common metrics used in appraisals include gross leasable area (GLA), net rentable area (NRA), and net leasable area (NLA).

This project had 3 requirements:

1. enable appraisers to select from a list of square footage metrics to base their appraisal on, specifically GBA, GLA, NRA, and NLA, while maintaining GBA as the default option
2. update computed values throughout the appraisal that depend on the value of the square footage
3. update generated text in the appraisal report to reflect the square footage metric being used

Before jumping into the details of how I created this feature, let me give a broad overview of what the system architecture looks like. We have a monolithic app with four different teams committing changes to it. The front end is written in javascript (using react) and is a series of interrelated forms organized into different sections that map roughly to the sections of an appraisal report. There's one section for basic property information, such as the address and square footage, and another section for recording the occupancy status, rent, and additional information about the building's units (if applicable). There's also a section for quickly identifying comparable sales, another for building a valuation based on those comps, and another for building a valuation based on the projected cash flow of the property. The frontend talks to a NodeJS backend with an Express API (javascript), and we're in the process of migrating it to NestJS (typescript). We use a MongoDB database, and our ODM models (mongoose) are fully migrated to NestJS, which means they have the added type-safety that comes with typescript. The backend also talks with various public APIs to automatically collect property information from state- and city-run data sources like New York City's PLUTO (Primary Land Use Tax Lot Output).

The forms the appraiser fills out in the app produce a MongoDB document associated with that appraisal. The document is continually updated and returned to the frontend as the appraiser saves their progress, where its value is held in the client's state using redux. It looks something like this:

{
	_id: object id
	report_generated: timestamp
	report_updated: timestamp
	appraiserId: int
	clientId: int
	latitude: double (i.e. floating-point number)
	longitude: double
	street1: string
	street2: string
	city: string
	state: string
	zip: int
	...
	...
	...
	GBA: int
	...
	...
	...
}

As you can imagine, there's much more information contained in an appraisal than I'm showing here, including many nested documents containing details about the property and the process through which multiple valuations of the property are determined, as well as custom text the appraiser wants to include in their appraisal report. In this example, the GBA (gross building area) lives at the top level of the document object, although in practice it lives in a nested document. When the appraiser finishes filling out all the required forms in the app, they'll see a button prompting them to generate a report. This sends the appraisal document to an appraisal-generation service written in C# that outputs a formatted word document as the (nearly) final deliverable for the appraisal client.

Alright, so now that we have the architecture out of the way, let's jump into the details of how we implemented this feature. The first challenge was deciding how to store different square footage metrics in the mongoDB document, keeping in mind our intention to design the feature to easily accommodate additional square footage metrics in the future.

The final changes looked something like this:

{
	id: object id
	report_generated: timestamp
	report_updated: timestamp
	appraiserId: int
	clientId: int
	latitude: double
	longitude: double
	street1: string
	street2: string
	city: string
	state: string
	zip: int
	...
	...
	...
	GBA: int
	squareFootage: int
	squareFootageMetric: string (default: 'GBA')
	...
	...
	...
}

We added two new fields: the integer squareFootage and the string squareFootageMetric. You might be wondering why we didn't remove the GBA field while we were at it. The reason for this is that there are two calculations that rely on GBA in every appraisal, even if the valuation conclusions are based on some other square footage metric. These two values are peripheral to the main conclusions of an appraisal and the details behind them are beyond the scope of this post. That said, they added complexity to the project because they required the app's forms to always collect GBA, and to optionally collect either GLA, NRA, or NLA. Fortunately, having the GBA field present actually helped my team implement the code changes in a piecemeal fashion that avoided merge conflicts in areas of the code that other teams were working on.

As I mentioned earlier, our database models are already migrated to NestJS, which means they have the type safety provided by typescript. As a result, we could constrain the field squareFootageMetric to the following subset of the type string:

enum squareFootageMetrics {
	GBA = 'GBA'
	GLA = 'GLA'
	NRA = 'NRA'
	NLA = 'NLA'
};

In practice, we didn't actually use an enum. It's a typescript feature that I avoid. Much has been written on the topic, so I won't dive into the details here. Instead of using an enum, we constrained squareFootageMetric with a dynamic type generated from an object. The general consensus in the typescript community for working around the use of enums is as follows:

const squareFootageMetrics = {
	GBA: 'GBA',
	GLA: 'GLA',
	NRA: 'NRA',
	NLA: 'NLA',
} as const;

// the following generates type squareFootageMetricsType = 'GBA' | 'GLA' | 'NRA' | 'NLA'
type squareFootageMetricsType = typeof squareFootageMetrics[keyof typeof squareFootageMetrics];

Now that we had updated the data structure, I created a data migration to adjust existing records. It took every existing appraisal document, set appraisal.squareFootage to the value of the appraisal.GBA field and set appraisal.squareFootageMetric to 'GBA'. With the data migrated, the next step was project requirement #1: to enable appraisers to select from a list of square footage metrics to base their appraisal on. The existing app included a form field like the following:

GBA:

I created a list of radio buttons above this input asking the user to select the square footage metric they want to use for their appraisal. The default selection for the list is GBA, and the options are created dynamically from the array Object.values(squareFootageMetrics). Since squareFootageMetricsType is also created dynamically from squareFootageMetrics, we can easily add additional square footage metrics to the system in the future with a single line of code. If the user selects a radio button other than GBA, then an additional form field underneath GBA appears. The GBA input is required, and the second input is required if showing. It works like this:

Try the interactive version on the site.

When the page is saved, the radio button selection sets the value of appraisal.squareFootageMetric, the first text input sets the value of appraisal.GBA, and the second text input sets the value of appraisal.squareFootage. If the second text input is null (which occurs when the GBA radio button is selected), then appraisal.squareFootage is set to the same value as the appraisal.GBA.

The last stage of development, where the bulk of the code changes actually occurred, was to change ~30 values downstream of a property's square footage and the basis for determining it (GBA, NLA, etc.) in a given appraisal. My team uses a JIRA Kanban board to track and coordinate our work, so I created an individual ticket on the board for each required downstream change. Note that I also broke down the aforementioned work into tickets, and I classed all tickets for this project under the same epic.

For the downstream changes, there were 3 types of tickets:

1. changes to the generated text in the outputted .docx appraisal report: these involved changing a hardcoded string such as 'GBA' to a dynamic template string like `${appraisal.squareFootageMetric}`.
2. changes to a computed value: these involved changing a piece of frontend or backend code such as:
   const pricePerSquareFoot = appraisal.valuation / appraisal.GBA
   to:
   const pricePerSquareFoot = appraisal.valuation / appraisal.squareFootage
3. changes to a computed value and a string value: these involved the process mentioned in #2 and an additional change to some associated frontend string value such as:
   "The unit's portion of total building area is unit area divided by GBA"
   to:
   `The unit's portion of total building area is unit area divided by ${appraisal.squareFootageMetric}`

As I mentioned earlier, because we didn't remove the appraisal.GBA field from the MongoDB document, we were able to implement these changes in a piecemeal fashion. Each change was isolated from the others, so we made a single branch and pull-request for each ticket. This made for quick turnaround times on code reviews and also enabled us to prioritize certain changes ahead of others. In some cases we would make a change to a specific form quickly if we knew another team was about to start working on that form. In other cases, we could wait a few days to touch a specific form while another team finished up and merged changes to that form. This naturally gave our team an incentive to review certain pull-requests quickly in order to speed up our own work. At this point in the course of the project I effectively stopped coding. My time was spent most effectively by coordinating my team's work around the work of other teams and by quickly reviewing the pull-requests my team members were opening.

Overall the process went smoothly. One of the hiccups we ran into along the way is that we found about 10 additional downstream values that needed to be changed. Our design team found about half of them and our engineers discovered the other half. I had already given estimates of our timeline before these tickets were added to the epic, but I was careful to communicate that strictly the engineering work (excluding QA, design, and product reviews) would be done for the existing tickets by a specific date This made it easy to update our self-imposed deadline when additional necessary changes were found. I just made ~10 new tickets and shared a new deadline for those tickets. Communicating this way turned out to be one of the most important decisions I made during the process as it prevented my team from getting stuck in a time crunch to hit a deadline.

Ultimately, the implementation of this feature is straightforward and easy to communicate. This is the aspect of the project I'm most pleased with. Without a well thought out plan for its architecture and implementation we easily could have ended up with a hacky, complex solution that would need reworking in the future. Bowery's web app now has a simple way for an appraiser to change the basis of a property's square footage calculation, and it has a trivially easy way for developers to further increase an appraiser's flexibility in this regard. This directly aids Bowery's operational efforts as it expands its business model to new appraisal types and geographies.

Special thanks to Shuvo Rahman, who helped plan the changes to the data structure.

• Navigate around the site, and see if your browser ever indicates that it’s loading
• On the home page, switch to dark mode and refresh the page while keeping an eye on the banner and favicon
• Turn off your internet connection and see if you can still navigate around the site
• Check out the mobile site if you’re on desktop (or vice versa)

The site’s features include:

• Fully responsive design
• Lazy-loaded images
• Optimized image resolution for different screen sizes
• Progressive web app functionality with offline navigation
• Light and dark mode
• JAMStack setup with GraphQL
• Google analytics integration

At the time of writing there’s still a few kinks to work out, and I’m sure I'll add some features and/or tweak the layout over time, but things are mostly good to go. I built this site with TypeScript, React, and Gatsby, and I deployed it with Netlify. You might ask, "Why use TypeScript for such a simple site?" Well, I had never used TypeScript before and I wanted to learn how it works. I used Bootstrap 5 for styling, and chose not to use it with react-bootstrap. Since Bootstrap 5 no longer uses jQuery, react-bootstrap is partially redundant. Plus, when I started this project, I already had experience using React style components (using Material UI) so I used this project to learn the authentic form of Bootstrap.

I had multiple false starts on this project. For instance, I considered using a Gatsby starter but after beginning development on one, was frustrated to discover it was using v2 of Gatsby. I wanted to be using the latest major release. Attempting to migrate the project from v2 to v3 was a headache, so I started the project over, and this time from zero. Literally, with npm init -y. I had a heck of a time figuring out all the configuration and adding packages one-by-one, but in the end I may have learned more from the setup alone than from the process of building the site. This gives me confidence to work on more complex projects in the future that don’t or can’t rely on common boilerplate like create-react-app. While getting everything set up, I learned to use a number of useful packages and tools including nvm, react-helmet, and bootstrap-dark-5 (enables bootstrap with dark mode). I also learned how to persuade ESLint and Prettier to cooperate with eachother with the help of eslint-plugin-prettier.

Before I continue, it's worth mentioning that this site’s core functionality is blogging. As noted in the site features list, I used a JAMStack setup. This makes creating new posts extremely easy. Making a new post is as simple as dropping a new markdown file in the appropriate directory and adding a few lines of frontmatter at the top of the file. Frontmatter is just data associated with the post such as the title, date, and slug (URL endpoint). Frontmatter is formatted as a YAML object and placed before any markdown content in the file. It's useful because Gatsby can query it with GraphQL and then use it to programmatically create content on your site at build time, including stylized links to posts and the posts themselves. This is a key point to keep in mind. Gatsby is a static-site-generator, meaning that the site contents are generated at build time. Gatsby doesn’t allow you to use GraphQL queries during runtime.

A cool feature of this site is that it uses MDX, which enables the use of JSX inside markdown files. With MDX, you can import react components at the top of a markdown file and use them later on in the file. I created a custom MdxImage component to handle images in markdown files. There are a few Gatsby plugins (all forked from gatsby-remark-images) that simplify using screen-size-optimized images in markdown files with markdown formatting, but none let you define a max width for individual images. By default these plugins make every image take up the entire width of the container they’re in. That bothered me, so I created a custom react component. In the future, I may write a post specifically about the MdxImage component since I know I’m not the only one frustrated with the lack of functionality from gatsby-remark-images.

Other than the JAMstack setup, I got into the weeds on a number of topics while working on this project and was dogmatic about some things (e.g. preferring margin over padding) to ensure future site maintenance is as straightforward as possible. I realized some interesting things while in the weeds, including that using an svg favicon with built-in dark mode is difficult if not impossible on Safari. If you don't know what I'm saying, take a look at Github's dark mode favicon on Safari versus its dark mode favicon on Chrome. On Chrome, the favicon changes color in dark mode. On Safari, the favicon just gets a white background in dark mode.

Another interesting thing I realized is that TypeScript has a difficult time working with the Array.prototype.reduce() method when it's passed an empty object as its initial value. I realized this while creating the display for the Thoughts page and the Projects page. On both pages, the headers are numeric years and each header sits above a list of posts from that given year. The display will only render headers for years in which there were posts. So, for example, if for some reason I only had posts on my site from 2021 and 2005, those would be the only two headers and there would be no intermediary headers for 2006-2020. To create this display, I intially utilized the Array.prototype.reduce() method. This approach was unnecessarily complicated and I ended up changing it later on, but the lesson I learned in the process is worth mentioning.

My approach started with a GraphQL query to get all the posts for either the Thoughts or the Projects page. The query would return an array of objects where each object included a post title, date, and slug. From here, I wanted to break this array into sub-arrays, one for each year in which there were posts, and then store the sub-arrays in an object. In case that's confusing, I'll state it another way. I took the return value of the GraphQL query and I used reduce() to loop through the array of objects while creating a new object with the following structure:

{
  2021: [
    { title: post1title2021, date: post1date2021, slug: post1slug2021 },
    { title: post2title2021, date: post2date2021, slug: post2slug2021 },
    … ],
  2005: [
    { title: post1title2005, date: post1date2005, slug: post1slug2005 },
    … ],
  …
}

With this object in hand, it's easy to render headers for only the years in which there are posts. For a simplified version of how I used reduce() to create this object from an array, check out the answers to this question on Stack Overflow. The approach works by passing the method an empty object as an initial value. The reduce() method then makes iterative changes to the empty object, ultimately returning a non-empty object. This means that the object has a type of either someObjectShape | {} or Partial<someObjectShape>.

In either case, this causes TypeScript errors. TypeScript looks at the return value of the reduce() method and notes that it could be the empty object {}, despite the fact that I know it can't be an empty object if the aforementioned GraphQL query is set up correctly. Given that the object could be empty, TypeScript determines that any values that depend on the properties of the object could therefore be undefined. This is the root of the problem. TypeScript won't accept the possibility of an undefined (or null) value unless it is explicitly stated as a possibility in a variable's type declaration. This is TypeScript's strictNullChecks rule, one of the key rules in TypeScript's strict mode.

As far as I know, there’s no way to fix this issue^[1]. You could turn off strictNullChecks or, for every variable that depends on the object's properties, use optional chaining or append |undefined to the variable's type declaration. None of these options are acceptable solutions though as they negate the benefits of using TypeScript strict mode in the first place. My advice is to simply avoid using Array.prototype.reduce() with an empty object as an initial value. And for that matter, avoid using an empty array as an initial value as well.

So, while I ultimately decided against using the approach discussed above, getting to the bottom of the issue taught me a bit about how TypeScript works. This process of learning by doing is exactly what I set out to do when I began this project. Building this site was an enjoyable challenge, and I hoped to fill it with original thoughts over time.

Notes:

1. In hindsight (as of 2022), there is a very clear way to fix this issue. The cleanest solution is to type reduce()'s output with a generic, so the compiler knows the shape of the accumulator from the start. See here. If you'd rather, you can also reach for a type assertion, the developer's way of telling the TypeScript compiler "You think the type is x, but treat it as y, because I have special information you do not that guarantees this type will always be y, never x." Assertions should generally be avoided though, since they silence the compiler rather than informing it, and they're often used where a plain type declaration would do. So, contrary to my advice above: the reduce function is awesome, I use it often, and I recommend it even when the initial value is an empty object or array.

Credits: The inspiration for this site comes from this essay by Patrick McKenzie.