I ran into some serious struggles when we got far enough into accepting most of the tenets of XP as standard practice that most jobs didn’t even debate half of them and then landed at places that still thought they were stupid. I’d taken for granted I wasn’t going to have to fight those fights and forgotten how to debate them. Because I Said So is not a great look.
Again - that's a business decision that needs to be made in the context of that business. The fact that testing was forbidden isn't in itself good or bad. It depends on that business context. THe post says nothing about how that decision was made, whether it was discussed, or if it was just his absolutist ideal he imposed without consideration of the broader cost-benefit.
And I still feel the original comment doesn't give this point enough weight.
Hard disagree. It's both. Choosing one way or the other comes with potential risks and rewards to the business and it's up to business leadership to choose what risks they want to take. Your job as an engineer - if you are not part of leadership is to explain those risks / rewards, and then let them make the call.
I have an education and experience in software development. If a manager told me to make a product in an unsafe manner, I'd refuse, and if push came to shove, leave.
Leave, both because I wouldn't be able to defend my work as a professional, but also because I wouldn't work under someone who would want to dictate the manner in which I do what I do.
This is missing the point. If you’re a 2 man team it’s much more important to have code that has a couple bugs in it but allows you to quickly find your product market fit. As opposed to perfect code with no bugs that is useless.
No one is disagreeing that tests are good in a vacuum / mature product. But if your focus is building a mvp, and you’re trading off the test time with other things, it’s not always worth it.
Screw “leadership” but consider for a second that you’re the leadership.
The truth is in the middle somewhere, regarding tests at least (yes, your microservices story is insane).
I think the author could have been happier with the no-test decision if they had treated the initial work as a prototype with the idea of throwing it away.
At the same time, writing some tests, should not be seen as a waste of time since if you're even at all experienced with it, it's going to be faster than constantly reloading your browser or pressing up-up-up-up-up in a REPL to check progress (if you're doing the latter you are essentially doing a form of sorta reverse TDD).
So I dunno... I may be more in line with the idea that's a bit insane to prevent people from writing tests BUT so many people are so bad at writing tests that ya, for a go-gettem start up it could be the right call.
I certainly agree with your whole cost-benefit analysis paragraph.
When it stopped being two people he still forbade tests. In this decade. That is fucking nuts.
Fun fact: the guy I worked a 2 man project with and I had a rock solid build cycle, and when we got cancelled to put more wood behind fewer arrows, he and I built the entire CI pipeline. On cruisecontrol. And if you don’t know what that is, that is Stone Age CI. Literal sticks and rocks. Was I ahead of a very big curve? You bet your sweet bippy. But that was more than twenty years ago.
Did anyone here actually look at the product they were actually building? It's an AI agent bug discovery product. Their whole culture is probably driven at a fundamental philosophical level about the problems of bug discovery. As he says: he wanted to rely on dogfooding - using their product as the way of spotting bugs.
That may have been spectactular naivete but it's not insanity.
The point I keep coming back to here that everyone is fighting me so hard on is that these blanket statements of: NO TESTS IS NUTS... absent of an understanding of the business context... is harmful.
What ends up happening is that your most fundamental features end up rotting because manual testing has biases. Chief among them is probably Recency Bias. It is in fact super easy to break a launch feature if it’s not gating any of the features you’re working on now. If you don’t automate those, yes, you’re nuts.
One of the worst ones I ever encountered was learning that someone broke the entire help system three months prior, and nobody noticed. Because developers don’t use the help system. I convinced a team of very skeptical people that E2E testing the help docs was a higher priority than automating testing of the authentication because every developer used that eight times a day or more. In fact on a previous project with trunk based builds, both times I broke login someone came to tell me so before the build finished.
Debugging is about doing cheap tests first to prune the problem space, and slower tests until you find the culprit. Testing often forgets that and will run expensive tests before fast ones. Particularly in the ice cream cone.
In short, if you declare an epic done with zero automation, you’re a fucking idiot.
I think maybe - this conversation is more about giving some more acknowledgement to the other side of this issue.
It's not that I disagree with you essentially - or particularly with respect to your analysis of your specific examples. 100% in the cases you describe. Those sound like beneficial tests. Particularly because your example SPEAKS to the business case - users were using the help docs (I think you mean users anyway). So yeah - that's important.
But I don't know why it's so hard extracting a simple acknowledgement of what I'm pointing out - specifically that the decisions like implementing tests IS a cost-benefit decision dependent on business context.
Funny you mention auth testing though. One time both me and the tech lead broke one of the auth flows in production within the space of a week of one another. Yep - no tests. Feel free to judge us insane. But here's how we thought about it - and when I say "we" that includes the business. First of all the auth flow was not actually used by any active users, so damage was low. Two man dev team. Complexity up until that point had been low, pre-product market fit, sales were dogshit, and cash had been low for some time. Feature shipping was the 110% priority. Ok - but these bugs were a sign complexity had increased beyond what we could manage without some tests. And given the importance of auth, it was now easy to make the case to leadership that implementing an e2e test suite was worth it. So we did.
If you still think a decision making process like that is insane - because we didn't immediately implement tests for every shipped feature. Well - I just think you're wrong.
There is supposedly a famous video series of Uncle Bob trying and failing to solve sudoku with TDD. He did not read any guides on solving it and tried from first principles instead, and bounced off of it.
It’s clear to me that if you don’t know what you’re building, testing it first has rubber duck value that can easily be overshadowed by Sunk Cost. I always test my pillars - the bits of the problem that are definite and which I will build off of.
Yes, starting with tests without market fit can also be fatal. But calling anything done without tests is just a slower poison. Before you airlift your brain to another unrelated problem you need to codify some of your assumptions. If you’re good at testing you can write them in a manner that makes it easy to delete them when requirements change. But that takes practice a lot of people don’t have because they avoid writing tests or they write the exact same kinds of tests for years at a time without every stretching their skills.
If you’re not writing tests you’re not writing good ones when you do. Testing is part of CI and the whole philosophy of CI is do the painful parts until you either grow callouses or get fed up and file off the scratchy bits. To avoid testing is to forget the face of your father.
> Yes, starting with tests without market fit can also be fatal. But calling anything done without tests is just a slower poison.
I think we are pretty close to agreement here. I'd be interested in what you have experienced in the realm of front-end testing though - whether you think things are just as cut and dried in that realm (that's another discussion though).
And I'll also accept the point about skill in test writing that improves the cost-benefit analysis. I'll also cop to not having that kind of practiced ability at testing to the level I would personally like. But it's chicken / egg. A lot of folks get their start at scrappy start ups that can't attract the best talent. And just can't afford to let their devs invest in their skills in this way. Hell - even established companies just grind their devs without letting them learn the shit they need to learn.
I feel a victim of this to some degree - and am combating it with time off work which I can afford at the moment. One of the things I'm working on is just understanding testing better - y'know, so I can in the future write a SKILL.md file that tells Claude what sort of tests it should write. lol...
Testing is hard. No, testing is fucking hard. I've had more mentors in testing than any other two disciplines combined. And I still look at my own tests and make faces. But to a man everyone who has claimed testing is not hard has written tests that made me want to push them into traffic.
Every problem is easy if you oversimplify it.
I send people who come to me struggling with their tests away with permission to fail at them but not permission to give up on getting better. You're gonna write broken tests. Just don't keep writing the same broken tests.
If anyone looking for a PhD or book idea is reading along with this, my suspicion is that it's so difficult because we are either 1) fundamentally doing it wrong (in which case there's room for at least 2 more revolutions in testing method) 2) someone will prove mathematically that it's an intractable problem, Gödel-style, and then someone will apply SAT solvers or similar to the problem and call it a day. Property based testing already pretty much does Monte Carlo simulation...
For backend tests, the penalty at each level of the testing pyramid is about 8x cost for a single test (and IME, moving a test down one level takes 5x as many tests for equivalent coverage, so moving a test down 2 layers reduces the CPUtime by half but also allows parallel execution).
For frontend I think that cost is closer to 10x. So you want to push hard as you can to do component testing and extract a Functional Core for unit tests even harder than you do for backend code. Karma is not awesome but is loads better than Selenium, particularly once you have to debug a failing test. I've been on long projects for a minute so I can't really opine on Puppeteer, but Selenium is hot flaky garbage. I wouldn't tolerate more than 100 E2E tests in it, even on a half million line project. Basically a smoke test situation if you use it like that, but you won't have constant red builds on the same eight tests on shuffle.
I want to say we had 47 E2E tests on a project I thought was going swimmingly from a SDLC perspective. But it might have been 65.
Great comment... and I feel after reading it, you're probably a pretty great person to work with. Acknowledging the pain / difficulty of a task, but inspiring folks, and giving them the opportunity to perservere is rare to find these days.
https://hackernews.hn/item?id=3033446 - Linking to this old comment because it links to each of Ron's articles, a discussion about it, and Norvig's version.
Norvig's solution is a work of art. When people ask me for examples of intrinsic versus accidental complexity, his sudoku solver is the best one I have. My only note is that he gives up and goes brute force early. When I first encountered it I had a lot of fun layering other common solving strategies on top of his base without too much extra trouble.
What I did not have fun with is porting it to elixir. That was a long journey to get to a solution I could keep adding stuff too. Immutable data is rough, particularly when you're maintaining 4 distinct views on the same data.
Did you edit the wording of your original comment slightly to emphasise the "actively disallowing them" in every situation? Anyway... if that is what you meant, then ok. It's less awful a statement than what I felt I originally read.
I'd still push back on your hyperbole though. I don't think the author was insane - and we don't know what the broader business context was when they started growing the team and decided to persist without building out the test architecture at that point. They made a call that dogfooding was going to be enough to catch issues as they grew the team. There are a lot of scenarios where that is going to be true.
One scenario where it wouldn't - the most likely - is that the team isn't actually dogfooding because they personally don't find the product useful. Leadership lambasts them to use the product more... but no one does cause it sucks so much it impacts their own personal productivity.
Even there I wouldn't use the word insane... just poor leadership.
He did not edit, and you're misunderstanding the meaning behind his post. Not everything needs to be pedantic and accurate, language is flexible, this is about communicating, not being right.
What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP
He edited his reply to me multiple times... which is what made me suspect an edit to the original comment. But whatever, I'm happy to acknowledge his original intent even if he did state it more harshly.
>What we really don't need is paragraphs of someone arguing because their own definitions differ slightly from the OP
This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations. Even if we allow for nuance OP is claiming, there is little constructive about his contribution. I feel fine about calling it out.
I got the sense from your reply that some extra clarity would be beneficial.
> This is unnecessary. OP came out with "AUTHOR IS INSANE" even on the most generous of interpretations.
I did not actually call the author insane, I called their decision to explicitly disallow testing insane. It's an insane decision. I am not _literally_ calling the author insane.
If you think this distinction really matters wrt the point I'm trying to make, then it's time for you and I to bug out conversationally. Sometimes two individuals have such different ways of communicating that the pain of exegesis isn't worth the squeeze. No hard feelings. I'm sure 50% responsibility is at least mine, but it's not going to be worth it for either of us figuring out exactly what.
I'm not really arguing with your point, I'm correcting your incorrect description of what I'm saying.
To argue with your actual point: I don't really care about the overall context, actively disallowing tests in a codebase is a _bad decision_. Look how it worked out for them.
> it's time for you and I to bug out conversationally
Not having ANY tests means tons of manual testing is needed every time you modify code, which will rapidly consume more time than writing the tests would.
The manual tests also stop being run, or get reduced to such an extreme that any value from them is going to be low. Testing only happy paths and maybe release specific tests. This is shockingly (to outsiders, not to anyone who's ever been in the industry) common in aerospace and defense systems. There were some aircraft I would not fly on for a few years until I knew our updates had rolled out. Now I'm not connected to that work anymore so I'm back to "ignorance is bliss" mode and try not to think about it.
> If you are a two man startup, burning through runway and pre-product-market fit... then spending a lot of time on tests is questionable (although the cost-benefit now with AI is changing very fast).
What's insane that people in 2026 still think tests slow you down.
It takes me maybe 40 hours (1 week) of coding to start receiving ROI from writing tests in a greenfield project, and by 80 hours I'm pretty sure I've saved more time from bugs and improved design due to TDD than I've spent writing the tests.
The ROI is even faster if I'm not the only developer on the project.
If your flagship product takes less time to develop than 40 hours, then your product is extremely vulnerable to being copied by another company, so your entire software project is a bad business idea.
So there really aren't many exceptions: either your project benefits from tests, or it's too easy a project to be a business.
So frankly, it's your comment lacking in cost/benefit analysis.
A dictatorship? Are you being forced at gunpoint to talk to people?
Perhaps more unsurprisingly, at the mere suggestion that socializing is good for you (it demonstrably is https://pmc.ncbi.nlm.nih.gov/articles/PMC11403199/), you went and wrote a comment that I can only imagine someone who is deeply unhappy would write.
That is not a kind judgment. While I hesitate at the word “dictatorship” it is fair to say that society puts more value on extrovert interaction than introvert contemplation, and it does this because extroverts dominate the social conversation.
I know what ECDSA is and if you brought it up in a random conversation unprompted I'd try to find your spaceship so I could escape the conversation on it.
I think people underestimate how pragmatic meta programming can be because there are some obvious downsides. Arguably one of things that made Rust so popular was its inclusion of procedural macros.
But beyond that the thing I don't understand about the modern hate towards macros is that they are simply very fun.
As someone who is "into" programming languages (and making toy implementations of them), I think some of the most important macros are along the lines of Rust/Haskells `derive/deriving` for quickly enabling serialization, printing etc. Using a language without such capability quickly becomes frustrating once you move to any kind of "real" task.
In any kind of real task, serialization is not the hard part.
If you can write a meta program for it, you can execute that in CI and spit out generated code and be done with it. This is a viable approach in any programming language that can print strings to files.
It’s not frustrating, but maybe it feels tacky. But then you shrug and move on to the real task at hand.
Dealing with nested association lists is a pain. this let you write your code with a dot notation like jq.
Macros are not only for solving a particular task (serialization, dependency injection, snippets,…) they let you write things the way it makes sense. Like having html-flavored lisps for template, sql-flavored lisp for query,… Lisp code is a tree, and most languages are trees, so you can bring easily their semantic in lisp.
You say that, but I've run into real production problems which were ultimately caused by bad serialization tooling. Language semantics are never going to be your biggest problem, but rough edges add up and do ultimately contribute to larger issues.
Yeah I strongly agree. I think the issue is that metaprogramming is complicated, so people (especially early in their careers) tend not to do it themselves, and only notice it when it's making their lives difficult. But there are a lot of cases where a little bit of judicious metaprogramming makes life MUCH easier. If you treat metaprogramming as a first-class tool, countless rough edges will smooth themselves out for you—everything from `#derive[Clone]` to `#derive[Serialize]`.
Ruby, Python, and Typescript use metaprogramming rather heavily. They lack the homoiconic property of lisps, but they can do both higher-order functions and monkey-patching.
Meta-heavy code usually offers a nice DSL, but is proportionally harder to drill down through.
Lisp code is a tree, which fits how most languages are written. So it’s easy to embed other languages in lisp. But other languages grammars are very cumbersome and can’t fit one another.
Socializing is not a "dull chore" it is a essential component of healthy living[1]
By not socializing, you are avoiding (to quote the linked article) a "fundamental human need." This is not something you can simply live without, just like you cannot live a good live without exercise.
The view you are espousing is fundamentally unhealthy.
These kind of findings are probably accurate on average, but not to a person. Some people are wired differently. Some (presumably most) require community and extensive social connection. I really think that some of us just need much, much less. I don't get much sense of reward from social interactions. It really does just feel like a dull chore most of the time. Even with people I genuinely like and respect.
Yeah, I've been trying to wrap my head around this recently. I always get a bit irked by the inevitable comments confidently asserting things like "humans are social animals, if you think you don't need tight social connections you're just hurting yourself". And then pointing to these results averaged out over the entire population as "proof".
It seems like there's got to be some statistical fallacy being made, like asserting "all humans need visual stimulation to survive" and then all the blind people on earth shrug at the data and realize they're not human I guess? On average it's true, "all humans" would go crazy if deprived of their sight, but it turns out some people do it just fine and can have rich, human lives.
I wonder if it's just when people live very social lives, the idea of deriving satisfaction in life internally, to be able to self regulate and maintain a health sense of identity without frequent input from others, is just too alien to consider. To not dislike people, or lack social skills, but just be as disinterested in socializing as I am in starting a coin collection. Or maybe all that is just extremely uncommon and experiences like mine are just a true rounding error.
I think it is like the way getting married is statistically more healthy.
Friends and a partner act like a small life coach. I am sure many unhealthy habits are correlated with being left entirely to your own devices. I know I would go to the doctor more if I had a partner coaching/bugging me that I go more.
We are the outliers. If everyone was wired like me, the concept of a dinner party would simply not exist and Facebook would look like this.
If it helps you understand the other side - very many people, and I consider myself one of them, went through a long part of life without realizing that "humans are social animals". In my case I was very unhappy for a very long time until I realized that socialization was the missing ingredient. Worse, I didn't even realize I was unhappy, and I had persuaded myself I was fine.
When you have this sort of a revelation, it's difficult to hold it in. You want to shout it from the rooftops. You want to grab every single person you can find who has a life remotely like yours years ago when you were unhappy, and save them, in the same way that you yourself needed saving.
I try not to do this any more because I understand it's annoying, and the message is unlikely to successfully transmit anyways. But I suspect this is the phenomenon you are observing.
Thanks, that does help to see it as good faith advice. I'd be totally on board with a framing like "If you're alone and unhappy or dissatisfied in life, social connection could likely be the missing piece." Though it seems even that often follows up with "If you _think_ you're content being alone, you just don't know what you're missing", similar to how parents talk about how their lives changed after having kids. Which is fine and could be true for pretty much everyone, I just hate that it's stated in a way that's unfalsifiable. That if you think differently you're just fooling yourself, and you'll change your mind once you do it.
I've found a lot of those assertions about how to live a "great" life (often based on societal averages about life expectancy) don't fit my actual subjective experience, and I had to spend years doing all the "right things" in life and wondering why it wasn't fulfilling for me. Similar to the sibling comment, it's been liberating to stop taking that type of advice as applicable to me, but that means it jumps out at me everywhere now, hah.
Oh, and for what it's worth, I'm approaching my 40's, have had partners, lived with them for years, good relationship with family, never been burned or damaged socially. Those things just still never seemed as central or necessary to me as they apparently are for others.
For me it was the opposite. Once I realized that I don't have to say yes to everything or socialize unless I want to, no matter how seldom, I became much happier.
I used to be like you, living my life based on external beliefs of what I "should" do. Once I realized that I didn't have to all my stress disappeared and I've never been happier.
People told me I "should" exercise for years and I didn't, but when I did I suddenly got a lot less depressed and my life turned around for the better so I'm going to continue to trust other people
You won't be happier if you don't eat healthy, stay indoors al day, avoid talking to anyone, never exercise, never clean up, because those things are considered a chore. There are things people avoid doing that are still needed to be healthy!
There is a deep irony in an argument that pushes a pro-socializing view in a black-and-white, authoritarian way, "shoulding" statements, shaming tactics. It's actually anti-social, and the authors of the cited paper probably would not agree.
I organized a large (600+-person at its peak) Meetup in Park Slope, Brooklyn, NY during Meetup's hayday (2010-ish).
Meeting heaps of different people from all walks of life was interesting at first. But like a previous poster stated, connections like these are fleeting and take a lot of work to maintain (especially if you're a man, which I am; see the end of this post for more on that).
Consequently, the process of meeting people eventually became very same-y after a short while, and knowing that these conversations usually won't amount to anything other than nice, fleeting moments got old.
There was also the drama of managing "interesting" personalities in a free Meetup group. I passed the baton in 2012 or so, but that's another post for another day.
I'll conclude this post with some unsolicited advice: try to learn what people do for work without asking them directly.
EVERYONE expects this question, and it can be a conversation killer if your occupations don't intersect (less likely) or if the person you're conversing with hates their job (more likely). Everyone ALSO loves talking about themselves. Finding out how someone spends the largest part of their day without asking point-blank adds interesting twists and turns that can really liven up a conversation. It also makes you a better listener and better at asking questions.
I lied; I have more unsolicited advice. The easiest way to give a shit about what someone does for work is to ask lots of questions! Unless they hate their job, in which case, you'll want to ask questions that get them talking about what they do enjoy!
Typing that last paragraph reminded me of another reason why I got burned out on socializing with people. I'm a man. Most men only like sports and video games; two things I couldn't care less about. Socializing with other men as a man who dislikes these things is extremely difficult, especially in the US South, where I live. I blame the suburban lifestyle, but that, too, is another post for another day.
What do you like to talk about?
I'm passionate about my work and happy to discuss topics but not too keen to explain it to someone who has nill knowledge of the subject or industry.
Honestly I don't talk much. But generally things related to whatever we're doing, entertainment (books, movies, sports, and so on), my kid when I had him, and now that I am getting older a bit more philosophical meaning of life type stuff.
Have you tried getting meta about sports and video games? I don't care about sports, but I'll be interested if you talk to me about the business of sports clubs or the technicalities of stadiums. Video games have a lot going on around them: The lawsuits and general weirdness around how Disco Elysium was made is the stuff of several documentaries, for example.
Anecdotally, I'd say women are worse when it comes to interests. It's incredibly common that they just don't have any, which isn't the end of the world, oddly enough. There might be little to discuss, but drinking some wine, going to the movies or a gallery while having a pleasant conversation - these can be fine activities. Hard to turn it into a club, but on the other hand it's basically universal.
> I'd say women are worse when it comes to interests
You're looking at it wrong, or from a Mans perspective. Woman don't need the same "activities" or "hobbies" as men, these are doing thing that Men like.
Woman just need to socialize to socialize. Thats why they have book clubs, brunches and wine/art. They just need to talk.
Absolutely. I think I might actually prefer this, somehow. It's very relaxed.
One thing that vexes me in dating women, however, is that it's hard to figure out what "type" of woman a woman is. I think men might be a bit easier to read at a glance.
I agree people love to talk about themselves. I disagree about work being the one to go for though. Career is the default conversation; the boring conversation.
I ask 'What keeps you busy?' and if people think of work then that's fine, but for those of us that don't center our lives that way there is an opportunity to discuss something else. Asking what you do for income is a more narrow and closed conversation.
I do think unhealthy is the way to put it. I think that being asocial is kind of like being overweight, in that they have similarly negative effects on health[1]. Of course, being in good health is multifactorial, and just as you can find many overweight people who are otherwise in fine health, you can find many people (like yourself) who eschew social situations but are otherwise perfectly happy.
Though I do think, if you extend the metaphor, that saying that socializing is a dull chore is a bit like saying exercising is a dull chore.
reply