Folder pattern I’m enjoying: “Local” shared directories.

1. First, create a shared directory at the root. This contains code shared across the entire project.

2. Create a shared directory in specific subfolders for code that's shared by a subfolder.

This conveys when something…

In TypeScript, declaring types saves me more time than it costs me:

✅Speeds up my reading.

✅Catches my errors earlier.

✅Clarifies my mental model.

✅Gives me robust, reliable autocomplete.

✅Avoids me spending time checking docs.

✅Helps me understand my own code later.…

Good question.

If we control the API, we know when the responses change. And if we have tests, they should find extra properties in development.

But if we don’t control the API, we probably shouldn’t be strict - the response may add properties at any time.

Disabled input fields aren't a loading strategy. Show a loading indicator.

Disabled buttons aren't a validation strategy. Show a helpful message when someone clicks the button.

Disabled buttons aren’t a security strategy. Visually hide features people can’t use. Or, display a…

Problem: Ideally, everyone is responsible for quality. But, if everyone is responsible, no one is responsible.

Solution: Establish a code owner.

This person is officially responsible for code quality. This could be the team lead, or a senior developer.

What’s a code owner do…

“Deploy daily.”

It’s a wonderful goal. But to safely deploy daily, you need a mature foundation:

Automated build & tests
No-downtime automated deploy
Integrate daily (small deploys)
Feature flags (hide incomplete work)
Monitoring to detect issues
Ability to quickly fix prod

Rule for choosing between a URL path and search param: Search params are optional.

So, if it’s required to render the page make it part of the URL's path.

If it’s optional (you can fall back to a default), make it a search param.

If the team is ignoring PRs that’s a management problem.

Managers need to make it clear that code reviews are important.

The team needs to know:
1. Who is responsible for doing reviews?
2. What’s the expected turnaround time?
3. What constitutes a good review?

Everyone…

This sounds nice but in my experience “review after merge” typically results in “no review at all”

'We don't do code reviews. We trust our developers'.

You have no idea how often I run a PR and find it's broken. It's *extremely* common. Even from senior devs.

We all make mistakes. So I trust no one.

Including myself.

How I get my PRs merged fast:

1. Keep the scope small

2. Provide a clear title and test plan

3. Write tests that document the expected behavior

4. Add screenshots or a demo vid if needed

5. Name things clearly

6. Follow established conventions

Make it easy to say yes.

Scenario: A search param is required to load the page. But the param is missing or malformed.

Poll: What should the app do?

I often see aria-labels that look like an id:

🚩 aria-label='delete-user-button'

An aria-label should have a *user-friendly* label that describes what the button does. And it shouldn't repeat the tag's name - that's redundant.

✅ aria-label='Delete Cory House'