Missing the splitting axe getting a little jammed at a knot.
Otherwise excellent.
322 karma · joined March 9, 2016
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.
From the preferences:
- Unlock a next key only when the previous keys are also above the target speed. (This will force you to practice keys that are problematic in context, it's frustrating but very helpful for reinforcement learning. For example, I struggle with B, C, V on my split because I don't use the “correct” fingers for those keys on a standard keyboard.)
- Add capital letters
- Add punctuation characters
- Add words to lessons (move it to the max)
Regarding getting much worse in the real world; IMO this isn't discussed enough. When you're relearning muscle memory, it's a very different beast to copy what you see (focused only on where your fingers are) as opposed to focusing on your thought and your fingers just “go there”. I, too, have found my speed plummet at first; at some point I decided to just go cold turkey and suffer being rather slow – trading it for eventual mastery.
In my case, because I was such a phenomenally sloppy typist, sometimes what felt slow was likely just as quick as a result of making fewer mistakes on the new split layout where my behaviour was forced to be better.
My current fuzzy find key combinations include:
ff: fuzzy find, limited to current project
fc: fuzzy find (c)ode -> expand search scope to all projects
fg: fuzzy find (g)lobal -> let's just search my entire home folder
I imagine I'd have to limit it to the first and remap 'fg', I use 'gf', 'gc', 'gg' for the grep versions of these commands.
Either way, very cool.
Random edit: It's also how I learned the word obsequious.
It's almost as if, as tool use and planning capabilities have expanded, Claude (as a singular product) is having a harder time coming up with simple approaches that just work, instead trying to use tools and patterns that complicate things substantially and introduce much more room for errors/errors of assumption.
It also regularly forgets its guidelines now.
I can't tell you how many times it's suggested significant changes/refactors to functions because it suddenly forgets we're working in an FP codebase and suggests inappropriate imperative solutions as "better" (often choosing to use language around clarity/consistency when the solutions are neither).
Additionally, it has started taking "initiative" in ways it did not before, attempting to be helpful but without gathering the context needed to do so properly when stepping outside the instruction set. It just ends up being much messier and inaccurate.
I have to regularly just clear my prompt and start again with guardrails that have either: already been established, or have not been needed previously / are only a result of the over-zealousness of the work its attempting to complete.
It's easy to tout big learning gains when you have to build a tool that administrators will buy (substitute the non-educator buyer persona for your school/board/system here.) And for administrators to pay for something, you must design a tool with, you guessed it, numbers that go up.
Learning often doesn't work like that when what you want to teach, ultimately, is how to learn (assessment for learning / developing cross-curricular competencies / visible learning etc. etc.)
I left the industry, disenchanted—no, despondent. No one really cared about providing educators a great tools and great content designed around them and their learners.
Hey, you know what, instead of providing the best learning experiences possible, let's just teach our students how to use Google or Microsoft's Office Suite so little Jenny can get a head start on those TPS reports.
Yeah, I'm salty. AMA.
1. I use a custom domain.
Turns out that there are two competing features, not-at-all documented. If you use a catch-all, like I do, AND use specific addresses for sending, the two are incompatible to some degree. Which is bonkers.
Example: with a catchall I can create any address I want (and I do). Some store wants an email for a big discount, cool, here's a throwaway. Buying something online, here's a throwaway.
Now sometimes, I need to reply using that throwaway. Turns out in Proton, this triggers a gotcha. As soon as I add the throwaway email to my list of email addresses for sending, I enter a world with a limit of 10 max.
That's fine, I can disable them right?
Nope, it turns out if I disable them in order to add aothers, Proton blocks those addresses *even though I have a catch-all*. WHAT?? Worse, if I try to delete the addresses, Proton will also delete the associated messages in my Inbox/folders. Excuse me?
2. What really pushed me away: Search.
Whatever proton is using under the hood is easily the worst search experience I've ever had from a mail product, and I use Thunderbird on my work machine.
Notable: Proton Bridge. I get why, but it's just terrible.
So many rough edges. Just not worth it.
For whatever reason, the FP-first approach it allows me to use, matches how I like to think about problems. For comprehensions for handling complex types, easily, feel like a superpower.
When I started (and I started out of necessity, inheriting a number of old Scala 2/Play 2.x codebases), it felt like a big mistake. Weeks of banging my head around abstractions I didn't yet understand, or immutability-first approaches that were different from my (limited) python experience had me terrified. It eventually clicked. For my first year, I committed to write some Scala every single day; it was worth it.
Though to be fair, two years with the language versus ten is a big difference, so I very well could be completely wrong here. It's just like, my opinion, man.
Would I enjoy writing any language after putting in a lot of dedicated seat time? I don't know. I certainly didn't fall in love with Python the same way - but I'm willing to admit I could be doing it wrong.
That said, a number of the concerns in the post are valid. There's some spread between Scala2 and Scala3, related libraries, tooling, and a few surprising gotchas. Testing frameworks are bit fragmented with Scala2 and 3 support. However, I've not found it nearly as horrible and the joy of being able to work with what is working has outweighed the occasional "WTF" cost (often measured in "time wasted" lol).
I can't speak to the IDE issues the author is noting, I don't use IntelliJ. I've found Metals + Neovim to be truly wonderful on the whole, and it's pushed me to be even more aware of the underlying tooling I'm using.
Scala's 3 enums, opaque types (and now named tuples) are just a few changes that have made Scala 3 pretty wonderful to work with. It doesn't seem to me like Scala3's release is a failure. The real word is messier than a well-written function. ;)
One thing I've found, not at all mentioned in the article, is how welcoming the Scala community is, whether by necessity or virtue (why not both?). They're open to accepting help, willing to mentor/teach, engage in reasonably thoughtful discussion (from my experience), and seem to be willing to support each other.
Scala also pushed me to start learning Rust. Some of their shared heritage and style made it an interesting target for my desire to learn a language for a few embedded systems projects I'm working on.
So is it a dying language? I don't know if I really care. I'm incredibly grateful it exists.
PS - ScalaJS is both fun and cool. I love that someone wanted to make this a reality.