Otherwise excellent.

> In just a few short years, Slack has gone on to become an indispensable work tool in our always-on often mobile work life.

For you maybe? For many companies maybe? It feels a lot like the "we have no choice here" when the reality is "this is the easy path". Surprise, the easy path has huge costs!

But I'd argue that what's happened here, in most cases (and whether they believe it or not) companies have relinquished control over their distributed/remote/online/collaborative culture to Slack's definition of "what works". In my opinion Slack's vision of the future is broken because it's not truly designed to help you or your team succeed. It's designed to keep you on Slack as much as possible.

This relates in no small way to the question about corp SWE being performative that was on the front page when I puked up this comment. https://news.ycombinator.com/item?id=48475871)

If you can't tell that I loathe Slack and all its ilk, let me be clear, absolutely I do. It's a terrible way for *most* teams to work. Without a huge (and I do mean huge) about of effort to enforce and reinforce specific behaviours, Slack will push your new hires (who are less connected to the company culture than insert smaller team who came before here) to bend to Slack, and stop trying to bend Slack to the needs of the company.

This gets worse as employees now exist in a place where they can move from company to company and Slack (along with their personal Slack baggage) moves with them. A stint at four tech-companies of significant size and Slack was there, helping destroy whatever positive culture existed before.

It's not Slack's fault per se; this article illustrates one of the pillars that makes Slack at scale hard to live with: it's a noise machine. It slowly increases the noise floor until you're the frog, the water's boiling, and you're dead.

I've had folks attempt to argue about this, but they're often (not always) already boiled and don't realize it. "It just sorta happened."

Slack's perspective: "relax and just let it happen, it'll feel great."

PS - One of my interview loops from a fairly well known OSS company involved an inane question about how one might develop a product to use Slack to improve employee connection in a remote work environment. I should have read it for the very real warning that it was. But I, too, am all too happy to fool myself into believing "this time will be different".

The smartest among them can weigh opportunity costs or count, or both.

Most of the jays will take two peanuts in the shell, go crack the shell open (sounds like they're cracking eggs in the trees, hilarious), cache the nuts (technically the seeds of the legume but anyway nuts from herein for brevity) and then take another unshelled one and fly away. Sometimes they crack open multiple shells and cache as many as they can before the final unshelled one.

The oldest of the jays, who is no longer alive, would regularly show up with so many cached nuts they could not take an unshelled nut. The cached nuts would get in the way.

They would occasionally drop a single peanut from their cache, because it meant they would be able to pick up an unshelled pair; that is they understood on some level the choice involved giving up some food because even more was contained in the shell.

Fascinating.

They, and one of their offspring who is still around, were the only jays that would do it. Though it's unclear if that's because they were "smarter" or simply because they trust us enough to take their time, whereas the other jays seem to act like they're stealing the nuts that belong to the two walking meat bags that live in the box and seem to leave their peanuts lying around.

There's the "what it achieves" today; software x works as intended as of right now.

And then there's "what it achieves" long term.

Those with significant experience with sprawling, LLM-generated, codebases, often built by those who don't understand the code produced, can attest to things being good today, unworkable tomorrow.

While this isn't true across the board, and my own experience should be considered anecdotal at best, those who consider "what it achieves" to also include long term viability as a success metric, are skeptical of these types of changes.

Personally, success for dependencies isn't just "does it work today" but "can I trust it to work long term."

I don't use Bun. I don't care about Bun. But my opinion is that how code is produced will have some effect on what it achieves, if the goalpost includes more than "it works today."

Bambu Labs however, has chosen to market their printers with an app that provides a "one-stop shop" for all things 3D-printer. You can browse their version of Thingiverse (or Printables or Cults 3D) and send jobs directly to your printer. You can also access your printer remotely (read outside your home network without tunnelling/port-forwarding/VPNs) to monitor prints, get notified when a print is done, get notified you've run out of filament, watch the printer work if it's equipped with a camera, etc. etc.

Bambu has been attempting to remove features that enable easy local (not-internet-connected) use cases and force everyone to use the cloud, etc. Or at least make it as painful as possible to skip the cloud.

Relevant context: X1C owner who did not update the firmware that forced bambu's "secure printing" workflow on users that previously used their local network "plugin".

I stopped using Handy, blocked the printer's access to the internet, and ultimately, did not miss a thing. The printer continued to work fine with my slicer of choice (softfever's fork of Bambu Lab studio's fork of Prusa Slicer's fork of slic3r, now known as OrcaSlicer).

Like most things these days, they make a decent printer, but are part of tech's steadfast march to control everything. The twist is that they're in a space defined very much by breaking control.

I don't use their SaaS offering, but I've been using the self-hosted versions (mostly in CE flavours, but occasionally paid) since the days of the weird black and white fox, when gitlab looked very bootstrap-y. (The logo in question for the curious, but you can't unsee it: https://upload.wikimedia.org/wikipedia/commons/0/0a/Gitlab_l... )

Anyway, since LLMs for coding became a thing, coupled with the realities of running a business post-IPO, it's been a slow-ish downward trend for the self-hoster, as their offering gets more and more bloat that's likely easier to manage at scale for Gitlab, but stands in stark contrast to what it once was.

Little things are pilling up; components left for dead (we now have both TODO - which is an abysmal mess, and "assigned work items" - WHY?!), issue boards that remain messy, advertisements creeping into the CE version, increasingly wild hardware requirements... and some recent changes to their documentation that strike me as a dark pattern; very much a recognition that either you're an enterprise running your own paid GitLab, with some kind of support, or you're a SaaS user and don't GAF about the ops docs.

The transition to websockets was annoying. Mostly because it kinda-doesn't work and there's no decent polling fallback, which results in time wasted hitting refresh, in 2026, when everything worked fine from 201x-2025.

I've kept my eye out for alternatives, but Gitlab's CI/CD, and the self hosted runners, is still my preferred flavour hands down and continues to be the reason I stick around.

Overall, it's a much slower decline, but like all stock-market-centric companies, you can feel the writing on the wall. Nevertheless, we're in the middle of a Gitlab migration from one cloud provider to anther because we still haven't found something better. :/

Former alcoholic, I got similar advice early on. It was life changing.

Blocking social media is no different from existing laws for cigarettes, alcohol and various other substances. Nothing wrong with using them, but we do restrict self-serve access for developing minds.

Sure, kids will find a way. That said, like a glass of wine at dinner, parents are free to share their social media experiences with their kids; safely, supervised, limited.

You can also play it on Steam if you can't find a crop of folks to sit down for three hours with you (though you can run through a full game against the computer in 35 minutes).

It's cooperative and has enough variety to keep it at exactly the right balance of fun/challenging.

Similarly, if you're looking for a wild 8 player game -> captain sonar. It sounds confusing until you start playing and then the light bulb goes on and you can't get enough.

Our perception of these things (for most, not all) is incredibly fluid, much like our perception of time. Music that moves us tends to have the right "technical imperfections". Too much and it comes off as amateur, too little, and it comes off as sterile.

Even on a production-level, the right amount of harmonic distortion/non-linearity can be a huge benefit to how sounds are perceived. The amount of soft-saturation tooling in modern electronic/in-the-box music production is wild. Almost every modern plugin seems to include some kind of "warmth" control now.

Yet another example how perfect reproduction doesn't sound quite right.

It was the workstation on which I learned Logic Audio before, you know, Apple bought Emagic. I took that machine, running very low latency Reason to live gigs with my band.

Carting around a full-tower computer (not to mention the large CRT monitor we needed) next to a bunch of tube Fender & Ampeg amps was wild at the time. Finding a good drummer was hard; we turned that challenge into a lot of fun programming rhythm sections we could jam to, and control in real-time, live.

Just over a year ago I decided to switch to Neovim. The reason for switching was personal; I was struggling with what I'll call "clutter" in other tools and I wanted a tool that would reinforce, at least lightly, a mode of working that promoted focus on what I was working on, while making it easy to reference other files without loading up my editor with tabs and other visual clutter (buttons/menus) I don't care about most of the time.

I took the advice I seemed to bump into repeatedly: try out vim mode in my current editor before making the plunge.

I really struggled at first. It felt wildly foreign. All the shortcuts were nowhere near to the world I was familiar with.

As I was about to give up, I ran into some advice that was along the lines of "stop trying to memorize shortcuts and start thinking in terms of what you want to achieve" (words and motions in vim-speak).

Your example of [C]hange [I]nner is a great one; that one in particular was life changing. Sure there are some words and motions that do require memorization, but so many others just flow naturally. And once you start thinking in actions, it's easy to see how they can layer on top of each other in really elegant ways.

I'm not even here trying to tout vim-like editors, I'd wager there are many editors that have some semblance of this kind of interaction, but rather to reiterate there's a shift from a PoV of function vs. goal.

Again, I don't think this is "the right way" but rather one of many perspectives that works in context with the phenomenology of me.

- Did someone really make a VC-backed "Rent-a-swag"?

- Did they also go full Saperstein?

Yep. They did.

Over the last few iterations of Sonnet and Opus, anthropic has definitely trained me to ask it to explain something "in detail" (or even "in great detail") when I want as much nuance as possible.

It used to be the inverse - way too much detail when I didn't want it.

I recently had to interact with an idiot wearing meta glasses. There should be a mandatory consent requirement AND an "on air" red led.

- "Ah, great taste my friend."

- "Ah, great pick to start with."

- "Ah, a lovely choice..."

You're absolutely right! But I don't need you to tell me that. ;)

This looks like a really neat project/idea; seeing the road map is exciting too, nearly everything I'd want.

I don't love the brackets syntax, or the [op val1 val2] ([* x x]) style, but I appreciate the attempt at clarity and consistency and none of these things are dealbreakers.

I do wonder why they've leaned so hard into talking about the type system being out of sight. Again, not a dealbreaker, but I feel strongly that explicit typing has a place in codebases beyond "describe something because you have to".

Strongly typed languages strike me as providing detailed hints throughout the codebase about what "shape" I need my data in or what shape of data I'm dealing with (without needing to lean on an LSP). I find it makes things very readable, almost self-documenting when done right.

From their docs about their choices: "The reasoning is simple: types exist to help the compiler catch your mistakes. They do not exist to help you express intent, at least not primarily." This strikes me as unnecessarily pedantic; as someone reading more code than I write (even my own), seeing a type distinctly—particular as part of a function signature—helps me understand (or add strong context) to the original author's goal before I even get to reading the implementation.

I find this doubly so when working through monadic types where I may get a typed error, a value, and have it all wrapped in an async promise of some kind (or perhaps an effect or two).

By the same token many languages allow you to leave out type annotations where they may be simple or clearly implied (and/or inferred by the compiler), so again, I'm not understanding the PoV (or need) for these claims. Perhaps Loon simply does it better? Am I missing something? Can I write return types to stub functions?

From the above blog post: "That's how good type inference feels! You write code. The types are just there. Because the language can see where it's going." Again, it feels strongly geared towards a world where we value writing code over reading/maintaining/understanding code, but maybe that's just my own bias/limitations.

Will follow it closely.

I recently switched to a split columnar layout but not for solely for ergonomics sake - I do the same things as you but with my right hand handling b, g, t, and my left hand moving over to accommodate (with "incorrect" fingering for c, and variable fingering for the whole of the left side).

My choice to move to a split was primarily motivated by a need to reset my typing style and a hatred for where the escape key sits on a keyboard (not forgetting the waste of space that is the spacebar.)

It would be neat if someone would make a zmk / qmk keyboard with five thumb keys where the space bar is. Might be the sweet spot for most.