My answer to the question would be: start explaining what you're asking the OS to do when you run your program. There's an entire category of developers who view the IDE and the language as a perfect hermetically sealed environment, until they meet a leaky abstraction.

Some favourites:

1. Depleting the outbound TCP ports because ports aren't infinite and the code didn't know that.

2. Any nodejs BS that involves a precompiled C lib, where homebrew or some nonsense 'just works' on the dev machine but prod runs alpine/musl. NPM sneaking arch specific blobs in is really to blame here but what do we expect from the failed state of package managers.

3. Assuming latency is not a thing. Network calls everywhere. No management of timeouts / killed connections.

4. Memory, in all shapes and forms. Most typically thinking a GC prevents memory leaks, but more generally, having no clue whatsoever what the memory usage profile of the application is.

A systems engineer (IMO) has much better answers to these questions than a regular developer, and it is absolutely mostly arcane nonsense, (ulimit anyone?), until it isn't.

Personally I love OS tech so maybe I'm just cut out for it. I used to be able to tell what the machine was doing from the HDD whirrs and still have a 'feel' for system latency, e.g. when something completes too quickly.

After 17 years in this career, I dislike calling myself a "software engineer" because it's a meaningless term that now is used to describe anyone that knows how to build a web page. "Full-stack engineer" has also been stolen from us by recruiter to refer to frontend devs. WTF.

As a teenager I started doing software interfacing with hardware, reversing on Windows then I wrote my own mini OS, got a job and did web dev, sysadmin, backend, infrastructure, and CTO, alongside dozens of consulting contracts.

I get hired to fix a problem, and soon enough I'm diving into the technicalities of the network stack, or tracking down a bottleneck with spit and strace, or scaling an infrastructure horizontally and making it fault tolerant.

At this point most of the value I provide is not in the volume of code I deliver, but designing, operating and maintaining systems as a whole. A systems engineer, if you like, but as the article mentions, that's a real qualification that's got nothing to do with this.

The issues is that in the job market I have to compete with everyone called a software engineer, slap a senior to it, which these days refers to anyone that has 5 years of experience, and feel it's very hard to convey to a recruiter the depth of my experience. A programmer operates on code, a "systems engineer" looks at systems holistically, horizontally (i.e. architecture) and vertically (i.e. diving down the stack)

My personal record is two characters of code per two weeks of work.

Embedded device kept crashing when initializing GUI rendering library (a precompiled one, STemWin IIRC). Two weeks of disassembly, instruction-level tracing of the MCU core narrowed it down to the contents of external RAM not being correct (that is- what was being read did not match what was being written).

Some more poking with oscilloscope, reading the datasheets and low level memory initialization revealed an incorrectly set RAM configuration register that was related to burst writes. RAM test during bringup used word-by-word writes, but when DMA was used only the first word in transaction was written correctly.

Mine is approximately minus one instruction per week, and it was the best money the company ever spent. Hard real-time is hard. (It was a strange processor with, among other things, delay slots everywhere, so you could never make just one change without ripple effects.)

It's sad but I'm pretty sure "types" like you all will be labeled "enemy of the state" soon... Oscilloscope ? Registers ?? ;)

That is, if things will keep going the way things are currently going - corporations, banning periodic tables from schools, elected stallers and clan mentality on all levels.

I just dabbled in embedded, once debugged an arduino I2C peripheral, went through the same process, but never fixed the problem :) I was easier to get a different peripheral.

Pretty much yeah. I can relate to everything you write there. I always thought most of this is related to when I learned reverse engineering in high school. That's basically when I started understanding memory and why it mattered.

Unfortunately recruiters also don't understand the kind of profile, they just lump us in the group of "generalists" and say you need to specialize if you want to progress and yet in a lot of projects I often ended up understanding more about the details than the so called specialists.

I once had a client that I saved dozens of millions a year due to a fix that they had accepted as "just part of the system" only for the manager to fire me with a severance, because by fixing it I undermined his decision to scrap the project.

Self deprecation and lauding aside, I’m curious what new titles others would propose? When I migrated into the field many moons ago, the two titles I saw mostly were “analysts” and “programmer”. The first had underpaid connotations, the second was rife with social awkwardness cues that Hollywood had run with for a while.

Historically known as or referred to as a "Renaissance Man" [1] or polymath [2].

[1] https://en.wikipedia.org/wiki/Renaissance_Man

[2] https://en.wikipedia.org/wiki/Polymath

But very very frustrating for the world to work in such an anti-productive and nonsensical way. I also wonder if you would have been fired anyways when the old system was scrapped.

I've heard that one before, so I'm going to agree. It's also inline with what the guy told me.

The system wasn't being scrapped they were just going to pay for almost triple the infrastructure. But yes, this was the first time I was exposed to performance reviews, I was as you said hired for something else entirely and it's possible that I would have been fired anyways since my job was actually about writing firmware and migration tools to migrate away from the old system(which also saved them a couple of millions a year). The performance review itself was however about tasks completely unrelated to what I got hired for.

I have done mostly contract work since then, but I am wondering if it is common to put your actual job content into your hiring documents to make sure people don't do performance reviews about unrelated tasks?

Honestly for contract work (and usually also full-time employees), the best thing you can do is focus on all the people who are responsible for your performance review and make them happy, make their initiatives look good, and get along with them so that they like you. Sometimes this means doing completely different work than you thought you were hired to do. Or doing all that in addition to what you were hired for.

The absolute worst case for a contractor is that you're "hired to fail" where there's a project with a 90% chance of failing so they bring in a contractor/team who either miraculously save it, or you're blamed for the expected failure. However, even here, if you show competence and make friends with the people who will stab you in the back in the short term, you may also find that some of them call for your services again in the future -- because you did "the job you were hired to do" and made it easy for them, made them look good, and were enjoyable to be around.

The written "rules" of the performance review don't matter, at least in the USA (maybe different in other countries). Performance reviews basically boil down to "how much do I like working with this person?" which definitely includes competence (people mildly dislike working with incompetent people), but also includes things like "makes my day happier" or "great conversation over beers / at the sports game".

I'm mid 30's and have worked a few contracting gigs but never really made it work out (usually it coincided with life being a little too chaotic at the time for me to fully focus on my client). So hopefully some others with more experience will chime in. But there's a lot written on this topic on HN, you can find a lot of experienced views from all sides of the table with a bit of searching!

Despite the terminological thefts and oversimplifications, I'm still proud to be a part of this industry. We're like the James Bonds of the digital world; we go by different names, but the substance of our work and our contributions are what truly define us. So, let them call us whatever they want... They may not always understand what we do, but they sure as hell need us to do it!

Doesn't really bother me, although it does make evaluating what you might actually DO in a particular role challenging. In this "SRE" position am I writing Kubernetes operators in Go, or am I a Jenkins pipeline janitor, or am I working the graveyard shift in a data center swapping dead hard drives? WHO KNOWS!

I'll cut a bit of slack to the frontend as it's also gotten significantly more complex over the last decade or so. I've seen places where frontend means "our iPhone app". Microsoft Office now has a version that runs in the browser.

Complex job, but a fun one! And crucially important for any product more complex than a dish washer.

But please, don't steal the name for some software "engineering" role...

In that sense the naming has been misappropriated in the SV tech circle to mean a "backend engineer that actually understands what is going on under the hood" sort of role.

My father was an electronic engineer, and I would love to get into it eventually as I grew up organising his components drawer, burning LEDs and licking solder wire (yeah.. I regret it now), but that's going to be something I'll have time for when I retire.

I think I can an extend a little into the non software realm, though my undergrad degree/ first jobs were in civil engineering. I migrated to computers and ended up going back to school for that.

I work writing software for biologists now, though my understanding of the underlying biology in that is shallow (Compared to my biologist coworkers)

I loved the story about how a developer of ZFS, from the Sun days, went down a rabbit hole of optimizing the filesystem because he didn't like the sound hard drives made on certain write loads. Turns out he was right, there was funky stuff going on with the I/O scheduler.

Too long ago, I don't remember the source, sorry.

This is a tell. You’re old enough that stacks used to be shallower and you were closer to the OS.

For some reason whenever text is updating it makes a faint buzzing noise.

The matrix movie joke about seeing code is actually pretty close to the truth. Not necessarily a sign of a great programmer, but still a nice skill to have.

https://www.theguardian.com/technology/askjack/2010/mar/03/p...

Now I have a not so fun job at Big Tech doing SRE type work; all of that mucking around is abstracted away from me.

I guess that dimension of debugging is now lost with SSDs. I didn't run an anti-virus and noticed by machine had caught a virus (in this case, DOS/Natas) because of the extra moments of whirrs during boot and when running applications.

I wonder how much slower processes would run if you generate sound on the computer itself from every hard drive write. I don't have deep enough knowledge about the OS to know where you would run your sound program without affecting performance (i.e., are there log files that could be read, so it is not directly interacting with the hard drive writes? would those still be timely enough to give a good indicator of what the computer is actually doing?)

If that could be solved, then you could have a sound for network activity, every time a kernel module loads, etc, so users don't need to have deep knowledge of the system to know when there is a problem- they just have to learn what sounds right. I think it would be really neat to have music made by the machine itself and love the idea of adding back that dimension of debugging.

I've seen some replies that this is basic stuff everyone should know, but the fact is, people don't. Even Senior or Principal engineers (depending on the company). You can get very far in software engineering without understanding anything outside the bubble of your domain. Hell this is basically why the field of SRE exists, because a lot of developers do not know how to write reliable software that works in the real world, not just in a perfect test environment. If you've somehow worked your entire career surrounded by engineers who have even an entry level understanding of how networks function, you're the outlier. More often I've found people invent their own bizarre mental model of what's happening that only has the vaguest grounding in reality.

And honestly that's ok much of the time. Everyone can't be an expert in everything. Just have some grace about it. Don't pull a Dunning-Kruger and assume because you are a fabulous Java developer you are automatically an expert in every technical field. Most of us aren't.

2) You threw a one-line, no-help comment out there. That's going to get you downvoted unless it is at least interesting or funny.

3) Now you're complaining about downvotes, which is a big red sign for "downvote me more, for I am mad".

Of course it can be argued that language evolves like people, but after all, also in physics or mathematics we don't just replace or redefine terms ad libitum (you won't pass exams if you use your own terminology), and on systems engineering there are university courses and a well established scholarship (at least there were when I was a student many years ago).

... a scientist.

My first job title at my current workplace was "systems engineer." My degree is in physics. I evolved into the role of being the person on the project who understands and can explain how the whole thing works. It doesn't mean just dictating a theory of operation, but also testing that theory.

My job is in an area where products involve both hardware and software. I certainly don't claim to know every design detail. Part of the trick is figuring out what things I actually do need to know, and how to nail those things down.

This sort of thing comes up a lot while programming. Something weird happens and you start to wonder - why does it behave like this? Answering these questions has led me all sorts of places - to reading specs, debugging into databases, compiling my own Firefox, all sorts of things. The chance this knowledge pays off sooner or later is wildly high.

Computers are deterministic and debugable. You usually have the source code and everything it does was designed and written by people like you. A curious, scientific attitude is a beautiful thing to nurture in software.

Be careful to make sure that it was actually a "debug mode only" assertion (Chesterton's Fence and all that). I have seen too many programmers assume that when it is not necessarily true. Assertions are for establishing "Program Correctness" and hence many are left in Production Code. Of course how you handle it i.e. log/die/catch clause/signal trap is up to the system design.

and

> you start from the assumption that when you see something, you wonder why it is the way it is. Then maybe you observe it and maybe do a little research to figure out how it came to be the thing you see in front of you.

These both resonated with me deeply. I see a lot of people in tech who got into it for the money, or -- more charitably -- because they thought it might be cool, without much depth to that determination. I got into it in the late 80s, when I was 8 years old, because I was intensely curious about how things (first mechanical, and later digital) worked, and wanted to know how, and wanted to be able to make things that worked in the same way.

I'm not saying the first category of people are deficient, but I definitely see people like that struggle with things that seem fairly obvious to me. Of course it's just because humans are pattern matching machines, and I've devoted a large chunk of my life to exploring these sorts of patterns, at many different levels of abstraction.

I'm not trying to say I'm somehow so cool or a better human because of it, but I do think that "being a curious person", and having been acting on that curiosity all your life, really does give you a leg up when it comes to tech-focused fields (and presumably others, but I don't have experience with them, so I can't say). Most problems boil down to a much smaller set possible solutions, and being able to see the patterns that get you there can take more experience and time than many people are willing to devote.

I read this, and instinctively thought, "Wow - this person's old! This'll be a cool historical anecdote".

Then I remembered I was also 8 in the late 80s. (I had an old BBC B Microcomputer I programmed on badly.)

So I’m then terribly old. And I have lived a life driven by curiosity for everything. I’m no system engineer for sure but have self discovered a lot that sometimes proves useful and engineers and fellow product managers are like “ WTF how did you know that?!”

The good old school system engineers knew how and why the software worked from the metal to the terminal and how to use the whole system productively. I’m in awe of such people and they are a privilege to work with.

Oh and FTR started programming with punch cards when at high school. Used a local bank to compile Fortran.

It definitely isn’t for everyone and you need to be very persistent, but I enjoy not having to relearn tech stacks every 4 years and job security for Wizards tends to be quite good. The downside is you can spend 80+ hours tracking down a bug that results in a one line change (don’t ask me how I know).

We don't need to ask, we've all been there :)

In short, 'systems engineering' as an engineering discipline has nothing to do with managing systems, servers, and networks.

Outside computing, "systems" include non-computer entities.

Where a systems technician may get in trouble: accurate and proven floating point calculations and where it comes from (minimal polynomial, range reduction, etc), real understanding of the maths of cryptography. Proofs of common performant algorithms (ring buffers synchronized with atomic variables, unification,etc). It may need a deep understanding of signal processing, depending on the field, etc etc.

But since everything was already put in boxes (libs), a systems technician can re-use mostly all of them: the set of skills required is no higher than high school level.

Basically, an engineer has a deeper undertanding of information systems, but work most of the time as a "technician", and has some background knowledge to help him/her ramp up on tricky stuff.

Can software based systems engineers please call themselves software systems engineer.

I've been a 'traditional' systems engineer for many years and when searching for jobs (or with recruiters), it's always a mess trying to filter out the software only systems engineering gigs.

I use a lot of software in my work too, it's just that I also have to do 'hardware' by the end of the work.

It's not a big ask (I think), but man, would it make a lot of sense.

So, par for the course on this blog.

The article just seems to be a series of ramblings. I am not quite sure why people are enamoured of it.

Seriously though, if you look up "systems engineering" on Wikipedia, it talks about "how to design, integrate and manage complex systems over their life cycles". That's definitely not my personal slice of the world. I don't think I've ever taken anything through a whole "life cycle", whatever that even means for software.

Just have to love the beginning!

One idea a young grasshopper might keep in mind: maybe most all fields are such, that you'd be grumpy about a lot of things in them, once you have decades of understanding.

So, if someone is telling you that the reality of field A has a lot of downside, but you're not hearing that about field B... maybe the situation is that you aren't hearing from someone knowledgeable/representative/honest enough about B, but you have a rare opportunity to learn from a straight-talking expert in A.

And even though your specific application won't EOL, there are many times where features are deprecated and that complex system must be altered. Maybe I'm just grizzled in my old age, but it seems like this author was writing about Systems Engineering while claiming not to know what it is..

You don't need to understand the product management or biz management side, but it helps. A Senior needs to understand the basic phases of an engineering product's lifecycle from birth to death, and how to design for and complete each one. But a more standard systems engineer just needs to understand how systems work, how they are designed, implemented, and kept running. The rest comes over time.

You don't have to be an expert in every part of the product. Like, you don't have to be an Operations Manager to engineer a product for production. The "boring" engineering work is all that's required. But it really helps to know a bit about everything else: how to find requirements, draft designs, liaise with stakeholders, make a POC, test it, implement components, tie them together into a system, test it, run it. Having a sunset plan is also great but not required.

It definitely helps to have some experience in the industry you want to work in. If you wanna build a candy factory, having interned on the factory floor helps. Having built similar machines before helps.

My company used to title me: "System Architect". Yes, always singular, they're Germans and have no feel at all for English language.

Then HR bought a pricy scheme from some consultant, and now I'm suddenly an "Advanced System Engineer". And also mightily pissed off for not being a senior title.

It's like they roll dice around here. People went from being Data Analysts to being developers and vice versa. People were assigned titles that don't fit, purely so they could be outfited with certain benefits exclusively tied to those titles in a rigid scheme.

Leave it to HR to screw over any industry naming conventions and to make my future job applications great fun, when I will explain why I'm not really that thing that's actually on my CV.

Not as pissed off as when you'll find out during salary negotiation that you're not an Advanced System Engineer after all, but an Advanced System Engineer.

It is also easy to read between the lines in the letter to see if you did just the minimum or they were really happy with you. The fear of a bad letter can keep people accountable until they leave (best case) or be used as a threat by an unscrupulous employer (worst case).

This affects international jobs a bit less, in my experience.

The second reason, nobody is asking for those anymore it seems. The last couple of jobs I took, nobody asked for any of my letters.

Otherwise I agree, it takes some internal convincing to not care about them if your are used to them your whole life.

Im short, those letters suck. And almost everybody knows it.

I also would not bet on me forgetting you, I do interview quite a few people, but negative experiences stick in my head like a sore thumb. So, I think your only options are pray that you don't meet me along the way, or someone like me. It'll be for the best for both of us, honestly.

It was really fantastic learning wise. I really got to see how things are implemented. I use those learnings even to this day. When a junior full stack developer runs into system level issues I often times see them go completely blank and I then gleefully roll up my sleeves and put on my susadmin hat, it’s quite fun.

I am actually getting my Masters in Systems Engineering and work for a large aerospace corporation - systems engineers are not admins and not even close. It’s simply not what they do.

In an industrial plant Systems Engineer is a specialized discipline in the vein of Mechanical/Chemical/Electrical etc. Engineer.

My best attempt to explain it would be a System Engineer has a multi-disciplinary holistic view of the entire "system".

In my world the focus is process specific i.e each systems engineer would oversee one particular engineering "process".

For example with a fluidized bed reactor, Mechanical engineer would be familiar with mechanical systems (valves, hydraulics etc). Electrical engineer would know about PLCs, Interlocks, limit switches, Chemical Engineer would know about things like Chromatographs, Gas Flow meters etc.

The Systems engineer knows the big picture how pieces are integrated into the whole working system.

People are overloading the term Systems Engineering.

My bachelors is in Computer Science.

Systems Engineering has its roots in Industrial Engineering. Which is why you will see courses in Systems Modeling and Analysis (eg Discrete Event Simulation), Decisions and Risk Analysis (eg Game Theory, Linear Programming), Requirements Analysis and Principles, and Researcb Methods (Factorial ANOVA, p value, t value, Residual Analysis, Regression Analysis, Treatments, etc.)

I think within the software engineering field there's a general agreement about what "systems engineering" means and entails. FWIW here's an OCW course[1]

[1] https://ocw.mit.edu/courses/6-033-computer-system-engineerin...

Systems Engineering has its roots in Industrial Engineering. Which is why you will see courses in Systems Modeling and Analysis (eg Discrete Event Simulation), Decisions and Risk Analysis (eg Game Theory, Linear Programming), Requirements Analysis and Principles, and Researcb Methods (Factorial ANOVA, p value, t value, Residual Analysis, Regression Analysis, Treatments, etc.)

Im not talking about the author, but if you have ever heard phrase "seniors with 5 x (their first year) of experience"

then not doing whole soft. dev. life cycle would be first sign of this.

Jumping between projects every year and doing similar stuff sucks, yet people do that and are proud of the fact that they change jobs every 1 or 1.5 yr

When i hire, i look for DIY skills. Tinkering with stuff. Repairing broken pens, toys, door-frames, or UIs. That has proven to be the only relevant signal. Lots of people can apply formulas. Few question them. Seems Rare skill nowadays.

Maybe because i'm DIY reverse-engineer-everything guy myself. You know, people hire their similars :)

offtopic: some very-old DIY things of mine: https://svilendobrev.com/napravisam/

pff, maybe i need to make a separate chapter on handles and hooks and such, i have (re)build dozens..

have fun

I honestly don't give a damn how my system works, so long as it works. It's just that the way I use it tends to make that a very temporary state of affairs.

It doesn't particularly matter how you come by the library of a thousand mostly useless low-level factoids about the system. So long as it accumulates, and you keep having to make use of it to work around the problems you yourself caused a few days prior, you won't be able to avoid becoming a systems person.

Today a BS in computer science covers a wide range of topics outside of syntax and databases. On the day you graduate, you have a set of hard skills writing code that are likely immediately applicable to a job and you also have more abstract theoretical instruction related to real world scale, deployments.

There are also types of problems that are very difficult to teach in a classroom setting. Those things where the core code works fine, but in a scaled production implementation, it’s not meeting the mark. Success there usually involves iterations over weeks or months to get a working solution.

Being a really great systems architect involves mixing the hard technical skills with the softer qualitative skills learned along the way.

My path to 'doing' systems engineering for a time (it really wasn't my thing) was by maintaining software an actual sys. eng. had written, fixing problems with it, extending it and eventually becoming responsible for it.

Best lol - API of a library we were using changed so that instead of taking a pointer to a struct to allocate memory for, it just wanted an amount of memory to allocate. We didn't notice, it passed all our tests (sheer luck) and dumped core on prod all day long. Funny.

"... All of these people will play a role in my ultimate success as a dystopian warlord philosopher. However, the most important person in my gang will be a systems programmer."

It's right there in the intro, truly a classic.

As opposed to some word in lower caps that would have had some bytes going over 0x7f? ('a' to 'z' go from 0x61 to 0x7a) That sentence got me confused!

It is okay to be a "developer", it's not a naughty word, and it's okay to not be an "engineer" in the sense that Rachel means it. That said, there is considerable overlap between "doing engineering" and being an effective, skilled software craftsperson. Enumerate edge cases as exhaustively as possible, capture solutions for them. Ask "what if this breaks?". Have an answer. This isn't "being an engineer", engineers get in Actual Trouble when a bridge falls down, but it is being a skilled crafter of software, and they're not dissimilar questions. The level of rigor applied might differ, but if this isn't where your brain is going by default, it is a worthwhile and even necessary skill to cultivate to build something worth using.

Of course, if you're building something people rely on, you'd better be working with and listening to people who are putting (or attempting to put; this is a young field, after wall) some kind of engineering rigor into practice.

Wait until you learn how much software is in a modern car!

Hope that helps.

Not true, just tried it in MSVC and it compiled fine but with a warning on conflicting types.

"HTTP" is of type const char* and sizeof(size_t) == sizeof(const char *). Doesn't matter if its 32 or 64, I'm not aware of a platform where that isn't the case.

> but this story is about an instance where malloc was accidentally being called with the first bits of a string instead

If that's the case, then it should have been something along the lines of *"HTTP" instead.

If I meant that it would cause the compiler to report an error then I would have written that.

> If that's the case, then it should have been something along the lines of *"HTTP" instead.

We can say that they really should have written memcpy to get the string literal into the size_t or we can accept that sometimes people use language imprecisely and expect readers to make an effort to understand rather than make an effort not to understand.

I don't disagree with you there, however, things like pointers and string literals (and what they actually represent) in my experience are a source of confusion to junior systems engineers. I'd imagine that the intended reader is someone who wants to be a systems engineer, not someone who is already a systems engineer. I expect the reader to be motivated to understand (after all, they are reading the article) but not understand and get confused because of the imprecise language, especially in the case in programming where precision matters (or the code doesn't work).

it would be neat if people ran -Wall -Wpedantic, and valgrind. but, you know, they don't.

That's kind of where people the author talked about think the magic of "systems engineer" comes from.

I'm sure you've had that one team mate who took like 5 tries to pass code review. Not every team has a you, and crazy things land in prod, because that one team mate didn't have you to keep them correct.

CHERI has sizeof(pointer) = 16, sizeof(size_t) = 8. It's probably the most widespread system where sizeof(uintptr_t) != sizeof(size_t) (and it's admittedly a niche system).

It's likely something like

malloc('HTTP') // note the single quotes

or

const char* s = "HTTP"; malloc(*s);

Also I would expect the string to be reversed if she's working on a little-endian system (which the most common ones today are, including Intel 64 bit and ARM64).

I didn't, but probably because they may read like they are lecturing Rachel. Which looks bad in itself, but feels extra ridiculous for anyone familiar with Rachel's blog. She pretty much knows how malloc and C work. She probably could write her own malloc without sweating.

Worse still, OP is seems to try to imply that Rachel is trying to lie and brag about some irrelevant gift (decoding hexadecimal in her head) by making up examples. Let's just say that it's not very charitable and it's also against HN guidelines.

OP could just have expressed their surprise and asked for some clarification instead. They are not reading "is really" correctly and not considering that Rachel is taking some shortcuts so the article remains simple and enjoyable to read, as most good writers do, which in the end makes OP's whole comment somewhat moot.

See abbeyj's reply for more context. The full explanation is in Rachel's article abbeyj points to, there's no need to guess.

edit: I had skipped the last line of OP's comment. It's just outright mean. No wonder they are downvoted actually.

it’s about building useful intuition to guide your curiosity the next time an eyebrow goes up.

bsd is used in prod only slightly more than macos.

It's not "misery is good for you" but having to solve random problems is an opportunity for learning the guts you otherwise don't get.

Linux on a laptop used to fill this niche nicely. Does it still?

being on linux means you gain intuition debugging locally. whatever you might be debugging.

to sum up my point: linux. never not be running it.

to your point, linux is a better experience now than before. this is for great good, not a cause to search for a more brittle os and distro.

at eod, os isn’t that cool. software is cool.

You really learn something keeping brittle systems functional. Linux laptops with nvidia gfx cards definitely used to qualify in ways a t480s really doesn't nowadays.

When fixing things that break, strace, gdb, perf, ftrace, BPF, write or fix a kernel device driver, understand what the OS and compiler don't do for you, what they often will do for you that maybe you don't want them to.