One thing I don't see much research into (maybe I'm wrong) is whether the US has major data quality issues with labor data.
Jobs reports just don't seem at all to square away with the vast anecdotal accounts from both employed and unemployed individuals across a swath of industries.
It's no secret that companies put up job listings they either have no intention of filling or are simply H1B fraud (impossible listings used to justify an eventual H1B hire).
This would make the "true" number of open jobs within a sector far, far worse than reported.
Comparing jobseekers to job openings is also a very imprecise approach. For certain industries, the gap is bound to be far worse than for others. And the same is true when you look at it by level, experience, etc.
The US is thus in a weird position where equity markets look OK... largely boosted by gains in a small selection of companies (in what's perhaps an AI fueled bubble) and the economy looks a tad rough but not horrible. The real impact of tariffs + broader economic policy is being underrepresented in the data.
This can only last so long. Eventually, inventories will be depleted and tariff impacts will rear their head. Eventually, the true unemployment rate will result in increased eviction rates, lower savings rates, and lower median consumption.
I think publicly traded companies post employee headcounts in their public financial disclosures, so I would assume we would see a general rise in head counts starting in 2020, followed by a leveling off or decline starting in 2023. For example, Google. https://www.macrotrends.net/stocks/charts/GOOG/alphabet/numb...
> Jobs reports just don't seem at all to square away with the vast anecdotal accounts from both employed and unemployed individuals across a swath of industries.
Agreed and on multiple fronts.
e.g. I can imagine that white collar workers may not claim unemployment due to a combination of embarrassment/"I don't need it as much as other folks" so the numbers are probably under-reported there.
I've also heard it's bad for recent grads but then a recent grad I know sent me the below:
"I’ve been hearing this a lot lately, and honestly, it’s pretty silly. Yes, tech majors are definitely over saturated, but in my opinion, you shouldn’t be able to go to school for four years, do the bare minimum the entire time, and get a great job after college. From my experience, everyone who worked really really hard and knew their stuff got to a place that they’re happy with"
The above could have been what I said back in 2002 right after the dotcom boom. In other words, it's unclear if companies are hiring fewer junior folks, junior folks were benefiting from ZIRP/boom market or a combination of both.
What you said is how the USA worked for my entire life until the H1B saturation finally reached a critical point! Young men and women would find jobs after college, it was NORMAL to have that be the case. What's going on right now is NOT normal. I got a job right out of college in 1995 with a CS degree--in fact, I had two offers, and I was nothing special. People with actual connections did really, really well back then. It was an optimistic time, and yes, Clinton was President, but he lucked out with the dot com era boom. It obviously imploded by 2001 or so.
I think the reasoning behind why you can mostly look past the fake listings is that the numbers are treated as meaningful relative to each other, and so, the ratio of false listings should be relatively similar.
They probably realized that the move here is to just put it out there and if there are consequences, they can just wave their hands of it. Unlikely to be government backlash and legal backlash will come down to "we told you it was experimental".
PRs are as long as they need to be and as short as they need to be. This idea that any problem can be decomposed into 100-200 line changes is ridiculous. That's not realistic in many cases (esp. for refactoring work, etc.)
There are certainly exceptions. And if a problem cannot be decomposed, then you have a "stop the world" formal code review with a team-wide multi-hour dive into the code.
In my world, though, we use the refactoring tools such as feature flags and incremental improvements. We can use stacked pull requests. It requires training and discipline but it's absolutely doable for 99% of tasks.
Impressive sounding slop that either rarely amounts to anything, breaks, or becomes someone else's problem. Unfortunately I'm starting to see these people at work...
What's worse is they also tend to be the type of "evangelists" that become wildly defensive or accusatory when you question anything about their work.
> generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written.
This part tracks. It's honestly rather generic.
> if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not hardened industry titans joyfully cracking their whip over an army of junior devs and LLMs.
This, I'm not sure applies either. TBH the biggest risk I'm seeing already right now is how quickly we're starting to see juniors trying to enter the job market who don't have the faintest idea how actually code. Let alone build software (but let's be honest, that's usually been the case). What decisions to make when writing something are based on factors outside just implementing the functionality: how maintainable is this? how extensible?
Giving a junior a sycophant that's reasonably competent at spitting out something functional (not necessarily functional in the sense you need it to be but apparently working) is a recipe for disaster IMO.
There will absolutely be some who "get it". But, how does that scale?
More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".
> More worryingly, something I don't see discussed enough is "review fatigue". It's far more fatiguing reviewing the output of an LLM than writing the code yourself a lot of the times. Early on in your career, this might lead to the tendency to just say "eh, looks alright enough".
I am definitely worried about that. I got into a mode of doing morning code review every morning due to having a bunch of active open source repos, so over time as they grow in activity I learned to adapt my schedule, mind set, and everything around how to do the right amount of code review (when to finish the PR yourself, when to give pointers to train a new contributor, when it's not worth your time yet to say more than "tests fail", etc.). I started for years pulling every piece of code locally, running it, figuring out why someone would make a change like that, etc. and then it took like 5 years before I could actually start to do code review well just by reading a git diff. I needed to know the domain, the language, the problem space, and how people tend to work, all well enough to make that simple enough to have a mental model.
Then, I tend to see some junior programmers put up LLM stuff and I go "oh just handle the extra memory allocations and it's good to go" and they go "wait handle what where?". If you can't eyeball that in under a minute of scrolling through the code... then you shouldn't be doing code review by scrolling through it yet. But if they keep doing it like this, they will never build that skill.
That's why I think the right LLM usage is really for those who have already built that code review skill. It's not to gate the usage of LLMs, but people will never learn if they aren't strongly engaging with the code at some level.
The reality is, ecosystems evolve. First, we had mypy. Then more type checkers came out: pyre, pyright, etc. Then basedpyright. The era of rust arrived and now we have `ty` and `pyrefly` being worked on heavily.
On the linter side we saw flake8, black, and then ruff.
Decoupling makes adapting to evolution much easier. As long as both continue to offer LSP integrations it allows engineers to pick and chose what's best.
The whole premise of uv that you don't need to know that you can install specific python version using eg pyenv (`uv python install` or `uv run` may do it implicitly), you don't need to know about `python -m venv`/virtualenv (`uv venv`), or how to create lock files pip-tools / pipenv / poetry / etc(`uv lock`), or pipx (`uv tool install`) or `pip install`/ `pipenv install`/`poetry add` / many others (`uv add`), or how to build artifacts setuptools / hatchling / poetry way / etc (`uv build`). Other commands such as `uv sync` didn't break new ground too.
`uv format` is similar (you don't need to know about `ruff format` / black / yapf ).
All actions listed in your first paragraph, except for installing specific Python versions, are actions related to the area of packaging. Doing it in one tool is completely sensible. I'm not a fan of uv managing Pythons, but I guess that ship has sailed.
But formatting code is a completely new area that does not fit uv.
Jobs reports just don't seem at all to square away with the vast anecdotal accounts from both employed and unemployed individuals across a swath of industries.
It's no secret that companies put up job listings they either have no intention of filling or are simply H1B fraud (impossible listings used to justify an eventual H1B hire).
This would make the "true" number of open jobs within a sector far, far worse than reported.
Comparing jobseekers to job openings is also a very imprecise approach. For certain industries, the gap is bound to be far worse than for others. And the same is true when you look at it by level, experience, etc.
The US is thus in a weird position where equity markets look OK... largely boosted by gains in a small selection of companies (in what's perhaps an AI fueled bubble) and the economy looks a tad rough but not horrible. The real impact of tariffs + broader economic policy is being underrepresented in the data.
This can only last so long. Eventually, inventories will be depleted and tariff impacts will rear their head. Eventually, the true unemployment rate will result in increased eviction rates, lower savings rates, and lower median consumption.
reply