898 karma · joined December 11, 2014
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.
It's amazing how much we continue to learn about these conditions.
Total amateur here, but it strikes me that one important difference is that performance matters in software in a way that it doesn’t in mathematics—that is, all proofs are equally valid modulo elegance. That means that abstractions in software are leaky in a way that abstractions in mathematics aren’t.
In other words, in software, the same systems get reused in large part because they’ve been heavily refined, in terms of performance, unexpected corner-case behavior and performance pitfalls, documentation of the above, and general familiarity to and acceptance by the community. In math, if you lay new foundations, build some new abstraction, and prove that it’s at least as powerful to the old one, I’d think that you’d be “done” with replacing it. (Maybe downstream proofs would need some new import statements?)
Is this not the case? Where are people getting stuck that they shouldn’t be?
There are things you can do to try and even things out. Etherium has been considering “quadratic voting” to solve a similar problem (in this case, that would look like tracking consumption and increasing the unit price of fuel as you consume more fuel, so that cost goes up quadratically with consumption). That seems hard to enforce, though, and doesn’t help with foreign opportunists.
Yes! I would add that IMO the communication style can be learned and there are great rewards for doing so.
I believe the rough statistic that 20% of people on a typical project are contributors. I don’t believe that it’s because the other 80% are losers. IME it’s because no serious effort has been made to include them, make sure they understand wtf is going on around them, and help them solve whatever is holding them back.
If you do this, a) it does work, and b) the need for small teams becomes apparent because the now-onboarded person can’t find anything that isn’t already being worked on, so they (with encouragement) start a new thing. And there are limits to people’s ability to understand what’s happening, especially if they’re inexperienced, and some people really don’t have the skills to contribute, but by and large, building bridges for people is still highly worth doing.
Before AI, I worked at a B2B open source startup, and our users were perpetually annoyed by how often we asked them to upgrade and were never on the latest version.
Parenting children is impossible, therefore all parenting lies on a spectrum from terrible to catastrophic, and it’s hard to know how you did until they grow up (if ever) because there’s a lot of sensitivity and subtle emotional stuff, especially at very young ages, which are the most important and the ones you remember the least. I’m certain there are screen-free parents who are worse for their kids than a good chunk of tablet-hander-outers
I sometimes wonder if modularity will become even more important (as it has in physical construction, e.g. with the move from artisanal, temperamental plaster to cheap, efficient drywall), so that systems that AI is not able to reliably modify can easily be replaced.
I really like to understand the practice of software engineering by analogy to research mathematics (like, no one ever asks mathematicians to estimate how long it will take to prove something…).
Something I think software engineers can take from math right now: years of everyone’s math education is spent doing things that computers have always been able to do trivially—arithmetic, solving simple equations, writing proofs that would just be `simp` in Lean—and no one wrings their hands over it. It’s an accepted part of the learning process.
It made me cautiously optimistic that all of Anthropic’s work on alignment, which they did for AI safety, is actually the cause of Claude code’s comparatively superior utility (and their present success). I wonder if future progress (maybe actual AGI?) lies in the direction of better and better alignment, so I think this is super cool and I’m suddenly really interested in experiments like this
Not like human programmers. I would never do this and have never struggled with it in the past, no...
When you publish a library, people are going to use it more liberally and in a wider range of contexts (which are therefore harder to predict, including whether a given violation requires human intervention)
Given all that, where are professors supposed to find and hire students who don't want to stay in academia themselves? I think a lot of these students wind up being aspiring immigrants, and I'm not surprised that a lot of them would also have a hard time finding a place for themselves after graduating and that many of them would leave. Also, the abstract seems to argue that that US still benefits greatly from this arrangement: "though the US share of global patent citations to graduates' science drops from 70% to 50% after migrating, it remains five times larger than the destination country share."