I feel similarly.
I've been pure remote since COVID.
I used to complain about having to come into the office just to stare at a screen quietly next to people.
Being remote has been great in some ways, but I've really noticed the reduction in connection to coworkers and the major decline in informal collaboration. I've also had to dedicate a room of my house as an office (have kids, so working from any common space is fully impossible).
My life just feels smaller now, when most days instead of traveling through the city on a busy train to meet up with dozens of collaborators, discuss, eat together, I start my day by sitting down in a small room by myself in front of a screen.
Work is what I do with most of my days. I'd like it to be as engaging and as socially connective as possible. I don't like commuting, but I'm planning for my next job to be in person.
This is why I like more bottom-up approaches to coding.
Code broken up sorta arbitrarily, that's compressed moreso than abstracted, is hard to follow.
But, when there's a reasonably small set of solid domain abstractions (even extremely complex ones in implementation), that's totally fine.
This is where preferences vary; some folks have committed nuances of various helper libraries to memory, and find it easier to process a `fuse_zip` combinator or whatever than a loop, but for the readers who'd need to look that up, it's an attention land-mine.
API design, abstraction design, is a type of UX design, and like other forms of design, accessibility is a concern. Keeping the vocabulary fairly small and the abstractions well-behaved and consistent help nearly everyone, but particular ADHD folk.
An underrated factor in this conversation is implementation effort.
Javascript is arguably the most widely run interpreted language in the world.
Pre-Chrome, JS was uniformly rather slow, but Google was betting on webapps being good and usable, so they brought on some top-tier compilation/VM talent to build V8. As fast Javascript existed, it made it possible to do more natively in the browser, and other browser vendors joined in an arms race there.
Tons of effort overall, tons of money and time from top-tier experts.
There was no equivalent competition between major organizations to make Python fast. Folks have tried, but not on the same scale.
Yes, factors like language design and existing ecosystems entanglements played a role here, but if Python had the investment in performance Javascript had (financial and expert attention), it'd be dramatically faster today (though it may have required a fork or similar, depending on how tied to simplicity Guido was feeling).
To be clear, I'm not saying nobody tried to make Python faster, or that Python devs don't know what they're doing. I know very well both of those things aren't true. But, the kind of sophistication required to make Python fast in absolute terms is very hard to build and maintain, and for various reasons nobody who has found Python to be too slow has found "invest in a bunch of person-years of VM engineer attention dedicated to performance work" to be their best path.
I imagine it varies, but from most people I know, it's the very definition of "labor of love".
It's certainly a big time and effort commitment and sometimes you'd rather not, but there's basically nothing in life I care about more than my kids.
And they can, in a moment, give me more joy or fulfillment than I'd find in a week in my pre-kids life.
I'm someone who needs alone time, and it's really hard for me at times, but their wellbeing impacts my wellbeing more than my wellbeing does, they sorta naturally became my #1 priority in life, so anything but taking care of them to the best of my ability simply doesn't make sense to me.
it's funny, because I believe the author has contributed to at least 4 of these directly in his day job, and has published code for a few more.
But I guess you can't buy bread with substantial contributions, if ability to buy bread is our metric. But it's not a good metric.
Is the point of this that you can do large-scale data processing without the overhead of distribution if you're willing to pay for the kind of hardware that can give you fast random access to all of it?
We've found this to be basically true. Git operations that stat() a lot are dramatically, catastrophically slower on OS X, and that's part of why my employer started doing fs watching there and mostly left Linux as is.
More than once I've had to update a cross-platform tool to avoid stat()ing because though cheap on Linux, it took 10s of seconds on OS X.
Work is what I do with most of my days. I'd like it to be as engaging and as socially connective as possible. I don't like commuting, but I'm planning for my next job to be in person.