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.
> 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...
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.
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.
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.
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.
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.
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.
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.
I've heard analysis that a significant proportion of middle east water and food supply - in the form of desalination plants, and cargo through the Strait of Hormuz - is within reach of Iran's capabilities. The logic is that you use this to collapse middle eastern economies which blocks the flow of the investment from Arab states into AI infra that is propping up the US economy.
The prediction that there will be greater demand for specialist frontend and backend engineers is the one that surprises me. How do folks think about it? I've been assuming the opposite - that demand for specialists will decline because expectations around what a single person should be able to do will grow.
I'm a frontend specialist developer currently taking some time off to reskill - and trying to decide exactly which direction to go. My thinking was that I would need to lean into design and product - leverage my technical knowledge in building interfaces to be able to inform the product side. Knowing what is easy or hard to build hopefully would speed up the product side.
That's interesting - but I guess we need to understand better what innovation counts as a good example of Chinese incipient superiority.
If China is leap frogging the west technologically, then it can still only be a very recent fact. It stands to reason that their current innovations will be developed on top of much of what they learnt from the west.
That doesn't mean that a particular innovation does not deserve to be counted as an example of their progress, just because that innovation was on the shoulders of western tech. Most progress is done on the shoulders of others anyway. So I don't feel examples like this should be discounted.
But also - there are a lot of dimensions to think about here. For example, one dimension is the raw development of a technology. Maybe China has not developed so much newer tech (although I'm reading much to the contrary in this respect also). But another dimension is the economics involved in implementation. With scale comes so many advantages. Business models that just aren't economical in Western countries can thrive in China.
There was one example that really struck me. I was at a mall with my partner and her friends (who live in Guangzhou). Those friends wanted to order something to drink. One of them got out their phone, ordered those drinks and had them delivered outside the mall. This was less effort and cost in their minds than actually wandering around the mall trying to find the drinks they wanted. Heaps of people just get their morning coffee delivered.
You might not think this example is a good demonstration of technological superiority. Every country has the phone and internet tech for goods delivery. But that they can leverage the technology to this degree is only be possible where the cost of delivery is so low - as it is in China.
So yeah - raw innovation is one dimension, but opportunity for implementation is another very important one as well.
I think the west is in for a rude shock when it finally realises how fast China is developing technologically.
I was there a few months ago in Guangzhou, it was stunning to see how many EVs were on the road. You can tell too - because they have a distinctly coloured license plate.
The scale that China can achieve is just mind boggling. We went into a giant mall - 7 levels. And it was all just jewellry. A whole mall! Blew my mind. Apply that sort of scale to technological development. They can do things other countries just can't because of that scale. Here's another example of a data center they just built:
I get the sense that some people are just starting to really cotton on about what China is really becoming - for example that recent review from Marques Brownlee of the Xiaomi EV.
But still - most of the narrative in the west seems to be doomerism about their demographics and real-estate over investment. We will see.
It's going to be interesting to see if China can offset its oncoming demographic challenges with their technological progress.
I bought the book - looks good! Would be keen to know which magazines they were originally published in. I feel you should include those references in the book (forgive me if I've missed them.)