I find it interesting that this is the conclusion you draw from this. I won’t go into a discussion on the efficacy of the various mandates and policies in reducing spread of the disease. Rather, I think it’s worth pointing out that a significant portion of the proponents of these policies likely supported them not because of a desire to follow the authority but because they sincerely believed that a (for them) relatively small sacrifice in personal freedom could lead to improved outcomes for their fellow humans. For them, it was never about blindly following authority or virtue signalling. It was only ever about doing what they perceived as the right thing to do.
So if the arguments are rooted in medical reasons, it's okay to be inhumane? Nazi propaganda argued that getting rid of Jews helped prevent the spread of diseases, because we all know that Jews are disease carriers. See how slippery the slope is here? Certainly you have seen the MAGA folks point out the measles outbreaks are coming from illegal immigrants, right?
I am quite sure that people felt justified in their reasoning for their behavior. That just shows how effective the propaganda was, how easy it is to get people to fall in line. If it was a matter of voluntary self sacrifice of personal freedoms, I wouldn't have made this comment. People decided to demonize anyone who did not agree with the "medical authority", especially doctors or researchers that did not tow the party line. They ruined careers, made people feel awful, and online the behavior was worse because how easy it was to pile on. Over stuff that is still to this day not very clear cut what the optimal strategy is for dealing with infectious disease.
COVID restrictions were public health, an overriding concern listed in the US Constitution as general welfare as a reason for the US government to exist at all.
Yea, closing beaches and parks is on par with the Nazis did to the Jews.
The Covid measures were also totally targeted at certain groups of people with immutable characteristics and not at people who actively wanted to spread disease.
How are people like you still making arguments like this in 2026? Were you also one of the people claiming we’d all be dead in a year from the vaccines?
https://frodejac.dev is my personal site. Perhaps more interesting is https://notes.frodejac.dev which is more of like live journal, primarily built as a way to learn Go and SQLite. Wish I spent more time adding content to it, though. I have quite a few interesting topics to write about, but rarely find the time to do so.
That’s already addressed in the article; it’s like paying off credit card debt with another credit card.
I guess it all depends on your end goal. If you intend to make your vibe coded app into a profitable, maintainable product with any sort of reliability guarantees you better understand its failure modes and how to fix things when they break. It’s really hard to create recovery procedures for a black box.
No one’s being forced, but we’re encouraged to explore and experiment with AI tools. And not just for writing code. It's a quite firm belief in the company as a whole that the winners in the 'AI age' will be the companies that are able to utilize AI tools improve their internal workflows and become more productive. So we get to try out lots of different things, and we make sure to share our learnings with each other.
I would argue that is a feature of pair programming, not a bug. By forcing you to use the slower I/O parts of your brain (and that of your partner) the process becomes more deliberate, allowing you to catch edge cases, bad design patterns, and would-be bugs before even putting pen to paper so to speak. Not to mention that it immediately reduces the bus factor by having two people with a good understanding of the code.
I’m not saying pair programming is a silver bullet, and I tend to agree that working on your own can be vastly more efficient. I do however think that it’s a very useful tool for critical functionality and hard problems and shouldn’t be dismissed.
I guess it depends on a person. My experience is close to that of 'ryandrake.
I've been coding long enough to notice there are times where the problem is complex and unclear enough that my own thought process will turn into pair programming with myself, literally chatting with myself in a text file; this process has the bandwidth and latency on the same order as talking to another person, so I might just as well do that and get the benefit of an independent perspective.
The above is really more of a design-level discussion. However, there are other times - precisely those times that pair programming is meant for - when the problem is clear enough I can immerse myself in it. Using the slow I/O mode, being deliberate is exactly the opposite of what I need then. By moving alone and focused, keeping my thoughts below the level of words, I can explore the problem space much further, rapidly proposing a solution, feeling it out, proposing another, comparing, deciding on a direction, noticing edge cases and bad design up front and dealing with them, all in a rapid feedback loop with test. Pair programming in this scenario would truly force me to "use the slower I/O parts of your brain", in that exact sense: it's like splitting a highly-optimized in-memory data processing pipeline in two, and making the halves communicate over IPC. With JSON.
As for bus factor, I find the argument bogus anyway. For that to work, pair programming would've to be executed with the same partner or small group of partners, preferably working on the same or related code modules, daily, over the course of weeks at least - otherwise neither them nor I are going to have enough exposure to understand what the other is working on. But it's not how pair programming worked when I've experienced it.
It's a problem with code reviews, too: if your project has depth[0], I won't really understand the whole context of what you're doing, and you won't understand the context of my work, so our reviews of each others' code will quickly degenerate to spotting typos, style violations, and peculiar design choices; neither of us will have time or mental capacity to fully understand the changeset before "+2 LGTM"-ing it away.
--
[0] - I don't know if there's a a better, established term for it. What I mean is depth vs. breadth in the project architecture. Example of depth: you have a main execution orchestrator, you have an external data system that handles integrations with a dozen different data storage systems, then you have math-heavy business logic on data, then you have RPC for integrating with GUI software developed by another team, then you have extensive configuration system, etc. - each of those areas is full of design and coding challenges that don't transfer to any other. Contrast that with an example of breadth: a typical webapp or mobile app, where 80% of the code is just some UI components and a hundred different screens, with very little unique or domain-specific logic. In those projects, developers are like free electrons in metal: they can pick any part of the project at any given moment and be equally productive working on it, because every part is basically the same as every other part. In those projects, I can see both pair programming and code reviews deliver on their promises in full.
Agreed, particularly on code reviews: the only useful code reviews I've had were either in an outright trainee/expert relationship or when the reviewer is very experienced in the gotchas of the project being modified and the reviewer is new.
Peer and near-peer reviews have always wound up being nitpicking or perfunctory.
An alternative that might work if you want two hands on every change for process reasons is to have the reviewer do something closer to formal QA, building and running the changed code to verify it has the expected behavior. That has a lot of limitations too, but it least it doesn’t degrade to bikeshedding about variable name aesthetics.
