IMO this is such a manager-brained take. If your long-term strategic goals aren't being advanced, you have to figure out why. Talk to your team and figure out what the deal is. Talk to other teams too, while you're at it. You might accidentally solve a problem.
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.
You know what, I read it again and I don't even disagree with the concrete advice in the post—weekly meeting, starting with open tasks from last week—which I would characterize as a basic, ubiquitous, almost anodyne organizational coordination tool. My problem is this part:
> 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.
My point being, in case it’s still unclear, that “I’ll create pressure on everyone and then progress will happen,” is IMO bad management.
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.
A lot of this is about knowledge debt if I’m reading it correctly (people not knowing things that they should know, or knowing the wrong things). In my last few jobs, I’ve maintained an Anki deck about facts relevant to my job (who certain people are, how certain systems work, details of the programming languages we use, etc.)
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.
I think about this a lot, though one paragraph from that article:
> 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.
> 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.
Isn't that what git is for, though? Just have your LLM work in a branch, and then you will have a clear record of all the changes it made when you review the pull request.
IIUC this kind of thing is usually called “managed deployment.” Minio used to have a slick implementation of this, and I think databricks does as well. Usually it’s less “execute arbitrary commands on customer hosts,” and more “send metrics and logs to shared repository and send RPCs to customer deployment”
It's heavily inspired by Databricks' deployment model. And you're right that it's not "execute arbitrary commands". Commands are predefined functions in the deployed code that the developer defines upfront and customers can review.
The metrics/logs part is also core to Alien... telemetry flows back to the vendor's control plane so you actually have visibility into what's running.
Honestly IMO this kind of thing just depends a lot on tone. “That won’t work because” tends to piss people off and they usually do the thing anyway. “Cool idea! What about …? We tried … years ago and failed because of that” works at least sometimes (and sometimes they have a good answer)
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.
> what happens is that, as in software, certain ideas get ossified. That’s why, for example, every OS has a POSIX layer even though technically the process/namespace/security model could be radically reimagined possibly to create more easily engineered, correct software.
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?
I know what you're saying but elegance is not simply an aesthetic concern.
The value of a proof is not only its conclusion but also the insight that it provides through its method.
The goal of mathematics is not to prove as many theorems as possible but rather to gain an ever deeper understanding of why certain statements are true. The way that something is proved can be more or less useful to advancing that goal.
As an example the elementary proof(s) of the prime number theorem are just about as famous as the original proof. Sometimes the second bite of the cherry is even juicier than the first.
Exactly. The reason mathematicians and physicists care about elegance is because they care about understanding things. Elegance, like you said, isn't about aesthetics, even though people seem to think they're synonymous. But the elegance is that you've reduced things to simple components. That not only makes it easier for us humans to understand but it means you're closer to the minimal structure. Meaning you know what matters and more importantly, what doesn't.
Tbh, elegance is something programmers should strive for too. Elegant code is easier to build upon, easier to read/understand, easier to modify, easier to adapt. For all the same reasons mathematicians want elegance. Though it's true for many domains. People love to throw around the term "first principles" but that's not something you (usually) start at, that's something you derive. And it's usually not very easy to figure out
Proof irrelevance I don't think is accepted in constructivist situations. Those are, however, not that relevant to the recent wave of AI math which uses Lean, whose type system includes classical mathematics.
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.
reply