Why the down vote? This was a factual statement and not some judgement: The name implies that some previous "era" was greater than the current - and hence current cannot be the pinnacle.
Thanks, I see your point. Was not trying to be snarky/funny, but rather come with counter example to parent. I was thinking about the (recent) "Era of globalization" - but perhaps that is too short of a time span to be called an era
Just tossing out more examples than just MAGA would likely have sufficed IMO. Current Russian expansionism, 1930s Italian ambition in Africa, etc, etc. There's a fair bit to to make interesting comparison to even if you restrict yourself to "modern" (i.e. industrial revolution and beyond) societies.
[1] shows that they their coal plants have not been sitting idle i 2025 and are producing close to what they did in 2024. [2] shows that coal based electricity produced is still increasing, but their overall CO2 emissions / kWh is lowering [3]
One of the biggest thing a lot of people are missing is that from this year Solar + battery became cheaper than coal in China. And avg annual price decline for solar and battery is still around 8-10% ie if you don't go to solar and electric machinery you will not be able to compete with China as they are about to reach the point in the next 10 year where electricity/energy is practically free.
It is weird to me that nobody wants to import Chinese electric cars. If Chinese investors and politicians are really subsidizing the production of electric cars, importing them would be basically having the new grid subsidized by a foreign government!
The usual argument is that this kills the domestic car industry, leaving us fully dependant on Chinese cars: what's going to happen when they hike their prices by 1000%, or threaten to stop all exports?
Pretty sure it's because a domestic auto industry is considered strategically important to maintain in case of war. Also, the supply chain employs a lot of people and maintains industrially important skills.
Look at the absolute values, your kettle doesn't run of fractions it runs on absolute power and EU&US are about the same. USA has fractionally lower renewables because they have very large fossil production. EU is making up for its lack of fossils through high efficiency policies.
Some points in parent comment are absolutely valid IMO. Would you hire a carpenter who walks back and forth to his toolbox to pickup at single nail at a time and then use the hammer with both hands near the head. And when cutting a 4x4 beam will use 1-inch strokes with the handsaw (again with two hands).
Using SSH to get the project files is not a good example of a hard to learn skill they need for the job, they should just have provided a zip on a web page or so or sent it directly to the user.
So to me it seems most of the test was just "have you done these trivial things before" rather than test if they can program web apps.
It would be like the carpenter being forced to buy nails and docking them points for now knowing where the closest shop to buy nails in are and taking time to look that up. Of course it is better if some look it up quicker, but its not a core part of the job. Then when they drove there, you gave them a manual stick car, so the ones who were used to automatic fumbled around in the car, also bad look! So now you see carpenters who drove manual were much better, as your biases told you! That is not really the skill you should care about, it is very quick to tell him where it is.
I don't think your analogy is apt. Having your development environment set up and knowing how to use your tools reasonably efficiently seems like it should be a low bar to pass. We're not talking about giving someone unfamiliar tools or an unfamiliar vehicle and expecting them to perform higher level tasks. We're just watching people use their existing tools to see if they're actually familiar and comfortable with them.
OP's post was "having custom themes" "bias against people using windows".
These aren't tests if a user can si their job or knows their tools. This is a cultural purity test to see if they have the same quirks as OP. And is a terrible way to judge if someone will perform.
I had my own reply, but using your analogy if I may: if I asked an apprentice carpenter to measure up and build some sort of structure in front of me with the tools provided, and they stumbled and made some awkward choices but the result was otherwise sound and they had other good qualities, yeah I'd consider hiring them. I think the scenario you describe though would be more equivalent to someone who flat out doesn't know how to even use a computer, which is a different case (I wouldn't hire that person).
I was thinking about basic tool use. I expect a junior engineer candidate to wield a computer way better than my mom. They are applying for a junior engineer position not and apprenticeship starting with close to zero training.
I have no problem with candidates who stumble and make awkward choices during the interview, as juniors by definition lack experience and the interview process is a stressed situation.
I think we need to stop seeing "can program" as being equivalent to "is an expert computer user", because those are genuinely two different, if related and overlapping, skillsets.
There is no particular reason that an expert C++ programmer also needs to know every keyboard shortcut or be an expert at the Linux command line, if those things are not actually relevant to the job you're trying to hire them for. Just because it's been common among millennial and older programmers (like most of us) to combine the two doesn't mean we should discriminate against programmers who don't fit that mold, as long as they're actually good programmers.
You're presenting a false dichotomy, though. No one in this subthread is expecting an expert computer user. We're just expecting them to have their development environment already set up, and to be familiar and comfortable with their tools.
If they come in with a Linux laptop but aren't comfortable with the command line, that's weird. If they come in with a Mac or Windows laptop and do solid work only with GUI tools, that's fine. If the job requires being able to use specific tools (command-line or GUI or whatever), then the interview should evaluate that as well.
Well, first of all, most likely dozens of them, at least, are good programmers.
In fact, most likely dozens of them will be perfectly good hires for the position.
The idea that you must hire only the single best possible candidate can lead to some pretty dehumanizing treatment of applicants, when the truth is that a) there almost certainly is no "single best possible candidate", there are many people who would do a roughly equally good job there, and b) your processes are almost certainly not optimized to actually find the true single best candidate for the job, but rather the person who is best at applying and interviewing for jobs among the candidates.
All that said, for "how do you actually design a better process"...I sure as hell don't know. I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.
> I'm a programmer, not an HR person or hiring manager; that's outside my skillset. But that doesn't mean I can't accurately identify glaring flaws in the current system based on my understanding of human nature.
No, it pretty much does mean that.
Until you can come up with concrete improvements and understand the potential flaws in those proposals as well, you can't usefully critique the existing system.
Better example: you press the ok button, and sometimes, only sometimes, it triggers twice.
You tell your lead, they say "I know." You ask why they haven't fixed it, and they lead you down a deep rabbit hole of fundamental, unsolved issues with event bubbling, and show you the 20 different workarounds they've tried over the years. "In the end," they say, "nobody's figured out how to not get it to sometimes fire twice."
Thus hiring. Sure it looks not right to you, but, come join us in hiring and you'll see, a better way has yet to be found. At least when I run interviews it's an actual real problem rather than a leetcode thing - I always just grab something reasonably difficult I recently did for the company and convert it to an interview problem.
Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain. Of that 10, 2 were the best. Criticizing not wanting to work with the best doesn't make sense to me. Lemme put my capitalism hat on, there: we have competitors, we need to code faster than them to get clients before them. If we don't, we lose revenue and don't get another funding round, and the company dies. Also all hiring is reported back to the investors who have an expectation we get good people. Also we give equity - why wouldn't I want the best possible people on my team so that I have the highest chance of my equity paying out big?
Capitalism hat off, yup, this system is dehumanizing and not configured to deliver the greatest societal good. Alienated labor detached from the true value of the goods produced, absolutely. What can I do about that at my job? On the side I run a co-op that operates under literally the opposite principles: anyone can join, we will train you to get the skills you need to get better jobs, and no margin of the rate is siphoned away for a capitalist class.
The problem with your last paragraph, of course, is that there is no "system", no generalizable concept of "societal good", no such thing as "true value" independent of the subjective evaluations of an object by disparate parties, and no "capitalist class" that actually exists as such.
Everything is down to particular patterns of interaction among particular people, all acting on their own a priori motivations, with none of the reified abstractions you're referencing actually existing as causal agents.
I applaud your efforts with the co-op you're describing, and if you're able to make it work, scale up, and sustain itself in the long run, more power to you. But it's a bit strange to imply that in the more common scenario, it's somehow untoward for the people paying the upfront costs of your endeavors -- and indemnifying your risk exposure -- to expect a share of the proceeds in return.
> Your guess that ~24/200 will be "good enough" is unfortunately wrong in my experience. In my last go, only 10/200 were able to demonstrate sufficient knowledge of the required skills to be hireable, and by that I mean fulfill the needs of the role in a way that justifies their salary, rather than be so inexperienced as to be a drain on resources rather than net gain.
I mean, this is fundamentally dependent on the specific position being hired for.
I'm interested in this conversation however this comment doesn't really mean anything to me. What are you saying? And so, how would you hire? If you just wanted to say, "hiring sucks," I agree. Hiring sucks.
This comment is saying "the percentage of any given 200 programmers applying for a job that are, in the end, reasonably fit to do the job depends on the job being applied for".
If the job is a mid-level C++ programmer job at an insurance company, many more of them are likely to be good fits than if it's a senior embedded systems architect job at an aerospace firm.
Yes, I was going to say, seeing the generated SQL can be almost useless depending on the execution plan.
When you have a solid view of the schema and data sizes you can start to be more predictive about what your code will actually do, THEN you can layer on the complexity of the ORM hell code.
Can we agree that this is only applies to queries where all the filter conditions use cols with indexes? If no indexes can be used, a single full table scan with OR surely is faster than multiple full table scans.
Absolutely. Though I don't recall seeing multiple sequential scans without a self-join or subquery. A basic filter within a sequential scan/loop is the most naive/simplest way of performing queries like these, so postgres falls back to that.
Also, fwiw, BitmapOr is only used with indexes: https://pganalyze.com/docs/explain/other-nodes/bitmap-or.
That was the extreme case - the multi-scan would be gotten if a casual reader tried your (neat by all means) AND-only query on a non-indexed table (or partially indexed for that matter).
Gotcha, I misunderstood your comment. The multiple counts is a definitely very contrived example to demonstrate the overhead of BitmapOr and general risk of sequential scans.
Havn't tried Colima, but podman is very simple to use and smells like docker cli.
On Apple Silicon machines however, latest podman version uses VM images which Rosetta doesn't work with, and hence it will use qemu for running amd64 containers. You can fix this by either installing podman 5.5 or create the VM from and older image [1]. My only complaint here is that the stock machine images are pretty large (~1G )
If you use containers to run tools that create files in your host (i.e. build tools), then you can use your host username as the default in the VM (machine init --username $(id -un)), and then run containers with --userns=keep-id. That way the the container command starts with the same username and uid as you host user - this is pretty tricky to get working with docker, from my experience.
We use Bazel as our build tool and we create a lot of images based on shared layers. Bazel produces oci layout directories that contain descriptors and symlinks to the actual layer tars. Podman can start a container "directly" from these directories[2], which speeds up image testing considerably, since it can detect known layers immediately. With docker you have to stream a tarball with all the layers and descriptors to the docker daemon, only for it to discover that it already knows most of the layers.
