The charts show software dev gaining more jobs under the COVID demand and stimulus swing, and then losing more as those went away and monetary policy got tighter than even it had been even before the COVID stimulus.
The easiest explanation for the whole chart is "Software dev is more reactive to the monetary policy environment than most other industries, because more of it is funded by new capital investment -- whether VC money or otherwise -- instead of ongoing operations of stable firms compared to most other industries."
Trying to add other explanations is fun, but there's not a lot of evidence for any of them, or even that more explanations are needed.
How are sec 175 changes in the US not also a top explanation? This has a massive cost to small businesses and startups trying to hire software engineers, and a big impact to any team trying to grow.
Because the data doesn't match. The author addresses this in his blog post -- essentially every country has the same graph of SWE jobs, but only the US has sec 175.
Big tech layoffs were a global issue and U.S. tech firms hire (and fire) globally. So like it or not, U.S. economic issues have a downstream impact around the world.
Sec 175 especially hurt small to mid-size tech companies (especially fast growing ones...) which I imagine amplified the problem across the board.
> How are sec 175 changes in the US not also a top explanation?
You mean the change from deductible as a current expense to five-year amortization under changes to Sec 174? In an easy money situation, the way it increases tax liability in year one while decreasing in year 2-5 is not a big deal, it becomes more of an issue as the cost of financing goes up, so the main effect is to increase the already-high sensitivity of software development to tightening credit.
... partly because it's quicker to get started with software projects?
No expensive machines or lab equipment, sometimes not even office space needed, just people with laptops
But the cycle wave length should ... Be similar to how many years people spend studying? That doesn't seem to be the case here?
Quoting the Wikipedia link:
"high salaries in a particular sector lead to an increased number of students studying the relevant subject; when these students enter the job market at the same time after several years of studying, their job prospects and salaries are much worse due to the new surplus of applicants."
Maybe you could say it's related to investors' pork cycle (of different/unknown wavelength) not students' pork cycle :-)
Or maybe just one-time opportunism: low interest rates etc
I tend to agree with you, if only because the swing in Europe on the IT job market has had less amplitude and is more spread out, similar to the difference in stimulus policy.
The local IT market is quite small and Google is a very large employer here.
Two things had happened then:
1. Other companies froze hiring, because they got scared of „what does FAANG know that we don’t that they’re reducing employment” - no other reason really
2. A few hundred of pretty good Google engineers flooded the small market.
2023 was very rough, things got much better since then though.
I believe many software tools work like a vice for beurocrats making the beurocracy way less efficient.
Like, forcing some not very edge case friendly set of text field validation rules onto the beurocrats such that he can't just do what he tries to do as he could with paper work.
In many orgs. nowadays the processes seem to be made to fit the computer programs not the needs of the beurocracy.
That seems a little backwards. I'm not sure exactly what you mean with making bureaucracy less efficient, but form validation is an example of automated, technologically enforced bureaucracy - in some sense, it's a more efficient form of bureaucracy. It's certainly less flexible, but lack of flexibility is arguably the point of bureaucracy; less flexibility suggests more rather than less efficient bureaucracy.
Yes and no, form validation is a double edged sword: without it whoever receives the data may have to deal with inconsistencies, so removing that will increase efficiency.
However, the flexibility and adaptability of human interaction is lost when an intermediate digital system enforces rules without exception, and that loss can absolutely result in inefficiencies because the world is always changing and your digital models rarely reflect reality.
Let's say you work for a government agency processing stolen bikes. To fill in your form you must select a category of bike, but "fatbike" is not an option as the software was built in 2012. As a human using paper, you could easily talk to your colleagues and agree that you can now check the "e-bike" checkmark and write "fat" beside it to indicate a fatbike. In the software world, some company (hopefully the one that built the original software) will quote you 50k to do it, it won't work correctly, and you'll thank them for the pleasure of dealing with them.
In another example, let's say you have to get a building permit to build an extension to your house, and based on your postal code the system tells you that you are too close to a nature reserve and are not allowed to do any construction, and the system rejects your application. The government has recently ruled that this does not apply anymore to residential housing development, to improve the housing crisis situation, but the software is not up to date with this change. In a paper world the human could simply approve the permit based on their knowledge of the real world, in the software world the computer program will never approve your permit.
This whole thing may sound anti-automation. Its not meant to be, rather its a reminder that the processes we automate should leave enough flexibility and adaptability to deal with the real world. This does not come for free though: the bike system would need to allow you to add categories, or a free-form details field. The permit system should work in an advisory manner, but allow overrides by a professional specifying a reason, or it should allow you to disable/modify/create rules on the fly.
However, no matter what you do, form validation will always leave somebody out in the cold, some edge case uncovered, that a human could always resolve, but a system cannot.
Great points! To be clear, I was not trying to say that automated and strictly enforced bureaucracy is a good thing. The bureaucracy of the form is very efficiently implemented. That's mostly not a good thing (or at least it often has costly consequences), but it is an example of software creating more efficient bureaucracy - efficient as bureaucracy, but often not efficient in fulfilling its supposed goals.
Aha, ok. I'm not 100% sure I understand but I imagine you mean that bureaucracy, viewed negatively as simply the execution of some process, is expedited by form validation. I have to agree then indeed that this is true. I thought of bureaucracy more as the whole of the functioning, so efficiency would include successful resolution, not just successful process.
Thanks for the write up. I am having an emotional crisis having to defend bureaucrats against us. (I conveniently blame their systems not being FOSS, not us programmers blindly following orders. No... not our fault).
I love me some FOSS but I don't think that helps here, does it? In the end the person having domain knowledge is no longer in control of the process, because its been transferred to an automated system. Therein lies the issue, even if the software can be modified it cannot be done by the domain expert, or on the fly, or at low effort.
A FOSS system could be changed by the beurocracy in a more straight forward manner than a procurement circus with the copyright holder of the software, is my reasoning.
And even if they produce "real" products. How many of them are needed. How many of them are redoing the same thing. And how many could in perfect world be done more efficiently by resusing some common solution.
Jobs funded by speculative investment that are highly sensitive to monetary policy are pretty orthogonal to the kind of thing addressed by "bullshit jobs" theory. They may be societally harmful or low-social-value more often than other jobs, but generally for very different reasons than bullshit jobs. They are "lottery ticket" jobs, where many are wasted, some are very valuable, and its hard to predict in advance which are which (for investor value; for various reasons endemic to capitalism more generally, this is a very imperfect proxy for social value, but that problem is also mostly orthogonal to the kind off harmful job "bullshit jobs" addresses.)
The easiest explanation for the whole chart is "Software dev is more reactive to the monetary policy environment than most other industries, because more of it is funded by new capital investment -- whether VC money or otherwise -- instead of ongoing operations of stable firms compared to most other industries."
Trying to add other explanations is fun, but there's not a lot of evidence for any of them, or even that more explanations are needed.