Instead it's more like "nothing to see here, kindly vote in our puppet candidate X, thanks!" for various local values of X.

The Tuesday law was passed in 1845. Instead of changing it, many legislators are pushing in the opposite direction: trying to selectively suppress their opponents' votes further. If it hurts them more than us, it's a worthy goal!

[1] https://www.cpr.org/2022/07/13/colorado-counties-begin-audit...

It has engineers. It might yet surprise. Nvidia hasn't proven it can turn a ridiculous amount of capital into a matrix-multiplication moat.

This argument has been around since time immemorial. The right way to think of it is more like a country club or a who's who, rather than a survey or a directory.

As for the news at hand, it's really more about Intel than Nvidia. Sic transit gloria mundi.

When remote work is an option, it'd be nice to know the health opportunity cost of RTO. Sadly the cohort is too hard to study outside of nursing home residents.

The question is not what's affected. It's how much monetary policy it takes to achieve the desired output and employment effect, and where is the employment effect. We want to stop increasing rates once the effect is achieved.

We raise rates because the economy is overheating. Too much money is chasing too few goods, raising prices. In response to the favorable prices, too many jobs are chasing too few workers, raising wages.

Rising prices and wages (without rising productivity) means inflation. We're at one edge of the Phillips curve [1] and need to move back to the middle.

> That may be a goal, but it isn't the goal.

The goal is actually to raise unemployment. That's what the "cooling the overheating economy" euphemism means. However, we don't have the tools to raise it evenly in all sectors. The only tool we have is the short term interest rate.

Luckily, it affects the long term rate, which affects demand for homes, new and existing. For (say) every 20 fewer homes sold, one realtor and one banker might go unemployed. But for every 20 fewer new homes built (say), 50 laborers might go unemployed. That's why the transmission is primarily through construction [2] [3]. The consumer durables sector (appliances) used to have a large multiplier too, but most of those manufacturing jobs have been automated or moved overseas.

> they wouldn't be lagging if the effects must have already happened

You can model the lag effects as geometric decays of the original impulse. You need a negative original effect (one impulse of high unemployment) that will then regress back to baseline (continued but fading unemployment.) We didn't have any impulse, hence no decay.

The only thing that could really go wrong is a resurgence of inflation if the cuts were too fast, but chances are we would have seen that already too.

> relative to where we would have been without intervention

The problem here is we were at too much output/employment. We had to get through that moment and fix the problem without overshooting in the opposite direction.

We couldn't do better, that's the whole point. It's not like there was potentially more output to be had. The actual problem is that output was too high. That's why there was inflation.

[1] https://en.wikipedia.org/wiki/Phillips_curve

[2] https://www.usnews.com/news/economy/articles/2022-12-20/new-...

[3] https://www.infracapfunds.com/post/why-the-us-is-unlikely-to...

> we really won't know for sure for at least a decade or so

We absolutely already know. The contractionary effect of a raise in rates is largest in the short term. You can't have a lagging effect after rates are cut if there was no contraction to begin with.

As for how the Treasury and Fed managed the crisis, it was easily the most incredible macro success story since I've been alive. Had you told me in 2022 that they'd manage sub-3% inflation without a recession at all, I'd have said you believed in fairy tales.

[1] https://fred.stlouisfed.org/series/HOUST

Unfortunately, housing in most areas was screwed to begin with. This was not nearly the case with prior inflation bouts that required rate increases. The Fed was left with two bad choices. It did what it had to do.

If the economy was Windows XP, housing would be its networking stack - its most exploitable sector. This is largely because of local governance and regulatory capture [2]. Housing has been artificially undersupplied for 5 decades under a variety of pretexts, such as architectural integrity. It has effectively turned the sector into a pyramid scheme that captures the wages of renters.

[1] https://archive.is/8wAry (from https://www.nytimes.com/2022/04/19/opinion/inflation-interes...)

[2] https://en.wikipedia.org/wiki/Regulatory_capture

   f(x) = 6x^2 - 5x + 1

   g(x,a,b) = ax + b
   f(x,q()) = q(x,3,-1) q(x,2,-1)
   f(x,g)

However, it's algebraically orthogonal. It has advantages in some cases, for instance if you later add code for a 6th-order polynomial and need to use its zeroes for something else.

We know that it could be better in some cases. Is it a good bet to predict that it will be better overall? The problem domain can fracture across a thousand orthogonal "creases" like this one. The relevant skill is in making the right bets.

Here's an example that's not orthogonal. Let's say we think the 6 coefficient might be more likely to change in the future:

   g(x,a) = ax^2 - 5x - 1
   f(x,q()) = q(x,6)
   f(x,g)

If:

1. You know where the 'creases' of orthogonality are. You've carved the turkey 1000 times and you never get it wrong anymore.

2. As a result, there is hardly any difference in complexity between code that is and isn't easy to extend.

Then write code that is easy to extend, not delete.

The question is whether your impression of the above is true. It won't be for most junior developers, and for many senior ones. If orthogonality isn't something you preoccupy yourself with, it probably won't be.

In my experience, the most telling heuristic is rewriting propensity. I'm talking about rewriting while writing, not about refactoring later. Unless something is obvious, you won't get the right design on the first write. You certainly won't get the correct extensible design. If you're instructed to write it just once, then by all means make it easy to delete.

The less-sophisticated efforts are basically misdirection and camouflage. They are intentionally disarming, akin to how their 'strongman' puppets make an effort to bumble and 'accidentally' feed the trolls. Covfefe bigly, if you will.

This is not far off from the guidelines in many cases, e.g. Windows code (well, not every variable of course.) A lot of Java design was copied from C++.