Why would anyone want to live on Soylent? - <AUTHOR> http://www.raptitude.com/2014/05/why-soylent/ <comment><USER2> My uncle, who admittedly is pretty weird, used to only eat Costco pasta and peanut butter for 95% of his meals. The other 5% of the time he had lavish dinners with friends and family, and felt free to spend quite a bit. His logic was "I would rather have one amazing meal every now and again instead of a bunch of mediocre meals spread out." This may or may not be insane to you in terms of philosophy, but the biggest flaw is that he only ate two kinds of food for weeks on end. I imagine Soylent would be perfect for people like this: on a limited budget they can enjoy the occasional lavish meal without sacrificing nutrition for all their other meals.

From the people I know who like the product, it seems to me that Soylent caters to people whose eating patters are already strange. I find it appealing because I tend to obsess over making sure I'm getting all the right nutrients and food groups (I never am). I like the idea of drinking Soylent every morning as an insurance policy, I know I'm at least getting all the nutrients I need once a day.

<comment><USER3> Almost everyones' eating habits are strange. Unless you pay close attention to what you eat (which a subculture does, but that's the vast minority) then you're eating randomly. Soylent beats that for nutrition.

</comment></comment><comment><USER4> I'm someone who loves food. I enjoy cooking wonderful meals. Almost every day I spend twenty to thirty minutes making lunch. It's not uncommon for me to spend an hour or two making dinner.

Generally, I'm pretty confident that my diet is "healthy."

But, when thinking about Soylent, people seem to be comparing it to perfection.

Why not compare it to some other things.

For example, would it be healthier to have a burger, fries, and a milkshake from McDonalds, or to drink Soylent?

Isn't the answer obvious?

Even as someone that regularly eats healthy meals, I still occasionally find it hard to have a healthy meal.

Whether or not Soylent should be a complete replacement for food, it's probably a great replacement for so much of the garbage junk food that many people eat very, very, regularly.

Maybe someday Soylent will put fast food out of business. The benefits would be obvious.

<comment><USER5> You make reasonable points. Why do people compare Soylent to perfection?

Here's what they said when fund-raising:

> "You can finally join the easy, healthy, and affordable future of > nutrition."

> "What if you never had to worry about food again?"

> "For anyone that struggles with allergies, heartburn, acid reflux or > digestion, has trouble controlling weight or cholesterol, or simply doesn't > have the means to eat well, soylent is for you."

> "Soylent frees you from the time and money spent shopping, cooking and > cleaning, puts you in excellent health,"

>"By taking years to spoil"

>"there is much evidence that it is considerably healthier than a typical diet."

Soylent invites comparisons to existing replacement meal products (there are many) and makes false claims.

</comment></comment><comment><USER6> From the article:

        Rhinehart is well aware of the fact that Soylent
        isn't the first beverage designed to replace meals.
        He considered using Ensure for his initial no-eating
        experiment, but found it much too expensive, too sugary,
        too unpalatable, and sub-optimal in its ingredient
        make-up.

        The differentiating factor seems to be in the intended
        purpose. Meal-replacement shakes have never been
        presented as a food — something that you could (or
        might want to) live on for an extended period.

<comment><USER7> I hope that the companies making the existing Soylent-like products (though I have yet to find one that is unflavored and isn't targeted to dieting people or to bodybuilders...) take the hype around Soylent as a cue to market their stuff this way. I trust their nutritionists more than I trust the Soylent guys' knowledge, which (as I think I read somewhere) comes from just reading some nutrition textbooks.

<comment><USER8> Currently they have employed an on-staff nutritionist. That part is unfortunately not very well known...

</comment></comment></comment><comment><USER9> The poor hacker's desk delivered lunch. There's so much overhead which goes into putting meals together. Just having to make ONE more decision is a day can totally derail me. That decision could be "what's for breakfast?"

Personally, I would rather drink from a bag all day and then throw a fiesta for dinner to make up for bag time.

</comment><comment><USER10> This was touched on in the article but I still feel it's necessary to point out that nutrition is one of the least understood fields in science.

The primary reason is that there are almost zero proper clinical trials and interventional studies. We have thousands of cohort studies which prove almost nothing.

For example, for 60 years saturated fat has been considered the enemy of cardiovascular health (because of some poorly conducted cohort studies in the 60's and 70's). Just this March, BMJ published a major meta study that showing that there are no proven causal links between saturated fat and heart disease. In fact it is now being suggested that avoiding saturated fat has been detrimental because Americans have replaced fat intake with high glycemic index foods causing obesity and T2D.

Personally I have no doubt that Soylent will fail to provide some required nutrient or fail to induce a certain hormonal or chemical response which is obtained via natural food intake. We simply don't understand nutrition well enough to check all the boxes. That said, if Soylent wanted to follow the scientific method and conduct a proper interventional clinical trial with a control group, adequate study population and duration I would be happy to consider the results.

<comment><USER3> So by that logic Soylent is exactly as acceptable as any other food eaten regularly. Except Soylent at least tries to cover all the bases, constituting a variety of known food components. While a constant diet of cheeseburgers and waffle fries has not.

I've heard folks trot out the "what about the unknown food components?" That's a spurious argument - eating random processed food has no guarantee of including magic mythical food ingredients. And I'm skeptical of imaginary ingredients that are essential to health - how would that work? Man in the wild would die unexpectedly unless consuming some vitamin present only in Zimbabwean ground-nuts? Evolution must have screwed up royally for that to be true.

<comment><USER10> Soylent could be considered exactly as acceptable as any specific food but most other diets offer a very wide diversity of foods. The current thinking in nutrition science seems to be that diversity in diet gives us a better chance of eating how we should be eating. Because we don't actually know how we should be eating we rely on that diversity. It's naive to think that the definition of "nutritionally complete" (which Soylent adheres to) isn't going to change over the coming decades. A traditional diet will still have a chance of being "nutritionally complete" under future requirements whereas Soylent's exact formula almost ensures that it won't.

I think what's even more important are some of more complex functions of digestion and nutrition response. For example, what is the glycemic response of Soylent? In December Annals of Internal Medicine published a study (1) showing that a daily multivitamin has no benefit to the longevity and health of the average American but we do know that dietary interventions which increase dietary intake of certain vitamins via actual foods are beneficial to health. Scientists are still figuring out why but it is apparent that you can't just take a pill or formula containing certain nutrients and gain the same benefits of getting these nutrients through food.

(1) [http://annals.org/article.aspx?articleid=1789253](http://annals.org/article.aspx?articleid=1789253)

<comment><USER3> I'm doubtful the majority of human throughout history have had a diverse diet. We're not adapted to require that; in fact we're adapted to conform to whatever diet we regularly consume. Lots of folks report stomach problems when eating food different from what they normally eat!

</comment></comment></comment></comment><comment><USER11> I've been enjoying my first week of Soylent. I eat "regular" dinner, but the rest of the day I drink a cup of soylent every couple hours. The best part about Soylent is it's hackable. I'm looking to gain weight, so I use whole milk instead of water, and add 4 eggs and 1/4 cup heavy whipping cream which also dramatically improves the taste (for me at least).

It's almost like drinking melted ice cream, to be honest.

<comment><USER12> What's your poop like?

<comment><USER11> Fairly normal, maybe a bit paler.

<comment><USER12> Thanks for the candid reply. Some juvenile part of me was hoping you'd say it was now a colorless, odorless gel.

What prompted the question is the recent spate of articles on gut flora. That was the first thing I thought of when I heard of Soylent--what does it do to your microbiome? If anyone can speak or speculate knowledgeably on the topic, I'm curious.

</comment></comment></comment></comment><comment><USER13> Why "live on it"?

I don't live on exclusively on anything else. It's a cool idea and I hope it replaces "some" meals because occasionally I just don't have the time and it has to be better (and more convenient) than fast food. Why do we have to take good things to extremes and set up unnecessary "all or nothings"?

<comment><USER14> This confuses me too! The first time I ever heard about Solyent, it was this guy who decided to live on it for 30 days. I guess it generates better press than: "I occasionally eat Solyent in moderation, and it's pretty good".

</comment></comment><comment><USER15> Would be perfect for me. Never heard about it. I have a nasty food intolerance (rare from of gluten intolerance) that I was not aware off and made my life miserable. Unconscionably I realized that eating is not good for me when I worked as a scientist and had a heavy workload. Hence I lived on coffee, skipping breakfast, skipping lunch and ate my first meal around 5 or 6pm. One day my feeling for hunger was gone. First you form habits, then they form you I guess.

Other people eat because they are hungry. I eat because I know I have to sustain my body. It is often hard for me or even annoying to eat food and I have difficulties getting my calories every day. Yes, I would buy this drink.

</comment><comment><USER16> Using the oil packets and purchasing the most cost effective plan (28 bags for 255/month), Soylent gives you 220 calories per dollar. For a relatively sedentary averaged sized adult male (2100 calories/day), it will cost you about $285/month.

Ensure powder from Amazon[0] gets you to about 205 calories per dollar, which comes to $305/month for the same adult male. I don't buy the 'it's a lot cheaper than Ensure' line.

Another competitor, "Optimum Nutrition Serious Mass" is on Amazon in 12 pound bags for $49. It works out to 408 calories per dollar. Only $154/month for the same example male.

Admittedly Ensure and Serious Mass have different marketing than Soylent (Ensure for old people and Serious Mass for bodybuilders), but if you compare their ingredients you'll find they aren't very different.

[0] [http://www.amazon.com/Ensure-Nutrition-Powder-Vanilla- Flavor...](http://www.amazon.com/Ensure-Nutrition-Powder-Vanilla- Flavor/dp/B0007XXPLQ) [1] [http://www.amazon.com/Optimum-Nutrition-Serious- Chocolate-Po...](http://www.amazon.com/Optimum-Nutrition-Serious-Chocolate- Pound/dp/B000GIPJ0M)

</comment><comment><USER17> I think it could find a big market in people who care A LOT about eating specific nutrient proportions.

I'm working on the website Eat This Much ([http://www.eatthismuch.com](http://www.eatthismuch.com)) and a huge portion of our audience are people that want to eat EXACTLY 40% of their calories from carbs, 30% from fat, and 30% from protein (that's part of the zone diet, as an example). Our meal plan generator allows you to request those proportions, but sometimes it can't meet the exact targets due to any number of other constraints, and it's a huge source of complaints from our users. It's a pretty complicated problem to solve while trying to give people a varied and interesting diet with real food, but Soylent makes it very simple. I use my own site as much as possible, and I'm excited to have it give me half of my calories from Soylent (probably my breakfast and lunch).

</comment><comment><USER18> It's possible that living on Soylent is healthier than the way the majority of people eat, maybe a large majority.

</comment><comment><USER19> I'm not sure people will want to live on Soylent, at least the first batch seems to be targeted at people who are intrigued by the idea and want to experiment with it. If that experiment pans out, then maybe there will be a question about why people want to live on it.

</comment><comment><USER20> The explicitly stated purpose of Soylent is NOT to live on. NOT to "End Food". It is to be a better _occasional_ meal replacement. It's a nice improvement on many boring products that preceded it (Ensure, etc). But, that doesn't make for good linkbait headlines nor revenue-generating eyeballs on sidewall ads. This is yet another in a long series of manufactured-controversy articles propping up Soylent as either the Savior or the Devil. YOU DECIDE!

Not that I mind. I'm a backer of Soylent. When my month's supply arrives, I'm looking forward to living on it 100% for 30 days for a few reasons:

1) I need to lose a bit of weight. I know that for me, the best way to do that is to significantly change my "generally good but occasionally indulgent" diet. I know from experience that I can't willpower that into happening. But, I think that if I commit to a defined, strict diet, I stand a chance. Soylent should be particularly good for that because supposedly it won't leave me with carb/protein/fat cravings like every other diet I've tried.

2) I like the idea of going on a cleanse. What better cleanse than supposedly exactly what your body needs and nothing else?

3) I'm interested in the chemical science vs. mystical vitalism theory of nutrition debate. I.e. do we need certain chemicals or do we need " _something_ to do with _Real Food_ " to thrive? Supposedly, people feel really fine living on Soylent. I want to see for myself first-hand. I plan to get my "blood work" numbers measured before and after.

<comment><USER21> > I need to lose a bit of weight. I know that for me, the best way to do that > is to significantly change my "generally good but occasionally indulgent" > diet. I know from experience that I can't willpower that into happening.

I had the same problem. The way I increased my willpower was by:

       1) Weighing myself every day (always at the same time if I could)
       2) Writing it down.
       3) Graphing it in Excel

I found that seeing how my behaviour over the previous days had affected my weight gave me the willpower to eat smaller portions and forgo snacks. And having a _short feedback loop_ allowed me to correct if I started slipping. I still ate plenty, and had snacks/biscuits etc. between meals, (I didn't feel like I was starving myself) but I found that a small change in daily intake was enough to gradually make the weight come off.

<comment><USER22> Calculate how much calories you eat. You can find online the max amount of calories to lose weight.

<comment><USER21> Too much work, and I've already lost as much weight as I need to [1]. Weighing yourself every day and recording the result is very easy. All you need is a pad and pen by your scales. And if you want to graph it, once you have a spreadsheet, then updating it (even if only once a week) is very quick, and seeing the graph head downwards, is _very_ motivating.

I found it was the smallest habit I had to form to produce a result.

[1] I've gone from almost 20st 5-6 years ago to just under 11st.

<comment><USER23> I wouldn't want to do it on an ongoing basis, but the act of calculating out a few meals can be helpful to calibrate one's sense of how much they should be eating.

It can be easy to miss how calorie rich certain foods are.

<comment><USER21> > It can be easy to miss how calorie rich certain foods are.

That's exactly why weighing myself every day worked for me; I wasn't able to kid myself about how much I was eating. I also found that the odd big meal didn't matter, as long as I didn't make it a habit (which I didn't do thanks to having a tight feedback loop).

</comment></comment></comment></comment></comment></comment><comment><USER24> > The big-picture implications are also interesting. Rob Rhinehart definitely > has grand ambitions for this product and hopes it will play a role in > alleviating hunger.

Well, this is the part that excites me a lot. Industrial scale production and distribution of a nutritionally sufficient meal could do wonders in the developing world. As of now, even though there are food subsidies for the poor, there are additional expenses (gas, stoves) and wastage involved. And the saved time could be put to work.

A different incarnation of solyent could change the world.

Last time I said this [[https://news.ycombinator.com/item?id=7765697](https://news.ycombinator.com/item?id=7765697)], I was surprised I got downvoted into oblivion. I was genuinely curious why this isn't a good idea to take up at the governmental level.

<comment><USER5> Because there is already enough food for the world, that food is just poorly distributed.

But concentrating on just the specialist end of disaster nutrition: World Food Programme et al already have products that are vastly cheaper than Soylent.

20% of the world population live on less than $1.25 per day. About one billion people lack access to clean drinking water (the primary ingredient in Soylent).

Here's what the world food programme does: [https://www.wfp.org/nutrition/how- wfp-fights-malnutrition](https://www.wfp.org/nutrition/how-wfp-fights- malnutrition)

Here's a list of special nutritional products: [https://www.wfp.org/nutrition/special-nutritional- products](https://www.wfp.org/nutrition/special-nutritional-products)

Here is the factsheet about existing WFP products (note price and shelf life) : [http://documents.wfp.org/stellent/groups/public/documents/co...](http://documents.wfp.org/stellent/groups/public/documents/communications/wfp255508.pdf)

Soylent is far far too expensive for this role. It requires clean water. Rob making the claim that Soylent could help world hunger is yet another sensationalist sleazy claim made in ignorance of existing market.

</comment></comment><comment><USER25> I'm seriously considering it, at least as an experiment. I have type 1 diabetes, so I'm constantly trying to figure out how much insulin to take -- and I don't always get it right. This is _mostly_ a matter of judging the food I'm consuming, but not completely; there's also endocrine issues which affect blood glucose levels (usually pushing them up), and exercise usually pulls blood glucose levels down.

I think having a "standard diet" which takes food out of the picture would make it much easier to figure out how all the other pieces fit together.

<comment><USER26> You'll know how to manage your condition better than others but I'll point out that there is talk about a rather high GI for soylent thanks to the maltodextrin. Which could possibly mean it's not suited for you (or rather you might have to have a lot of smaller meals). Alternatively you could lookup DIY soylent and roll your own more appropriate recipe.

<comment><USER25> _rather high GI for soylent thanks to the maltodextrin_

That's certainly a concern, although I think the GI has dropped since the initial version thanks to the introduction of oat flour.

But for the purpose of figuring out how all the variables interact, it doesn't really matter if Soylent is good T1D food or bad T1D food... as long as it's _consistent_. I certainly wouldn't switch to Soylent long-term without seeing how it affects my A1Cs, but as a short-term experiment it might be worth having worse numbers in order to learn how to get better numbers.

</comment></comment></comment><comment><USER27> People keep going on and on about the nutritional value of the drink overall, but I'm somewhat curious to the effects it might have on the digestive tract.

For example, if you ate soylent for a full year, and then went straight back to regular food, would your body have trouble digesting solid food now that it hasn't had to do so for a long period of time? What if we extend this time period to 5 years, or 10? I think we can maybe pull some insight from astronauts in this regard, as we should have some information about the change from tube-food to solid food from extended space missions.

I can see soylent being a fantastic replacement in some respects, particularly with regards to coeliac's disease or with dairy allergies, but I'm still partially skeptical about the kinds of change that soylent will introduce in the future. One of the great parts about food nowadays is that you can basically grow and manufacture it anywhere, with the obvious caveat that not all food is available everywhere at once. On the other hand, with soylent, our food is almost "centralized" in a sense, since it is likely more difficult to create soylent than it is to throw seeds in the ground, or hunt and scavenge. This is sort of the reason why I'm curious to how the human body will react to such an abrupt change in diet. If humans just eat liquid food for an extended period of time, or their whole life, will they eventually lose / have difficulties with eating solid, more traditional food? Should a crisis arise (something akin to great floods or an earthquake), will it be possible to produce / ship enough soylent fast enough to fulfill the dietary needs of the population in need of aid?

Of course, these sorts of questions assume that soylent will become a dietary replacement, rather than an occasional meal replacement, but I get the feeling, at least from this article, that replacing the diet is the plan of Rhinehart et al. I won't personally test soylent out, I love fancy food and flavours too much to bother, but in some sense I will follow the product and see what happens with it. I don't think something on this scale has ever been attempted before with regards to dietary / meal replacements, so it should be interesting (not necessarily good or bad, just interesting) to see what kinds of disasters / utopias unfold thanks to a full dietary replacement.

</comment><comment><USER28> Maybe "soylent profitable" is the new "ramen profitable" or whatever.

</comment><comment><USER29> Can folks in the Bay Area pick up Soylent sooner than the 10-12 weeks it takes to ship to new customers? I'd totally be willing to drive to pick up a shipment--I want to try this life hack out NOW (or as close to now as possible).

<comment><USER25> Aside from "know someone who knows someone" hacks, I don't think so -- the 12 week delay is due to production constraints, not shipping constraints.

</comment></comment><comment><USER5> So many people are saying "i don't want to think" \- Indians need to expand "tiffin" to the US. Make it nutritious and you'd make a freaking fortune.

</comment><comment><USER30> Soylent is a huge first step. Henceforth, we'll know "what we don't know" about specific humans, and what is a general baseline throughout. That'll help us (humanity) make directed efforts to automate soylent mixture tweaking. I really can't wait for a device that scans me before each meal and decides what I need. Nutritionists would be in high demand, because who's going to trust a machine? At least for N years until entire generations have been through this system.

</comment><comment><USER31> I assume if you subsist on a diet of liquids alone that your teeth get upset due to complete underuse.

Anyone know if that's true?

<comment><USER2> Not a doctor, but I'm wondering what you mean by "upset"? Teeth are calcified body tissue, if I'm remembering HS biology correctly, and I don't know how having them not mashing down on things could damage them. Curious to hear other thoughts on this.

<comment><USER32> _and I don 't know how having them not mashing down on things could damage them_

Stephan Guyenet had a series of rather interesting blog posts on malocclusion. One of the factors he mentioned in conclusion was the toughness of food.

[http://wholehealthsource.blogspot.dk/2009/12/malocclusion- di...](http://wholehealthsource.blogspot.dk/2009/12/malocclusion-disease-of- civilization.html)

 _There are three main factors that I believe contribute to malocclusion in modern societies:

1\. Maternal nutrition during the first trimester of pregnancy. Vitamin K2, found in organs, pastured dairy and eggs, is particularly important. We may also make small amounts from the K1 found in green vegetables.

2\. Sucking habits from birth to age four. Breast feeding protects against malocclusion. Bottle feeding, pacifiers and finger sucking probably increase the risk of malocclusion. Cup feeding and orthodontic pacifiers are probably acceptable alternatives.

3\. Food toughness. The jaws probably require stress from tough food to develop correctly. This can contribute to the widening of the dental arch until roughly age 17. Beef jerky, raw vegetables, raw fruit, tough cuts of meat and nuts are all good ways to exercise the jaws._

However, this covers development up to age 17. What would happen to the teeth of a grown up man if he stops using them, I'd also be interested to know (from sheer curiosity)

</comment></comment></comment><comment><USER33> Soylent bars sound like a cool idea. No dishes to do, no groceries to shop, no time spent in the kitchen.

Pure gain.

</comment><comment><USER34> It seems like a great solution to the "forgetting to eat" issue while hackathoning.

</comment><comment><USER35> Another "stop liking what I don't like" view. You could make similar arguments against fast food and other products of convenience.

<comment><USER14> The author is actually coming out mostly in favour of Soylent. The title asks a question and the article tries to answer it.

</comment></comment><comment><USER36> Just because the ad says you'll want to live on Soylent, doesn't mean you would.

There's a certain kind of people who like to buy into simple formulas for health, success and so on. There are more of them than it's comfortable to admit.

The ad is worded to appeal to them, because after all Soylent is a business, and which business would ignore the large segment of the market that'll be buying your product regularly, _every single day_?

For those who are more balanced thinkers, Soylent remains an interesting option when you need to have a meal on the go. Better than fast food.

A side reminded, just like with vitamin pills, you should be skeptical of some of the claims made about Soylent's ingredients. Say, just because a product has calcium in _some form_ doesn't mean your body can assimilate it in that form.

</comment><comment><USER37> All this really is, is ground up rice, a vitamin pill, and some oil. No Thanks.

</comment><comment><USER38> 1\. There are a lot of (nonessential) nutrients that you get from plants that you won't get from this drink.

2\. Our idea of "everything the body needs" can change.

3\. We don't know the long term effects of relying solely on it.

The author spends a lot of time on stupid counterarguments. Seriously, do your homework.

<comment><USER39> 1\. Soylent doesn't seem to be entirely based on fine chemicals. When you go through their ingredients list, "fish oil", "oat flour" and "rice protein" likely contain a lot of the "(nonessential) nutrients" you fear missing out on.

I still wouldn't want to be the guinea pig to exclusively live off of Soylent.

2+3. Having said that, there is plenty of research on "Total Parenteral Nutrition" and "Enteral Nutrition" for those that cannot consume regular foods for medical reasons. It isn't exactly a solved problem however, there are still issues.

<comment><USER38> [http://www.webmd.com/diet/phytonutrients- faq](http://www.webmd.com/diet/phytonutrients-faq)

"More than 25,000 phytonutrients are found in plant foods. WebMD takes a look at these six important phytonutrients -- and their potential health effects: Carotenoids, Ellagic acid, Flavonoids, Resveratrolm Glucosinolates, Phytoestrogens"

Find them in Soylent? It's cute that you put nonessential nutrients in quotes though. It's like this foreign term that only I use.</comment></comment></comment>


Startup developing killer swarm drones for Indian Air Force - <AUTHOR> https://medium.com/@asiaainews/startup-developing-killer-swarm-drones-for-indian-air-force-f1ec8bdfae07 <comment><USER2> Daniel Suarez's 2012 book Kill Decision was only 7 years ahead of its time.</comment>


Meet Uber's software engineer apprentices - <AUTHOR> https://eng.uber.com/engineer-apprentices/ <comment><USER2> A great initiative.

It's funny though, how hard they are trying to shed their image as a misogynistic organization. Probably in the right direction hopefully.

<comment><USER3> It's nice, but I'm not sure it's a good idea. I've worked in companies that have had toxic cultures before and bringing young and inexperienced people into that situation was a really bad idea. This is a good idea for a company that doesn't have Uber's problems, but the worry is that you're taking people's first experience in computer science and making it a part of a culture clash. You're likely to re-entrench the existing culture and push these people out of software engineering for good.

</comment></comment><comment><USER4> It's fascinating to me that two years ago, these folks would have been happily hired as "eng 1". Entire teams were composed of folks that had just completed boot camps. I'd love to hear from one of those current/former junior engineers about what they think of this new program and whether it feels like a slight.</comment>


Pentagon Ordered to Tell Congress If It Weaponized Ticks and Released Them - <AUTHOR> https://gizmodo.com/pentagon-ordered-to-tell-congress-if-it-weaponized-tick-1836391549 <comment><USER2> Tick researchers have refuted this myth that the military created Lyme disease or were responsible for its spread here: [https://elemental.medium.com/what- its-like-to-be-a-creepy-cr...](https://elemental.medium.com/what-its-like-to- be-a-creepy-crawler-field-researcher-32c635338989)

> _What's the strangest sort of question you have to handle?_

> _Keesing: The conspiracy theory that the government made the Lyme bacterium, > that's gotta be up there. I mean, really?_

> _Ostfeld: There was a man at a public event where I was speaking a few years > ago who, in the question and answer session, pontificated about how the Lyme > disease bacterium was created by the CIA at Plum Island as a biowarfare > weapon — which if you know anything about this bacterium is absolutely > ludicrous. It would be the stupidest biowarfare weapon you could possibly > imagine. In any event, I said that this was actually not true, the DNA of > this bacterium has been amplified in museum specimens of mice that were > collected around the turn of the 20th century. So that predates Plum Island. > And I said, there was a recent discovery of a mummified human corpse in the > Swiss Alps in a National Geographic expedition that was 13,000 years old and > they amplified Borrelia burgdorferi DNA from this mummified frozen corpse. > And this guy responded by saying, "Yeah, so, you think it's far fetched that > the CIA would take this frozen human corpse and dump it out of a helicopter > in the Swiss Alps to cover up what they did?" So there's no correcting the > conspiracy theorists._

<comment><USER3> Good example of people being unwilling to consider the facts.

Minor nitpick: I'd like us to get away from using "conspiracy theorist" as an always-negative term. The truth is, many conspiracy theories have turned out true (people do, after all, conspire in secret to do evil). Additionally, there are conspiracy theorists who are reasonable and who have changed their opinions when corrected.

<comment><USER4> Yeah, every prosecutor who indicts someone on conspiracy charges is a conspiracy theorist, by the plain meaning of it.

What crosses the line into "truther" territory is generally a fantastically organized coverup as explanation for a lack of corroborating evidence.

<comment><USER5> It's possible to condition people to actively avoid something. Shock, labels and association with unrelated (often false) information are pretty effective. [http://s3.amazonaws.com/nasathermalimages/public/video/prete...](http://s3.amazonaws.com/nasathermalimages/public/video/pretext.mov)

</comment></comment></comment></comment><comment><USER6> Notably, the bill requests information about activity in the 1950-1975 timeframe – when there _were_ other risky domestic biowarfare research projects involving the undisclosed release of disease-causing agents. For example, the SF bay area was dosed with military-delivered bacteria in 'Operation Sea-Spray':

[https://en.wikipedia.org/wiki/Operation_Sea- Spray](https://en.wikipedia.org/wiki/Operation_Sea-Spray)

<comment><USER7> Scary stuff! "Open-air tests" is a nice way of putting it..

> Operation Sea-Spray was a 1950 U.S. Navy secret experiment in which Serratia > marcescens and Bacillus globigii bacteria were sprayed over the San > Francisco Bay Area in California.

> From September 20 to 27, 1950, the U.S. Navy released the pathogens off the > shore of San Francisco. Based on results from monitoring equipment at 43 > locations around the city, the Army determined that San Francisco had > received enough of a dose for nearly all of the city's 800,000 residents to > inhale millions of particles each day during the week of spraying.

> Between 1949 and 1969 open-air tests of biological agents were conducted 239 > times.

</comment></comment><comment><USER8> This seems like a weird conspiracy theory. I mean if you are looking for a bio weapon, one that doesn't have person to person spread, has a distinctive rash, doesn't result in immediate death (but can cause chronic conditions) and is treated by fairly common antibiotics seems like a strange choice.

<comment><USER9> The report does not look to determine if the defense department created Lyme disease. Rather it suggests that the Pentagon weaponized ticks.

What if, for example, they enhanced the Lyme bacteria to make it more contagious as part of an attempt to make it a carrier of a more deadly pathogen?

<comment><USER10> Or they were just looking at the ticks themselves as a delivery mechanism of 'whatever'.

</comment></comment></comment><comment><USER11> Could the return of that conspiracy theory be prompted by the recent spread of this invasive tick species:

[https://www.cdc.gov/ticks/longhorned- tick/index.html](https://www.cdc.gov/ticks/longhorned-tick/index.html)

[https://www.wired.com/story/the-terrifying-unknowns-of- the-a...](https://www.wired.com/story/the-terrifying-unknowns-of-the-asian- longhorned-tick/)

</comment><comment><USER12> This reeks of conspiracy theory, _however_ if one were to weaponize an insect, ticks would make sense. They're small and undetectable, evasive, bite you without you knowing it, and tough as nails.

<comment><USER7> While we're speculating, I imagine mosquitoes would be a good candidate as well - it's a natural vector of infections, common enough to be dismissed/ignored..

Oh, I see it also happens to be popular among conspiracy theory enthusiasts, and not without basis in _some_ fact.

[http://www.hoaxorfact.com/technology/tiny-robot-mosquito- dro...](http://www.hoaxorfact.com/technology/tiny-robot-mosquito-drones-being- researched-by-the-us-government.html)

</comment></comment><comment><USER13> Sigh. Historical accounts of Lyme disease go back at least to the 1700s, predating the founding of the lab in question by a couple of centuries.

This seems to be an offshoot of the anti-vax hysteria.

<comment><USER14> I certainly know nothing of the motives of this investigation, but a quoted passage in the main article states that the inquiry is about "whether the Department of Defense experimented with ticks and other insects regarding use as a biological weapon between the years of 1950 and 1975" rather than the highly implausible and easily discredited characterization that the government may have somehow invented the Lyme bacterium.

<comment><USER15> I wonder why they limited the inquiry to that date range.

</comment></comment></comment><comment><USER16> That "If" is doing a lot of work in that title.

</comment><comment><USER17> Serious question: does the Pentagon actually have to comply? What authority does Congress have to compel the Pentagon to do such?

<comment><AUTHOR> Withholding funding?</comment></comment>


Études for Elixir - <AUTHOR> http://chimera.labs.oreilly.com/books/1234000001642/index.html <comment><USER2> > Elixir is still in the process of development; as of this writing its stable > version number is 0.9.1.

Seems a bit out of date; afaik the latest stable is v1.5.3. Not sure how much has changed in-between though.

<comment><USER3> There has been a huge amount of change in the language since 0.9, so this is probably wildly out of date.

</comment></comment><comment><USER4> Cool, I have been playing with Elixir over the last few weeks! It seems really interesting but I know elixir might not be the right application for it but I was wondering if anyone would have a good strategy for making a CLI application handling (non blocking) user keyboard input, not using the IEX.

<comment><USER5> Have one process block on waiting for user keyboard input and send the keyboard input to your main process for actual reaction. That way the input is only blocking a completely separate process and not your main worker process.</comment></comment>


Ask HN: Besides Stackoverflow, what websites do you Use to find coding solutions - <AUTHOR> <comment><USER2> I always just use Google for all my programming related searches. Usually it finds a stackoverflow result but not always. You will need to clarify further if you're looking for another answer.

</comment><comment><USER3> Depends: for architectural stuff usually a mix of AWS, Microsoft, Martin Fowler, etc. For programming SO and the language/platform/SDK docs themselves. For infrastructure man pages, AWS/Microsoft for cloud, etc. All in all usually just going back to the root of the product.</comment>


MathJax: Beautiful Math in All Browsers - <AUTHOR> https://www.mathjax.org/ <comment><USER2> wow look good I like it

</comment><comment><USER3> I like MathJax and find it quite easy to use, standard. However, I have some issues with sizing the font - anybody solved these easily?</comment>


It's like a science fiction nightmare, say Christian bakers in gay marriage case - <AUTHOR> http://www.telegraph.co.uk/news/politics/12133736/Its-like-a-science-fiction-nightmare-say-Christian-bakers-in-gay-marriage-cake-case.html <comment><USER2> Translation: they want to have freedom to discriminate people. That's just not very nice.

<comment><USER3> The gay marriage side of this is a complete straw man. In a free society, a private group has every right to refuse service for _any_ reason. It has nothing to do with discrimination and it's definitely a case the government should be siding with the bakers.

I support gay marriage, but I also support this couple's decision. To support otherwise is supporting the removal of individual freedoms.

<comment><USER4> I support the couple but I am uneasy with it.

The stance that "a private group has every right to refuse service for any reason." is the same thing that they said in the South with Jim Crow laws and racial covenants. So how can I say that what the couple is doing is within their rights but at the same time say that Jim Crow laws were not right? I can't quite square that circle.

</comment></comment></comment><comment><USER5> Why don't they just find a different bakery?</comment>


Google starts a push for cross-platform app development with Flutter SDK - <AUTHOR> https://arstechnica.com/gadgets/2018/02/google-starts-a-push-for-cross-platform-app-development-with-flutter-sdk/?amp=1 <comment><USER2> Perhaps the most interesting piece from the article:

> When developers are writing Flutter apps for Android and iOS, they're also > technically writing Fuchsia apps, or at least code that will carry over to > Fuchsia very easily.</comment>


A bird's eye look at Pyongyang - <AUTHOR> https://www.nknews.org/gallery/come-fly-with-me-an-exclusive-360-birds-eye-look-at-pyongyang/?c=1508331523393 <comment><USER2> Pfff, commies are everywhere. I'm getting youtube spam from them now</comment>


Bacterial "immune system" used to engineer human DNA in human cells  - <AUTHOR> http://arstechnica.com/science/2013/01/bacterial-immune-system-used-to-engineer-human-dna-in-human-cells/ <comment><USER2> Ok, this is an interesting step. In-situ genetic manipulation without the use of a retro-virus.

If this pans out I expect it will have a disproportionate impact on both treatments for genetic disorders, and shady manipulation of genetic information for profit.</comment>


Crimea, the Tinderbox - <AUTHOR> http://www.nytimes.com/2014/03/03/opinion/crimea-the-tinderbox.html?hp&rref=opinion&_r=0 <comment><USER2> _Crimea is routinely described as "pro-Russian," given that an estimated 58 percent of the population of two million is ethnic Russian, with another 24 percent Ukrainian and 12 percent Crimean Tatar._

Because Stalin deported, murdered or otherwise replaced people who used to live there.[1] Genocide works.

[1] [https://en.wikipedia.org/wiki/Deportation_of_the_Crimean_Tat...](https://en.wikipedia.org/wiki/Deportation_of_the_Crimean_Tatars)

<comment><USER3> >Because

No. Russians had already become by far the largest ethnic group in Crimea before any deportation had taken place.

[https://en.wikipedia.org/wiki/Crimea#Demographics](https://en.wikipedia.org/wiki/Crimea#Demographics)

The deportation happened in 1944, the 1939 census shows Russians at 49,6%. Crimean Tatars were down to 19,4%.

That still doesn't excuse Russian intervention the last few days, though.

>Genocide works.

Genocide and deportations or ethnic cleansing are distinct things. Deporting hundreds of thousands of people is already bad enough, no need to use terms that don't apply to it.

</comment></comment><comment><USER4> I just watched two BBC programs about the Great War (WWI) [1] and the similarities between that episode in history and this one are chilling.

Don't get me wrong, I don't think we will have WWIII but the way the pieces are moving on the set (at least so far) is eerily familiar.

[1] [http://www.telegraph.co.uk/culture/tvandradio/tv-and- radio-r...](http://www.telegraph.co.uk/culture/tvandradio/tv-and-radio- reviews/10660290/The-Necessary-War-BBC-Two-review.html)

EDIT: in case people as for details, the most obvious is the treaty that Belgium and UK had entered into which became the casus belli for the UK once Germany invaded Belgium.

Today there's the Budapest Memorandum on Security Assurances [2] between Russia, the USA, and the UK and Ukraine of course.

[2] [http://en.wikipedia.org/wiki/Budapest_Memorandum_on_Security...](http://en.wikipedia.org/wiki/Budapest_Memorandum_on_Security_Assurances)

</comment><comment><USER5> I'm surprised this situation hasn't materialised earlier. With all the "forced migrations" happening during and after WWII both to and from the area of todays Ukraine, the country became a tinderbox a long long time ago. Most of that is the result of Churchill and Roosevelt giving up on that part of Europe during Yalta, for the benefit of Stalin.

</comment><comment><USER6> It's not only that Crimea is massively pro-Russian, it's the fact that it was a part of Russian Federation (a part of Soviet Union back then) before it was "gifted" to Ukraine by Khrushchev in 1954. It was more of a formality back then, but it doesn't change the fact that a lot of its population still consider Crimea a part of Russia.

<comment><USER4> After they deported the original ethnic group, the Crimean Tatars

[https://en.wikipedia.org/wiki/Deportation_of_the_Crimean_Tat...](https://en.wikipedia.org/wiki/Deportation_of_the_Crimean_Tatars)

</comment></comment><comment><AUTHOR> World War One began a hundred years ago, and today it feels like Europe hasn't progressed at all in those hundred years. Sadly, the Marx Brothers "Duck Soup" remains as relevant as ever.

[http://en.wikipedia.org/wiki/Duck_Soup_(1933_film)](http://en.wikipedia.org/wiki/Duck_Soup_\(1933_film\))

<comment><USER7> You think Europe hasn't progressed? Tell me how many shots Russian and Ukranian troops have fired at each other (at the time of me writing this comment).

Alternatively, how many shots have soldiers from the UK, France, Spain, Belgium, the Netherlands, Switzerland, Sweden, and Norway fired at each other in the past 60 years? Sure, there's more the Europe than the west, but we're doing pretty well when it comes to peace in that area.

Or, on a more practical note, how many millions of dollars of value has been added to the economies of European states due to agreements such as the EFTA, CEFTA, and the EU Customs Union? How many trade disputes have been resolved?

<comment><USER8> I agree. Freedom of movement and capital has been a giant leap, and something no other region in the world has achieved. In the mean time if you travel within the US don't be surprised if you are stopped at a random DHS checkpoint.

<comment><USER9> > Freedom of movement and capital has been a giant leap, and something no > other region in the world has achieved.

I agree that it is a giant leap, but disagree that no other _region of the world_ has achieved this. India and China have larger populations than the EU. And, the USA has built itself on having decent freedom of movement between the 50 states, and has far fewer barriers to that movement.

I take it that your comment refers to border patrol overreach and note that even Schengen (EU border agreement) allows border patrol up to 50km past the border.

<comment><USER8> Comparing 25+ countries vs 1 country makes the point.</comment></comment></comment></comment></comment>


Ask HN: What's the setup of your home office? - <AUTHOR> As per title. What is your home office setup in these times of forced "work from home"?<p>Any non obvious product you can suggest me to purchase and improve my home office? <comment><USER2> Good monitor mounts to maximise desk space. I use Ergotron LX HD which can handle heavier screens. Mine is the taller sit-stand version, with the additional handle that sits between the VESA mounts so that I don't pull on the actual screens.

Alternatively a good electric desk like a Jarvis or Uplift, or Ikea's Idåsen.

A good desk lamp that can project diffuse light onto your face for meetings. Combined with a good 1080p camera that sits high. E.g. Logitech C920S. Not a low-res up-your-nose laptop webcam.

Visit [https://www.reddit.com/r/battlestations/](https://www.reddit.com/r/battlestations/) [https://reddit.com/r/averagebattlestations/](https://reddit.com/r/averagebattlestations/) [https://www.reddit.com/r/Workspaces/](https://www.reddit.com/r/Workspaces/) [https://www.reddit.com/r/macsetups/](https://www.reddit.com/r/macsetups/) for more ideas or envy.

<comment><AUTHOR> Thanks!!!!

</comment></comment><comment><USER3> If you're doing video calls, you need good video lighting. Neewer makes some good products in this space.

Also, you're going to want a good microphone. Blue (now owned by Logitech) and Røde make good USB-connected microphones you might want to look at.

Do some research on what it takes to put on a good YouTube or Twitch stream, and those products are likely to also work well for doing regular video calls for business.

<comment><AUTHOR> Thanks!!!

</comment></comment><comment><USER3> See also the page linked from the HN article "How we've upped our audio game, and improved our video calls" at [https://news.ycombinator.com/item?id=24021471](https://news.ycombinator.com/item?id=24021471)

<comment><AUTHOR> Thanks!</comment></comment>


TDD Doesn't Work - <AUTHOR> http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-work.html <comment><USER2> Commenting on TDD stories here is historically a bad practice, but i'll add my input here.

I have never let my teams go full TDD. The reason is that in all my experience, TDD sacrifices a lot of velocity for the sake of automated tests. When i hear about the reduction in total bugs injected, it is a "duh" moment. The fastest way to make a team inject 30% fewer bugs is to have them write 30% less code. That isn't snarky, it's true.

Automated testing is one of the many tools available to software engineers. And it is a valuable one. Unfortunately, TDD is too much of a good thing. It relies so heavily on automated testing that it ventures far into the realm of diminishing returns.

Once, in an argument about TDD, i said it was akin to having someone build a shed. But upon checking in on them, you saw they were using a hammer to smash screws into boards. When you ask them what they are doing, they tell you it is Hammer Drive Construction. It is perhaps overly harsh, but it reinforces the point: tools have a place. Automated tests really shine on mission critical logic that does not get rewritten often. Use it where it makes sense. I wouldn't recommend using it ubiquitously.

Then again, i also recommend having fun coding. So i suppose the actual message here is: do what makes you successful, not what comments or studies say.

<comment><USER3> so what's your approach to ensuring the software you deploy is correct?

<comment><USER4> How does TDD prove its correctness? TDD suffers from the same limitations as the code - it generally only covers what you could think of.

It's a powerful tool, but I think any belief that sufficient test coverage (in most common cases) actively proves correctness is misguided. In the general case, even full test coverage proves only that you've tested for the conditions you expect - but does nothing to verify the correctness of behavior in conditions you didn't expect.[1]

To me the benefits of TDD are three-fold:

1\. It makes you think of what you're building in more detail before you build it.

2\. The methodology puts heavy emphasis on short test-code cycles.

3\. (Applies to any methodology that emphasizes coverage) You end up with an acceptable-to-great regression suite[1], and anecdotally it seems people do a better job of at least ensuring tests exist when required to by the methodology.

All of these things are equally possible without TDD. Short iterative cycles and additional forethought are perfectly possible without TDD, but they do require more discipline - it is harder to remember to stop after completing a small set of changes without a forcing mechanism.

[1] rust is a possible exception here, still wrapping my head around it.

[2] the value of this regression suite varies greatly from project to project. A hint that tests are of low value /potentially high cost can be seen when you're finding that minor internal changes either break a large number of tests or reduce coverage to noticeable degree. Particularly in absence of functional changes.

<comment><USER5> "How does TDD prove its correctness? TDD suffers from the same limitations as the code - it generally only covers what you could think of."

Another limitation is that because the tests are (usually?) written by humans, the tests could also be wrong.

So you think your application works, but it turns out that both your application code and your test code were wrong and you didn't catch a bug at all.

<comment><USER4> That's the biggest drawback of any kind of tests - there is always the risk of testing the wrong thing, or not testing enough of the possible right things. and you're absolutely right - because the test is also code, it also can and often will have bugs.

When you write tests for what you're about to code, or what you just finished coding, it's a challenge to write a test that is not flawed in the same way the code is - because you don't know the flaw is there in order to test for it.

By thinking things out first you can decrease the number of these (and enforcing that discipline is a major plus for TDD ) but for typical non- trivial application without a lot of control over its inputs, it's close to impossible to do.

Tests are often reactive as well - because the changes that require them are reactive (bugs, new reqs, arch changes, etc). That doesn't detract from the value of them, but it's a limitation that explains well why even 100% coverage never stops the bugs from showing up.

I think I'd be happier with TDD if fewer people presented it as if it solved all the problems. TDD is a powerful tool, but tools are only as omniscient as the people who use them.

</comment></comment></comment></comment></comment><comment><USER6> I'm definitely in the TDD-is-not-a-one-size-fits-all programming style camp and I'm glad to see a study that supports that conclusion. I was at Railsconf when DHH said his bit in 2014. My office and I followed the subsequent debates between him and Kent Beck (since my dev group was largely pro-TDD). Lots of anecdotal arguments. It's nice to see some more quantitative data on this!

In my programming experience I've found that I prefer to write tests AFTER I do development of a new feature. Oftentimes the implementation is in such flux that continually updating the test as I go along is tedious and kills the creative flow.

However, when it comes to fixing bugs in existing software, I find it more helpful to write a test that duplicates the bug FIRST, then code the solution.

If anything, the reason to recommend TDD is simply to enforce writing tests to begin with. It's so easy to get a feature working and gloss over testing it.

EDIT: What's up with liquidise's statement about commenting on TDD stories being bad practice? Do the TDD fanatics downvote to hell everything anti-TDD?

<comment><USER7> I read the article, but I haven't read the study. The article seems to show that the study is useless - it proves nothing, it's neither pro-TDD, nor anti- TDD. Taking a seemingly strong side of an argument supported by the study, but not commenting on the linked article itself, can explain the downvotes.

<comment><USER8> If the study showed anything, it was that TDD and TLD might be similarly useful at least on short timescales. I think GP was saying that they believed tests were useful, but that it was unnecessary to strictly stick to doing them the TDD way.

</comment></comment></comment><comment><USER9> Before I go in, I will state that in 99% of the times I'm a TDD hater. Actually I don't even like writing tests after the fact because I just like to build and move on.

I could never understand why the ruby on rails tutorial insisted on walking newbies through TDD and skipped all chapters where they start talking about tests when I started learning rails. I still think it's a bad idea to make newbies do all the weird TDD stuff when they don't even know how to build something.

I'm so opinionated about this that most people around me know this. And in most cases it works without needing to write any tests. And even if something fails, I can quickly patch it. As long as I wrote the app in a nicely modular way, I've not had much problem.

That said, right now I'm working on writing a JS library. And believe it or not, I AM doing TDD right now. I can't believe it myself.

I think in cases where the logic involves a lot of intricate details, it's impossible for me to write something without writing tests. I'm not talking about simple web apps. I'm talking about stuff like: template engine, parser, etc.

My current setup: I write a test and document it before I write a function. That way I don't get carried away while implementing and know exactly what I'm trying to build. Then I write another function that utilizes that function I just wrote, and so forth. This way I know when the next function doesn't work for some reason I know exactly where something went wrong. Instead going back and debugging every single function used along the way, I know it's the most recent one that's causing the problem.

So my conclusion: you probably don't need to write tests for all your stuff, but there are indeed cases where you will NOT be able to proceed without writing tests.

<comment><USER10> Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time.

<comment><USER9> Agreed, in my case what ends up happening is I start out with no tests but soon the project becomes huge and i have to start writing tests if I want to push stuff without fear.

The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be).

I think this is why this topic has been polarizing. Some people feel the need and some people do, depending on which role you're playing in your organization.

Nowadays interestingly, even the large companies are moving towards more testing because they can cut QA costs that way.

<comment><USER11> > most large companies have a QA team

Not sure what companies you are referring here. Google and Amazon does not have QA team for most of dev team.

I worked at Amazon and now work at Google.

<comment><USER9> There are many other large companies other than Amazon and Google.

Just because Google and Amazon don't have QA team doesn't mean the occupation doesn't exist.

<comment><USER11> I do not intend to say QA as an type of engineering position does not exist. What I was responding to is the parent's claim that "most large companies have a QA team so this fear is not super tangible to many developers"; that's not true in general.

<comment><USER9> It's kinda funny I'm even debating about this, I don't know where your confidence comes from.

You use the two most edge cases as an example (Amazon and Google). Most other "less techy" companies don't have the luxury to not run QA. Good for you that Google and Amazon doesn't have QA, but those are the exception, not the rule. Just go to glassdoor and search for QA and you'll see tons of QA job positions for large companies.

Since you mention Amazon, for example, WalMart has QA engineer positions.

<comment><USER11> I do not want to nit picking our discussion. But I seem failed to convey my ideas: 1\. QA exists prevalently 2\. In general software companies do not have dedicated QA team for every engineer team 3\. Lack of testing is a real concern for maintainability in big companies, because developers need to write tests themselves.

I do not disagree with your examples, but they are orthogonal to my point #2 #3. Let's go back to your original comment:

""" The thing is, most large companies have a QA team so this fear is not super tangible to many developers. And small startups are more focused on building stuff quickly (which they should be). """

The comment was responding to: """ Once you release a product that will be used by many customers and developed by many people throughout its lifecycle, which come and go as the time passes, you won't be able to maintain/extend it without a proper testing suite. It's not only about complexity, but also about maintainability. Some tests will also rot in time. """

My understanding is that, you meant to say that the fear of lack of testing harms maintainability is not so relevant to developers in big companies, because they have dedicated QA team (writ tests for them).

My comment says, in general, big companies do not have dedicated QA teams for dev teams, so there is no dedicated QA team write tests for dev team. My examples are 2 of the largest software companies in the world. Among them, Google redefined how people access information, Amazon reinvented how developers access computing resources.

I think my examples support my intention to prove that your statement and what it implied, in general, is not true.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Oh man, it is really funny that he ends it with telling people to read the study.

To clarify the linked study is attempting to replicate [https://dl.acm.org/citation.cfm?id=1070834](https://dl.acm.org/citation.cfm?id=1070834), THE seminal study in Test Driven Development. Well to be more precise it was replicating an existing replication of that study which failed to replicate the original results. They were trying to modify the design so as to account for issues in the experimental design that may have led to the replicated study being inconclusive.

This is significant because if you were not aware of the failed replication, and believed that TDD was supported scientifically as more productive because of that original study, then you SHOULD be reconsidering its place in your development process. If that isn't the case your opinion is unchanged by these particular results(even in the article inspiring this one the author admits that their opinion was already based on a much more thorough analysis, see: [http://neverworkintheory.org/2016/10/05/test-driven- developm...](http://neverworkintheory.org/2016/10/05/test-driven- development.html)).

Now what I want to know is why people insist on writing articles in this awful conversation format. It wastes a lot of words to make a simple argument poorly.

<comment><USER13> Probably because they have a sense of humour, and the conversational style makes it more entertaining to read...?

<comment><USER12> Is it entertaining or funny if you identify with the character who is talking down? I mean this particular example doesn't seem to contain any jokes from my reading.

</comment></comment></comment><comment><USER14> tl;dr = someone did a study that used a methodology that confirmed that working in small chunks and writing tests as you go is good, but that it's not very important if you write the tests before the small chunk of code or after the small chunk of code.

<comment><USER15> Aren't tests supposed to be a tool to help design API? in that perspective a test should be written first. The problem IMHO is the choice of methodology as there is several kind of tests. Some may be more time consuming when it comes to the set up.

<comment><USER7> Personally, I think unit tests shine best when you're designing an API. I can swing from hate to love and back about TDD in minutes, but when it comes to thinking about how your code will be used, unit tests (did we stop using that term?) are a tremendously useful tool I have.

I guess if all code written could be seen as an API, TDD would be great, but that's not the world I live in.

<comment><USER16> This is why I prefer free to implement open standards that are (hopefully) well designed and specific.

Inter-operablility and interchangeability of parts means that it's possible to validate an implementation to at least some degree.

The best example that I can think of off the top of my head is the OpenGL 4.4/4.5 work that is nearing conformance for the Mesa3D project ( [https://en.wikipedia.org/wiki/Mesa_(computer_graphics)](https://en.wikipedia.org/wiki/Mesa_\(computer_graphics\)) ); while the functional coverage for the main modern drivers is 'complete' the official conformance testing has already resulted in some bug fixes and additional areas to focus on improving.

That real life case study is yet another example of how an API and conformance tests built around that API result in better code and in a more consistent experience that isn't dependent upon a mono-culture implementation.

</comment></comment></comment></comment><comment><USER17> In all discussions about TDD, it is important to distinguish between having having an automated test suite for your code which is run frequently, and writing your code test _first_ \- which is what TDD is, by definition.

It is possible to advocate for the former, while thinking the latter is consultantware snake oil. (my position, fwiw)

<comment><USER18> Yeah, I agree. TDD is also, you cannot write a single line of code without writing a failing unit test though. Well, I'm not a fan of that either.

I mean, sometimes I like writing an acceptance test to begin with and work inwards.

People sometimes interchangeably use "TDD" for "testing". Also, just because you do TDD, doesn't mean your code can be great, I've seen people assert pointless things and the unit has gotten so small that people now define them as methods in classes. Which I also think can lead to some crazy maintenance suite of tests.

If you're interested, this was a fun discussion about TDD between two professionals: [https://www.youtube.com/watch?v=KtHQGs3zFAM](https://www.youtube.com/watch?v=KtHQGs3zFAM) Jim Coplien and Uncle Bob.

</comment></comment><comment><USER19> The author was going somewhere when he began writing about what a developer is thinking about, but, perhaps because he was focused on vindicating TDD, he did not arrive there.

A developer who is writing unit tests must have a good idea of the purpose of the target of the tests, so she is thinking about requirements. Furthermore, if she is writing unit tests for small components (which will often be the case on account of everything being done in short cycles) then a lot of that purpose is contingent on other aspects of the design and how it is all supposed to work together: in other words, she is thinking about design.

If you don't spend some time thinking ahead about big-picture requirements and design issues, you are in danger of going a long way down a dead end.

</comment><comment><USER10> I thought that TDD morphed into ending up with a regression/integration/conformation test suite instead of using tests as specifications written prior to writing products. And even 100,000s of tests won't help you in very advanced applications like cloud/cluster infrastructure as sometimes it's simply too difficult if not impossible to come up with tests (imagine observer effect when your cluster deadlock happens only in certain rare nanosecond windows and adding a testing framework will make you miss those windows and the problem never happens) and people with mental capacity capable of writing them (e.g. Google/FB-level) are better utilized in writing the product itself.

<comment><USER20> Why you think that debugging and fixing deadlock in cluster in production (of multibillion business) is easier and cheaper than writing of functional test case? Maybe you just prefer trips to angry customer versus boring office work. :-/ [http://www.reuters.com/article/us-nasdaq-halt-tapec- idUSBRE9...](http://www.reuters.com/article/us-nasdaq-halt-tapec- idUSBRE97L0V420130822)

<comment><USER10> The thing is that there are problems we simply can't solve in theory nor in practice, yet we use approximate solutions all the time - and that is the case of advanced distributed algorithms. In theory, we simply can't handle real- world asynchronous systems. And when we pretend we have partially synchronous systems and build abstractions around them, they aren't 100% working. Now add in some complex bugs (like getting a distributed deadlock in transacted system involving exactly 7 nodes but not less nor more) and you might start understanding why functional test case might not really be an option to avoid these issues (you can obviously write them but they won't really help you). I worked on such a system, we had 100,000s of tests yet they were clustered around known issues and not issues that happened when e.g. a node went down and up, data were out of sync and sockets between nodes were becoming full due to OS' performance limitations. And moreover, many of these issues start showing up only when you push throughput to the max, e.g. during trading spikes etc. and adding a test that checks invariants would lower the throughput and those issues simply won't show up anymore.

<comment><USER20> Each test case increases confidence in the system by small amount. Confidence never can approach 100% (because we need to predict future to achieve that), so no amount of testing can give you 100% confidence, only 80%, 95% (2x price), 98% (4x), 99,5% (8x), 99,95% (16x), 99,995% (32x), and so on. It's your message, right?

<comment><USER10> My message is more like your confidence after writing hundreds of thousands tests might be just 50%. From my own experience, every single bad case that can happen in a complex system will happen at some point at some customer, wrecking their system and costing them potentially millions, in serious trading bugs even leading to a bankruptcy. Your testing suite won't catch these initially but reactively when you add that test case to your regression suite after bad things happened. In complex systems, tests are just a heuristics for quality, not really something you can rely on (but it's way way better to have them than not). Often tests are clustered around low-hanging fruit or around parts of system used by developers or initial customers and any deviation in usage patterns can cause an outbreak of new, unexpected incorrect situations. Similarly, proving correctness using some formal verification tools might increase your confidence, but won't give you 100% either, as we simply can't model reality properly even within our own frameworks :(

<comment><USER20> In such cases, I use "torture" test cases: lengthy, random test cases, which are trying to abuse and overload system with no data, incorrect data, random data, huge data, high latencies, duplicated messages, missed messages or random aborts, random speaks, etc. They allows me to discover situations not covered by test cases. I also try to use underpowered hardware for such testing. Of course, I cannot imagine all possible torture scenarios, but I saw lot of bug and security reports, so I still know lot of scenarios, more than I willing to write tests for.

<comment><USER10> That's a good approach as well! In addition, nowadays with VMs/containers you can even simulate nodes going randomly up and down, which is a bit of a challenge if you do it in a real testing cluster.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> TDD presents a paradox that requires split-brain thinking: when writing a test, you pretend to forget what branch of code you are introducing, and when writing a branch, you pretend to forget you already knew the solution. It is annoying as hell.

You CAN indeed cover all your branches with tests afterwards. You can even give that a fancier name, like "Exploratory Testing". Of course it may be more boring or tedious, but is a perfectly valid way to ensure coverage when needed.

TDD was great for popularizing writing test first; However I much prefer the methodology called CABWT - Cover All Branches With Tests. Let the devs choose the way to do it, because not everyone likes these pretend games.

<comment><USER20> TDD requires you to write FUNCTIONAL test first, not unit tests you are talking about.

<comment><USER21> I was commenting on the methodology as I heard and watched it explained by the author (Robert C Martin), as well as the way it was presented in his videos.

TDD workflow is fine; it's not thinking about the pink elephant (the source code) idea that bugs me.

<comment><USER20> Robert Martin is author of Agile manifesto.

[https://www.quora.com/Why-does-Kent-Beck-refer-to-the- redisc...](https://www.quora.com/Why-does-Kent-Beck-refer-to-the-rediscovery- of-test-driven-development)

The original description of TDD was in an ancient book about programming. It said you take the input tape, manually type in the output tape you expect, then program until the actual output tape matches the expected output.

<comment><USER22> +1. TDD could be considered as a derivation of the Scientific Method (Hypothesis Testing).

[https://en.wikipedia.org/wiki/Scientific_method](https://en.wikipedia.org/wiki/Scientific_method)

[https://en.wikipedia.org/wiki/Hypothesis](https://en.wikipedia.org/wiki/Hypothesis)

Test first isolates out a null hypothesis (that the test already passed); but not that it passes/fails because of some other chance variation (e.g. hash randomization and unordered maps).

[https://en.wikipedia.org/wiki/Null_hypothesis](https://en.wikipedia.org/wiki/Null_hypothesis)

... [https://en.wikipedia.org/wiki/Test- driven_development](https://en.wikipedia.org/wiki/Test-driven_development)

<comment><USER20> +1 Right on the spot.

TDD requires you to draw your target first, then hit or miss it with the code, like in science: hypotheses -> confirmation/declining via experiments -> working theory.

But in practice, lot of coders are hitting a point instead, then they draw target around that point, like in fake science: we throw coin 100 times, distribution is 60/40, our hypothesis: random coin flip has 60 to 40 ratio, our hypothesis confirmed by experiment, huge savings, hooray!

</comment></comment></comment></comment></comment></comment><comment><USER23> Author is only partially right about TLD being as "doing TDD in your head", since it's (at least for me) in a much more abstract form of a general idea, a concept, of what I want to achieve. When using TDD you need to come up with the very specific results that you will test and you need then to implement those specific tests, to the last line of code. This means that if you make any changes to the logic afterwords, you need to throw away your pre-written tests and write new ones, the time spent on writing them was wasted. TLD is much more flexible and easier to update, no code is thrown away if you change something. Before I start I just need to decide what I'm trying to solve with my current block of code, and then I later write a test to check if I did it properly. Then I do the next block of logic, and the next test. Since code blocks are directly related to the steps in my logic, it's very natural to come up with the tests for them, just test if the things work as you planned it. If in the middle of that work I realize that I need to do something in a completely different way, there's no pre-written tests, so no time was wasted on coding tests that were never going to be used. And, at least to me, this kind of situations happen a lot, I often refactor and improve things as I work on them, so for me TLD is much more suitable approach.

</comment><comment><USER24> tl;dr the recent studies proved that that you're testing first or last doesn't matter, provided you're frequently flipping between writing a test and writing code.

The author thinks that TDD is preferable because it helps you maintain discipline.

I personally think it's worthwhile besides that because it means you design the API before implementing, meaning it is cheaper to fix API design mistakes. IIRC this aspect wasn't actually tested in the studies (API signatures were given up front).

<comment><USER25> And that's one of the things TDD gives you - as you write the test, you have to _use_ the API. If that's painful or even just awkward, it's telling you something...

<comment><USER26> Except that it is not real use.

Might be better than nothing, but if you are designing a reusable API, you'll be better using it on some real code.

<comment><USER24> >Might be better than nothing, but if you are designing a reusable API, you'll be better using it on some real code.

This is generally why I take the top down approach to coding:

1) Write ultra high level test

2) Write code that implements it.

3) In that code if I need something lower level, write the API that I want

4) Write a lower level test that mirrors what I just wrote in real code.

5) Implement the code that passes that test & use it at the higher level.

etc.

</comment></comment></comment></comment><comment><USER27> Let's say I have a new theory, called Understanding Driven Development. The system says:

It's a bug if someone needs to change code and they, at any moment, see code they don't understand. Stumbled into the wrong place? Bug filed for better notes on organization. The code you need to touch not understood? Understand what you see before you make a single change. If you change code and don't update docs, or documentation and code out of sync? It's a bug, and changing one to match the other _without detailed understanding_ is a bug too!

Now, that seems reasonable. And if a study comes out and says people can't make program changes faster, on average, when participants are given a bit of code identical, but with more (accurate and non-trivial) comments, that doesn't mean UDD doesn't work. It doesn't test it on real, full size applications. The code was the same, despite clarity of code is one of the goals of UDD -- one of the core claims is that UDD gets you better code to begin with. It focuses on a tiny test of something not necessarily core to the UDD mindset.

But it's evidence that at least one claim I've made is false. In fact, that study would be enough for me to throw that idea set into the garbage.

</comment><comment><USER28> I work at ThoughtWorks. TDD is central to everything that we do. That said, like anything else, TDD done to an extreme is probably a bad thing (too much time spent on tests rather than implementation) and it not being done at all is also usually bad (too much time fixing bugs that could have been caught by tests written beforehand).

Balance is key.

</comment><comment><USER29> I prefer to rather then write tests plan out the interactions between all components in large projects. This will show you how all the pieces interact and what cases to need to handle in each functional unit. After this, I sit down an write all the code.

After I know the organization of the source, I write out each functional unit of the code one at a time. As I go, I write each bit of test code for my source. After this I integrate every function unit.

If a change is needed, I go back to the drawing board and find a better overall organization. This happens often due to either performance constraints or the need to abstract a section further.

After this I'd consider embedding a unit test suite.

Works great for small to medium projects.

</comment><comment><USER30> Previous 300+ comment thread which referenced the actual paper, not a blog post about it:

[https://news.ycombinator.com/item?id=12740456](https://news.ycombinator.com/item?id=12740456)

</comment><comment><USER31> For those like me who enjoy HN but aren't s/w developers:

[https://en.wikipedia.org/wiki/Test- driven_development](https://en.wikipedia.org/wiki/Test-driven_development)

</comment><comment> awinter-py Careful -- in these studies the subjects are writing tests before writing code.

In practice there are 'test-heavy' devs who use factory data and the test suite to run skeleton code with crashpoints, and switch actively between test and imp files.

This has tests & implementation being written in parallel vs strict TDD which has us finishing tests before writing program logic.

Most test suites depend not just on functional requirements but also on implementation details, so it seems obvious that tests-before-logic development is inefficient.

<comment><USER20> TDD requires to write FUNCTIONAL test case first for every new feature. Functional test case should not depend on implementation. Integrational and unit tests are.

</comment></comment><comment><USER32> I must be one of the very few people who can write working and mostly bugless code and without writing any kind of test. Writing tests feels like the most wasteful and possibly harmful thing to me (like by people forcing dependency injection etc. where otherwise unneeded).

I don't really know what to think of the situation? Is this how it has always been? Do most software engineers really have no idea what they're doing?

<comment><USER33> > I must be one of the very few people who can write working and mostly > bugless code and without writing any kind of test.

Or you may be using a different definition of "mostly bugless" than the rest of us.

I do gamedev. The ability to patch post-release is _not_ a given, even today, for all platforms. Crashes, corruption, progress blockers, etc. are all VERY BAD in this environment.

I see bellow you're writing network code in C. I don't suppose you've done any fuzz testing? Run with address sanitizer? Static analysis? We live in a world of exploitable 1-byte buffer overflows. Maybe not such a big deal for a throwaway blog server, but perhaps a bit scarier if you might be facing HIPAA fines, or running industrial equipment.

A very important note here: Mostly bugless _as far as you 're aware_ and mostly bugless _in actuality_ are two _very_ different things. Without testing, I'm not sure how you can have any confidence that you're in the latter camp.

<comment><USER32> For my hobby projects I admittedly don't do much testing - simply because no one is paying me to. Only in rare cases do I intentionally write a test when something seems complex. And I do run address sanitizer etc. where that can reasonably be done (e.g. not on microcontroller code). Anyway my point is, my code has considerably less bugs than what you'd get from reasonably proficient programmers even if they DID write tests.

For example, I'm currently writing a TCP/IP stack for embedded systems [1]. While it's not quite complete yet (misses some essential code like fragmentation and congestion control), I'm very confident that it has (and will have when complete) much less bugs than related portions of lwIP; see for yourself all the bugs I've found in lwIP [2].

Again feel free to find bugs in my code. I very much appreciate people pointing out bugs, as it helps me make even fewer bugs :)

> We live in a world of exploitable 1-byte buffer overflows.

Indeed. But buffer overflows are so easy to avoid, just don't write over the end of the buffer. I doubt I've done a buffer overflow in years. The bugs that I do make, are much more complex.

[1] [https://github.com/ambrop72/aprinter/tree/ipstack/aprinter/i...](https://github.com/ambrop72/aprinter/tree/ipstack/aprinter/ipstack)

[2] [https://savannah.nongnu.org/bugs/index.php?go_report=Apply&g...](https://savannah.nongnu.org/bugs/index.php?go_report=Apply&group=lwip&func=browse&set=custom&msort=0&report_id=101&advsrch=0&status_id=0&resolution_id=0&submitted_by=101487&assigned_to=0&category_id=0&bug_group_id=0&severity=0&summary=&details=&sumORdet=0&history_search=0&history_field=0&history_event=modified&history_date_dayfd=11&history_date_monthfd=11&history_date_yearfd=2016&chunksz=50&spamscore=5&boxoptionwanted=1#options)

</comment></comment></comment><comment><USER34> You can also write "Methodology X doesn't work always". All methodologies work well for some situation and for others they don't. In my view TDD is great for a lot simple things and algorithms and you can structure your code in a way that most of the code is inherently testable. But when things are so complex that you don't even know the correct architecture upfront, TDD is a killer.

<comment><USER13> If things are that complex, sounds like you need to be doing some discovery work (spikes) first to break the problem down. Then you can use TDD again :-D. So, I guess you're right - if you don't know wtf you're supposed to be doing, TDD is a killer. But then, so is anything else.

</comment></comment><comment><USER35> That blog post could pretty much apply the same arguments to itself. And who knows if Bob's experience is simply correlation not causation. Perhaps Bob is just a smart, meticulous engineer, and it wouldn't matter how he went about his dev work, the quality may be good regardless.

</comment><comment><USER19> Test-first was promoted as being the secret sauce that made TDD so much better than anything else, so this is something of a qualified vindication, but I do think (from my own experience) that writing down what I am thinking does help me see flaws that I had overlooked.

</comment><comment><USER36> good article; would like to add that a study based on "21 graduate students" is hardly representative of the software developer population...

</comment><comment><USER37> (to nobody in particular)

Please the article before commenting.

It's not totally clear from reading some of the comments that people have actually read the article.

It's a good one, please do.</comment>


We need a search engine for individually produced content - <AUTHOR> https://devennavani.me/articles/2020-05/we-need-a-search-engine-for-individually-produced-content <comment><USER2> Spot on, Deven.

At the moment, I use an RSS service[0] and reader[1] fed with almost 20 years worth of gleaned feeds to accomplish much the same thing.

The collection grew to such an extent that I had to categorize the feeds, with the most interesting/generally low volume in a "daily" category (the idea for which I stole from Slow Feeds[2] (now known as Web Subscriber[3])).

But a dedicated search engine for handcrafted content would be awesome.

EDIT: I saw [https://wiby.me](https://wiby.me) mentioned in a recent HN comment. The About page[4] states in part, "The Wiby search engine is building a web of pages as it was in the earlier days of the internet."

[0] [https://newsblur.com](https://newsblur.com)

[1] [https://reederapp.com](https://reederapp.com)

[2] [https://onethingwell.org/post/80985561981/slow- feeds](https://onethingwell.org/post/80985561981/slow-feeds)

[3] [https://zoziapps.ch/slowfeeds/](https://zoziapps.ch/slowfeeds/)

[4] [https://wiby.me/about/](https://wiby.me/about/)</comment>