This looks like LLM slop (not only the writing, but the analysis itself).
To start, it is based on a single machine check. It has little context, but if this was a common problem, I'd expect more data points.
The MC happened 8 hours after the freeze. It's not unusual that a hardware/kernel failure cascades to multiple subsystems so I'd be sceptical that the MC has a direct relationship to the root cause of the freeze.
(Part 13) Why does it quote an Engineering Change Notice rather than a consolidated spec?
(Part 11) LaneErrStatus=0xFFFFFFFF is 32 bits. As far as I know, PCIe x32 is very rare.
(Part 8.4) How is it surprising MMIO isn't included in memory dumps?
(Part 4) How is the definition of a MCE relevant here?
The security model is that applications run in a sandbox (e.g. Flatpak, snap) and only get D-Bus, Wayland, etc. access via restricted means (e.g. xdg-dbus-proxy).
The "friction" is that Wayland developers don't want a sandboxed application with access to the Wayland socket to pwn your machine.
Trying to isolate applications within the same UNIX user is essentially unfixable since there's ptrace, LD_PRELOAD, /proc/$pid, .bashrc drop-ins, etc.
The author must know about all of this, as it's mentioned in the LD_PRELOAD note in the end. In my view, the model he proposes is security by obscurity (putting hurdles on top of a fundamentally insecure system).
There's definitely some that hold CQRS, DDD, TDD, ... as _the_ way to design software and over-engineer around it, so I can understand some pushback.
Knowing those patterns is very helpful as a way to think about design problems, as long as you have the common sense to realize applying the pattern "by the book" is often overkill and you can just take some ideas out of it.
That article conflates as "Pure engineering" both reducing a software system to a small set of cohesive concepts, and architecture astronauts, when those are polar opposites.
When all leadership is asking is "what is the short term business value?", it's pointless to make that case. It's much easier to measure "yet another feature" than "fix the root causes of what makes our product subpar and slows us down". Not only that, but an incompetent engineer's "tech debt grooming" may make things worse.
I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.
In the long term, once the damage from vibecoding is better understood (for customer impact and team morale), there's an incentive to push them out, both from the leadership and the individuals side.
I assume it can be different for everyone. This post resonates with me, but my social anxiety mixes being sensitive to negative feedback and low self-esteem.
So, you want to avoid both being disliked, but also being liked - because this puts you in novel situations you fear lead to an even bigger failure down the road.
> Maybe things are this equal and fair on the senior, high-paying part of the spectrum
I don't think the fundamental dynamics change by seniority, just that after some level there may simply be a smaller pool.
From the interviewers perspective, it makes sense to reject a candidate if they see any possibility it could be a flop. A bad hire is going to frustrate the team and look bad to the company, missing the best candidate is just going to result in hiring their next best pick.
> As someone just starting out, the general feeling among my peers is that I must bend to the interviewer's whims, any resistance or pushback will get you rejected.
I guess this is very context dependent but I can also see "bending to the interviewer's whims" backfiring if they see you're just trying to flatter them. I could see some interviewers valuing that you can explain your point if it's framed in a way that shows you are both observant and easy to work with. If it's framed as a more aggressive kind of pushback, yes that's going to get you rejected.
But yeah, I can also see that if you're willing to take any offer at any company as a junior just to get your feet into the industry most interviewers may not be specially smart and resisting is likely to go wrong.
Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`.
In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.
Welcome to the web side. Everything’s bonkers. Hard-earned software engineering truths get tossed out, because hey, wtf, I’ll just do some stuff and yippee. Feels like everyone’s stuck at year three of software engineering, and every three years the people get swapped out.
That's because they are being "replaced", in a sense!
When an industry doubles every 5 years like web dev was for a long time, that by the mathematical definition means that the average developer has 5 years or less experience. Sure, the old guard eventually get to 10 or 15 years of experience, but they're simply outnumbered by an exponentially growing influx of total neophytes.
Hence the childish attitude and behaviour with everything to do with JavaScript.
Sorry, I had assumed this was what you were doing when I wrote my question but I should have specified. And sorry for now making your npm install step twice as long! ;)
npm ci should be much faster in CI as it can install the exact dependency versions directly from the lockfile rather than having to go through the whole dependency resolution algorithm. In CI environments you don't have to wait to delete a potentially large pre-existing node_modules directory since you should be starting fresh each time anyway.
Yeah, I think I had made the assumption that they were using `npm ci` / `yarn install --frozen-lockfile` / `pnpm install --frozen-lockfile` in CI because that's technically what you're always supposed to do in CI, but I shouldn't have made that assumption.
For as much as the author may get roasted for stating the obvious, I've often seen this "measure everything" mindset, coming from those you'd think should know better than that.
I've even seen this stupidity in myself sometimes. In a way it's funny how you can get so lost on the numbers that you forget about the thing.
This is just the frame that the author is trying to prop up in order to sell us their shallow, meaningless piece.
I wouldn’t normally even comment something like this about someone’s article, but I see this pattern a lot in “influencer” content that people sometimes share with me and I am worried that if we don’t point it out, we will lose our ability to spot nonsense like this and side step our critical thinking.
The “trick” is contrasting or relating something completely irrelevant to some sort of nonsensical or obvious “thought piece”.
I am sure this is some sort of named fallacy and someone else can explain it a lot more eloquently, but this is my attempt.
Look at my other posts and you'll see I'm not like an "influencer content" person. I purposely made this piece shallow to encourage more people to read it and discuss the core idea, rather than get distracted by specific examples or points.
I've blogged long enough on a personal level, done corporate PR long enough at a professional level, to know that the more words there are, the more people get bogged down in the details.
I plan to follow up this post with specific callouts and associating it directly with my work (both positively and negatively). But, for example, if I used Terraform as an example of something in this (hypothetically), people would focus in on arguing the merits of "feeling" Terraform. That's not the point.
I couldn't help but laugh when reading this, knowing that 80% of this thread would be picking apart any specific example if you provided one - completely missing any kind of "reading between the lines" message.
We have a recent hire who comes from a background where a) the user base was much larger and b) metrics were the best way to understand outcomes.
Our company is smaller and earlier than that. I enjoy the focus on metrics, it's a good push for us, but sometimes you just have to do the obviously good thing for users without trying to build a metrics framework around it.
I totally agree, I wasn't trying to push the merits of metrics. I meant that feeling and metrics are not mutually exclusive and that is what the author was trying to claim.
> Measuring and feeling are not mutually exclusive.
They are not mutually exclusive, but they compete to a degree. If someone's time is mostly spent on what can be measured, they can't spend time on "common sense" or investigative work that is less easily tracked. At the end of they day, trying to measure everything makes as much sense as trying to document every line of code. (Most of this, naturally, also applies the other way around).
> This is just the frame that the author is trying to prop up in order to sell us their shallow, meaningless piece.
> I see this pattern a lot in “influencer” content that people sometimes share with me
I think a lot of the shallowness is from blogs or HN being a public, persistent, broadcast written media. In a face to face conversation, you can generally follow up and share more specifics and nuance without fear of getting a bad reputation.
If anything I think the bias is the other way around, on the Internet whatever you write can get cherry-picked and framed to make you appear terrible, in person it's much easier to get a fair sample.
I'd say the opposite, LLMs are a know-it-nothing machine to perfectly suit know-it-alls. Unlike a human, it isn't that hard to get the machine to say what you want, and then generate enough crap to 'defeat' any human challenger.
To start, it is based on a single machine check. It has little context, but if this was a common problem, I'd expect more data points.
The MC happened 8 hours after the freeze. It's not unusual that a hardware/kernel failure cascades to multiple subsystems so I'd be sceptical that the MC has a direct relationship to the root cause of the freeze.
(Part 13) Why does it quote an Engineering Change Notice rather than a consolidated spec?
(Part 11) LaneErrStatus=0xFFFFFFFF is 32 bits. As far as I know, PCIe x32 is very rare.
(Part 8.4) How is it surprising MMIO isn't included in memory dumps?
(Part 4) How is the definition of a MCE relevant here?