* people tend to not measure things and when they actually do bother they tend to measure the wrong things, the things of immediate comfort
* measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect
* people tend to guess at measures because either they are incapable or the effort is too high
* when people guess at measures they tend to be wrong more than 80% of the time and when they are wrong they tend to be wrong by multiple orders of magnitude
* measurements tend to produce micro-improvements, but those micro-improvements add up in ways that are both significant and unexpected
* if you want to go faster the most certain course of action is to modify your technology and techniques
* hiring is slow, just as adding more people to a late project makes it slower
* changes lower in the stack tend to grant both increased speed and increased flexibility. Increased scale comes from what you do with those
>Rowers have a word for this frictionless state: swing... Recall the pure joy of riding on a backyard swing: an easy cycle of motion, the momentum coming from the swing itself. The swing carries us; we do not force it. We pump our legs to drive our arc higher, but gravity does most of the work. We are not so much swinging as being swung. The boat swings you. The shell wants to move fast: Speed sings in its lines and nature.
Our job is simply to work with the shell, to stop holding it back with our thrashing struggles to go faster. Trying too hard sabotages boat speed. Trying becomes striving and striving undoes itself. Social climbers strive to be aristocrats but their efforts prove them no such thing. Aristocrats do not strive; they have already arrived. Swing is a state of arrival.
Hmmm, so it sounds like the root cause isn’t really about “speed” at all… but something else?
For example, someone in a meeting saying things lacking credibility and everyone else just goes along with it anyways. Then it snowballs meeting after meeting.
Weird analogy. Nonsensical from both physical standpoint (the only energy input when swinging is the person on the swing "pumping their legs"), and practical one (you usually sit down with the swing already at an angle and then kick off, so a good 50% of the arc/momentum is there from the setup).
Right, and remember how getting the rhythm right was the whole trick of it? Learning when to bend back and when to lean forward? When to pump your legs, so that your relatively small inputs were additive to the momentum of the swing, not fighting it? How when you kicked at the wrong time, you could feel the balance upset, you could feel the swing slow?
It's not bad I think. We must be open-minded and humble, like a child, and learn how the system actually works in order to be effective.
Often times our first instincts will not work, so we must observe, experiment, and try again. And not be afraid of looking foolish with our legs flailing around. Find the underlying rhythm and flow with it, not against it.
The original quote is a bit unclear, but it does refer to being on a playground:
"Recall the pure joy of riding on a backyard swing: an easy cycle of motion, the momentum coming from the swing itself. The swing carries us; we do not force it. We pump our legs to drive our arc higher, but gravity does most of the work. We are not so much swinging as being swung."
I found it excerpted in Getting Things Done, where the author presented it as the ideal for how one should approach their life, both professionally and personally.
GTD is the opposite of being on a swing. It's the constant fear of the parents shouting your name from the balcony to tell you the playtime is over and you need to get back home for a Weekly Review.
> * measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect
I don't understand what you're trying to say. What are the reasons some people can't introspect? Is it even true that some people can't introspect?
There are many reasons. Some are ethical like conflicts of interest or bias. Some are financial like insufficient time or missing tools. Most commonly the cause is personality and sometimes it’s types of neuro-divergence.
Regarding "measurements tend to produce micro-improvements", not if you are the first to actually measure stuff in a codebase. There tend to be big fat low-hanging fruit.
> measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect
you can't measure everything, and choosing what to measure is an editorial decision that introduces bias.
Bias is the whole point. Measures are taken to produce outcomes that someone has selected. Typically the person accountable for the results of their team or department. They have editorial authority.
The problem is that in software development, measures are rarely executed well. The things that are measurable are either not as important as things that are not objectively measurable, or they can be too easily gamed.
You can fail a project not because you were technically wrong about anything, but because you burned your customer out by taking 6 months instead of 6 weeks to find a viable solution to their problem. Speed is a feature from the perspective of your customers. There is economic value associated with it.
Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas. This is how a lot of business leaders feel every day. Speed is the best way to meet uncertainty in complex domains. Unless you are fairly sure you can one shot the problem with a single commit, having a process to iterate with some expediency is important to success.
There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast.
There are many different types of software customers. A company that contracts an iOS/Android developer to build them an app for an upcoming conference is different from a WalMart that hires developers to build them an e-commerce platform which is also different from a software developer who uses an AWS service who is different from the average Windows or iOS users. All are “software customers”. Yet
> There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast.
I don’t really now what customer type that would even be. Is the customer the one controlling the quality or reliability or driving the solution? How would the customer even know you’re “going too fast”? They can’t. They’ll just tell you “everything is half broken all the time, wth?” Is that how they tell you you’re going too fast?
Calling an HVAC tech to fix a broken AC is like an engineer doing a hotfix to alleviate a problem. No one is saying that should take 6 month. A better analogy is expecting the your home builder to build you the house in few days because it’s Texas in August and the sun is too hot outside. Then spending the next 6 years fixing “issues” in the house that was built in a week. Yeah, they didn’t put insulation. Yeah, they run the electrical wiring on the outside. Yeah, the walls aren’t anchored, and plumbing just dumps everything under the house. But at least you’re not in the hot sun.
> Real speed exists. Real speed is what happens when the work is understood, the constraints are clear, the people involved know what they’re doing, and the decisions have been made cleanly enough that execution can happen without constant re-litigation.
I think the article is arguing against speed preventing the kind of planning and alignment that makes smooth delivery possible. Rushing is probably the easiest way to make mistakes that ultimately kill projects, credibility, or at least increase the costs in relational capitol, time and morale. Defaulting to a panicked frenzied state of mind is a perfect way to fail at delivering expedient results.
Depends on the organisation as I've seen the opposite (excessive planning without taking action) too. I'm on the speed side of things nowadays because I was usually wrong when I thought that the "work is understood and the constraints are clear".
Yes, the problem is the feedback loops often don't really exist in the planning stages. It is more difficult to gauge progress. There can be very detailed specifications or plans that won't survive their first contact with reality. This is why waterfall is over with.
Yet - not planning effectively is also a huge problem.
It seems as if you did not really read the article.
The piece is titled "Religion of Speed" -- in other words speed (or apparent speed) as the guiding principle over anything else.
It says nothing even remotely like "you should take 6 months to do something that can be accomplished in 6 weeks."
And this statement:
"There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast"
is baffling to me.
In my experience (40+ years in software development) I have never had a customer/client that would be in a position to have the proper situational awareness + technical depth to make this judgement call.
And even worse I would guess that if even this was not the case that 95% of the time they would not say you're going too fast, instead they would ask to go faster.
I like this argument, but I don't think the article argues against taking urgency into consideration. Do you have anecdotes about companies or people that actually ignore urgency?
I've experienced enough business-critical incidents (or requests) where people across all seniority are just randomly trying stuff, making a mess, without taking time to coordinate, understand the problem, and solve it. It almost always resulted in more overall time and bigger blast radius than if we did it not out of panick.
OTOH my "slow" (I still did things fast, just not purely for the sake of looking fast) and steady approach always took me less time overall to find a proper fix. I also became known as the person who could always find the best possible fix when there's an incident/time constraint, but I also thought that was systematically bad instead of fixing the culture/process.
It's still faster to take a minute (and deep breath), understand the whole problem (incl. urgency and how that affects your solutions), and then solve it. It doesn't mean you can't keep your customers in the loop and assuage their concerns.
Businesses fake urgency all the time. I guess I have never worked in any of these 'high stakes' companies. My whole career, everything was reportedly urgent, but when you missed the deadline, nobody dies, nobody got fired, you just slipped a little and leadership pretended even more urgency. And if you slipped a lot, people got burned out and quit and leadership would institute 'war rooms' and 'crunch time'. And if you slipped a hell of a lot, the project would probably get canceled and the rest of the team was absorbed into various other projects. Nothing matters, the company's stock goes up and down randomly--having nothing to do with your project's failure or success, yet the message from above is always "FAST FAST RUSH URGENT!!!"
Please define viable solution. It's like a piece of string: how long is it? It's a very subjective statement "6 weeks to find a viable solution" - could just as well be 6 months.
Sure you can deliver something that might seem viable and the customer might also a cycle of updates as the viable solution becomes the solution - but how many updates are tolerated and how bad are the problems in the seventh week?
Sure we dumped waterfall for agile and now we live in a constantly updating world of "viable solutions" ...
>but the customer will almost certainly let you know when this happens
The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break. On top of that, because the rate of shipping new features doesn't necessarily match with the rate of usage of said features the moment you'll find out about it will not happen ASAP but probably sometime later, making it even harder to truly know if going fast is the right thing to do in the moment.
> The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break
This is what the GP meant. They won’t spoon feed you the “you’re going too fast”, but they will give you other signals that you can, and would benefit from, interpreting as “you’re going too fast”
The religion of speed is the religion of VC investment backing, because VCs have set time horizons for delivering returns to their own investors. You can only get their interest if you can make them believe you can deliver 10x growth on their schedule.
Committing to that schedule — and really believing in that commitment — is what turns someone into the sort of person who sets arbitrary project timelines that disregard technical practicality, and then kills projects when they fail per those arbitrary timelines.
These timelines are not arbitrary. They are dictated by the cost of money (for the VC). They have little to do with the target market situation, and totally don't care about technical considerations. They only care if your profits, or at least revenue, or at least market share grows fast enough. If it does not, they write off their losses and liquidate the company.
This is the fear that dictates the damned speed™: either you go up insanely fast, or you die. If your goals do not align with this approach, do not take VC money. If you want to develop things without haste, only join a startup with a proven PMF and insanely goos sales team, which takes care of hockey- stick growth so that you can concentrate on quality.
I never said the VC's timeline is arbitrary! They're ultimately based in loan interest rates / bond yields / etc — as you say, the "cost of money."
But the timelines that founders and CEOs can end up coming up with for the arbitrary subprojects/efforts they choose to pursue to try to get the company closer to giving those VCs the hockey-stick growth they demand, are much more arbitrary. Mostly in the sense that such subprojects/efforts can often be selected/pursued with no thought to the fact that either the goal is technically impossible within the chosen time budget; or, even if possible, that the effort won't demonstrate results within the chosen time budget, and so will be given up on whether or not it's working (because founders interpret absence of metrics as metrics relaying absence.)
Which is to say: if you can guarantee from before you start that a given subproject or effort will be considered "a failed experiment" — then you'd think it would be obvious that you shouldn't do that one. That you should put it on the backlog of things you can try after PMF + hockey-stick growth, when you have time to evaluate things thoroughly.
But that doesn't seem to be obvious to a lot of founders and CEOs. Many of them spend a lot of their and their employees' time setting off on efforts that everyone in the room basically already knows they'll be cancelling two weeks later, before said effort has had a chance to either succeed or fail on its merits.
If you want to feel real urgency, try working at a company attempting to bootstrap without VC funding. Unless your company is very lucky to strike gold early on, the pressure to deliver fast and get money coming in is even more real. Everyone wants to start getting paid real salaries instead of eating ramen noodles. Everyone wishes they could hire a few more people to spread the workload around.
Startups are very hard, period. In my experience, the ones that get VC funding are a less stressful than those that don’t because you start with a generous buffer of money in the bank and you have investors who might backstop the company’s bank account if you run out. They do want returns, but bootstrapped companies also want returns too. That bootstrapped founder who sacrificed potential earnings for years to get their startup off the ground wants employees delivering fast, too.
It’s not a religion or cult. It’s the reality of startups. Something is risked to start them and the people who risk it expect a larger reward than they would have received. For VCs, that larger reward has to be better averaged returns than investing in the stock market or other investments. For founders, that large reward needs to be larger wealth than what they could have gotten working for FAANG. The pressure comes either way.
I like setting arbitrary project milestones or timelines. They don't have to kill the project, but it's good to cast efforts in relief against external developments.
It's not just technical practicality that's disregarded, it's nearly everything valuable about anything that's worth doing. It's why VC is a cancer on the world.
Use to work with a pretty jaded Army Colonel. He'd often say: "even periodic motion looks like progress on short enough time scales." And also, "Slow is smooth and smooth is fast."
In the sharp turns, you feel like that's where you should try really hard to go fast. Because you're going so slow!
But really, it makes more sense to slow down MORE, be smooth and controlled and get the turn right. And you'll get a better drive and be faster later. slow in, fast out.
also, the math wins - going 1mph faster on the 1/4-mile straightaway works out better than going 1mph faster on the 100-foot slow turn.
While I agree with the idea, the math is misleading.
Going 1mph faster on the 100-foot turn may be faster overall than going 1mph faster on the 1/4-mile straightaway if the speed difference is large enough.
Ex:
- 1/4-mile at 100 mph takes 9s, at 101 mph, it will take 8.9s
- 100 ft at 20 mph takes 3.8s, at 21 mph it will take 3.2s
It means that overall, in this situation, it is better to go 1 mph more on the turn (8.9 + 3.8 > 9 + 3.2).
hmm... this is all my remembering old stuff. I thought there was better math when you go faster on the long parts vs trying to go faster on the short difficult parts?
better instead to use the short stuff to set up for better speeds on longer parts.
When I was in basic the instructors repeated this incessantly. About two thirds of the way through what Americans would call OCS they made us walk into "the gas hut" which is a concrete bunker-like building in the middle of a field near the rifle range.
Inside the hut is a hot plate with an old shitty skillet. Inside the skillet are pellets that give off tear gas when heated. You walk into the hut and immediately get slapped in the face by what I might charitably describe as the worst onion-eyes you've ever experienced, multiplied by at least 100.
But the training is fantastic because in that moment as I was standing there with my eyes scrunched and burning, I unconsciously whipped out the gas mask, put it on, did the proper drills with the filter and decon cream, and had no conscious recollection of having done so. The urge to rip off the mask and rub your eyes is overwhelming. The instructor told me "good drill" and sent me on my not-so-merry way.
Same thing with mag drills. You slap that forward assist without even thinking. Anyways, slow really is smooth which really is fast.
From an engineering perspective slow is smooth is fast, but from a sales perspective slow is smooth is slow. If you quote superior quality with 6 months later delivery your competitor will get to sign a contract that could very well last 5-10 years and comes up just so rarely. Missing out on that contract doesn't always mean you get to focus on other projects, it could mean you have to fire whole teams of people that you don't have anywhere to assign anymore.
From my perspective a failure point is when companies do delegate time to make things correct, but demand results from the get go. Billing and tracking becomes weird for them if you work on infrastructure, design systems, component libraries, system design etc and you have nothing to show for after 6 months or a year. "But the future development will be super fast" doesn't fly past upper management unfortunately.
Urgency can definitely be real, but you can't actually go faster by not planning. There are plenty of cases where just a few hours of planning could have made a huge difference, preventing weeks of thrashing and rework.
Sure, it seems true for a short period. But rushing something forward means you cut corners and that catches up with you over time. Anyone who has ever had a sales team asking for special features to be hacked into a product with little or no time for any proper architectural considerations or releasing before all the testing is complete in order to “get the big deal” has felt this. Yes, the other side may win a deal, but rarely the war.
That said, I’ll very deliberately make the distinction between going slow in a thorough and responsible way from just being slow in an incompetent way. Market forces are real and a consistently slow team gets canceled. To put it another way, sometimes slow is smooth and smooth is fast, and sometimes slow is just slow. The trick is knowing the difference between.
I realized early on that sometimes management thinks that if you don't look stressed than your not taking it seriously enough. Phrases like "I don't feel that you have a sense of urgency" really messed with my head back then.
Real management is about making decisions, most typically about how to apply limited resources amongst competing options.
But a lot of Managers (and the managed) think it is about managing people. Their real role is “Overseer” not Manager, and in that role their real task is to ensure you’re working harder.
I have had that exact same thing said to me. didn't so much mess with my head as make me think someone with such a poor grasp of appearance vs reality had no business being a CEO.
We did a paper airplane test in 5th grade. We split into teams and made them like McDonnell Douglas, etc. First, we saw how many airplanes we could make and then how far they flew. Everyone was rushing to get the planes made, but I took my time and measured them to make sure every fold was done right. My planes flew the farthest, and our team won the government contract. The moral of the story was that haste makes waste.
It was a school experiment. The government doesn't want sloppy planes; they want them to be of high quality and fly far. The government was the teacher who decided who won.
Sorry if it sounded like I was picking on your story, that wasn't my intention.
I was just thinking out loud. You hear stories of "do 100, it beats doing 1" and "plan well and do 1, it beats doing 100", in the end... you sort of chose the stories that agree with you.
Yeah, but if you do 100 things with low quality, it is going to be crappy. In the mid-1990s, I did quality control work on debugging code for Visual BASIC and ASP web pages. Now people are rushed to do sloppy work in quantity because it is done fast, not quality, where it is done right.
Speed is not velocity. A person jumping off of a 100 floor building, will have a lot of speed, probably think they are flying!
Velocity comes from being thoughtful. Thinking about thousands of dependencies and navigating towards the end goal.
In big corporations, neither speed nor velocity matter. Its mostly garbage products. There will be deadlines and these are planned for Annual Performance Review. There will always be some success story (or the milestones changed) to show that the people favored by the leaders are 'delivering' on the right 'metrics' and they need to be richly rewarded. And also this 'success' is because of the excellent 'stewardship' by them, therefore they must also be rewarded.
I think the author is having a kind of idealistic, relaxed view of work. Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.
These are obvious lessons of agile management. Even if they are not absolute, maybe that post is meant as some kind of relative statement, in general, speed is a good thing. More speed than you are comfortable with.
> Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.
The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.
The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.
In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.
I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.
Most deadlines are artificial and self-inflicted. The author is not advocating that if you have a literal fire consuming half your home that you should sit down on the floor, ponder your possibilities, schedule a few calls for discussion, then send a few messages on Slack to decide what to do; of course some things are more urgent than others. The author is calling out a “speed cult”; they’re not making an absolutist argument but the exact opposite, advocating for “the discipline of judgment”.
When I worked in consulting, the majority of deadlines were still self-inflicted, based on estimates provided by us.
If you fall into the fast -> unexpected -> iteration -> alignment cycle the author mentions, those estimates tend to be based on the 'fast' part only; that closes deals.
Deadlines are artificial constraints (typically, some deadlines are unshakable—eg "we have to launch the payload when conditions are clear") that, imo, distract from the actual goal or task at hand.
Sadly, a deadline is more often used as an excuse to rush, and not because the deadline itself is of material consequence (e.g., meeting a vendor's production deadline is unshakable).
Instead, the more common reality is that someone in a position of limited agency uses the deadline as a sort of mental whip. This may get a result faster, but rarely is the work that was rushed solely to meet a deadline the best the team/individual was capable of. More often, you get a broken mess that now necessitates wasting more time later cleaning it up (this is the part I think traps a lot of people; it's a stealing from Peter to pay Paul situation).
When I've discussed this in the past, most misinterpret my point through too binary a lens. This isn't some hippie dippie idealist "just, like, do whatever maaan" kind of take.
Instead, it's a suggestion for those in an environment that's always "moving fast" but rarely if ever hitting the mark. This leads to papering over the obvious problem: the team or individual responsible for the bad work is rarely someone of pure incompetence and more often is just under completely imagined pressure that doesn't exist (beyond the confines of the minds involved).
I'm not naive, of course you can't blanket apply this line of thought to every situation (especially in corporate America). I'm more so angling at "have you considered that rushing is the reason everything you ship falls apart and doesn't meet its goals?"
Case in point: FedEx deployed some new dashboard software for their employees doing package handling. I came in to drop off a MacBook I was sending in for repair. While scanning it in, the system just broke (in the "it ain't doing the thing no more, ma" sense). The clerk was able to manually scan it, so skipped the system and gave me a receipt. A week later, Apple never got the laptop. I start calling around frantically, now having to do work I shouldn't be doing. It was determined that the label printed (the one I got a receipt for) wasn't the "correct" label to scan (that was hidden under another label already on the box). This led to weeks of unnecessary phone calls re-explaining the situation to various employees, now arguing with me about a mistake FedEx made.
Eventually, Apple called it a mulligan after a month and sent me a new laptop.
My point: whatever caused the FedEx team to rush had a ripple effect of wasting inordinate amounts of time and costing Apple $5K. Why? Because whoever built that dashboard software rushed and made an otherwise simple idea into a half-working, frustrating mess. This is the type of situation I have in mind when I tell others "we need to slow down."
Like I alluded to in the post, it's not about moving slow as a matter of psychological comfort, but as a means to avoid creating messes in the present (and future) in service of an arbitrary deadline that's less rooted in necessity and more so in fulfilling the ego of whoever is in charge. That's a tough pill to swallow, I get it, but like most things, the actual problem isn't the process or reality, it's the human mind convincing itself of things that just aren't true.
Fedex Returns is just about the least competent product technology entity I've ever encountered and this migration was a garbage fire even by their low standards. I doubt if they could have gotten it right if they spent 10 years on it, and its entirely possible they did do that.
I work for FedEx and even our scanners are garbage. If they spent more time on quality SWE instead of impressing management, things would work out for them very well in the long run.
Reader here. Thanks for creating this. Totally resonates with my own thoughts, so if I'm wrong at least I have company :-)
I do have a suggestion for those who object to this line of reasoning: Follow the 5 why's to try and get to the source of your own reasoning and see whether it still makes more sense - in the sense of whether you end up adding to the common good
It’s been well thought out and edited but it’s clearly written by AI, and it was obvious long before “load-bearing”. Still - it makes an important point well and is worth reading.
If every use of AI was like this, I perhaps wouldn't have this slight allergic reaction to it, but as it stands, this voice and rhythm has become associated with bad lazy grifting writing.
The longer I spend in my career the more obvious this is to me. Unfortunately younger colleagues don't always have the maturity to have also realised this, which can be a problem if they end up above me in the management chain!
I try to kickstart reflection on this by saying things like "Some of the biggest impact I've had has been the code I chose not to write."
Felt this in my bones. It’s painful how accurately this describes my current work situation. The pressure comes from the top - leaders that have no idea what they want but they want _something_ to happen NOW. This has only gotten worse with the recent AI thoughtleadering because now the expectation has been seeded that every random brainwave should take at most one hour to implement (given enough tokens).
What can an IC do in an environment like this? If you slow down and attempt to find any clarity, you’re labeled as slow and ineffective. If you cave to the pressure and start slinging slop with the rest of them, you’re just perpetuating the spiral. Genuinely asking - how do others thread this needle?
I’m in a similar boat. The one thing that seems to help is recognizing when the ask from leadership is genuine, and also sensible from a product point of view. Seize that moment to go fast, and give that your full attention.
The other project will either peter out, because they made no sense from a product point of view or because leadership lost interest. If they’re simple, can likely be done quickly with the help of AI.
It’s not a pretty answer, but AI has helped me cope with this kind of situation much better than in the past.
I also wonder if this kind of workplace is a myth. Maybe every business really is a disaster if you look close enough. Or maybe it does happen, once in a while, where a company really hits their stride, but it’s essentially random when they do.
Or, maybe I’ve just been working in disasters too long and I’m cynical, hard to say.
I have definitely worked on teams that hit their stride frequently. Definitely not every project or deliverable, but often enough that people got used to it. Unfortunately that was maybe 4 or 5 years ago and I haven't seen it since.
There's decision speed and execution speed. You want to sometimes slow down decision speed and get this right. But then develop fast once the target is selected. Chopping wood - you don't slow down the axe swing - but you better be careful where you aim.
> It’s treated like proof of seriousness. If you’re moving fast, you’re ambitious. If you’re cautious, you’re scared. If you ask to slow down and think, you’re blocking momentum. If you point out that the current plan has all the structural integrity of wet cardboard, you’re being negative.
For a significant portion of corpo office work, this actually holds. Not all work critically needs perfection, most just needs to be done. The trick is to be able to discern immediately which work does not fall into that category and actually needs to be done slowly and carefully.
Nothing in the post is wrong, but there's an anti-pattern where teams resist change, the software ossifies, and people cite these mantras like "slow is smooth and smooth is fast", when in reality the users just want new features shipped on the order of weeks/months, not quarters/years. Users eventually lose patience, leave or fork the code or solve their problem differently, and route around the team that doesn't get stuff done.
You're right and I'd argue that the approach I'm suggesting in this post gets your delivery schedule more aligned with weeks/months than with quarters/years.
What we have now produces quarters/years delays (and in a lot of cases, an inevitable throwing up of the hands to move on to the next disaster/panic). It's paradoxical, certainly, but the Tortoise and the Hare is one of the most accurate fables ever written (why I keep a little tortoise figurine on my desk).
Older generations understood this and go figure, the world was far more stable. We sold that out in favor of speed and quick profit and now we're in for a serious roller coaster ride. And for what? The illusion of having moved faster in the present at the expense of stability in the future.
This honestly applies to current society, not just work.
Even the fun bits of life have been infected with the "speed" thing. We want things, and we want them NOW!
But movements like this come and go, what actually stays are the real things, the ones made with time, passion and love. The rest is just waiting to be forever forgotten.
Some people are unable to become motivated unless there is pervasive sense of emergency. They will delay their own work to the last possible minute and pull all-nighters just for the excitement. When those people get promoted to management they can be hell to work for, having concluded that the only way to motivate themselves holds for everyone else as well.
I agree with all of this, but the inverse is just as bad.
Incompetent people will always find a hiding spot through imitation. They will bikeshed and posture like they know what they're talking about. Then they rush anyway at the last minute and still make a mess, or they delegate to someone who will do the same.
The actual problem starts at the top of the organization. All it takes is one bad link in the chain and oversight is lost.
I agree with this. When people say speed, they often mean cycle time. How fast can I iterate towards a working solution to a problem? A low cycle time can hide many flaws in your staff and hiring. Experienced developers can go slower and be more deliberate because they know where they are generally headed, so they need fewer cycles to get there.
The biggest joke of the entire things is that no one wins by being first anymore. It is not the 1990s.
If anything, you win by being a good second. Facebook won because it watched MySpace mistakes and fixed them.
There is even less value in being first with this AI-driven nonsense. The first mover just creates the template everyone else feeds into an LLM. You do the hard work. Someone else collects the reward.
More specifically, winning often means being last. Case in point: Lycos, AltaVista, Yahoo!, Infoseek... then Google. Let others rush around doing your prototyping.
Only partly true. Look more carefully. Page and Brin devised their product as a response to other search engines—-which they couldn’t have done by rushing into search engines. For them, given their ages, their timing was probably happy accident. Still, why not imitate successful accident?
I can't think of very many first movers that really had an advantage. Maybe if you get a lot of essential patents. Or you get very lucky with timing and capture a large market nobody noticed wasn't serviced.
But so many of today's market leaders were late entrants. Sometimes many years late.
Ubers advantage was selling under price for years and being willing to break laws worldwide. And before someone brings up medallions, Uber was selling under price and breaking labor laws where in countries where taxis worked as a normal competitive market.
They did not had to be first. They were not first either.
"The better work is usually calmer than people expect. It still moves[...] It does not worship motion for its own sake."
There's two architects, Reiser and Umemoto who wrote a book called The Atlas of Novel Tectonics about maybe 20 years ago and a sentence that always stuck with me was "in a moving world the nomad is the one standing still".
The whole cult of speed irony, like digital nomads who only ever seem to camp out in Starbucks, is that they're the most homogenous, like-minded, incapable of independent thought people you will ever meet. They'll tell you they've done 50 things and stayed in 50 countries and somehow seem less travelled than someone who just stood still. Same with the whole productivity software velocity, ship this or that crowd. They always have 20 projects but seemingly never actually do anything, or do the same thing everyone else does.
> nobody wants to do the slower, harder work of making sense before moving.
I fear it’s more perverse at times, people just don’t always understand and can’t make sense of it so they just rush to start something as it avoids admitting the truth
I would, yes, given how unsustainable the whole AI industry looks like. It would be way, way better if they could figure out their things out before pushing so hard for the whole software world to adopt their experimental tech
I don’t see the problem with the technology not being available widely for way longer as it improves. If you think the current situation is a good one you’re not paying attention to how ridiculous the spending has been on the AI bet. What exists now is not sustainable at all, and is already the cause of a massive worldwide inflation. And so far no proof of improving companies ROI.
The AI push is going to damage our societies for a long time
It's irrelevant... The spending commitment OpenAI has for 2030 is larger than the projected AI infra market in 2030. And we still haven't seen a proof that agents contribute positively to consumers ROI. It's a capital misallocation problem, a number problem, that has nothing to do with subjective feelings regarding LLMs
no... please actually look at the information we know about AI vendors and how much debt they have. OpenAI is projected to have more than $20B in losses for 2026. They wouldn't _just_ need to make a shit ton of money, they would need to first become profitable, then do a shit ton of money while staying profitable, for multiple years, just to match their spending commitment. That's not even taking in account their ROC and company valuation
Sure but if they do make money and profit, your concern would have been invalid in hindsight wouldn’t it?
Your concern seems to be profitability of OpenAI but that’s easily falsifiable. I’m not saying it’s 100% but I’m saying if they do turn out profitable, your concern wouldn’t have been valid.
depends on the exact chain of events, but if the economics are indeed solved, and AI labs are found to have a sustainable business model, that concern would be addressed. I would still see the technology as anti-human and would still see the concept of an agentic economy as deeply unserious, wasteful, and risky. Not exactly sure what your point is though.
FWIW my concerns aren't only for OpenAI, it's just the poster-child of the AI bubble. SpaceX AI strategy and investment is a complete joke (the S-1 they filled is an insult to a reader's intelligence). Anthropic seems to have been more cautious but has the same fundamental economic problems. Nobody in that whole industry has a moat, the top AI vendors are way too exposed to Chinese/open-weights labs. The datacenters debt investment vehicles (SPVs) look extremely shady and made to obfuscate the underlying assets. The HBM manufacturers seem to be going through one of the most violent boom-burst cycle ever. Oracle is... doing Oracle things, I would be shocked if that company is still alive in its current form in 5y. And so on
> It's a capital misallocation problem, a number problem, that has nothing to do with subjective feelings regarding LLMs
Now you say
> I would still see the technology as anti-human and would still see the concept of an agentic economy as deeply unserious, wasteful, and risky. Not exactly sure what your point is though.
You can see how someone might be confused with this. Is it your subjective feeling? Or objective economics? I’m not interested in your subjective feelings on AI.
On objective economics: your concern would be invalid if the AI companies overall make profit. If they don’t, then you would have been right on the point of being careful.
No, I don’t see the confusion. There are a lot of distinct issues with LLMs. In my initial message I made it clear I was talking about the economics issues.
> your concern would be invalid if the AI companies overall make profit. If they don’t, then you would have been right on the point of being careful.
No, that’s fallacious reasoning. If the AI vendors are currently profitable that doesn’t mean the concerns regarding their unsustainability is invalid, but that changes the calculus depending on the details. They could be profitable right now on paper and still be economically not viable. The core problem is that the amount of money allocated to the AI bet is completely disproportionate compared to the actual economical value of the technology. That’s where the imbalance is. The exact reasons for the imbalance can change over time, but there would still be a misallocation. The companies would need to be profitable, and/or their expenditures would need to pay off, and the overall demand needs to grow exponentially, and they need to be protected from Chinese competitive pressure, etc.
This thread is emblematic of the HN view of AI. It starts with some vague concerns - you specify that it is a purely economic concern and not subjective feeling. After being asked that if the economics work out would your concern be proved wrong, you then started mentioning things like anti-human and piling up a random list of other topics.
Essentially you have made your concern utterly unfalsifiable - however the material world situation pans out in AI, your concern would be validated. There's a lot of emotion in all this and its a good idea for you to separate it out from your real objective concerns.
I won’t engage with you again on this website, you’re not engaging in good faith. Read the thread again, none of my responses are me trying to weasel out. I took your (fairly low quality) questions seriously, and answered them honestly. My _economics_ concerns are definitely falsifiable, but not with such simple assertions as „but what if they are profitable“. That’s would only address one of the multiple economics problems, something I clarified in my responses. The fact that I, personally, would still want the technology to be eradicated, even if the economics math out, is a different concern altogether. There are layers of concerns, societal, economics, political, cultural. you seem to approach the topic really naively
Yes exactly the layers of political and social concerns are all new and you added them up in the later part of the thread. You might realise, I hope, that these are all nebulous concerns. Basically left yourself unfalsifiable - a person could have made the same layered unfocused accusation on the internet in 1980s. Something something anti human, something societal and political. It’s a good tactic I tell ya.
If you do go fast and don't deprive your customers of your product but the product breaks and doesn't deliver its intended value, is that a better tradeoff?
Re: AI development, I'd say it's foolish to slow down research, but worthwhile for rollouts to the market. The time that should have been used for preparing people/businesses was wasted on fearmongering campaigns. Now we have a fire hose of slop that's out of control.
> If you do go fast and don't deprive your customers of your product but the product breaks and doesn't deliver its intended value, is that a better tradeoff?
Its not a good tradeoff if it breaks it enough that people move off your product, I obviously concede that.
Ultimately a firm should be incentivised to improve their long term profits after accounting for externalities to the world. Fast or slow is an implementation detail.
>Re: AI development, I'd say it's foolish to slow down research, but worthwhile for rollouts to the market. The time that should have been used for preparing people/businesses was wasted on fearmongering campaigns. Now we have a fire hose of slop that's out of control.
Its not clear that your subjective view of slop is reason enough for the world to slow down on AI rollout and I'm glad I don't live in a world that doesn't necessitate slowing down due to whims and fancies of a few people's subjective aesthetic takes.
Ironically for me, all the companies _do_ want to slow down their pace for reasons related to actual safety. I think you would appreciate the cause and the foresight (if any).
> Its not clear that your subjective view of slop is reason enough for the world to slow down on AI rollout and I'm glad I don't live in a world that doesn't necessitate slowing down due to whims and fancies of a few people's subjective aesthetic takes.
This is a misunderstanding of what I'm talking about. It's not about "slop" in and of itself, it's about what reality that slop inevitably creates. There's a lot of focus on the output ("ermagherd you wrote this with AI"), but very little on the ripple effects/second-order effects (people spinning up cults, ending marriages, and gambling away their money [1]). That's not just cute "look at the freaks" stuff, that's a serious, civilizational-level problem 1-2 decades out.
You're right that my subjective opinion means dick-all beyond being that of an experienced, educated user of this stuff. But I'd at least hope that people take heed of what I'm saying and start to push back when it's objectively clear that decisions are closer on the spectrum to disaster than they are to benign mediocrity.
Thank you for sharing that link, this is exactly what I'd hope to see happening behind the scenes.
A while back, I read that as you age, you tend to slow down not because of your age itself, but because you incorporate all the experience you’ve accumulated over the years into your thinking process. I wish I still had the link or something...
But on the flip side let's not pretend there is no benefit at all in being fast.
For example, there are certain situations where slowing down will only push out decisions you would take anyway. Or: You develop a fully fledged product just to find out you could have found out that no one needs it with a simple mock-up. It's good to know when it's appropriate to be fast and when not.
The rocking horse quote is new to me, but coincidentally enough I've often described the same behavior as a skittish horse. Still very valuable to not confuse motion with progress.
I find this speed-obsession to just be a natural side-effect of obsessive toxic competitiveness that's plaguing the internet. And its been around for a while. Clickbait videos and articles like top 10 holiday destinations or how to improve on X are top recommended content. What to do and not to do to be the "best" runner/cyclist/manager etc. Then there are small things like measuring "time" it takes to read an article. This obsessiveness feels in many ways harmful. You don't need the best pen to draw or not code because AI can do it better. You also don't need to have the best bike for going up and downhill and neither do you need the classic Tour douchebag attire. Its totally ok to be a human, run short small laps around a nearby hill, draw shitty landscape art and write semi-legible prose on Hacker news. Its also fine to write code to maintain sanity in AI-infested workplace (shocking I know). The internet won't tell you that though.
This article highlight a huge problem which permeates every aspect of society.
The entire education system is built around the assumption that speed = merit. Any time a person has to sit a test under time constraints, the most significant factor being measured is thinking speed. Not reliability, not creativity; just speed.
I have similar thoughts about 'short term thinking'; this is another religion which has quietly taken over nearly every aspect of the modern human experience.
A very relevant book that goes beyond the workplace (but also includes it): Alienation and Acceleration: Towards a Critical Theory of Late-Modern Temporality by Hartmut Rosa
Amen to disgust with the cult of speed. A large part of what people spend their time trying to do fast doesn't really need to be done at all; most of the rest doesn't need to be done fast. One of the tragedies of our modern world is that there are so many things that could be done that would make it better, and some of them are urgent, but instead people are rushing to do quickly stuff that would be better left undone.
Surely there is a middle ground between speed being the overriding concern and stagnation. Also there is a question of what makes for better life/work balance and healthier working environment. I guess those things don't matter so much to the ambitious. You can sleep when you die and other mantras guaranteed to cause serious health concerns on down the line.
I don't think posts should be flagged for being AI (they often contain interesting or important ideas as well), but I do think it should be pointed out.
It's like deepfakes. You only know it's AI when it's not convincing; when the deception has failed. When you're fooled, you don't know it's AI. You just think it's a video.
As a manager I'm guilty in part of driving the cult of speed
However I noticed that whether a team member thought for a day, or thought for a week, the result was essentially the same. The tactics may have more details but the overall plan and impact id expect was roughly the same. They had blind spots, opportunities that could make it more impactful that only came to light when they talked thru it.
So for me, it was better to touch base sooner than later and get the broad plan right, then let them figure out the details and get to it
I think the desire for longer term planning is to smooth out the variance.
Yes, frequent base touching, to ensure alignment on the broad contours is right, but I find yeeting a significant project with one day of planning has a tendency to turn up either requirement gaps, cross team coordination problems, or wildly inaccurate effort estimates (the classic "20 minute adventure" taking a month or two).
Now this can be fine, and in my experience management loves this approach _provided nothing unexpected happens_, but totally loses their shit when your two week effort turns into a 6 week slog with a "not sure boss" estimate for a completion date because the scope and methods are so ill defined
Slow is smooth. Smooth is fast.
My learnings about speed:
* people tend to not measure things and when they actually do bother they tend to measure the wrong things, the things of immediate comfort
* measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect
* people tend to guess at measures because either they are incapable or the effort is too high
* when people guess at measures they tend to be wrong more than 80% of the time and when they are wrong they tend to be wrong by multiple orders of magnitude
* measurements tend to produce micro-improvements, but those micro-improvements add up in ways that are both significant and unexpected
* if you want to go faster the most certain course of action is to modify your technology and techniques
* hiring is slow, just as adding more people to a late project makes it slower
* changes lower in the stack tend to grant both increased speed and increased flexibility. Increased scale comes from what you do with those
>Rowers have a word for this frictionless state: swing... Recall the pure joy of riding on a backyard swing: an easy cycle of motion, the momentum coming from the swing itself. The swing carries us; we do not force it. We pump our legs to drive our arc higher, but gravity does most of the work. We are not so much swinging as being swung. The boat swings you. The shell wants to move fast: Speed sings in its lines and nature.
Our job is simply to work with the shell, to stop holding it back with our thrashing struggles to go faster. Trying too hard sabotages boat speed. Trying becomes striving and striving undoes itself. Social climbers strive to be aristocrats but their efforts prove them no such thing. Aristocrats do not strive; they have already arrived. Swing is a state of arrival.
—Houghton Mifflin, Mind Over Water
Hmmm, so it sounds like the root cause isn’t really about “speed” at all… but something else?
For example, someone in a meeting saying things lacking credibility and everyone else just goes along with it anyways. Then it snowballs meeting after meeting.
Weird analogy. Nonsensical from both physical standpoint (the only energy input when swinging is the person on the swing "pumping their legs"), and practical one (you usually sit down with the swing already at an angle and then kick off, so a good 50% of the arc/momentum is there from the setup).
Right, and remember how getting the rhythm right was the whole trick of it? Learning when to bend back and when to lean forward? When to pump your legs, so that your relatively small inputs were additive to the momentum of the swing, not fighting it? How when you kicked at the wrong time, you could feel the balance upset, you could feel the swing slow?
It's not bad I think. We must be open-minded and humble, like a child, and learn how the system actually works in order to be effective.
Often times our first instincts will not work, so we must observe, experiment, and try again. And not be afraid of looking foolish with our legs flailing around. Find the underlying rhythm and flow with it, not against it.
You clearly didn't read this. It's about rowing. Not being on a playground.
The original quote is a bit unclear, but it does refer to being on a playground:
"Recall the pure joy of riding on a backyard swing: an easy cycle of motion, the momentum coming from the swing itself. The swing carries us; we do not force it. We pump our legs to drive our arc higher, but gravity does most of the work. We are not so much swinging as being swung."
It's a bit confusing since it starts with "Rowers have a word for this frictionless state..."
I spent a good minute or two trying to picture what 'drive our arc higher' could mean during rowing, as that is not when force is exerted...
I found it excerpted in Getting Things Done, where the author presented it as the ideal for how one should approach their life, both professionally and personally.
GTD is the opposite of being on a swing. It's the constant fear of the parents shouting your name from the balcony to tell you the playtime is over and you need to get back home for a Weekly Review.
Aka “mechanical sympathy”
Mechanical empathy
> * measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect
I don't understand what you're trying to say. What are the reasons some people can't introspect? Is it even true that some people can't introspect?
There are many reasons. Some are ethical like conflicts of interest or bias. Some are financial like insufficient time or missing tools. Most commonly the cause is personality and sometimes it’s types of neuro-divergence.
Regarding "measurements tend to produce micro-improvements", not if you are the first to actually measure stuff in a codebase. There tend to be big fat low-hanging fruit.
> measurements, when executed correctly, are objective with numeric evidence, thus some people are wholly incapable of measuring things for the same reasons some people cannot introspect
you can't measure everything, and choosing what to measure is an editorial decision that introduces bias.
Bias is the whole point. Measures are taken to produce outcomes that someone has selected. Typically the person accountable for the results of their team or department. They have editorial authority.
The problem is that in software development, measures are rarely executed well. The things that are measurable are either not as important as things that are not objectively measurable, or they can be too easily gamed.
You can fail a project not because you were technically wrong about anything, but because you burned your customer out by taking 6 months instead of 6 weeks to find a viable solution to their problem. Speed is a feature from the perspective of your customers. There is economic value associated with it.
Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas. This is how a lot of business leaders feel every day. Speed is the best way to meet uncertainty in complex domains. Unless you are fairly sure you can one shot the problem with a single commit, having a process to iterate with some expediency is important to success.
There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast.
There are many different types of software customers. A company that contracts an iOS/Android developer to build them an app for an upcoming conference is different from a WalMart that hires developers to build them an e-commerce platform which is also different from a software developer who uses an AWS service who is different from the average Windows or iOS users. All are “software customers”. Yet
> There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast.
I don’t really now what customer type that would even be. Is the customer the one controlling the quality or reliability or driving the solution? How would the customer even know you’re “going too fast”? They can’t. They’ll just tell you “everything is half broken all the time, wth?” Is that how they tell you you’re going too fast?
Calling an HVAC tech to fix a broken AC is like an engineer doing a hotfix to alleviate a problem. No one is saying that should take 6 month. A better analogy is expecting the your home builder to build you the house in few days because it’s Texas in August and the sun is too hot outside. Then spending the next 6 years fixing “issues” in the house that was built in a week. Yeah, they didn’t put insulation. Yeah, they run the electrical wiring on the outside. Yeah, the walls aren’t anchored, and plumbing just dumps everything under the house. But at least you’re not in the hot sun.
Of course! The article agrees with you
> Real speed exists. Real speed is what happens when the work is understood, the constraints are clear, the people involved know what they’re doing, and the decisions have been made cleanly enough that execution can happen without constant re-litigation.
I think the article is arguing against speed preventing the kind of planning and alignment that makes smooth delivery possible. Rushing is probably the easiest way to make mistakes that ultimately kill projects, credibility, or at least increase the costs in relational capitol, time and morale. Defaulting to a panicked frenzied state of mind is a perfect way to fail at delivering expedient results.
Depends on the organisation as I've seen the opposite (excessive planning without taking action) too. I'm on the speed side of things nowadays because I was usually wrong when I thought that the "work is understood and the constraints are clear".
Yes, the problem is the feedback loops often don't really exist in the planning stages. It is more difficult to gauge progress. There can be very detailed specifications or plans that won't survive their first contact with reality. This is why waterfall is over with.
Yet - not planning effectively is also a huge problem.
So then the article boils down to, doing things well is good and doing things poorly is bad?
Not arguing against speed, just poorly-executed speed.
If you assign speed-based KPIs to everything, you will get both the good speed and the bad speed.
> Consider your state of mind when you call the HVAC tech to fix your broken condensing on an August afternoon in Texas
And consider your state of mind after the tech came over 6 times in a week, each time claiming to have fixed your HVAC but it keeps breaking.
It seems as if you did not really read the article.
The piece is titled "Religion of Speed" -- in other words speed (or apparent speed) as the guiding principle over anything else.
It says nothing even remotely like "you should take 6 months to do something that can be accomplished in 6 weeks."
And this statement:
"There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens. Let them decide for you how fast is too fast"
is baffling to me.
In my experience (40+ years in software development) I have never had a customer/client that would be in a position to have the proper situational awareness + technical depth to make this judgement call.
And even worse I would guess that if even this was not the case that 95% of the time they would not say you're going too fast, instead they would ask to go faster.
I like this argument, but I don't think the article argues against taking urgency into consideration. Do you have anecdotes about companies or people that actually ignore urgency?
I've experienced enough business-critical incidents (or requests) where people across all seniority are just randomly trying stuff, making a mess, without taking time to coordinate, understand the problem, and solve it. It almost always resulted in more overall time and bigger blast radius than if we did it not out of panick.
OTOH my "slow" (I still did things fast, just not purely for the sake of looking fast) and steady approach always took me less time overall to find a proper fix. I also became known as the person who could always find the best possible fix when there's an incident/time constraint, but I also thought that was systematically bad instead of fixing the culture/process.
It's still faster to take a minute (and deep breath), understand the whole problem (incl. urgency and how that affects your solutions), and then solve it. It doesn't mean you can't keep your customers in the loop and assuage their concerns.
Businesses fake urgency all the time. I guess I have never worked in any of these 'high stakes' companies. My whole career, everything was reportedly urgent, but when you missed the deadline, nobody dies, nobody got fired, you just slipped a little and leadership pretended even more urgency. And if you slipped a lot, people got burned out and quit and leadership would institute 'war rooms' and 'crunch time'. And if you slipped a hell of a lot, the project would probably get canceled and the rest of the team was absorbed into various other projects. Nothing matters, the company's stock goes up and down randomly--having nothing to do with your project's failure or success, yet the message from above is always "FAST FAST RUSH URGENT!!!"
It has to be done by next week.
Here it is. It is done.
Great, now we put it on a shelf and ignore it for 6 months.
From my perspective, every time.
Edit: the last time this happened to me, they later revealed that it was going to be shelved for a year.
Don't confuse urgency for FOMO.
> There is definitely a point where you are going too fast, but the customer will almost certainly let you know when this happens.
Usually by stopping doing business with you forever.
> viable solution
Please define viable solution. It's like a piece of string: how long is it? It's a very subjective statement "6 weeks to find a viable solution" - could just as well be 6 months.
Sure you can deliver something that might seem viable and the customer might also a cycle of updates as the viable solution becomes the solution - but how many updates are tolerated and how bad are the problems in the seventh week?
Sure we dumped waterfall for agile and now we live in a constantly updating world of "viable solutions" ...
>but the customer will almost certainly let you know when this happens
The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break. On top of that, because the rate of shipping new features doesn't necessarily match with the rate of usage of said features the moment you'll find out about it will not happen ASAP but probably sometime later, making it even harder to truly know if going fast is the right thing to do in the moment.
> The customer won't be able to tell you "you're going too fast", but he will tell you that stuff break
This is what the GP meant. They won’t spoon feed you the “you’re going too fast”, but they will give you other signals that you can, and would benefit from, interpreting as “you’re going too fast”
The religion of speed is the religion of VC investment backing, because VCs have set time horizons for delivering returns to their own investors. You can only get their interest if you can make them believe you can deliver 10x growth on their schedule.
Committing to that schedule — and really believing in that commitment — is what turns someone into the sort of person who sets arbitrary project timelines that disregard technical practicality, and then kills projects when they fail per those arbitrary timelines.
These timelines are not arbitrary. They are dictated by the cost of money (for the VC). They have little to do with the target market situation, and totally don't care about technical considerations. They only care if your profits, or at least revenue, or at least market share grows fast enough. If it does not, they write off their losses and liquidate the company.
This is the fear that dictates the damned speed™: either you go up insanely fast, or you die. If your goals do not align with this approach, do not take VC money. If you want to develop things without haste, only join a startup with a proven PMF and insanely goos sales team, which takes care of hockey- stick growth so that you can concentrate on quality.
I never said the VC's timeline is arbitrary! They're ultimately based in loan interest rates / bond yields / etc — as you say, the "cost of money."
But the timelines that founders and CEOs can end up coming up with for the arbitrary subprojects/efforts they choose to pursue to try to get the company closer to giving those VCs the hockey-stick growth they demand, are much more arbitrary. Mostly in the sense that such subprojects/efforts can often be selected/pursued with no thought to the fact that either the goal is technically impossible within the chosen time budget; or, even if possible, that the effort won't demonstrate results within the chosen time budget, and so will be given up on whether or not it's working (because founders interpret absence of metrics as metrics relaying absence.)
Which is to say: if you can guarantee from before you start that a given subproject or effort will be considered "a failed experiment" — then you'd think it would be obvious that you shouldn't do that one. That you should put it on the backlog of things you can try after PMF + hockey-stick growth, when you have time to evaluate things thoroughly.
But that doesn't seem to be obvious to a lot of founders and CEOs. Many of them spend a lot of their and their employees' time setting off on efforts that everyone in the room basically already knows they'll be cancelling two weeks later, before said effort has had a chance to either succeed or fail on its merits.
The rocket equation of a turtle egg..
Venture-backed companies is an extremely small subset companies when you look at this objectively.
The alternative is debt financing, and let me tell you, there's a lot more deadlines and urgency in there.
If you want to feel real urgency, try working at a company attempting to bootstrap without VC funding. Unless your company is very lucky to strike gold early on, the pressure to deliver fast and get money coming in is even more real. Everyone wants to start getting paid real salaries instead of eating ramen noodles. Everyone wishes they could hire a few more people to spread the workload around.
Startups are very hard, period. In my experience, the ones that get VC funding are a less stressful than those that don’t because you start with a generous buffer of money in the bank and you have investors who might backstop the company’s bank account if you run out. They do want returns, but bootstrapped companies also want returns too. That bootstrapped founder who sacrificed potential earnings for years to get their startup off the ground wants employees delivering fast, too.
It’s not a religion or cult. It’s the reality of startups. Something is risked to start them and the people who risk it expect a larger reward than they would have received. For VCs, that larger reward has to be better averaged returns than investing in the stock market or other investments. For founders, that large reward needs to be larger wealth than what they could have gotten working for FAANG. The pressure comes either way.
I like setting arbitrary project milestones or timelines. They don't have to kill the project, but it's good to cast efforts in relief against external developments.
It's not just technical practicality that's disregarded, it's nearly everything valuable about anything that's worth doing. It's why VC is a cancer on the world.
Use to work with a pretty jaded Army Colonel. He'd often say: "even periodic motion looks like progress on short enough time scales." And also, "Slow is smooth and smooth is fast."
I remember learning to race on the track.
In the sharp turns, you feel like that's where you should try really hard to go fast. Because you're going so slow!
But really, it makes more sense to slow down MORE, be smooth and controlled and get the turn right. And you'll get a better drive and be faster later. slow in, fast out.
also, the math wins - going 1mph faster on the 1/4-mile straightaway works out better than going 1mph faster on the 100-foot slow turn.
While I agree with the idea, the math is misleading.
Going 1mph faster on the 100-foot turn may be faster overall than going 1mph faster on the 1/4-mile straightaway if the speed difference is large enough.
Ex:
- 1/4-mile at 100 mph takes 9s, at 101 mph, it will take 8.9s
- 100 ft at 20 mph takes 3.8s, at 21 mph it will take 3.2s
It means that overall, in this situation, it is better to go 1 mph more on the turn (8.9 + 3.8 > 9 + 3.2).
It is a metaphor.
Getting pedantic about the simple math laid out in the metaphor seems like you have lost the plot.
hmm... this is all my remembering old stuff. I thought there was better math when you go faster on the long parts vs trying to go faster on the short difficult parts?
better instead to use the short stuff to set up for better speeds on longer parts.
oh whatever.
With racing, in particular, the high accident zones are the corners so that's where extra care is required.
Hence, in racing, the common advice to newbies is "to finish first, first you must finish".
IOW, make fewer mistakes before you try to go faster.
Being fast is good, if there is not any obstacle on the way)
>"Slow is smooth and smooth is fast."
When I was in basic the instructors repeated this incessantly. About two thirds of the way through what Americans would call OCS they made us walk into "the gas hut" which is a concrete bunker-like building in the middle of a field near the rifle range.
Inside the hut is a hot plate with an old shitty skillet. Inside the skillet are pellets that give off tear gas when heated. You walk into the hut and immediately get slapped in the face by what I might charitably describe as the worst onion-eyes you've ever experienced, multiplied by at least 100.
But the training is fantastic because in that moment as I was standing there with my eyes scrunched and burning, I unconsciously whipped out the gas mask, put it on, did the proper drills with the filter and decon cream, and had no conscious recollection of having done so. The urge to rip off the mask and rub your eyes is overwhelming. The instructor told me "good drill" and sent me on my not-so-merry way.
Same thing with mag drills. You slap that forward assist without even thinking. Anyways, slow really is smooth which really is fast.
From an engineering perspective slow is smooth is fast, but from a sales perspective slow is smooth is slow. If you quote superior quality with 6 months later delivery your competitor will get to sign a contract that could very well last 5-10 years and comes up just so rarely. Missing out on that contract doesn't always mean you get to focus on other projects, it could mean you have to fire whole teams of people that you don't have anywhere to assign anymore.
From my perspective a failure point is when companies do delegate time to make things correct, but demand results from the get go. Billing and tracking becomes weird for them if you work on infrastructure, design systems, component libraries, system design etc and you have nothing to show for after 6 months or a year. "But the future development will be super fast" doesn't fly past upper management unfortunately.
Urgency can definitely be real, but you can't actually go faster by not planning. There are plenty of cases where just a few hours of planning could have made a huge difference, preventing weeks of thrashing and rework.
Sure, it seems true for a short period. But rushing something forward means you cut corners and that catches up with you over time. Anyone who has ever had a sales team asking for special features to be hacked into a product with little or no time for any proper architectural considerations or releasing before all the testing is complete in order to “get the big deal” has felt this. Yes, the other side may win a deal, but rarely the war.
That said, I’ll very deliberately make the distinction between going slow in a thorough and responsible way from just being slow in an incompetent way. Market forces are real and a consistently slow team gets canceled. To put it another way, sometimes slow is smooth and smooth is fast, and sometimes slow is just slow. The trick is knowing the difference between.
> The trick is knowing the difference between.
The trick is striking a balance. The article is arguing that there is little to no balance and that "apparent speed" trumps all other concerns.
Hence the use of the word "Religion" in the title.
I realized early on that sometimes management thinks that if you don't look stressed than your not taking it seriously enough. Phrases like "I don't feel that you have a sense of urgency" really messed with my head back then.
Real management is about making decisions, most typically about how to apply limited resources amongst competing options.
But a lot of Managers (and the managed) think it is about managing people. Their real role is “Overseer” not Manager, and in that role their real task is to ensure you’re working harder.
I have had that exact same thing said to me. didn't so much mess with my head as make me think someone with such a poor grasp of appearance vs reality had no business being a CEO.
They tend to be a bit anxious and get anxious that your not anxious. There are many that are not like that
We did a paper airplane test in 5th grade. We split into teams and made them like McDonnell Douglas, etc. First, we saw how many airplanes we could make and then how far they flew. Everyone was rushing to get the planes made, but I took my time and measured them to make sure every fold was done right. My planes flew the farthest, and our team won the government contract. The moral of the story was that haste makes waste.
Your team won government contract for paper planes?
It was a school experiment. The government doesn't want sloppy planes; they want them to be of high quality and fly far. The government was the teacher who decided who won.
They measured really really well
There are anecdotes supporting almost any point.
We've all heard about the "make 100 clay pots", or, sometimes it's photos group vs "make 1 perfect clay pot" group.
Yeah, but I made more than 1 plane. You don't want planes that can't fly and crash because they were made sloppily and fast.
Sorry if it sounded like I was picking on your story, that wasn't my intention.
I was just thinking out loud. You hear stories of "do 100, it beats doing 1" and "plan well and do 1, it beats doing 100", in the end... you sort of chose the stories that agree with you.
Yeah, but if you do 100 things with low quality, it is going to be crappy. In the mid-1990s, I did quality control work on debugging code for Visual BASIC and ASP web pages. Now people are rushed to do sloppy work in quantity because it is done fast, not quality, where it is done right.
Speed is not velocity. A person jumping off of a 100 floor building, will have a lot of speed, probably think they are flying!
Velocity comes from being thoughtful. Thinking about thousands of dependencies and navigating towards the end goal.
In big corporations, neither speed nor velocity matter. Its mostly garbage products. There will be deadlines and these are planned for Annual Performance Review. There will always be some success story (or the milestones changed) to show that the people favored by the leaders are 'delivering' on the right 'metrics' and they need to be richly rewarded. And also this 'success' is because of the excellent 'stewardship' by them, therefore they must also be rewarded.
This quote is gold: "Do not confuse motion and progress. A rocking horse keeps moving but does not make any progress.” — Alfred A. Montapert
Impossible to disagree with the author, and yet something seems missing in the discussion... Let me check:
Ctrl-F, 'deadline'
0 result.
Oh, yeah, that's what missing from the discussion.
And without any trolling, I'm curious about what the author would have to say about this matter.
Not all "need for speed" comes from a vacuum. Is it always legit ? Should we push back ? Sure.
Do we always meaningfully, practically, realistically have a choice anyway ?
I think the author is having a kind of idealistic, relaxed view of work. Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.
These are obvious lessons of agile management. Even if they are not absolute, maybe that post is meant as some kind of relative statement, in general, speed is a good thing. More speed than you are comfortable with.
> Moving quickly, even if you break things, has a clear advantage over being perfectionistic, waiting to get feedback, building things that are not needed.
The entire point of slowing down is so you don't do this. Understand the problem well first, so you don't waste time building something that was never viable in the first place.
The author isn't advocating for perfect. You have to understand the problem well enough to know what all of the critical assumptions are. Some assumptions will derail an entire project if you get them wrong. Others will be a minor inconvenience, at worst.
In software, having a solid handle on future architecture means you can speak to how unanticipated new features fit in. You know what parts you can skip for now, and have it not be a big deal.
I've started to wonder if many of the people obsessed with speed lack capability. If you can't build something well, you can try building something poor quickly. This certainly applies to my current employer.
Author here. This is the correct interpretation of what I was getting at.
Most deadlines are artificial and self-inflicted. The author is not advocating that if you have a literal fire consuming half your home that you should sit down on the floor, ponder your possibilities, schedule a few calls for discussion, then send a few messages on Slack to decide what to do; of course some things are more urgent than others. The author is calling out a “speed cult”; they’re not making an absolutist argument but the exact opposite, advocating for “the discipline of judgment”.
> Most deadlines are artificial and self-inflicted.
most software in the world is built by consulting companies for external customers and under their customer's deadline, thus not self-inflicted
When I worked in consulting, the majority of deadlines were still self-inflicted, based on estimates provided by us.
If you fall into the fast -> unexpected -> iteration -> alignment cycle the author mentions, those estimates tend to be based on the 'fast' part only; that closes deals.
I'm the author.
Deadlines are artificial constraints (typically, some deadlines are unshakable—eg "we have to launch the payload when conditions are clear") that, imo, distract from the actual goal or task at hand.
Sadly, a deadline is more often used as an excuse to rush, and not because the deadline itself is of material consequence (e.g., meeting a vendor's production deadline is unshakable).
Instead, the more common reality is that someone in a position of limited agency uses the deadline as a sort of mental whip. This may get a result faster, but rarely is the work that was rushed solely to meet a deadline the best the team/individual was capable of. More often, you get a broken mess that now necessitates wasting more time later cleaning it up (this is the part I think traps a lot of people; it's a stealing from Peter to pay Paul situation).
When I've discussed this in the past, most misinterpret my point through too binary a lens. This isn't some hippie dippie idealist "just, like, do whatever maaan" kind of take.
Instead, it's a suggestion for those in an environment that's always "moving fast" but rarely if ever hitting the mark. This leads to papering over the obvious problem: the team or individual responsible for the bad work is rarely someone of pure incompetence and more often is just under completely imagined pressure that doesn't exist (beyond the confines of the minds involved).
I'm not naive, of course you can't blanket apply this line of thought to every situation (especially in corporate America). I'm more so angling at "have you considered that rushing is the reason everything you ship falls apart and doesn't meet its goals?"
Case in point: FedEx deployed some new dashboard software for their employees doing package handling. I came in to drop off a MacBook I was sending in for repair. While scanning it in, the system just broke (in the "it ain't doing the thing no more, ma" sense). The clerk was able to manually scan it, so skipped the system and gave me a receipt. A week later, Apple never got the laptop. I start calling around frantically, now having to do work I shouldn't be doing. It was determined that the label printed (the one I got a receipt for) wasn't the "correct" label to scan (that was hidden under another label already on the box). This led to weeks of unnecessary phone calls re-explaining the situation to various employees, now arguing with me about a mistake FedEx made.
Eventually, Apple called it a mulligan after a month and sent me a new laptop.
My point: whatever caused the FedEx team to rush had a ripple effect of wasting inordinate amounts of time and costing Apple $5K. Why? Because whoever built that dashboard software rushed and made an otherwise simple idea into a half-working, frustrating mess. This is the type of situation I have in mind when I tell others "we need to slow down."
Like I alluded to in the post, it's not about moving slow as a matter of psychological comfort, but as a means to avoid creating messes in the present (and future) in service of an arbitrary deadline that's less rooted in necessity and more so in fulfilling the ego of whoever is in charge. That's a tough pill to swallow, I get it, but like most things, the actual problem isn't the process or reality, it's the human mind convincing itself of things that just aren't true.
Fedex Returns is just about the least competent product technology entity I've ever encountered and this migration was a garbage fire even by their low standards. I doubt if they could have gotten it right if they spent 10 years on it, and its entirely possible they did do that.
I work for FedEx and even our scanners are garbage. If they spent more time on quality SWE instead of impressing management, things would work out for them very well in the long run.
Author, here. Thanks for sharing this!
Reader here. Thanks for creating this. Totally resonates with my own thoughts, so if I'm wrong at least I have company :-)
I do have a suggestion for those who object to this line of reasoning: Follow the 5 why's to try and get to the source of your own reasoning and see whether it still makes more sense - in the sense of whether you end up adding to the common good
Ironic that parts of the article feel so AI written.
load-bearing this load-bearing that
They don't seem that way to me. I should also note that AI generated content can at times be better than some human generated content
It’s been well thought out and edited but it’s clearly written by AI, and it was obvious long before “load-bearing”. Still - it makes an important point well and is worth reading.
Agree exactly!
If every use of AI was like this, I perhaps wouldn't have this slight allergic reaction to it, but as it stands, this voice and rhythm has become associated with bad lazy grifting writing.
[dead]
> But those questions feel slow because they remove the little dopamine hit people get from motion.
An AI won't have written that - that would imply that AIs would be criticising their overlords and masters.
Thanks for writing it! It was exactly what I needed to process my frustration with work today.
The longer I spend in my career the more obvious this is to me. Unfortunately younger colleagues don't always have the maturity to have also realised this, which can be a problem if they end up above me in the management chain!
I try to kickstart reflection on this by saying things like "Some of the biggest impact I've had has been the code I chose not to write."
Felt this in my bones. It’s painful how accurately this describes my current work situation. The pressure comes from the top - leaders that have no idea what they want but they want _something_ to happen NOW. This has only gotten worse with the recent AI thoughtleadering because now the expectation has been seeded that every random brainwave should take at most one hour to implement (given enough tokens).
What can an IC do in an environment like this? If you slow down and attempt to find any clarity, you’re labeled as slow and ineffective. If you cave to the pressure and start slinging slop with the rest of them, you’re just perpetuating the spiral. Genuinely asking - how do others thread this needle?
I’m in a similar boat. The one thing that seems to help is recognizing when the ask from leadership is genuine, and also sensible from a product point of view. Seize that moment to go fast, and give that your full attention.
The other project will either peter out, because they made no sense from a product point of view or because leadership lost interest. If they’re simple, can likely be done quickly with the help of AI.
It’s not a pretty answer, but AI has helped me cope with this kind of situation much better than in the past.
If quality isn't valued, then your only alternatives are to try to change that (good luck), accept it, or look for somewhere that does?
I really love the ideas here.
I also wonder if this kind of workplace is a myth. Maybe every business really is a disaster if you look close enough. Or maybe it does happen, once in a while, where a company really hits their stride, but it’s essentially random when they do.
Or, maybe I’ve just been working in disasters too long and I’m cynical, hard to say.
I have definitely worked on teams that hit their stride frequently. Definitely not every project or deliverable, but often enough that people got used to it. Unfortunately that was maybe 4 or 5 years ago and I haven't seen it since.
> I also wonder if this kind of workplace is a myth.
It’s not.
There's decision speed and execution speed. You want to sometimes slow down decision speed and get this right. But then develop fast once the target is selected. Chopping wood - you don't slow down the axe swing - but you better be careful where you aim.
> It’s treated like proof of seriousness. If you’re moving fast, you’re ambitious. If you’re cautious, you’re scared. If you ask to slow down and think, you’re blocking momentum. If you point out that the current plan has all the structural integrity of wet cardboard, you’re being negative.
For a significant portion of corpo office work, this actually holds. Not all work critically needs perfection, most just needs to be done. The trick is to be able to discern immediately which work does not fall into that category and actually needs to be done slowly and carefully.
Nothing in the post is wrong, but there's an anti-pattern where teams resist change, the software ossifies, and people cite these mantras like "slow is smooth and smooth is fast", when in reality the users just want new features shipped on the order of weeks/months, not quarters/years. Users eventually lose patience, leave or fork the code or solve their problem differently, and route around the team that doesn't get stuff done.
You're right and I'd argue that the approach I'm suggesting in this post gets your delivery schedule more aligned with weeks/months than with quarters/years.
What we have now produces quarters/years delays (and in a lot of cases, an inevitable throwing up of the hands to move on to the next disaster/panic). It's paradoxical, certainly, but the Tortoise and the Hare is one of the most accurate fables ever written (why I keep a little tortoise figurine on my desk).
Older generations understood this and go figure, the world was far more stable. We sold that out in favor of speed and quick profit and now we're in for a serious roller coaster ride. And for what? The illusion of having moved faster in the present at the expense of stability in the future.
This honestly applies to current society, not just work. Even the fun bits of life have been infected with the "speed" thing. We want things, and we want them NOW! But movements like this come and go, what actually stays are the real things, the ones made with time, passion and love. The rest is just waiting to be forever forgotten.
Some people are unable to become motivated unless there is pervasive sense of emergency. They will delay their own work to the last possible minute and pull all-nighters just for the excitement. When those people get promoted to management they can be hell to work for, having concluded that the only way to motivate themselves holds for everyone else as well.
> The original rushed work gets recorded as “fast.”
That's often the important part (to the perpetrators).
Their part gets done quickly. The cleanup is SEP (Somebody Else's Problem[0]).
[0] https://en.wikipedia.org/wiki/Somebody_else%27s_problem
I agree with all of this, but the inverse is just as bad.
Incompetent people will always find a hiding spot through imitation. They will bikeshed and posture like they know what they're talking about. Then they rush anyway at the last minute and still make a mess, or they delegate to someone who will do the same.
The actual problem starts at the top of the organization. All it takes is one bad link in the chain and oversight is lost.
I agree with this. When people say speed, they often mean cycle time. How fast can I iterate towards a working solution to a problem? A low cycle time can hide many flaws in your staff and hiring. Experienced developers can go slower and be more deliberate because they know where they are generally headed, so they need fewer cycles to get there.
> I agree with all of this, but the inverse is just as bad.
The inverse would be "The Religion of Slow".
I have never seen or experienced anything remotely like this in the real world.
Have you?
The biggest joke of the entire things is that no one wins by being first anymore. It is not the 1990s.
If anything, you win by being a good second. Facebook won because it watched MySpace mistakes and fixed them.
There is even less value in being first with this AI-driven nonsense. The first mover just creates the template everyone else feeds into an LLM. You do the hard work. Someone else collects the reward.
>If anything, you win by being a good second.
More specifically, winning often means being last. Case in point: Lycos, AltaVista, Yahoo!, Infoseek... then Google. Let others rush around doing your prototyping.
Google didn't win because it was last. It was last because it won!
Only partly true. Look more carefully. Page and Brin devised their product as a response to other search engines—-which they couldn’t have done by rushing into search engines. For them, given their ages, their timing was probably happy accident. Still, why not imitate successful accident?
It's always in the last place you look.
You mean, Google lasts because it won one.
Xerox to Apple
I can't think of very many first movers that really had an advantage. Maybe if you get a lot of essential patents. Or you get very lucky with timing and capture a large market nobody noticed wasn't serviced.
But so many of today's market leaders were late entrants. Sometimes many years late.
JIRA?
JIRA is from 2002, Bugzilla is from 1998, GNATS is from 1992.
Not sure that this is universally true. Youtube, Uber, Airbnb and others all have massive first-mover advantages.
Ubers advantage was selling under price for years and being willing to break laws worldwide. And before someone brings up medallions, Uber was selling under price and breaking labor laws where in countries where taxis worked as a normal competitive market.
They did not had to be first. They were not first either.
OK, so apparently YouTube was not a good example !
Google Video, with the might of Google behind it, launched three months before YouTube.
Didn't Vimeo come out a year before?
"The better work is usually calmer than people expect. It still moves[...] It does not worship motion for its own sake."
There's two architects, Reiser and Umemoto who wrote a book called The Atlas of Novel Tectonics about maybe 20 years ago and a sentence that always stuck with me was "in a moving world the nomad is the one standing still".
The whole cult of speed irony, like digital nomads who only ever seem to camp out in Starbucks, is that they're the most homogenous, like-minded, incapable of independent thought people you will ever meet. They'll tell you they've done 50 things and stayed in 50 countries and somehow seem less travelled than someone who just stood still. Same with the whole productivity software velocity, ship this or that crowd. They always have 20 projects but seemingly never actually do anything, or do the same thing everyone else does.
> nobody wants to do the slower, harder work of making sense before moving.
I fear it’s more perverse at times, people just don’t always understand and can’t make sense of it so they just rush to start something as it avoids admitting the truth
If you don’t go fast you deprive your consumers of your product. It’s not clear why that tradeoff is good?
There was a recent petition signed by all major AI labs to slow down AI development. Would this author or you guys agree it’s a good thing?
I would, yes, given how unsustainable the whole AI industry looks like. It would be way, way better if they could figure out their things out before pushing so hard for the whole software world to adopt their experimental tech
if they took their time then billions of people wouldn't have access to it for years and decades.
its now super clear that AI is a step improvement in coding, mathematics and other domains. the push for AI has worked out in hindsight.
there will always be people who will parrot the METR study and claim productivity didn't increase but its best to ignore them.
I don’t see the problem with the technology not being available widely for way longer as it improves. If you think the current situation is a good one you’re not paying attention to how ridiculous the spending has been on the AI bet. What exists now is not sustainable at all, and is already the cause of a massive worldwide inflation. And so far no proof of improving companies ROI.
The AI push is going to damage our societies for a long time
Why do you think the spending is ridiculous? Do you not agree that we've had a step improvement in coding, mathematics, search/retrieval?
It's irrelevant... The spending commitment OpenAI has for 2030 is larger than the projected AI infra market in 2030. And we still haven't seen a proof that agents contribute positively to consumers ROI. It's a capital misallocation problem, a number problem, that has nothing to do with subjective feelings regarding LLMs
In that case, if the numbers do work out and labs make shit load of money, would you agree you were mistaken?
no... please actually look at the information we know about AI vendors and how much debt they have. OpenAI is projected to have more than $20B in losses for 2026. They wouldn't _just_ need to make a shit ton of money, they would need to first become profitable, then do a shit ton of money while staying profitable, for multiple years, just to match their spending commitment. That's not even taking in account their ROC and company valuation
Sure but if they do make money and profit, your concern would have been invalid in hindsight wouldn’t it?
Your concern seems to be profitability of OpenAI but that’s easily falsifiable. I’m not saying it’s 100% but I’m saying if they do turn out profitable, your concern wouldn’t have been valid.
depends on the exact chain of events, but if the economics are indeed solved, and AI labs are found to have a sustainable business model, that concern would be addressed. I would still see the technology as anti-human and would still see the concept of an agentic economy as deeply unserious, wasteful, and risky. Not exactly sure what your point is though.
FWIW my concerns aren't only for OpenAI, it's just the poster-child of the AI bubble. SpaceX AI strategy and investment is a complete joke (the S-1 they filled is an insult to a reader's intelligence). Anthropic seems to have been more cautious but has the same fundamental economic problems. Nobody in that whole industry has a moat, the top AI vendors are way too exposed to Chinese/open-weights labs. The datacenters debt investment vehicles (SPVs) look extremely shady and made to obfuscate the underlying assets. The HBM manufacturers seem to be going through one of the most violent boom-burst cycle ever. Oracle is... doing Oracle things, I would be shocked if that company is still alive in its current form in 5y. And so on
Here’s what you said earlier
> It's a capital misallocation problem, a number problem, that has nothing to do with subjective feelings regarding LLMs
Now you say
> I would still see the technology as anti-human and would still see the concept of an agentic economy as deeply unserious, wasteful, and risky. Not exactly sure what your point is though.
You can see how someone might be confused with this. Is it your subjective feeling? Or objective economics? I’m not interested in your subjective feelings on AI.
On objective economics: your concern would be invalid if the AI companies overall make profit. If they don’t, then you would have been right on the point of being careful.
No, I don’t see the confusion. There are a lot of distinct issues with LLMs. In my initial message I made it clear I was talking about the economics issues.
> your concern would be invalid if the AI companies overall make profit. If they don’t, then you would have been right on the point of being careful.
No, that’s fallacious reasoning. If the AI vendors are currently profitable that doesn’t mean the concerns regarding their unsustainability is invalid, but that changes the calculus depending on the details. They could be profitable right now on paper and still be economically not viable. The core problem is that the amount of money allocated to the AI bet is completely disproportionate compared to the actual economical value of the technology. That’s where the imbalance is. The exact reasons for the imbalance can change over time, but there would still be a misallocation. The companies would need to be profitable, and/or their expenditures would need to pay off, and the overall demand needs to grow exponentially, and they need to be protected from Chinese competitive pressure, etc.
I still don’t understand your overall point
This thread is emblematic of the HN view of AI. It starts with some vague concerns - you specify that it is a purely economic concern and not subjective feeling. After being asked that if the economics work out would your concern be proved wrong, you then started mentioning things like anti-human and piling up a random list of other topics.
Essentially you have made your concern utterly unfalsifiable - however the material world situation pans out in AI, your concern would be validated. There's a lot of emotion in all this and its a good idea for you to separate it out from your real objective concerns.
I won’t engage with you again on this website, you’re not engaging in good faith. Read the thread again, none of my responses are me trying to weasel out. I took your (fairly low quality) questions seriously, and answered them honestly. My _economics_ concerns are definitely falsifiable, but not with such simple assertions as „but what if they are profitable“. That’s would only address one of the multiple economics problems, something I clarified in my responses. The fact that I, personally, would still want the technology to be eradicated, even if the economics math out, is a different concern altogether. There are layers of concerns, societal, economics, political, cultural. you seem to approach the topic really naively
Yes exactly the layers of political and social concerns are all new and you added them up in the later part of the thread. You might realise, I hope, that these are all nebulous concerns. Basically left yourself unfalsifiable - a person could have made the same layered unfocused accusation on the internet in 1980s. Something something anti human, something societal and political. It’s a good tactic I tell ya.
There is not a single reply where you understood the position you were arguing with.
I'm the author.
If you do go fast and don't deprive your customers of your product but the product breaks and doesn't deliver its intended value, is that a better tradeoff?
Re: AI development, I'd say it's foolish to slow down research, but worthwhile for rollouts to the market. The time that should have been used for preparing people/businesses was wasted on fearmongering campaigns. Now we have a fire hose of slop that's out of control.
Why? Rushing.
> If you do go fast and don't deprive your customers of your product but the product breaks and doesn't deliver its intended value, is that a better tradeoff?
Its not a good tradeoff if it breaks it enough that people move off your product, I obviously concede that.
Ultimately a firm should be incentivised to improve their long term profits after accounting for externalities to the world. Fast or slow is an implementation detail.
>Re: AI development, I'd say it's foolish to slow down research, but worthwhile for rollouts to the market. The time that should have been used for preparing people/businesses was wasted on fearmongering campaigns. Now we have a fire hose of slop that's out of control.
Its not clear that your subjective view of slop is reason enough for the world to slow down on AI rollout and I'm glad I don't live in a world that doesn't necessitate slowing down due to whims and fancies of a few people's subjective aesthetic takes.
Ironically for me, all the companies _do_ want to slow down their pace for reasons related to actual safety. I think you would appreciate the cause and the foresight (if any).
https://www.pacingthefrontier.com/
> Its not clear that your subjective view of slop is reason enough for the world to slow down on AI rollout and I'm glad I don't live in a world that doesn't necessitate slowing down due to whims and fancies of a few people's subjective aesthetic takes.
This is a misunderstanding of what I'm talking about. It's not about "slop" in and of itself, it's about what reality that slop inevitably creates. There's a lot of focus on the output ("ermagherd you wrote this with AI"), but very little on the ripple effects/second-order effects (people spinning up cults, ending marriages, and gambling away their money [1]). That's not just cute "look at the freaks" stuff, that's a serious, civilizational-level problem 1-2 decades out.
You're right that my subjective opinion means dick-all beyond being that of an experienced, educated user of this stuff. But I'd at least hope that people take heed of what I'm saying and start to push back when it's objectively clear that decisions are closer on the spectrum to disaster than they are to benign mediocrity.
Thank you for sharing that link, this is exactly what I'd hope to see happening behind the scenes.
[1] https://www.theguardian.com/lifeandstyle/2026/mar/26/ai-chat...
A while back, I read that as you age, you tend to slow down not because of your age itself, but because you incorporate all the experience you’ve accumulated over the years into your thinking process. I wish I still had the link or something...
But on the flip side let's not pretend there is no benefit at all in being fast.
For example, there are certain situations where slowing down will only push out decisions you would take anyway. Or: You develop a fully fledged product just to find out you could have found out that no one needs it with a simple mock-up. It's good to know when it's appropriate to be fast and when not.
The rocking horse quote is new to me, but coincidentally enough I've often described the same behavior as a skittish horse. Still very valuable to not confuse motion with progress.
I find this speed-obsession to just be a natural side-effect of obsessive toxic competitiveness that's plaguing the internet. And its been around for a while. Clickbait videos and articles like top 10 holiday destinations or how to improve on X are top recommended content. What to do and not to do to be the "best" runner/cyclist/manager etc. Then there are small things like measuring "time" it takes to read an article. This obsessiveness feels in many ways harmful. You don't need the best pen to draw or not code because AI can do it better. You also don't need to have the best bike for going up and downhill and neither do you need the classic Tour douchebag attire. Its totally ok to be a human, run short small laps around a nearby hill, draw shitty landscape art and write semi-legible prose on Hacker news. Its also fine to write code to maintain sanity in AI-infested workplace (shocking I know). The internet won't tell you that though.
This article highlight a huge problem which permeates every aspect of society.
The entire education system is built around the assumption that speed = merit. Any time a person has to sit a test under time constraints, the most significant factor being measured is thinking speed. Not reliability, not creativity; just speed.
I have similar thoughts about 'short term thinking'; this is another religion which has quietly taken over nearly every aspect of the modern human experience.
A very relevant book that goes beyond the workplace (but also includes it): Alienation and Acceleration: Towards a Critical Theory of Late-Modern Temporality by Hartmut Rosa
Thank you for the recommendation!
Amen to disgust with the cult of speed. A large part of what people spend their time trying to do fast doesn't really need to be done at all; most of the rest doesn't need to be done fast. One of the tragedies of our modern world is that there are so many things that could be done that would make it better, and some of them are urgent, but instead people are rushing to do quickly stuff that would be better left undone.
Because the antonym is stagnation.
Work takes all the volume you give it.
The best managers I worked with had at least one common feature: always giving deadlines to move things forward.
Because you don't live on an empty planet. Other companies and people also run forward.
Being slow means you will get behind. In some markets, like software, this means you won't get anything at all.
Surely there is a middle ground between speed being the overriding concern and stagnation. Also there is a question of what makes for better life/work balance and healthier working environment. I guess those things don't matter so much to the ambitious. You can sleep when you die and other mantras guaranteed to cause serious health concerns on down the line.
Work-life balance is more about work hours and purpose vs how quickly you're targeting to finish things, at least in my view.
Thank you, Claude, very interesting.
I agree but I believe it is still well thought out and worth a read, which is rare.
I don't think posts should be flagged for being AI (they often contain interesting or important ideas as well), but I do think it should be pointed out.
The compulsion of pointing it out has becomes very annoying IMHO.
Slop is slop -- if it is AI generated slop then fine, call it out.
If it is not slop what is the point of this compulsion? It derails a lot of threads when the content is actually good.
That's a great point.
It's like deepfakes. You only know it's AI when it's not convincing; when the deception has failed. When you're fooled, you don't know it's AI. You just think it's a video.
As a manager I'm guilty in part of driving the cult of speed
However I noticed that whether a team member thought for a day, or thought for a week, the result was essentially the same. The tactics may have more details but the overall plan and impact id expect was roughly the same. They had blind spots, opportunities that could make it more impactful that only came to light when they talked thru it.
So for me, it was better to touch base sooner than later and get the broad plan right, then let them figure out the details and get to it
(Note I work in marketing, not engineering)
I think the desire for longer term planning is to smooth out the variance.
Yes, frequent base touching, to ensure alignment on the broad contours is right, but I find yeeting a significant project with one day of planning has a tendency to turn up either requirement gaps, cross team coordination problems, or wildly inaccurate effort estimates (the classic "20 minute adventure" taking a month or two).
Now this can be fine, and in my experience management loves this approach _provided nothing unexpected happens_, but totally loses their shit when your two week effort turns into a 6 week slog with a "not sure boss" estimate for a completion date because the scope and methods are so ill defined
This is very interesting
Apparently it wasn't worth slowing down and letting a human write this article.
I can relate
[dead]
[dead]