USB-C is the connector type, not the cable. The connector type supports multiple protocols, including for interoperability with other connector types as a cable can have USB-C in one end and something else in the other end and users expect the cable connection to just work the USB way.

I think you are confused. USB-C refers to the connector type, not the cable, let alone the protocol.

https://en.wikipedia.org/wiki/USB-C

Also keep in mind that the standard supports cables with USB-C connectors in one end and USB-A connectors in another end. What do you expect the USB-C end to do?

Some mechanical keyboards ship with an embedded USB hub that supports a couple of USB ports that allow users to pick and choose what devices to plug in.

I wonder why this feature isn't widespread.

Everyone would be better served with a generic USB hub in the keyboard, not shipping a security key with the keyboard.

Expressing feelings and staying assertions are two different things. If you go around saying the sky is red and someone asks you for the source, it's not reasonable to throw a tantrum while desperately trying to move the goalpost by weaseling around with excuses such as "well aktchualy it feels red to me" nonsense.

If you make a statement, own it. If you are caught peddling baseless bullshit don't complain about being caught, complain about mindlessly posting baseless bullshit.

This reads like the prelude to Month Python's "what have the Romans ever done for us" skit.

I recommend you catch up on the post-covid "return to office" conversation, particularly the arguments from municipalities and local governments. Even though I'm a diehard WFH guy, you clearly missed all the arguments on how forcing people to commute to the office benefits the economic activity in urban neighborhoods.

Now, if your employer opted to build offices in the middle of nowhere... That's another issue.

This is utter nonsense, and reeks of a desperate and deep denial. I mean, you might as well rationalize your denial by claiming they don't like you because they don't like you.

Have you tried actually listening to what critics have to say? Nimby doesn't just pop up out of nowhere at ever spot because someone failed to do PR.

This baseless assertion contrasts with any report or reasoning. They are noise generators operating 24/7 that eradicate social activity and purpose to such a degree that makes high-security prisons feel like community centers.

Please in your own words state what you feel is the primary advantage of having a data center in your neighborhood.

> The data centers in Aurora are surrounded with prairie green space; everything else, including the nicest office buildings, are a sea of eyesore asphalt parking lots.

You don't need to build a data center to plant some trees. There are other ways to do that, you know?

> But data centers by themselves intrinsically seem like very good neighbors, much better than warehouses and strip malls

You got to be joking. Datacenters are massive warehouses whose main output is noise 24/7.

Strip malls at least serve a purpose in the community, such as fulfilljng needs of those who go there to shop, and simplify the job if small business owners to setup and maintain a shop.

This feels like a blatantly unrealistic opinion to have, which goes completely against any observable evidence.

Without a login, you can barely click on any link without being spammed by login prompts. If you visit anyone's posts tab you are greeted with a comically bad collection of posts that only show stale years old tweets that follow no discernible pattern or logic. And you cannot sort by timestamp.

This is comically bad given Twitter's sales pitch of being a microblogging site that lives in the now.

The truth of the matter is that today's Twitter is a sad clone of the glory days Twitter. Lauding these developments as something praise worthy is perplexing.

Lines or code is an indicator, not a goal. If you write long-winded functions, your code is bug prone and harder to test and verify. If you refactor it, it gets shorter. Where do you draw the line?

The same goes for how many characters you accept between two line breaks. Some go for 76. Some for 130 or more. There is no difference if your line has 129 or 131 chatacters, but if you spew a comment with 999 characters in a single line then your feedback is actionable if you say "hey man, don't be that guy. Rewrite your comment and make it readable."

> (...) PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities.

Not really. Calling out basic things like "this function is far too long" is clear, objective, and actionable feedback. That is a good PR comment.

Dismissing clear and actionable feedback as some guys whims is a red flag, and a telltale sign of someone who has no interest to improve their output and address issues.

I don't think so. The US military still has the same Gulf War kind of punch. It's the same armed forces that supported multiple large scale military engagements and outright invasions without requiring changes to it's economy.

But that requires preparation and planning.

Trump did nothing of the sort, and forced the us military into an untenable position. The same armed forces that could easily occupy both Afghanistan and Iraq can't even support a limited engagement with Iraq until they started running out of ammo. That tells you everything about the level of planning that went into this mess.

You're missing the whole point. The point is not that missiles are easy to build. The point is that military interventions planned not only to prop up logistics but also to accommodate for supply constraints. There is no plan on earth that consists of firing a constant barrage of expensive missiles, and instead you have armed forces planning around using dumb and cheap alternatives that are easier to source and provision.

And Trump did nothing of the sort. There was no plan, no exit strategy, nothing. Not even a war declaration to kickstart the country's logistics infrastructure. Of course ammo runs out if there is no plan to provision it.

> This isn't the 1940s anymore where you can convert every car factory into making tanks and missiles.

That's also another point you missed. Trump even failed to mobilize the infrastructure to supply with basic ordnance. There is no plan.

Pay attention to what you are saying yourself: how do you start a war when you don't even secure your own supply needs for the first weeks of the engagement?

https://en.wikipedia.org/wiki/Reactions_to_the_2026_Iran_war

I don't think so. This observation completely misses the root cause, and it ain't missiles.

Armed forces size their stockpiles in terms of their short term needs focused on rapid reaction and deterrence. The goal is to be able to react to immediate threats and then shift the economy to a war economy to supply the effort in economically efficient ways.

What failed this time is that the trump administration was hoping to attack Iran without having to declare war, effectively starting a war without preparing for the war.

The results are obvious: the peace time stockpile was depleted at a time where the country was not prepared to replenish it. Trump shifter the us armed forces to deplete their stockpile while avoiding the responsibility of supporting them in their mission by taking care of supplies.

And so they ran out of ammo.

There are further compounding factors such as a lack of plan and lack of exit strategy. But placing your military in a state where they spend their ammo without any plan to ressuply it... You will have the same problem if you replace hellfire missiles with sticks and stones.

Training is a red herring. The root cause is constraints, or lack thereof. If you lock a junior dev in a basement and force him to deliver the same features that these LLMs output, you will see exactly the same type of slop. The root cause is that junior devs are inexperienced and oblivious to best practices and guidelines and even the team's internal standards. They output code unconstrained by these guidelines and thus output big balls of mud.

> I'm being tongue and cheek, but as someone who uses these things extensively in work and personal projects, I want to point out that it's new or novel that generating lots of plausible code is now vastly cheaper than it once was, so the scales are quite different.

I agree, but we need to be mindful of what is the actual root cause. I argue it's not AI coding agente but the diverse source of these code changes, which we also see in production settings in projects managed by large teams. In teams manned by junior devs you see very much the same slop building up to a big ball of mud in a few iterations. This is nothing new. What changed is that now ai coding assistants grant everyone access to what amounts to a large team of junior devs.

I don't think this personal opinion holds well when contrasted with reality. The truth of the matter is that in moderately large codebases, which is the norm in any production setting, at best you have a T-shape understanding of the system: in specific areas you might have somewhat deep understanding, but for the vast majority of the system you have at best a high level understanding of the software architecture.

This is why software engineering frames things like design patterns, principle of least surprise,single responsibility, etc as premium design and code quality traits: they allow developers to effectively extrapolate their high level understanding of the project onto components they know nothing about.

In any software development setting,you will find that the most successful and even senior engineer is that which successfully and skillfully manages this uncertainty, and is able to hit the ground running on environments they never touched. I had a colleague who once was a senior software development engineer at a FANG that mastered this art, and called it JIT onboarding.

So why are you pretending this is something new or novel?

I think this blend of criticism only serves to allow inexperienced developers to stand out by complaining that a very mundane aspect of working on projects as a member of a sizeable team is somehow a novel development caused by LLMs.

And don't get me started on the "slop" nonsense. Have you actually browsed through code written by people?

I think there's some confusion in your post. You're seeing people claiming that the rate their code changes is so fast that they find it hard to keep their mental model up to date and in sync with the actual codebase. They frame this as a LLM issue, but those of us who worked in large teams will understand how it feels to be faced with a dozen changes popping up in critical areas of a code base each time we prepare to submit our own code change.

Once you understand this, you'll easily understand where all the efficiency gains are manifesting. Today's lone cowboy developers are experiencing the same type of struggles to keep up with a project that in the recent past affected projects worked on by large teams.

I mean, think about it for a second: what do you think is behind this higher rate of change?

This is a very ignorant and even cynical comment. You purposely omitted the fact that "the western world" was collaborating with China to the point where major corporations were developing tight partnerships, but only to see those partnerships being used to steal trade secrets about outright clone whole product lines.

To make matters worse, China is simulaneously demanding "the western world" transfers all tech to china while refusing to collaborate or even allow western companies to operate within their country.

Shall we talk about the extent that China has been targeting ASML industrial espionage?

https://www.asml.com/en/news/press-releases/2019/asml-disagr...

You are describing a templating system. It's useful to create projects from scratch, but that's not what software engineers do 99% of the time.

What software engineers do 99% of the time is modifying existing services to adapt to changing requirements that more often than not are grossly unspecified.

Also, a key part of a software engineer's work is serve as a point of contact with non software engineers to discuss what services do and plan work.

> If you were really good at your job as a contract software engineer in the past, you would basically just automate yourself out of a job and have to find a new one anyway. This just accelerates it.

I don't think this assumption holds water. At most your efficiency improved as short contracts to patch random customer projects now can meet the definition of done (maintenance be damned) in shorter iterations.

However, ironically we are also seeing the occurrence of consultancy firms specialized in providing software engineering services as contract engineers that are explicitly marketed as solutions to problems introduced by vibe-coding.

A few years ago I worked at a company who had a team of QAs dedicated to do manual acceptance tests. Up until the day where a critical regression went unnoticed and it turned out QAs were going through the test suite without actually checking the behavior. Following that the company got rid of all QAs except the software engineer in testing who was responsible for the whole automated test infrastructure, and instead of QAs the team held test days to go through the same manual test suite while we progressively automated them away.

And the whole process improved all across the board.