Sometimes we will have a huge stack of changes one of us is "finished but not clear to merge".

either:

- We just swap ownership of the branches and eng 2 now commits directly in branch 1. We review the final content together and typically pull in a 3rd person to review our combined work. Eng 1 either pairs with eng 2 until its finished or starts on a task that is decoupled from those changes.

- We use an integration branch that gets threated like the temporary master branch until the feature is ready to merge.

We need some new layer to handle things that used to be abstracted away by UIs

- filter to 6 of 50 fields for the paginated pipeline views

- show all the important fields on a detail view

- organize for understanding of fields that might have been poorly named in the public APIs

Some of this can be handled by a CLI wrapper around an API, but it really just shifts the complexity into a different system.

One thing that I haven't heard a lot of people talk about is that MCPs are often able to be far more flexible than a traditional REST api. You can ship breaking changes/renames and agents will adapt. Why should we couple the agent tooling locked 1-1 with our calcified systems?

I explicitly tell it about the skills and that it should load them when the context feels correct.

```prompt.md

Company Name codebase ...

# Skills

Use the company specific skills that look like `company-*`. Load them once per conversation if they seem relevant to what you are working on.

```

```SKILL.md

---

description: Company TypeScript libraries and conventions

trigger: Writing or reading TypeScript in Company services ---

# company-ts

```

Node to node mesh communication is cool and it works surprisingly well at small scale, but the moment we brought high powered repeaters online the difference was night and day. Coverage, reliability, and usability all jumped instantly.

It makes the tradeoff really obvious. Mesh is great for bootstrapping and local traffic, but once you care about real data propagation at scale, centralized infrastructure wins almost every time. Airtime is scarce, coordination matters, and having a small number of well placed high sites beats thousands of mediocre relays.

I still think there’s room for novelty P2P protocols, but mostly as an optimization layer on top of infrastructure, not as the foundation. Every time you push on this problem hard enough, you end up rediscovering the client router model for a reason.

The alternative of midtown/queens hotels are typically still $200-300, but cost more in travel time/expense.

My gripe here is mainly that before I could plan an outing for group and we could all live in the space and have common areas for eating/relaxing. Even if hotels were the same price, they still are a worse experience than staying in a house/apartment with friends.

I had previously been planning yearly trips to visit NYC with friends. For the last 3 years with Airbnb and I was booking 2-4 bedroom places for between 3-6 people. The cost per person per night jumped from ~$75-150 to $150-250 depending on the week. :-O

I'm also surprised we don't see the utilization of some GD&T style language to specify design intent. (https://www.gdandtbasics.com/gdt-symbols/)

For the problem of:

"I have a design I would like produced. Please make it like this please."

I couldn't imagine giving a machinist or welder a drawing containing no annotations. (This would be something an intern does once and the shop calls them up to tell ask them questions about what they actually need for 45min. Probably sending them back to rework it)

Pulling from the mechanical world:

  * make 3d models (equivalent to HTML/CSS components)
  * put 3d models into an assembly (HTML components together on the page)
  * make variations of the assembly to show range of motion (variations on user activity)
  * make "drawings" that contain components that are broken down to the smallest practical level (this would map to: modal, tables)
    ** in software these are usually managed similarly to Spreadsheet tabs
    ** this would contain a reference to the 3d parts + dimensional annotations. This means updating the assembly/part geometry automatically updates the drawing
  * anytime significant changes are made, issue new "Revisions" of those "drawings" are committed, issued, and then sent to the shop
  * 3d modeling software has change management systems so you'll automatically know if your proposed changes to a 3d part will break a drawing or assembly that depends on it

I spent a couple of months learning and working on projects in my free time. A consistent theme was getting stuck on a concept or bug and having no feedback to get past it. (Either, "give up, move on, come back to this later" or "oh, fix this one thing and its done".)

I guess, I could have made the transition without an immersive program, but I'm sure my outcome would have taken more time, had a lower starting salary, and eventually more cost money.

Retrospectively, there was $30k post-tax in opportunity cost of not working at a Mechanical Engineering job (bay area) for 6 months and the $22k tuition.