You know, I had a similar experience, but in my case I got an appointment with a psychiatrist afterwards, described the experience in detail, was given a computer test, diagnosed with ADHD, and then given a prescription. (Also in my case, I learned Adderall doesn’t actually feel great or help you if you take too much).

Take care of your kids. The war on drugs is stupid. Etc.

Most of LLM world is kind of anti-linux right now because the most popular LLMs are walled off by these huge companies and hella expensive. At some point, a nerd will realize they could hack together a surprisingly ok homebrew version of what everybody else is using, and do. Then a company realizes that they can build a brand on the anarchist, grassroots vibe of the homebrew thing, and capitalize its development (software development, but also community development, which is brand development for the company). Now, it’s much later, but the open source thing is competitive, and popular for being open-source.

At one point I got interested in why Red Hat handed over tens of millions of dollars in stock to Linus leading up to their IPO, in exchange for…nothing specific. Nominally it was a gift of appreciation, but handing out random gifts is somewhat opposed to maximizing shareholder returns. It’s because Linus controls merges to the Linux kernel and doesn’t have to care about Red Hat, and the board wanted him to care at least a little bit. They were stuck between “people trust our business because it’s built on this populist OS” and “this populist OS is mostly controlled by a guy who doesn’t work for us.” It’s hard to have one without the other.

I’m glad Apple is taking accessibility seriously, and I wish accessibility worked better on Linux, but I don’t think Linux is ever going to make developers “do their homework,” because the community wouldn’t trust a Linux like that. If the author is right, it’ll happen because “AI for the People, Inc.” builds a business on it and sponsors the work.

Well there’s your problem, control needs to go the other way. If you want your app to be AI-enabled, you need to make it easy for AI to control your app. Have you used OpenClaw? It’s awesome!

Most of my posts have aged terribly in the age of AI (especially the ones I didn't finish...so long, extended discussion of how to use a lab notebook when debugging, we hardly knew ye. Claude fixes our bugs now) but one job that engineers still have is the collection and retention of context that AI doesn't have and can't easily get.

What hermit wouldn't love meetings that simultaneously insist that you do more while taking away time to do it, all to avoid adjusting a pollyanna quarterly plan and budget!

Why am I awake at 1:00am, ruining my brain and body, trying to get this feature finished before the end of the week instead of three days later? Ah yes, so that we meet our quarterly OKR, and the next quarter's plan that the EM and PM negotiated without me or our customers isn't disrupted and doesn't need adjustment. That would invite reprimand from the director, and the extra work would be terrible for them, I understand.

I'm reminded of this recent thread in which Heroku left the devs in charge and suddenly features that the author had requested for years got implemented: https://news.ycombinator.com/item?id=47669749

Sometimes the problem is not enough motivation, though I think that if you hire well, that’s rare—the best engineers are intrinsically creative and motivated. Often, lack of progress is due to some other organizational problem—too much toil, unclear priorities, conflict, etc—and just adding pressure until progress happens is the manager equivalent of whining until your sister does your chores for you.

Even if it works, either

1. the team is working around the problem (which the manager doesn’t know about or understand, and isn’t dealing with it) and will eventually get fed up and leave, or

2. someone pushes extra hard and solves the problem for everybody else. Now, that person the de-facto leader, though they’re not recognized, and in fact are often penalized for getting distracted from the paper priorities, since the managers who do this are rarely interested in the mechanics of how their problem was solved. Respect for management is lost, because they don’t understand what’s happening. Eventually everyone gets fed up and leaves.

Managers can’t solve every problem themselves, of course, but the manager needs to understand what the problems are, explicitly set the priority of solving them, and understand and celebrate the solutions when they’re found.

> Everyone has other obligations, fires to put out, and emails to answer. It’s easy for long-term strategic, high-impact work to sink to the bottom of everyone’s todo list...this creates pressure on everyone to make progress.

One experience among many: I spent a very painful six months as a new grad, in a particularly dysfunctional corner of a mildly dysfunctional organization, in hours of daily back-to-back arm-twisty status meetings with team after team who wanted something from me and were sure this would get it (after which I would stay up all night working, since that was the only time I had left for that).

You know how it ended? The tech lead on my team cornered me in a conference room to find out why nothing was getting done, and I fully lost it with the guy. Like just started shouting that the actual consequences of ignoring the things people wanted ignored were transparently not acceptable, and I was barely sleeping trying to hold everything together. He got very quiet, said "ok," and we started going to meetings together and saying no to stuff. The amount that was collectively being demanded from me/us exceeded what could be delivered, but no one was on triage duty.

I've learned quite a bit since then (including spending a few years in management), so I've gotten better at understanding what's happening and asking for what I need. I've just also decided that "it's not my role to figure it out" managers (and PMs) are like rocks in the bowels of an organization. They’re in the way, subtly, quietly making everything bloated and painful as long as they’re there.

The number of managers who've successfully convinced themselves that knowing things and making decisions aren't part of their job, and just fill their days with arm-twisting and event-planning, is literally unbelievable to me. I've never met a founder with the attitude "yes I'll just put the stakeholders in an alignment meeting and my company will build itself," but somehow half the of the rest of leadership thinks that's a job.

I’ve started kind of a funny rule, which is that when I make a change now, I can use Claude or not. But if I use Claude, some cards have to go into the deck. Both about how the implementation works, and also about anything within the implementation I didn’t know about. It does force you to double-check things before committing them to memory.

> Many assembly programmers were accustomed to having intimate control over memory and CPU instructions. Surrendering this control to a compiler felt risky. There was a sentiment of, if I don’t code it down to the metal, how can I trust what’s happening? In some cases, this was about efficiency. In other cases, it was about debuggability and understanding programming behavior. However, as compilers matured, they began providing diagnostic output and listings that actually improved understanding.

I would 100% use LLMs more and more aggressively if they were more transparent. All my reservations come from times when I prompt “change this one thing” and it rewrites my db schema for some reason, or adds a comment that is actively wrong in several ways. I also think I have a decent working understanding of the assembly my code compiles to, and do occasionally use https://godbolt.org/. Of course, I didn’t start out that way, but I also don’t really have any objections to teenagers vibe-coding games, I just think at some point you have to look under the hood if you’re serious.

Yeah, and average kernel devs are not average SWEs

Management: “we’re going into maintenance mode”

Devs: “You mean we get to work on whatever we want?!”

Per the thread, it’s possible this problem could’ve been solved by burying the site in affiliate links…

Edit: also, bluntly, sometimes objections have answers that can’t be said. “DevOps won't want to support another service.”…”that’s because our devops engineers all think you’re an overpaid jackass and are strongly inclined to reject your ideas out of the gate. My one other idea they liked, so they’ll probably take a chance on another one.” What’s hard but important to remember is that sometimes you’re the person that things can’t be said to.