Cory House

10 lessons I've learned about handling React state over the last 7 years... (thread) #react #reactjs

Habit: 1. Claude opens my PR and creates a big, needlessly wordy description. 2. I whittle the giant description down to a couple short bullets so it's friendly to the reviewer. This helps me validate the changes are what I expected, and assures I understand the summary.

@mikeldking "Move integration tests to post merge hooks." What's your process when a test fails post merge?

Over the past 6 months we've maniacally prepped our repos to be coding agent friendly. Here are some things that worked. 1. Make CI blazing fast. Use every Rust, Zig, or Go ported tool that lets agents verify their work. This means UV, oxfmt, Typescript 7. Move integration tests to post merge hooks. 2. Trigger coding agents automatically based on triage labels. A coding agent should setup a proof of concept or repro steps automatically so an engineer can pick up the issue seamlessly. 3. Setup crons for things devs hate doing. Setup agents to fill SDK gaps, skill tuning, filling in critical regression checks. 4. Give agents ways to prove their work. Add screenshotting skills, agent-browswer, cloud storage for storing assets. 5. Make it possible to hermetically deploy your app, preferably multiple at a time. If a coding agent can deploy the app locally, the faster it can work. 6. Give the agents realistic production "simulation" data. Agents will work much better when they are working against data that looks like how your users use the product.

@JimG_Patriots @mattpocockuk Yep it’s handy

@housecor Try the /grill-me skill. @mattpocockuk

Habit: When I have a goal, but I'm unsure what approach is best, I ask AI for options and tradeoffs. Example: I'm working in a new test framework. So I asked: "I want to run one test instead by itself. What are my options and the tradeoffs?"

@normal_brandon1 Exactly. I prefer this over dedicated QA

@housecor In my shop, which is pretty mature, there is no dedicated QA people. There is a QA process which means one other dev needs to QA your work (and you need to be available to QA other devs' work). I think it's better that way.

If you were running your own software dev shop, would you hire dedicated QA?

@Snaggle97776422 What makes one good?

@housecor yes, good QA are worth their weight in gold

@jamesbender Define pure

@housecor I would hire a QA automation engineer with some good “pure” QA skills

@HelpfulAIGuy Would they be required to collab with devs also writing tests?

@housecor Yes I would. I would make sure they could write automated tests, but I would.

@MOOOOrion Agreed, but instead of separate QA is a separate dev sufficient?

@housecor Yes. You can't proof-read your own writing.

@0xPooka What’s a QA dev?

@housecor Dedicated QA? No. But I do think QA devs are some of the most well positioned to work with AI and actually deliver high quality results

@lets_make_dev It often has to read outside a single repo to perform a task

@housecor But I bet LLM token context is thin, amirite?

I’m working with a company that has 40 repos for one app. UI repo Test repo Logic repo DB scripts repo Etc All for the same app! Sure, monorepos have their tradeoffs. But needless decomposition = needless friction. Colocate stuff that changes together.

@mbritton Right without clear boundaries repos proliferate and don’t correlate with the organizational chart over time

@housecor Totally removed from your situation, but have been in scenarios where an excess of vendors and disparate teams working toward the same release schedule can lead to repo hell

@patrickgwsmith I’d estimate 40 devs and two user experiences

@housecor How many committers? And how many end user experiences? (Web app, mobile app, etc)

@TomasJansson How do you divide your dev teams?

@housecor We have 300 microservices, don’t ask me how you get there, and each service is its own repo. We have mobile subscriptions spread out over 20 or so repos 😖

@jamiebrough There are tradeoffs for sure but having far more repos than teams for a single app is hard to justify

@housecor This is actually sensible especially if tests are functional. A repo is no different than an npm dependency (which of course often have their own repos).

@jamiebrough WAT

@housecor I have 120 repos for one side project 😂

@derekm00r3 Yep but I do think a partial checkout would be sufficiently small in a unified repo

@housecor If only git submodules didn’t suck

@Principal_ADE A lot

@housecor How many files total?

@siddharthkp No far fewer teams than repos, and ownership of each repo is shared across teams which creates ambiguities and confusion

@housecor do they also have 40 teams?