People living in homes financed with a generous rate (~3% like you mentioned) mortgage are unlikely to move - that's correct. However, that's not the only piece of the puzzle. Keep in mind that home builders have recently produced at the highest level since 2008 [1]. When you pair this with high rates [2], it's likely that we will see inventory sitting on the market.
They say you shouldn't try to time the market, which is probably good advice. However, my approach is/was:
- back in April, moved 401k fund from S&P allocation to cash equivalent (2% yield). Note: this wasn't a cash out, just reallocation.
- Bought long-dated treasuries (10 yr and 30 yr). Allocated through July and August. This one is not doing well, but allocation was sized appropriately (< 2% of portfolio).
- pooling any excess capital in a savings account until volatility calms down.
- have a couple rentals and plan to continue holding. It will be interesting to see some buying opportunities in the upcoming year or two.
An increase of MBS offered on the market will cause mortgage rates to rise because there's too many loans for sale and not enough buyers. Buyers will demand higher and higher rates to make it worth their while.
I think the idea is that the Fed is trying to tamper demand by softening the economy. Lower demand will inevitably help prices.
It doesn't help much though if we get a "rough landing" and people can't afford food/housing because they're out of a job.
> If the Fed sells mortgage securities that pay low rates at a time when prevailing rates are much higher, it will incur big financial losses that reduce the funds the central bank returns to the Treasury.
Why does this reduce the amount of funds to the treasury? The losses are on the Feds balance sheet. My understanding is that the Treasury is not involved here, but the article hints at them being affected. Is it implying that treasury yields will rocket higher???
> In that scenario, expect officials to face tough questions from Capitol Hill to explain why they've lost billions of dollars on behalf of the American people.
If the Fed takes a loss, doesn't this mean that base money supply increases? Sure it will be drawing liquidity out of the system, but in the long run, it will leave more money in the system compared to where they started with QE.
Textbooks won't tell you about Brent Johnson's Dollar Milkshake theory. They also won't have insight on todays inflation and whether it's more similar to the 1970s or 1940s.
Textbooks are great for finance fundamentals, but shouldn't be the sole source of macro.
Here's a list of podcasts that touch on macro:
- Eurodollar University
- The Grant Williams Podcast
- Grant's Current Yield
- Hidden Forces
- Inside Baseball with Old Chestnut
- Keeping it Simple with Simplify Asset Management
- Library of Mistakes
- The Macro Compass
- Macro Musings
- The Macro Trading Floor
- Macro Voices
- The Market Huddle
- Money Sense
- On The Margin
- Real Conversations
- Real Vision Daily Briefing
- The Rebel Capitalist Show
- Super Investors and the Art of Worldly Wisdom
- Wealthion
The best thing you can do is be open to hearing all opinion/theories. Some people will contradict others, but over time you figure out who is right and who is not.
In addition, I also watch a few indices in my stock app for a high level overview. These are the treasury yields, corporate credit spreads, dollar index, s&p 500, nasdaq, etc. I used to follow much more, but it's not needed for higher level macro.
I tend to keep my PRs small enough to where several can be submitted within a day. This being said, I tend to keep my changes un-staged.
When I'm ready to commit:
1. `git diff` to get an overall picture of what changes were made. Which parts of this diff can be packaged into an isolated commit?
2. `git add -p` This is where I selectively stage bits.
3. `git diff --cached` to verify that the staged items are all in place
4. `git commit` with a detailed message.
5. Repeat steps 1-4 until all changes have been committed.
6. `git fetch origin main && git rebase origin/main`
7. Finally, `git push`
When PR feedback is left by peers, some teammates prefer you to not rewrite commits and force push. This makes re-review easier for them (especially if you use the Github features around PR review).
I opt for rewriting commits if it's okay with team members. This way you don't have "fix typo" commits getting merged into the main branch.
Does anyone have experience with Duplicati [1] or recommend it? I am tentatively looking to make the switch to something a little more sophisticated than manually tar-balling + rsyncing backups.
This article does a pretty good job of explaining how green events work. It seems that each of the threads will attempt to accept any/all incoming requests.
The podcast Making Sense by Jeff Snider and Emil Kalinowski dig into how the Fed functions and how dollars/collateral affect the (world) economy. Very interesting if you're looking to learn more about this. Jeff also has some very informative blog posts.
Local-first software feels underrated especially in the UX realm. Peer-to-peer applications such as Manyverse load instantly due to not being blocked by network requests.
My hope is that more apps are developed with a local-first mindset. CRDTs likely introduce additional complexity around data storage, so this would certainly be a drawback when considering local-first.
Destroy All Software screencasts by Gary Bernhardt has some great content. Besides the typical CS degree, I felt that these videos were most pivotal in me writing better code.
For smaller projects and teams, something like feature flagging can probably be avoided unless A/B testing is required.
For a company that has hundreds of engineers, with daily continuous deployment, it helps to have certain in-development features gated behind flags. When it comes time to deploy these new features, they can gradually be rolled out to users. If the feature starts triggering exceptions, it's very easy to scale back.
Once the beta feature becomes stable, often the feature is removed (along with all logic in the source code guarding this feature).
Similarly, for A/B testing, the feature flagging and logic is removed once a test is deemed to have either passed or failed the A/B experiment.
Like anything else in software, feature flagging can incur technical debt if not properly maintained.