It's hard because I have very, very little sympathy for the US auto industry. Very little (go fuck yourself Detroit).
However, China routinely focuses on certain industries and then uses state incentives to have Chinese companies mass produce products in those industries. It is all but impossible for any company, from any country, to compete with that (without similar government subsidization).
It seems to me that the solution isn't to ban Chinese exports or ignore Chinese subsidies ... it's to allow Chinese products in, with a tariff that balances the subsidization.
(Which is also hard for me to support, as I'm generally anti-tariff ... but it does seem like the right measure here.)
"without similar government subsidization" has any US company ever given such incentives? Or accept rescue or any money for gov?
In Europe take a look at VW, owned by the German gov. They are in trouble only because their CEO's and others who decide where they should go and do, they have no idea what they are doing. Zero. Grab a random person on the street and make it VW CEO that it will be much better.
This is why we had 100% tariffs well before Trump. To make it difficult but not impossible to compete. Europe clearly took it too far and it resulted in their biggest companies downsizing at best. I suspect once trump is out we'll look to Canada as a model.
Why would they need to? The Open AI bots were working around their master's limits on writing. A Chinese AI could just make its own private message board.
You think they don’t sandbox them? So by that logic, the Chinese models are either engaged in massive undetected cyber attacks or they’ve solved alignment?
Thanks, author here. Price has increased indeed, for both MacMini and Hetzner. The ratio for newer numbers remain very similar for new hardware; and already owned MacMinis become even more attractive. Will update the article (update: done), wish my AI could do all of this too with no intervention ;)
How is this new? Not only did Joel come up with this (literally) over two decades ago, but also this list was all over Stack Overflow (back when they had job listings, every listing showed which boxes the employer checked from Joel's list).
As a result, I think more coders have been exposed to it than almost any other tech blog post.
There was a time when every new PC CPU coming out was a giant deal: "Guys have you heard about this new Pentium processor, it's incredible?"
But over time, more and more people got into the chip-making business, and the big players started releasing more and more chips. Now only the die-hard CPU trackers worry about every new CPU and exactly how it's better ... while everyone else just worries about "which CPU will be good enough at this moment".
Same for smartphones. There was a time of unlimited hype and secrery around new iphones. Who remembers the story of an iphone 5 prototype left a bar. Journalists were going crazy, people were signing petitions for Apple to not hunt down but instead forgive the employee that made such a grave mistake. People were offering millions to buy the prototype so they can brag they got the new phone 2 weeks before everyone else did.
Or who remembers the dancing disease of 1518, were people would stop what they are doing and start randomly doing the same dance. The lords? Out of their minds. The priests? Terrified the devil had taken hold of the flock!
I have come to believe that it was probably some tik-tok like hype trend of doing a fortnite dance while waiting in line for bread and communion. And the energy back then, like now, was off the charts.
Hype and memetic trend seeking encoded deep in human psyche.
> Who remembers the story of an iphone 5 prototype left a bar.
That was the iPhone 4 actually which was special for having the first “retina” screen. It was in a case to make it look like a 3GS to be used for field testing. The journalists that got their hands on it and published about it before the announcement could not turn it on past I think the Apple logo and a message saying to return it to Apple (or maybe it was just completely off, my memory is fuzzy), but were able to confirm the pixel density via microscope and I remember it blowing everyone’s minds at the time.
> people were signing petitions for Apple to not hunt down but instead forgive the employee that made such a grave mistake
FWIW I asked about it when I worked at Apple and he was indeed not fired and I think may have even still been working there when I was there around 10 years ago (though don’t quote me on that last part, he may have left already and I’m misremembering).
He was apparently not fired or even really reprimanded since it was a genuine accident and he wasn’t the one that sold it to the press, but that did start a slew of new policies around accounting for work devices.
I had dev fused phones for open carry outside of the office while I worked there but had to register when I got them and when they were returned, which apparently didn’t used to be tracked so tightly until that incident according to my coworkers who had been there longer.
>If we want to explore alternative solutions, I’d rather do that before implementing one of them.
>If we want knowledge transfer, pair. Sitting next to someone, physically or virtually, while they reason through a problem teaches you far more than reading their completed solution afterwards.
>If we want junior engineers to learn how experienced engineers think, let them work with experienced engineers while they’re thinking. Pairing comes to mind again here, but teams could also do design sessions collectively with a whiteboard before they write (or instruct the agent to write) anything.
>If we want collective ownership, organise teams so people actually build and operate software collectively rather than relying on a pull request to tell everyone what somebody else has already built. For this again use pairing, mob programming, or team design sessions around whiteboard.
...
So in short, talk to people about decisions before you code (obvious advice, but plenty of shops don't do it) ... and replace all other functions of code review with pair programming!?!?
I mean, seriously, the answer to "what do we do with so much code to review" in this article is moronic! The vast vast majority of shops are not going to adopt Extreme Programming, and cut their velocity in half, by using twice as many programmers as they needed yesterday to get the same amount of work done!
The author frames the whole thing as an argument between her and some other guy, but I don't even know what the other guy's argument is (she left it out). Still, her argument so incredibly tone-deaf and awful, I'm definitely on his side.
I write a bunch of features. Most are pretty boring. A junior isn't going to learn much by pairing. But occasionally, I do big architecture changes. Those ones are perfect for early collaborative design, pairing, and discussion. The whole team benefits from understanding the architecture better and juniors get to see how seniors think about it. Then you can pair with juniors on the prompting or, more likely, the implementation plan to hand to the agents. That's maybe once a week.
I've done pair programming (at an Extreme Programming shop).
There are lots of benefits to the practice in terms of knowledge transfer, catching bugs (and otherwise benefiting from having "two sets of eyes") and so on.
But ... it definitely lowers how much code you produce. Maybe two people work a little faster than one (maybe it only cuts velocity to 55% or 60%) ... but it definitely cuts output by a lot.
Pair programming is not about getting more done, it's about getting less done (but done better).
my performance goes up when i pair program. therefore velocity is not cut in half. depending on the pair, the velocity may even be higher than the combination if the two people working individually.
also if pair programming means saving time on code reviews then that's a further increase in velocity.
If I had a nickel for every dev who has written a "productivity suite" of skills, and shared it with others as if it was a burst of innovation that everyone can benefit from (when it's really extremely specific to that dev and their workflow) ... well I'd have a lot of nickels.
It turns out productivity skill sets for Claude are a bit like opinions and assholes (everyone has one, and ...)
I mean, just to give you an idea of how common this is, my CEO made a suite like this ... although he had the self-awareness to realize what he made was very specific to him.
Agreed. Skills are hardly transferrable unless you are just focusing on globally applicable things like syntax, structure, etc. The most useful skills are things that are not well known and project/ organization specific. The "tribal knowledge" aspect of coding.
Yep. The useful skills are the org/team rules, and those are the ones that never leave someone’s laptop. Then Cursor’s on a different copy than Claude. That’s the actual problem — drift - not another public set of skills. skillrepo.dev is for keeping that set current in your environment.
Take Open AI for instance: it has "zero debt" ... and $665 billion to $1.4 trillion in "long-term commitments".
reply