It's Hard for Doctors to Unlearn Things - <AUTHOR> https://www.nytimes.com/2018/09/10/upshot/its-hard-for-doctors-to-unlearn-things-thats-costly-for-all-of-us.html <comment><USER2> I am a physician in the US. I think the article has valid points (esp. inpatient glucose control) but it also oversimplifies and glosses over some of medicine's more arcane aspects.

To give a tangible example I'll start with the unnecessary ankle x-ray. There is a set of guidelines called the Ottowa Ankle Rules[1] which we use to justify ordering plain films for a suspected fracture, but there are plenty of reasons why a doctor would still get them if the criteria weren't met.

One reason is clinical judgment and experience. Guidelines are just guidelines. Ultimately the doctor is the one making the call, as well as suffering the blame for that call if things go sideways. If everything were as simple as following algorithms and checklists, medical training wouldn't take 7+ years of post-undergraduate work.

But probably the most important reason has to do with the "patient satisfaction" (customer service) aspect. Ideally medicine wouldn't be a business, but it is and there's not much we can do about that.

Patients who present to an urgent care center or ED generally carry an implicit "something is seriously wrong with me or I would have just made an appointment with my PCP" vibe. These patients often don't like it when you explain that based on your history and exam, they most likely have a sprain/strain injury and an xray is not appropriate since we want to avoid unnecessary costs/radiation exposure-- as opposed to being relieved that they only suffered a minor injury. Even when spoken in a compassionate, straightforward manner, this explanation can come across to the patient as "nothing is wrong with you / you are malingering / your concerns aren't valid / I don't care about your symptoms", etc.

Sometimes patients outright demand tests, or worse, they'll say nothing but then complain to your employers that you medically neglected them, or you are incompetent, or what have you. Now if they had the audacity to file a malpractice suit, you'd (ideally) have no problem justifying your actions in a courtroom or deposition. But say they complain to the MBA (or some other person with no medical training) who runs the clinic or care center employing you. Your argument will likely fall on deaf ears, and be countered with some diatribe about how you're causing them to lose money. In that case it's a lot easier to just order the unnecessary xray.

Basically, the squeaky wheel gets the grease. There are plenty of other examples like this, and they all come down to choosing your battles wisely. I think it's kind of hard to blame the over-worked and behind-schedule doctor who orders something like an xray or lab test rather than taking an extra 10-15 minutes discussing the pros and cons with the patient, after which the patient might still not be convinced.

Having said that, there is a problem with superfluous testing in EDs, especially ones that rely on "standing orders" where e.g. virtually any patient presenting with abdominal pain might get a CT scan before the physician even sees them (something I strongly disagree with and can't think of a legitimate excuse for).

[1] [http://www.theottawarules.ca/ankle_rules](http://www.theottawarules.ca/ankle_rules)

<comment><USER3> In the U.S. I actually have witnessed both, seemingly contradictory, aspects. That is cases as you mentioned in urgent care where there is an extensive work done to you for no reason, that ends up to be even unrelated in the end, just to cover all bases and follow protocol. Yet, cases where a personal doctor is reluctant to prescribe blood work or chase symptoms that are not life- threatening, even with prior family history due to costs.

For instance, there was a with E.U. doctor referral for ultrasound and blood work. The reply was if it bothers me to consider painkillers or wait for it to get worse and come back. (Why should I take painkillers if we are not certain of the cause to begin with?) On the other hand, walking a friend into urgent care for their leg leads to a full checkup.

With the above I want to complement your view, that there is some extreme behavioral gap in how doctors' react that is not related with the patient's ailment.

And there is a lack of a middle ground between urgent care and making a personal doctor appointment. I find it surprising that if I break my leg I need to go to urgent care. There is no contagious disease, and I am not going to die if left untreated, but it is an event that requires time sensitive treatment. Yet, there is no concept of walking into a doctor's office, or at least it is not that easy.

Example case 2. Eye pain etc. After failing to get an appointment with any doctor, K is instructed to go to urgent care. K called ahead and asked if they could handle their case, yet there was no actual ophthalmologist there. K got a full "checkup" and got a "it's probably an infection"; they were prescribed antibiotics. Next day K's eye pain worsens with new symptoms. K gets an appointment with an optometrist so as to be referred to an ophthalmologist. It is the protocol to have an optometrist check you first apparently. Another half a day later, an ophthalmologist actually checks K and comments "thank god you came in this fast." That was after my wife begging several times on the phone with several doctors, that we need an appointment today and not in 2 months. Yes, patient K is I. (I could not make any phone call or walk at this point, I was for all intents and purposes blind and in pain.)

Thus, the system in place from my experience assumes that the patient i) is stupid ii) if not dying does not need a checkup within the next 2 months, or else has to go to urgent care.

Thus is it really the patients' fault when they are used to walk into urgent care to get any sort of timely treatment? Why would a person with a broken leg take the invaluable resources from someone actually in need of urgent care? I argue the system somewhat enforces this over-treatment. You have to go through the urgent care for any timely treatment, it is rightfully instilled in you that perhaps there is something serious going on. You would not pay urgent care prices for a strain right? Thus, it must not be a strain.

My E.U. experience: As a patient,you walk in to a doctor you consider appropriate (You can also make an appointment ahead of time and ask if uncertain). One might wait for a few hours. If it is deemed urgent, the doctor will make sure to see you first, or send you to urgent care/emergency room or hospital. If the doctor is not of the appropriate specialty, they will refer one appropriately. Paying everything out of pocket, costs extremely less compared to my copay for urgent care -- this is a simple doctor appointment, no urgent care.

</comment></comment><comment><USER4> I wonder how much of it is from the training methods - forgetting things is malpractice and thus things get hard emphasized to practically muscle memory "make sure to x-ray the ankle to confirm if it is a break or sprain" even if it would become very apparent without otherwise via deformation or not getting better and the treatment is immobilize both and ice helps with pain anyway.

I think the military has a similar problem with transition to civilian life in terms of "overdrilling". Medicine being a conservative field given the stakes furthers it.

</comment><comment><USER5> Yes. Just ask Ignaz Semmelweis.

<comment><USER6> [https://en.wikipedia.org/wiki/Semmelweis_reflex](https://en.wikipedia.org/wiki/Semmelweis_reflex)

<comment><USER7> Thank you. I was not familiar with this term. But to be clear:

Semmelweis was a physician in charge of a couple of clinics who documented differences in mortality rates and used this to suggest hand-washing for physicians before germ theory was a thing. He was thrown in an insane asylum and was badly beaten by the guards and soon died as a consequence of the beating.

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

</comment></comment></comment><comment><USER7> I will suggest that people default to habit when they are exhausted and this could be an underlying reason why physicians seem to do a poor job of stopping certain bad habits. Over the years, I have seen articles that suggest that exhaustion on the job is a major contributing factor to medical errors, though stuff that is most readily findable seems to mostly be about nurses and residents, not physicians per se.

I don't have a specific source in mind, so I'm not going to post a link. I have verified that you can find stuff on the topic by searching "medical errors due to staff fatigue". There may be other search terms that work.

</comment><comment> swingline-747 Big pet-peeves of doctors:

1\. The Academic Elitist: When they act like know-it-alls, poo-poo informed patients or any information that didn't originate from them.

2\. The Thickheaded: When they don't LISTEN and go about diagnosing whatever it is they're more interested in.

3\. The Evening News Anchor: When they act with over-confident, pseudo- infallibility, which seems to correlate invariably with being wrong.

4\. The Snakeoil Salesman: When they hard-sell products and services that aren't even FDA-approved, like this certain brand of CBD that this one doctor was pushing. _cough_ kickbacks _cough_

Bonus: The Histrionic and Defensive: When they gaslight or accuse their patient of behavior they didn't engage in, especially when they miss lab results and clinical symptoms that would explain said symptoms.

<comment><USER8> Have to agree with most of this list. My thyroid stopped working when I was a kid and despite many doctor's visits it went undiagnosed for about 2 years. It was ultimately diagnosed by my mother's coworker, a ticket booth attendant, who recognized the symptoms as being similar to her dog's. After enough badgering by my mother a simple blood test confirmed her diagnosis.

I can't say that my experience with doctors since then has improved my opinion of them. I've met with only about 2 physicians in my entire life that actually seemed genuinely interested in solving problems.

<comment><USER9> I've had similar experiences in my life as well. Purely anecdotal, but I've found NP's and PA's tend to listen more and just be more personable in general. I sometimes wonder if the extreme hours physicians have to work beat the compassion right out of them.

<comment><USER10> This so much.

Our NP was great, took time to understand the issue each time we visited and generally was on the mark much more often than other MDs I've seen over the years.

</comment></comment></comment></comment><comment><USER11> This isn't a very nuanced piece.

The glucose control effect is not unexpected. You are telling ICU drs, who spend their lives trying to adjust physiological parameters to keep the sickest patients alive, to do less. This is anathema to their way of operating. Of course adopting more intensive control and then letting it go will not happen at the same pace.

</comment><comment><USER12> Apologies, but it is hard for everyone to Unlean Things. It is just human nature/the way we are wired. It take discipline and great effort. What would doctors want to be different? We all got a comfort zone :)

<comment><USER13> Doctors are credentialed professionals. As professionals, they get a legal barrier to entry protecting them from competition in exchange for maintaining professional standards, which include ethical standards and continuing education. This in turn enables them to charge huge fees.

A lawyer is not allowed to stop learning about new laws; he would eventually be disbarred. An architect is not allowed to construct buildings that would only have been up to code at the time she finished her degree. And doctors should likewise not ignore the state of the art in their field.

<comment><USER14> Totally true, but it misses the point.

Doctors invest huge effort in keeping up with the state of the art in their field, the problem is that to be a competent doctor you also need considerable amount of intuition and heuristic.

New advances sometimes requires that you unlearn things and this i a completely different process; when you simply keep up with the state of the art you have a set of known facts and techniques and slowly you discover more and more of them. Unlearning things requires you to review entire branches of your knowledge tree to eradicate every trace of the now wrong fact

<comment><USER15> It's fine for doctors to intuit that "the cost and side effects of HipNewDrug outweight the benefits". It's not fine for a doctor to be unaware that HeretoforeUncurableCondition now has HipNewDrug as a possible treatment -- i.e. to not have unlearned that HUC is a death sentence.

<comment><USER16> That's not really what the article is about. It's actually about someone finding HipNewDrug is actually not effective at curing Frobulitis and in fact has adverse side effects, and yet doctors continuing to prescribe it for that condition.

<comment><USER15> It's the same failure mode though.

<comment><USER16> It's not the same. It's a bigger problem than the one you're talking about, according to the article. It's easier to get doctors to adapt some procedure than to get them to give one up.

<comment><USER15> Both are the same failure mode: "You used to always do X. You shouldn't do that anymore."

In my example, X was "tell patient they have a death sentence". The fact that yours is closer to a specific situation in the article does not make it "a different failure mode" with different dynamics and causes.

<comment><USER16> I don't know what to tell you. You are saying the opposite of what the article says and not offering me any reason to take your word over the article.

<comment><USER15> No, I'm not. I said that "thinking Y is uncurable" is the same kind of failure mode as "prescribing X for Z after the science starts to indicate that X is harmful". I then offered a very good reason to "take my word" on it: I stated the general form of the failure mode, parameterized over X, and showed what X would be in each case.

Did you miss that, or did you not consider it a good reason?

If you can take a moment to review the thread, I only brought it up to distinguish valid vs invalid reasons for not proposing a kind of treatment, and thus why a doctor's intuition would vs wouldn't be defensible given the state of the literature.

Where specifically is the article saying the opposite of any of that? Unless the article talks about the topic of appropriately classifying failure modes, which it isn't, it wouldn't bear on that topic.

<comment><USER16> The article identifies a discrepancy where it is much easier to get doctors to introduce a new treatment or practice than it is to get them to stop using or recommending it after it is discredited. I don't see how that could be the case if they're "the same failure mode."

<comment><USER15> People can fail to realize two failure modes are the same and merit the same treatment.

And I don't see what that would bear on my original point (which was just distinguishing between valid vs invalid reasons not to recommend a treatment).

<comment><USER16> People can equally well fail to realize that two modes of failure are different.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> What a surprise - it is easier to get doctors to do things that increase billing than it is to get them to stop doing something if it decreases billing. It is almost as if money is more important than the patient.</comment>


Google forcibly enables G Suite alerts for government-backed attacks - <AUTHOR> https://www.zdnet.com/article/google-forcibly-enables-g-suite-alerts-for-government-backed-attacks/ <comment><USER2> If for instance, the new aggressive cyber warfare posture the White house is promoting came true, would google honour this to inform me I was at risk of a US led cyber attack?</comment>


Most Americans don't think cellphone tracking will help limit Covid-19 - <AUTHOR> https://www.pewresearch.org/fact-tank/2020/04/16/most-americans-dont-think-cellphone-tracking-will-help-limit-covid-19-are-divided-on-whether-its-acceptable/ <comment><USER2> And for those lacking a cell phone or not carrying it all the time?</comment>


Facebook (PHP) is not very Copenhagen (Change to C++ to save planet) - <AUTHOR> http://www.webtoolkit.eu/wt#/blog/2009/12/17/facebook__php__is_not_very_kopenhagen

<comment><USER2> What this article fails to note is that writing C++ code to serve up web pages would be much less efficient from a human time perspective. You'd need many more developers working, and the average American emits 20 tons of CO2 per year. So if Facebook has 100 developers hacking PHP code, they'd probably need at least 200, or possibly 300 developers hacking C++ code. 100 developers is 2,000 tons of CO2 per year (at average rates). From an economic standpoint, it would make much more business sense to use carbon offsets. Not to mention that a 10x end-to-end efficiency improvement is AWFULLY optimistic. I'd say 2x or 3x at best.

<comment><USER3> There's a more glaring deficiency than that, which is that CPU is rarely the bottleneck on a webserver.

<comment><USER2> A "web server" in Facebook's cluster is just Apache+PHP. It doesn't do any disk work. It's not reading anything from disk, as that gets forked over to memcached or MySQL. If you've got thousands of boxes in this arrangement, clearly reducing the CPU usage thru whatever means will get you more efficiency.

<comment><USER4> can you elaborate more on "no disk work" and forked over things? i didnt get.

<comment><USER5> The webserver will only do computations which data they get from other services (memcache, etc...). They will never fetch the data locally, so there is no local bottleneck except the local bandwith and the efficiency of the code, thus the cpu.

<comment><USER4> then only logical reasoning behind is cheap machines for webservers and very powerful ones for "data" servers. otherwise network bandwith is only a fraction cpu-storage one.

</comment></comment></comment></comment></comment></comment><comment><USER6> Facebook makes heavy use of, and is one of the major contributors to, APC, the opcode cache. Most of the time, Facebook is hitting this cache, so its interpreted load is much, much less than this article estimates.

In other words, this article's author is railing against some imagined version of Facbook running some imagined implementation of PHP, not the Facebook that actually exists running PHP with opcode caching and memcached.

<comment><USER4> facebook may be a contributor but apc has only a minor release for the last 8 months.

<comment><USER7> APC has lots of users. Judging the userbase of a piece of software by the rate of major releases is like judging the speed of your car by the rate at which it breaks down.

It's an opcode cache. It doesn't need to gain features until it can read email.

</comment></comment></comment><comment><USER8> The reference used to justify the 10:1 superiority of C++ [http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=php&lang2=gpp&box=1) seems unlikely to have much bearing in this case. I doubt Facebook is calculating the Mandelbrot set or traversing huge binary trees in PHP.And as others have pointed out, CPU is hardly the only thing going on here.

Useful real-world benchmarks of even simple real-world systems are rare and require a lot of resource (mostly human) to construct. Here's an example benchmark I proposed once. [http://jackfoxy.blogspot.com/2009/10/time-for- real-world-lin...](http://jackfoxy.blogspot.com/2009/10/time-for-real-world- linuxapache-iis.html) At the time I couldn't find any bechmarks anything like this. I haven't tried looking since, but I suspect no one has bothered. It's a lot of work.

</comment><comment><USER9> Does that mean networks move bits faster and hard drives spin faster for C++ than they do for PHP?

<comment><USER10> It gets you closer to the theoretical maximum of your network and memory busses. When a single machine can generate queries and lookups and log and render results faster, you need fewer machines to handle a given load. I know we increased our web front end capacity by 5x when we migrated from PHP to Java that runs backend queries asynchronously, so we reallocated some boxes and now we won't need to light up new hardware for a while. The inefficiency of PHP really adds up when you reach hundreds of cores.

<comment><USER7> That sounds like an architectural change, not a problem with PHP's runtime.

It's quite possible that the solution to your particular problem can be better expressed in another language than PHP, or will run faster under a different language's runtime. This doesn't mean that PHP "is slow". It might mean that your problem is an imperfect fit for a PHP-based architecture at your particular scale.

<comment><USER10> We have made architectural changes, but not that day. We literally had a drop- in replacement that did the same work but sustained 5x the request volume before saturating on the same machines, with the rest of the datacenter unchanged. (The async client was merely for latency, not throughput.)

I don't believe any PHP runtime can ever be the fastest solution for a problem. The language requires runtime type checks and coercions inside the operators and builtin functions, both keyed and ordered access to every collection, ad hoc creation and destruction of variable bindings by name, and dynamically switching to reference semantics for any existing value. Each of these imposes a cost on passing arguments and evaluating expressions, and I didn't find any of them paid off by making code much simpler.

</comment></comment></comment></comment><comment><USER11> It's Copenhagen, or København, not Kopenhagen :(

</comment><comment> Asa-Nisse It would be 1:20 if they wrote it in assembler. I write all my webpages in Assembler and I eat bits for cereal.

</comment><comment><USER12> Consider Cambridge physicist David MacKay's Without Hot Air, especially the section "Every Big Helps."

[http://www.inference.phy.cam.ac.uk/withouthotair/c19/page_11...](http://www.inference.phy.cam.ac.uk/withouthotair/c19/page_114.shtml)

On a related note, I suggest the everyone run Wattzon.org to see where their carbon footprint comes from. I found that while I was a much lower user on everything else, heat accounted for 40% of my entire carbon footprint. Immediately I ran around the house and fixed the duct vents that I could close before, and now I'll have probably halved that, saving me $15 a month, $180 a year, and 20% of my carbon footprint.

Seriously! Little fixes can make _huge_ changes.

</comment><comment><USER13> Why rag on Facebook? Smells like linkbait to me, why not argue the general case? At least Facebook is _using_ their servers, what about all the unused servers? Old servers that could be consolidated? Servers running even more inefficient code than PHP?

</comment><comment><USER14> Good point. But I fail to see why C++ is the solution, when there are plenty of other languages that execute just as efficiently but do not have C++'s shortcomings. I would pick Haskell, but even good-old-Java will do just as well as C++ for Facebook's workload.

</comment><comment><USER15> If facebook has 30K servers, I highly doubt they have 25K of them being webserver.. Hyves (a dutch social network) at some point explained about 1 in 4 servers was webserver. The rest was storage, db, caching, proxys, chat, whatnot.

</comment><comment><USER16> If you're going to follow their line of thinking to its eventual end, then why not urge Facebook to just write everything in Assembly? :)

</comment><comment><USER17> Coding in PHP make Al Gore cry.

<comment><USER18> But Al Gore invented PHP!</comment></comment>


One wife for 2-3 brothers: Polyandry custom fading in India - <AUTHOR> http://www.nytimes.com/2010/07/17/world/asia/17polyandry.html

<comment><USER2> Interesting. I've just finished reading Sex At Dawn which explores human sexuality from an evo-psych point of view, particularly the link between us and Bonobos.

I have a healthy amount of skepticism about most evo-psych but the book made a very well argued point about the natural state of humanity being non- monogamous, and that early hunter-gatherer societies were mostly non- monogamous, one variant being the polyandrous kind of relationships described in the article. Though most of the examples had a more free-ranging variant, similar to Bonobo groups where there were very few rules about who slept with whom, regardless of marital status.

<comment><USER3> Matt Ridley's _The Red Queen_ also discusses this particular culture, being one of the extremely small number of polyandrous (one wife, multiple husbands) cultures ever known to have existed, in contrast to the extremely large number of polygamous (one husband, multiple wives) cultures. Interestingly, in the small number of cultures where it does exist, the men are always brothers -- presumably this is the only way to get the situation to work without the men killing each other and/or children which they suspect to not be theirs.

I haven't read Sex At Dawn, but human mating really has very little in common with bonobo mating. The human drive to pair-bond is actually incredibly strong (even in polygamous cultures the man almost always has one primary wife), and if I recall correctly, nearly unique among mammals (though common among birds).

<comment><USER2> Actually that's what made Sex at Dawn so interesting, they explore a number of hunter-gatherer societies (Amazon, Africa, China . . . ) and they are predominantly non-monogamous. They might have the concept of marriage, but often it won't be something that is recognizable when compared to the typical modern view. I.e. the marriage ceremony includes having sex with all of the men in the village.

They go on to make a very strong argument about the similarity between us and Bonobos. As I said before, I'm not sure I buy everything but they made a very strong argument.

And yeah, monogamy almost never occurs in nature. Even penguins who are supposedly monogamous only stick together long enough to have kids, then they rejoin the dating pool.

<comment><USER3> If we really had much in common with bonobos, we wouldn't have a concept of marriage at all. Everybody would be willing to mate with everybody at all times; whereas humans only want to mate with people they're attracted to.

The mere fact that men care whether their sex partners are good-looking tells us that pair bonding is pretty deeply ingrained in our psyches. While females have a stronger incentive to make sure the men they mate with are of the highest quality (since they could be stuck carrying and caring for their kid for a long time), men invest little in mating so in the absence of pair bonding should be willing to mate with _any_ female unless they expect to find a better female in the next few hours. Instead, men tend to be picky about the physical characteristics of the women they're willing to mate with.

I think the conclusion of The Red Queen on this subject was that humans are somewhere between monogamous and polygamous; men are polygamous when they can get away with it (i.e. when they're powerful enough to get away with taking more than their fair share of women) and monogamous when they can't. Women have little desire to have multiple husbands, but do want to mate with the best quality men, so will often marry lower-quality men but have affairs with higher-quality ones.

Strict monogamy no, but pair bonding as a deep-seated instict yes.

<comment><USER2> The point the book makes is that as we transferred from foraging to farming the entire dynamic shifted. As hunter-gatherers there was not competition for resources and it didn't matter who the genetic father of a child was. In most foraging societies today people don't care about paternity and treat all the children in the village as their own. In several Amazonian tribes they believe that children are made from an accumulation of semen in the mother and husbands often offer their wives to other people in the village.

The shift to farming meant that population density increased and competition for goods meant that wealth began to concentrate. With that there was a reason to ensure paternity. So yes we made a shift, but looking at our existence for the majority of the time that we've existed as a species we can see why we have always had a very tough time with monogamy.

Also, the idea that women have little desire to have multiple husbands is not true at all. Women are just as promiscuous as men are and when given the freedom are more than willing. Again, I highly recommend Sex at Dawn because the views that you're expressing are the exact ones that it addresses point by point.

</comment></comment></comment></comment></comment><comment><USER4> So what happens to the "extra" women?

<comment><USER5> Missing women of Asia <http://en.wikipedia.org/wiki/Missing_women_of_Asia>

<comment><USER3> But in a society where women are so valuable that they need to be shared, what's the incentive for female infanticide?

Is it possible that many of the women disappeared into harems of the nobility?

<comment><USER6> The women are valuable to grown men, they're not valuable to the parents that have to raise them. That's where the infanticide comes from.

<comment><USER7> It's very sad. In fact, the only state in India where there are more women than men (which is the natural state in most everywhere in the world) is Kerala, the state I'm from. I believe this is because the state has been run by the Communists for most of its post-independant history (which has also resulted in a 99% female literacy rate, again by far the highest in India).

Sometimes we forget about the social benefits communism has provided in certain parts of the world. I have no doubt, for example, that Afghanistan would be far healthier, wealthier and more advanced today if the Russians were not driven out in the 80s.

<comment><USER8> This is an important point, but I think Afghanistan as an example is a bit misguided. Home-grown (as much as possible) and home-governing communists are usually going to do a much better job than a colonial government of any political orientation, which is what I fear Afghanistan would have ended up as.

</comment></comment></comment></comment></comment></comment><comment><USER9> I would like to know of a polygynous or polyandrous hacker <http://news.ycombinator.com/item?id=1523224>

<comment><USER10> I created a throwaway account to reply. I'm not even sure this topic is Hacker News but hopefully I can add some insight. I'm a regular contributor here.

Where to start? I'm male, around 30 years old, American, raised Christian, not active in the religion. I was fairly awkward with women and people in general when I was younger, but I put myself through lots of experiences, learned a lot, and eventually became much more social, though I'm still a natural introvert.

I'm seeing women in a few different places. I have one regular girlfriend where we meet during the high ovulating part of her cycle each month, which starts 14 days from the first day of her period. We have our first kid's names picked out. I have another two or three women that are very important to me. All know, though I go light on details to hopefully avoid jealousy.

Thinking about how to set up homes, schooling, and parenting is difficult. I study a lot to learn about it. I intend to support all my children and to grow my family slowly as I can afford to provide. I work a lot, and I try to work smart in addition to hard. I do a mix of work with steady pay and with upside.

All my closest friends know, roughly 3/4ths of them approve. My parents know, they don't approve at all. I'm not sure when I'd go public with this: Just like being gay 100 years ago, it'd break a lot of potential opportunities and meet lots of scorn and criticism by people. I have some professional acquaintances on here who probably won't recognize this. A couple close friends are here too and will likely recognize this is me.

If you have any questions, go ahead and I'll reply when I've got a break in a little bit. I've thought about this extensively over a great many years. Also, if anyone has any bad reactions, or criticisms, or warnings, or think this is bad, then I invite you to share those as well. Actually, it'd be helpful to me in gauging people's reactions, so all are welcome to ask or respond if they're curious.

<comment><USER11> How is this different than being a dude from the trailer park or ghetto who has 4 kids with 4 different baby mommas?

<comment><USER10> When you have a family, you can do it with planning, foresight, and an ability to provide for your children and raise them well. Or you can do it without those things, which is usually what happens in the situation you described.

So having a family this way is different from a trailer park the same that a normal couple planning to have 4 kids together that they can afford to provide for differs from a trailer park couple having 4 kids they didn't think about having, weren't ready for, and can't provide adequately for.

<comment><USER11> It still sounds stupid to me, but good luck.</comment></comment></comment></comment></comment>


Please stop using white text on black background - <AUTHOR>

Is it just me?  White text on black background is just horrible on my eyes, when I leave the web page I continue to see patterns for 5 minutes.  This should be common knowledge among web designers/developers, no? <comment><USER2> white text on black is no better or worse than black text on white

Try dimming your display to a reasonable level and improving the lighting around your monitor(s).

</comment><comment><USER3> Please stop using black text on a white background.

Is it just me? Black text on white background is just horrible on my eyes, when I leave the webpage I see an afterglow for five minutes. It's like staring into a flashlight, no?</comment>


Ask HN: Quick way to make an A/B testing website? - <AUTHOR>

Do you know of any links or more information to make an A/B testing website? I'm thinking of putting one together, but need some more good links.<p>Thanks. <comment><USER2> What do you want to do exactly? Do you want to build an app to help people do A/B testing?

It might be worth trying to get in touch with someone like Patrick McKenzie. His username here is patio11 and his blog is <http://www.kalzumeus.com>. He's done a lot of writing about A/B testing and has even released a testing framework: <http://www.bingocardcreator.com/abingo>. I'm sure he has a lot of thoughts that would be very beneficial (I'm sure there are other people around here that could impart their knowledge too).

The nature of A/B testing often requires things to be pretty tightly coupled with the app itself. If you're providing a service for this it'd be interesting to see how you overcome that.

<comment><AUTHOR> Yes, I want to create an A/B testing (and other types of market research testing) on a level up based on consumers preferences. Say they like to read, so direct the authors tests to them and not to alliterates.

what do you mean "tightly coupled with the app itself"?

<comment><USER2> >what do you mean "tightly coupled with the app itself"?

I mean that the developer needs to set up rules for what gets displayed for the A/B test and then track the results. I guess you could create some kind of API they could hook into for this.

I may not notice replies here, so feel free to email me about this (email in profile).</comment></comment></comment>


The Best Cryptocurrency for International Money Transfer - <AUTHOR> https://www.keysheet.io/guides/best-coin-for-international-money-transfer/ <comment><USER2> Cryptocurrency and blockchain technology in general have many valuable applications and I fear articles like this, advocating its use as a means circumvent U.S. sanctions, will only serve impede the adoption of the technology broadly.

I'm an avid traveler and was once stranded in Cuba (before Obama eased travel restrictions) with only $5 USD left, no way of accessing my bank account, additional funds, or even to contact my family in the United States to let them know why I wouldn't be meeting them at the airport when my plane landed. All I could do was wait at the teeny tiny airport, starving, and hope I could talk my way onto the next flight to Miami.

I know as well as anyone that there are often good reasons for wanting to usurp these types of sanctions and that the sanctions often have collateral damage to innocent individuals who are simply going about their daily lives. But I do think it's important to consider that when you promote a technology's ability to bypass the intentions of lawmakers and regulators you are also making the case for them to do everything in their power to keep that technology from wider use. This is particularly dangerous because lawmakers have both significant power to impede technology and often a very poor understanding of how it works.

I would caution you to keep in mind that this article, and others like it, can cause just as much collateral to progress and innocent people as the sanctions it seeks to circumvent.

<comment><USER3> I hear you and I agree with what you're saying to a certain extent.

For cryptocurrency to take off, though, it needs real use-cases. This is as real as it gets.

<comment><USER2> I can think of 1,000 "real use-cases" for cryptocurrency that are far more valuable than sending money to a country facing sanctions in violation of U.S. law.

I can probably think of more than 1,000. If you want cryptocurrency to "take off" I can assure you that using it to commit a crime will result in the opposite.</comment></comment></comment>


Show HN: Deep Semantic Code Search - <AUTHOR> https://github.com/chnsh/deep-semantic-code-search <comment><AUTHOR> In this class project - we have attempted to learn a joint embedding space largely by implementing various ideas in excellent papers and blogs. We are looking forward to some feedback and comments.</comment>


Search for research papers filtered by popular websites using google power.. - <AUTHOR> http://www.google.com/coop/cse?cx=008475611130430976967:itx3ve6qmas

<comment><AUTHOR> Well you can include the sites you want to add so that it is restricted to what you need and tat wat i did "edu" for universities and added 6 websites for the other portals... im not sure if im clear here....but all these are pretty apparent on the control panel

</comment><comment><USER2> What are the key "customization" aspects the API let's you change? If you could share more about what you've learned form all your reading, more of us could contribute our thoughts ...

</comment><comment><AUTHOR> I just made it to try the custom search .... how do you think we can get better at this ?</comment>


How godaddy got its name (and logo) - <AUTHOR> http://www.bobparsons.me/9/how-godaddy-got-name-logo-mean.html

<comment><USER2> Don't use these guys for hosting: <http://nodaddy.com/>.

<comment><USER3> Any suggestions for good domain name registrars?

<comment><USER4> Others have suggested NearlyFreeSpeech.net here and so I signed up with them a while ago (switched from GoDaddy). I've been using it for domain registration, DNS, and web hosting. Since I have ~0 traffic, it's dirt cheap.

It's ideologically the polar opposite of GoDaddy. And the web interface is so much easier to use.

There's no reason not to switch.

</comment></comment></comment><comment><USER5> _Barbara Rechterman (my right hand person to this very day) and I were in my office. Someone said "How about Big Daddy?" A quick check revealed that it was taken. Then I said "How about Go Daddy?" And by golly, the name was available, so we bought it._

Of all the company name stories I've heard, this was the most anticlimactic.

Cool list of company name etymologies here:

[http://en.wikipedia.org/wiki/List_of_company_name_etymologie...](http://en.wikipedia.org/wiki/List_of_company_name_etymologies)

</comment><comment><USER6> I'll never forget having to explain to my credit card company that my frequent $8.99 purchases to GoDaddy.com were legitimate back in 2000.

When I got off the phone (with a female phone operator), my wife, who was listening told me - you know, they didn't believe you, they thought your "GoDaddy" purchases were for porn.

Now that I think about, I bet she did think that.

</comment><comment><USER3> I love the story of the logo. And I love how that logo story contrasts with this blog post: [http://www.webdesignerdepot.com/2009/01/how-not-to- design-a-...](http://www.webdesignerdepot.com/2009/01/how-not-to-design-a- logo/)

<comment><USER7> "...business owners or those wanting a logo will try to do it themselves. I highly recommend against this and suggest you leave the design to a professional, much as you would leave your dental work to a dentist."

Did they just compare logo design to _dentistry_? This blog post reads like an advertisement for a logo design firm.

<comment><USER3> Yeah, that blog post seemed out of touch to me. Sure, if you're going to redesign the McDonald's or Exxon logos you're going to want a professional and there _is_ a lot riding on the logo. But for everyone else the logo just isn't that important.

A logo is something that won't make or break your business. It's the icing, not the cake.

</comment></comment></comment><comment><USER8> On a sidenote, going to bobparsonsucks.com will redirect you to godaddy.com

</comment><comment><USER9> The use of "its" was correct in the original title.

<comment><AUTHOR> corrected</comment></comment>


Ask YC: Best practice for Python module imports? - <AUTHOR>

Im torn between two general module import styles. The import-everything-at-the-top approach where the beginning of each python file/module imports every module potentially needed later in the file OR the import-as-needed approach.
I know what I dont like; a file starting w/ 20+ import lines, that just seems ugly and java-y (no-flame, just sayin) to me. OTOH, the as-needed-approach seems perhaps a little too, uhm, disorganized? Although Id guess Im probably more partial to that approach.
This is a pretty minor stylistic issue but I havent settled on one approach and I'd like some feedback to come to some conclusion once and for all.
For example,
import foo import baz import bar import quux import django.foo
# etc
vs.
import sys
def some_os_thing():
  import os
  print os.getcwd()
def some_http_thing():
  import urllib
  print urllib.urlopen('http://...').read() <comment><USER2> The recommended convention in Python's own documentation is to import everything at the top, and on separate lines.

While technically Python doesn't import anything twice, it still takes nonzero time to check the module registry (a dictionary lookup). So if this happens every time your functions are called, it's unnecessary work, even if it's fast.

I personally tend to do all imports in one place, with the exception of test routines: I figure that a user of a module shouldn't really "depend" on modules that are only needed in test mode, so e.g. I would do a local "import" inside a _test() function.

<comment><AUTHOR> Ah ok, I wasnt aware that Python had an opinion, thats certainly (in my book anyway) a considerable argument for that approach then!

I think I might be converging on a reasonable practice of doing all imports in one place while including basic comments and/or just insuring at least that imports are grouped by category / 'package'.

# Sys imports import os, sys, urllib

# django imports import django.foo ...

# google apps imports import gdata.foo ...

<comment><USER3> If you have the same 20 modules coming in over and over, consider bundling them all up in a single module of yours that does nothing but load those 20 modules, then other modules simply import that module. There's nothing wrong with that. Imports are as eligible for refactoring as anything else.

If you have a _different_ set of 20 modules coming in over and over, you probably need to break up your modules more finely.

<comment><AUTHOR> Yeah Ive thought of that (lets call it the meta-import) approach as well (tho never tried it). I dont know why I hesitated but Im glad to hear that it seems sound.

<comment><USER4> Also note, google app engine throws a warning if try and import anywhere but at the top.

</comment></comment></comment></comment></comment><comment><USER5> If you're looking at 20+ imports, it may also be an indicator that there is too much going on in the file. With small, focused modules the question is moot.

</comment><comment><USER6> My rule of thumb: I only import things locally (i.e. within a function) if it is a conditional dependency. This is particularly true if it's something not from the standard library. Example: I might have an application that supports multiple database back ends, such as PostgreSQL, SQLite, etc, but I'll conditionally import only the one applicable DB API module.

</comment><comment><USER7> My own preference is on a case-by-case basis, and typically depends on whether I'm importing a module specific to my application, like a model or logic library, and whether I only need it for one specific method.

Standard libraries I'm more likely to import globally, since I'm more likely to want to use them several times.

The most important thing is to figure out what works for you, and then be consistent about it.

</comment><comment><USER8> One reason to import something within a function would be for lazy loading. If I do end up having many different imports, I tend to group them by library/framework.

I've learned a lot by looking at the source code for guido's rietveld: [http://code.google.com/p/rietveld/source/browse/trunk/codere...](http://code.google.com/p/rietveld/source/browse/trunk/codereview/engine.py)

</comment><comment><AUTHOR> Ok I appreciate the helpful discussion, this will inform my future practice. To wrap up, I think the takeaways are:

a, use your head, don't let convention override reason b, In general, keep module imports at the top of the file organized by type & package with the caveat that a large # of imports (say more than 10 or 20) may indicate the module is too ambitious and is a candidate for refactoring.

</comment><comment><USER9> <http://www.python.org/dev/peps/pep-0008/>

There's a section on imports.

</comment><comment><USER10> My preference is to use

from x import y

inside any function that needs y.

OTOH I think there are good reasons to go with the official Python recommendation, which another poster says states that all imports should be at the top on separate lines.

</comment><comment><USER11> Have a look at: [http://stackoverflow.com/questions/477096/python-import- codi...](http://stackoverflow.com/questions/477096/python-import-coding- style/477128#477128)</comment>


Test of 'Impossible' EmDrive Space Engine Passes Peer Review - <AUTHOR> http://www.space.com/34797-impossible-space-engine-emdrive-study-published.html <comment><USER2> This has been duped repeatedly. Previous discussion here:

[https://news.ycombinator.com/item?id=12995125](https://news.ycombinator.com/item?id=12995125)</comment>


IBM Watson to battle patent trolls - <AUTHOR> http://www.extremetech.com/extreme/108281-ibm-watson-to-battle-patent-trolls

<comment><USER2> Unfortunately, this article is just speculation. IBM is processing and mining the patent database, but everything else in the article - particularly the parts about about finding prior art ("battling patent trolls") is the from the ExtremeTech author, not IBM.

</comment><comment><USER3> Having IBM make a Watson instance that is dedicated to all patents would require a significant investment by IBM. It seems like it takes a lot of time and money to create specialized Watson instances. They have a specialized one that recognizes pharmaceutical patents right now. In the long run it would make sense to create something that fights patent trolls because the initial investment might pay itself off by avoiding patent licencing or having people find prior art etc...

</comment><comment><USER4> IBM Watson team is focused on medical data mining now. Training IBM Watson just for Jeopardy took over 7 years. They are struggling how to make Watson learn faster. It's not the CPU or RAM limitations. There are a lot of custom pipeline building that needs to happen. Medical data is usually behind firewalls, password protected. Even medical books and articles are not easily accessible. There is no place for side projects.

</comment><comment><USER5> Ah, the march of technology busily grinding the concept of intellectual property into dust. Glorious. Imagine if every patent troll was greeted by thousands of citations of previous use?

</comment><comment><USER6> how long before Watson discovers how profitable patent trolling can be for a brain powerhouse like it [he can or soon will be able to generate "method and apparatus for user interaction with interactive screen through rest interface" faster than thousands SV programmers] and switches sides? :)

</comment><comment><USER7> Why would IBM possibly want to have it's own AI fight IBM? Or will they put special locks in that block IBM from being read?

<comment><USER8> IBM does happen to have quite a lot of patents to counter with. Having been in business for 100+ years tends to do that.

<comment><USER9> Patents don't last 100 years. Are IBM's 50,000 patents all current?

</comment></comment></comment><comment><USER10> The headline sounds interesting, but extremetech's mobile website is so awful I can't read it... Breaks the back button on iOS sometimes and what's with the forced pagination?

<comment><USER11> Hey -- yeah, the OnSwipe thing...

Turns out that lots of people like it, but some people really detest it. I think we're fixing/changing it in the future, but I'm not sure of the exact timeline.

Thanks for soldiering on in the time being :)

</comment></comment><comment><USER12> I wonder if they have a patent on using an automated natural language processing system to fight patent trolls.</comment>


Show HN: RSS Reader – Distraction Free and ML Features - <AUTHOR> https://github.com/Maarten08/rss-reader-lesslessless <comment><AUTHOR> Made this on a sunday afternoon. What do you think?</comment>


Show HN: My Book, ADHD Pro – Happy Productivity for People with ADHD - <AUTHOR> https://adhdpro.xyz/ <comment><AUTHOR> I was diagnosed with ADHD 5 years ago, and it's been quite a struggle.

When I started in tech, I had a difficult time focusing on the right tasks at work. Sometimes I would hyperfocus and complete an entire week's work in one day, but most of the time, I was suffering and fighting myself to keep focused. Context switching was a tremendous drain on my energy, and my organization was chaotic at best.

I felt like shit all the time.

Two years ago, I started interviewing other "out" ADHD professionals to see what they were doing to manage. My goal was to be productive AND happy at the same time. I succeeded.

I found several patterns from these interviews and started compiling notes. I was also shocked at how poor our experiences were with therapy! The majority said therapy was NOT helpful with ADHD.

Other ADHD books seemed to be focused on "coping" rather than thriving, or they made overzealous claims about ADHD being a "superpower". It's a neurodevelopmental disorder with pros and cons, not magic.

When the pandemic hit, I quit my job and started writing. I took my own advice, and this project has been completed with minimal stress. I can't believe I'm actually launching something that I didn't have to _grind_ on. I was able to maintain sustainable productivity, and I think you can too.

If you have (or think you have) ADHD, I think this book can help you build a better strategy for how to maintain happy productivity while avoiding burn- out.

The book is DRM free and available in all major e-book formats, and the companion videos are all recorded at 1080p 60fps.

<comment><USER2> What's the main draw on your book vs others?

<comment><AUTHOR> There are some great ADHD books out there, but many of them are deeply scientific or for parents.

My book is geared towards people who want to complete side projects and have better strategies at work, without reducing the scope of their goals or quality of work. I explain how to take a mindful approach to ADHD symptoms rather than chaotically bouncing from hyperfocus to burn-out.

</comment></comment></comment><comment><USER3> Hey Rob, have you read Taking charge of Adult ADHD? If so, what are your thoughts?

<comment><AUTHOR> It's one of the books that I didn't get around to reading, so I don't have a solid opinion about it :)</comment></comment>


Show HN: Simple task management (punchTask) - <AUTHOR> http://punchtask.com/

<comment><USER2> So you're showing us...a landing page?

<comment><AUTHOR> Pretty much yeah, but more so the copywriting. Please let me know if this is a no-no on HN :).

</comment></comment><comment><USER3> would like to try it out when it comes out. check out our task management app, taskup: <https://taskup.com> and let us know what you think

<comment><AUTHOR> Will do, thanks for the feedback. Did you subscribe for the mailing list?</comment></comment>


Lunar Lander 3D in 5K - <AUTHOR> http://www.sebleedelisle.com/?p=428 <comment><USER2> Seb presented the story behind this at the 5K app competition final (<http://fivepoundapp.com/wiki/5kapp/>), held in our coworking space (<http://theSkiff.org>) in Brighton, UK last week. Absolutely brilliant!</comment>


Reasons to avoid code comments  - <AUTHOR> http://pauloortins.com/5-reasons-to-avoid-code-comments <comment><USER3> I'd say only overly verbose documentation is bad.

If a situation exists in which someone will access your code without the source code right in front of them; ie. it's a library that will be and depended upon by others, consider:

1) They probably will not compile or read your source code, so no matter how elegant your code is, they'll only see the exposed API, and _no_ how your function works wont be obvious.

2) Automatically generated documentation is usually very poor for unannotated code.

3) Writing simple intuitive APIs is actually _very difficult_ , and the chances that you'll get it right every time are virtually zero.

Maybe internal functions can be 'self documenting', but it's a silly to say documentation, in general, is bad.

Public APIs require documentation; if you don't document it, and the person who has to use it has to hunt down a copy of the source code to find out how to use it, trust me, they will curse you for it, not thank you for writing simple elegant code.

<comment><USER4> I'd say the opposite.

Nobody will read your documentation.

They will be able to see the API, so make sure that it's well designed, and as easy to use as possible (much easier in languages/IDEs with autocompletion).

And they will use code snippets, so make sure that you make those available. Feel free to walk people through the process of using those snippets, so they can understand them, but 99% of devs are just looking for some code they can splat in and get their system working.

A great example of this is the Quick Setup guide for Persona:

[https://developer.mozilla.org/en- US/docs/Mozilla/Persona/Qui...](https://developer.mozilla.org/en- US/docs/Mozilla/Persona/Quick_Setup)

Which walks you through what you need to do, giving you code that you can use at every step.

<comment><USER3> ...so you're saying, no one will read the documentation, because they'll all be looking at the documentation?

You've lost me I'm afraid.

(unless you're saying that api documentation, specifically, isn't very useful compared to say, examples, in which case, you're agreeing with me, because useless api documentation is what you get when you run a documentation tool over a code base without annotations...)

<comment><USER5> > ...so you're saying, no one will read the documentation, because they'll all > be looking at the documentation?

I think he means that devs won't be reading documentation like a book, chapter by chapter, trying to comprehend what API does, but instead they will look at tutorials and code snippets, and enter your documentation at random points via Google / StackOverflow links, mostly in cases when something is not working.

</comment></comment></comment></comment><comment><USER6> If your code comments are breaking any DRY principles, then it's likely it's because they're explaining what your code is doing. I agree that properly named variables and well structured code should be easy to understand if you want to know what it's doing.

The purpose of comments are to say why your code is doing what it's doing. These sorts of "why" comments should be encouraged, not avoided.

<comment><USER7> Yes, especially design decisions and reasons for stuff, that isn't obvious, like why this is looked up each time, and not cached, or why the data representation choosen is as it is, and not something simpler/faster, etc.

But there are ways to move some things from comments - gotchas can be made unit tests instead of //WARNING!!! in comments - made a test that checks the implementation for the error that shows when you cache this thing that can't be cached - even if somebody miss the warning in comments he will surely notice the problem when the test fail (comment should still be there so people that read code before making changes won't have to wait AFTER they changed stuff and run unit tests to see they shouldn't do this).

One great practice is to make unit test for every easy-to-reproduct bug, check before you fix the bug that it fails, fix the bug, and commit both test and the fix in one commit.

Some comments can be also moved to commit messages instead - <USER2> comments that explain why something was changed - you can always blame code and see relevant commit messages, and if the code changes blame won't show commit messages for the lines that aren't there. Comments may be still there after a change that made them misleading.

</comment></comment><comment><USER8> I dislike the last example he gives, even though the reason may be a decent one. Having Doc Comments in Java, for example, is great because Eclipse (and other IDEs) will actually explain to you what a function does when it does code completion and the format for those comments looks exactly like that example.

Overall, there are some very good points expressed in the article. I feel like the fact that new programmers are taught to comment a lot is good (completely uncommented code is often horrid, and let's be honest, new programmers often won't write good code). Perhaps there should be a stage later on (and maybe there is) where programmers with more experience are taught that they should actually avoid comments in general and just write good code (with the exception of doc comments, as I mentioned above).

</comment><comment><USER9> The example given as reason #5 just goes to highlight the original author's ignorance.

      /**
      *
      * @param title The title of the CD
      * @param author The author of the CD
      * @param tracks The number of tracks on the CD
      * @param durationInMinutes The duration of the CD in minutes
      */

Is a format used for tooling support, it's NOT "just a style".

Java & C# both provide format for XML comments, which are then used to generate API documentation and to improve auto-complete.

With these comments, a user of the function doesn't need to read through the source code to understand what it does.

A quick google shows that these tools exist for Javascript:

[http://stackoverflow.com/questions/9263005/javascript- docume...](http://stackoverflow.com/questions/9263005/javascript- documentation-generation)

[http://yui.github.io/yuidoc/](http://yui.github.io/yuidoc/)

I'm sure that the fulltime javascripters here could post better examples and tooling support..

<comment><USER10> The comment merely duplicates information already present in the function signature.

        public void addCD(String title, String author, int tracks, int durationInMinutes)

It's uninteresting and superfluous. Just like virtually all other Javadoc- style comments I've ever seen.

<comment><USER11> The title of the author, or the title of the CD? Or perhaps it's a track title?

<comment><USER10> If I encountered anyone actually calling that function and seriously wondering what "title" could refer to, my reaction would be to call an ambulance, because they're clearly in the midst of a stroke.

Comments do not exist to explain basic everyday concepts, nor basic linguistic skills.

You might as well ask "what's a CD?".

<comment><USER12> You assume "addCD" actually adds a CD to, say, a music library, rather than being a butchery of "addToCD". This might be unlikely in Java, but if this were C89 (where no function has a containing class and where no parameter based overloading is possible), I'd be calling you the ambulance if you weren't seriously wondering whether "CD" refers to what's being added to, or what's being added.

<comment><USER10> Bad names are bad code, and comments are not an excuse for bad code.

There's also no reason to believe someone with byzantine naming practices is going to be any better at documentation anyway.

And why would a function for adding _to_ a CD have an integer parameter named "tracks"? (If your next argument is "maybe it's for the track number"... Bad name! Bad code!)

Finally, context is important, and considering a single function in isolation and thinking up all the ways in which it _might_ be ambiguous (though I've yet to see anyone identify a plausible way in which this one could possibly be) is ridiculous. In all likelihood, the behavior of a function is even more obvious in the overall context of the system/API it's part of.

<comment><USER12> And I don't meant to suggest papering over bad naming conventions with comments. You're preaching to the choir there.

What I do mean to suggest is that while in any half decent codebase, addCD _should_ be unambiguous, someone thinking title is ambiguous isn't having a stroke -- at worst they're being incredibly jaded. API design is nontrivial, people make mistakes in the trivial cases distressingly often (due to laziness, lack of familiarity, wildly different backgrounds, or any number of other reasons), and relying on context too much has it's own problems anyways.

For example: We're missing it in the very snippet we're discussing. There's no class shown. You're filling in the blanks with reasonable code. I've seen far too much unreasonable code to dismiss it when talking coding styles, and even reasonable code is only a botched refactoring or two away from being unreasonable.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Comments are often a code smell. You should always be thinking "how are people going to figure out how to use or update this code effectively?" And when the response is to add a comment you should first pause and then consider alternatives such as: renaming variables/methods or extracting code/conditions into well-named methods. After you've expended the effort to make the code easier to understand and more "self-documenting" then go back for another pass and ask yourself the same questions, and write comments appropriately.

Generally the only comments you'll have left are API level info and documentation of "intent". Explain the inputs and outputs and their formats of every public method (especially for library code) unless it's mindbogglingly obvious through naming.

One of the most important other questions you should ask yourself when looking at code is how easy it would be for the comments to disagree with the code itself. That's another code smell, you should minimize the opportunities for that and make it as easy as possible to keep things in sync, keep the verbosity at an appropriate level. When I look at examples of my own code that I think are well documented I see some examples with hardly any comments and some where the comments are much longer than the method bodies. Just like everything else, documentation and commenting are judgment calls, don't just try to conform to a rule, use your knowledge and experience and keep reviewing your code for readability (and code you review for others as well, of course).

</comment><comment><USER14> Pardon the virulence, but this is idiotic advice. Or at the very least, an idiotic generalization.

Sure, comments that tell what a single line of code do are not very useful. They are verbose.

But you definetely _should_ comment on your architecture. What is the role of this class? How does it interact with other classes? Paint me a small picture that helps me quickly grok your software.

Functions/methods also, should be commented: are there inputs that are invalid? Should a particular relation between the inputs be respected? To understand a piece of code, I do _not_ want to read every other piece of code it calls into. A few English sentences are definitely much help. If you use an IDE and a statically typed language, you can even display that by hovering over the function name.

Developers don't need this kind of encouragement. I have never been bothered by excess comments when reading code (at worst a few inaccuracies have crept in), but I almost always wish for more comments and documentation in general.

</comment><comment><USER15> > _Comments are not testable /verifiable_

Although not strictly comments (rather, docstrings, which have a similar purpose), Python's doctest[1] allows you to write code in your docstrings and then test them for correctness.

[1] [http://docs.python.org/2/library/doctest.html](http://docs.python.org/2/library/doctest.html)

<comment><USER16> It works only in python, I think. At time, where is the best practice when testing in python ? Doctests or unittest ?

</comment></comment><comment><USER17> Good grief. SOME NUMBER blah blah RELIGIOUS ISSUE.

So I have trouble with any article that starts with SOME NUMBER because that's about as lazy as starting with a definition. It's bad discourse.

And I don't understand how RELIGIOUS ISSUE belongs on HN. In this case it's comments, but it could as easily have been favorite language, editor, or any general dogma.

Those are my "2 reasons to avoid the contentious but vapid article".

<comment><USER18> These sort of articles are definitely the worst part of HN. Take some common practice, invent dumb rules against it just to be contrarian, publish and get people fighting against each other.

<comment><USER16> It isn't to be contrarian. Discuss things like that, make new good practices born. It was the same with goto, singleton pattern and other things.

</comment></comment></comment><comment><USER19> > _@param title_

> _@param author_

> _@param tracks_

> _@param durationInMinutes_

May the params be null (title, author) or <= 0 (tracks, durationInMinutes)? What happens in such cases? Is an Exception thrown? Which? What exactly is the result of addCD()? Which related methods are available? ...

Yep, avoid bad comments, provide informative comments!

<comment><USER20> In systems grown over many years and by many developers, comments about such things are nearly worthless, because they can't be trusted. I wouldn't be surprised to see a comment saying "title cannot be null" right above code that explicitly permits null. A comment that lists which exceptions can be thrown is highly suspect, I would probably delete that just to avoid confusion, and make sure that it's obvious from the code instead.

<comment><USER19> > _comments about such things are nearly worthless_

The Java ecosystem lives on such comments. I wouldn't use a Java API without "Javadoc" documentation.

<comment><USER20> I don't endorse this way of developing software. It's profoundly bad -- in a way that comments can't fix.

</comment></comment></comment></comment><comment><USER21> _When we are writing a comment for a function we are repeating ourselves. We are transgressing the DRY (Don't Repeat Yourself) principle._

Agreed, but this only applies when code is meant to change. It has been pointed out (perhaps by Knuth on Literate Programming) that a good way of explaining something to another person is to do it in two different ways (comment and code), which is practical when code does not change.

The follow-up question is why does our code have to change so much. We use toolboxes (IDEs, compilers, version control) optimised for change management. Would it be possible to treat our code like the Clojure/Datomic crowd treat immutable data structures?

<comment><USER22> It has to change because our code is not the ends itself, but only a means to an end. The end itself is using rooted in human psychology - 'ease of use', 'problem solving', etc. This means that the end itself cannot ever be truly completed as it's about as close to a random process as you can find. This means that the code itself will have to continue to change to follow the random process it is trying to arrive at.

Simply: the environment the code is executed in changes, and so the code must change.

</comment></comment><comment><USER23> Here is the exact opposite point of view, that we need _massively_ more comments to the point where they are not merely comments, but comprehensive, prose discussion interwoven with code. As far as arguments to change the status quo go, I think Knuth's has more to recommend it: [http://www-cs- faculty.stanford.edu/~uno/lp.html](http://www-cs- faculty.stanford.edu/~uno/lp.html)

<comment><USER24> After looking at the source code for Tex, I have decided literate programming is a massive failure.

<comment><USER23> I think TeX in particular somewhat suffers from being written in a language few people know (a Pascal variant Knuth invented) and to 70s architectural standards (fixed buffers for everything, etc.).

Better recent examples:

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

[http://www.haskell.org/haskellwiki/Haskore](http://www.haskell.org/haskellwiki/Haskore)

and just about anything in [http://coffeescript.org/#literate](http://coffeescript.org/#literate)

</comment></comment></comment><comment><USER25> Comments that could have been mechanically manufactured from code "@param databaseWithFruit a database, with fruit" are indeed dumb. I omit them.

That said, people who modify code without seeing if the adjacent comments still make sense are bad. If something is wrong on your screen, you should notice it and fix it.

</comment><comment><USER26> It could be a hassle to keep comments as up to the date as the code they are meant to accompany, that I totally agree but I would argue with these main 2 reasons on why I prefer to comment as much as possible and update them as often as the code: 1) I am fairly certain that the next maintainer of my code would appreciate a well-written piece of code with proper explanation for especially clever portions or just plainly horrifying practices done for a production bug fix which must go out in minutes and the poor soul responsible for that already forgot about fixing the fix :).

2) Someone may remember every lines of code that they wrote in the past 3 months or so but I would not. I tend to forget code rather quickly so my comments serve as a memento to my future self, meaning I would do well to keep my comments up to date.

</comment><comment><USER27> Bad code has few comments. Good code has many comments. The best code has few comments.

<comment><USER16> Totally agree.

</comment></comment><comment><USER28> I used to hold the same opinion, that code should be expressive, so we shouldn't need comments. However, I've found this to be false for a number of reasons:

1) Proper comments allow you to explain the reasoning behind the code, not just what the code does.

Excellent examples of this sort of commenting include ZFS's code[1] and Linux's SLAB memory manager[2].

This is important because a lot of the time, there are minutae that are extremely important to get right, but it's not immediately obvious _why_ you did it that way. For instance, maybe there is a special reason fine-grained locking was implemented a certain way, perhaps there is a reason this method of IPC was chosen, etc. A lot of thought goes into properly architectured code, and without comments, future contributors have no idea why this works.

System architecture details become particularly important when you delve into more difficult problems. For instance, I've seen the following snippet of VHDL code:

      process(clock)
        if(rising_edge(clock)) then
          delayed_signal <= signal;
        end if
      end process

This piece of code delays the signal by one clock cycle, but a lot of time in poorly documented code, there's no explanation why! Maybe there's another signal that needed to be synchronized with this one, so you need another clock cycle. Maybe this signal needed to be re-synchronized into the clock domain and one DFF does the trick. Without appropriate commenting, you'll never know the true purpose of this code, so if you change something around it, there's a higher likelihood that everything will break.

2) Proper comments also explain what _isn 't_ there: the things that have failed, and why you probably shouldn't try them again.

The OP mentions that sometimes you spend a lot of time optimizing a block of code, only to find out that it doesn't come out better in the long run. Why isn't it commented? By commenting "oh, we tried this other topology, it didn't end up being right for this scenario because of reasons x, y, and z", you can save a lot of grief for somebody down the road.

You might say that the source history should show this, but how often do you look at previous commits when coding? I find that most people ignore the tree until it's time to merge, and even if previous attempts _are_ documented, their reason for removal is often abbreviated in the commit message: "wasn't fast enough"/"didn't work as expected".

You can see the result of this on a large scale, if you take a look at the file-drawer effect[3]. If you dump a huge amount of time/money into projects, and then don't let other people know what happened because it didn't turn out well, people are likely to repeat the same mistakes you made.

3) Proper comments make it easier.

I'll admit it: I'm lazy. If I don't write the comments that specify points 1/2 immediately, as I'm refactoring the code, I'll lose my train of thought. Even if I manage to get away and dump the ideas in another file, they probably won't be as clear as if I wrote it right then and there, with the source code to reinforce my arguments.

The time to context-switch between writing code and writing documentation should be as small as possible, so I'm a big fan of systems like Haddock[4] which allow you to write code and documentation and parse-out the docs into HTML for later browsing.

Ultimately, the code and your comments serve as knowledge for the future, so don't let your time go to waste: document what you did, why you did it, and why maybe other things didn't didn't work.

[1] [https://github.com/illumos/illumos- gate/blob/master/usr/src/...](https://github.com/illumos/illumos- gate/blob/master/usr/src/uts/common/fs/zfs/zio_checksum.c)

[2] [http://lxr.free-electrons.com/source/mm/slab.c](http://lxr.free- electrons.com/source/mm/slab.c)

[3] [http://skepdic.com/filedrawer.html](http://skepdic.com/filedrawer.html)

[4] [http://www.haskell.org/haddock/](http://www.haskell.org/haddock/)

Example of great Haddock docs: [http://hackage.haskell.org/packages/archive/snap/0.12.0/doc/...](http://hackage.haskell.org/packages/archive/snap/0.12.0/doc/html/Snap- Snaplet.html)

 _edit: formatting_

<comment><USER29>
      even if previous attempts are documented, their reason for removal is often abbreviated in the commit message: "wasn't fast enough"/"didn't work as expected".

If we're instructing people to write useful comments, why can't we equally instruct people to write useful commit messages?

<comment><USER28> The best comments are surrounded by pertinent code. I don't think I've seen a workflow yet that allows you to attach specific portions of commit messages to specific code passages, so it's a little difficult to ensure that what you're saying is clear.

It's also not guaranteed to stay with the lifetime of the file. This is often a problem if you're downstream; if you just download the source code, it's a lot of steps to go back and get to the source repo and look at all the commit messages.

Additionally, the commit log will be only be a log of deltas, and doesn't give you a picture of what's finally there. With well-written comments, you should get a good idea since they're kept up to date (I hope!) and present a unified picture of what's going on.

<comment><USER7> > Additionally, the commit log will be only be a log of deltas, and doesn't > give you a picture of what's finally there. With well-written comments, you > should get a good idea since they're kept up to date (I hope!) and present a > unified picture of what's going on.

Actually deltas are very useful. Blameing code is often very helpful, even if commit messages aren't that great, because you can see which lines were there from the start, and which lines changed together. That alone is often enough to deduce if something you see in code is stupid error, or sth that was intended.

In my company every commit has JIRA task number attached, so for EVERY line of source you can easily find why it's there from the big perspective. That's very valuable, and it's much easier to maintain commit messages than to update comments.

Of course some comments are still needed.,

</comment></comment></comment></comment><comment><USER30> API docs are not comments. If Java needs them, they should be maintained and up-to-date. Some languages don't need them to such a degree (type signatures in Haskell are damn expressive).

Higher level comments ("comments" is a suitable word here, it's not something your attach just for the sake of it) is a must for a code that does anything remotely complicated/interesting.

</comment><comment><USER31> This is nonsense. I can't count how many times I've come back to some code and had to read a comment to understand _why_ a decision was made or looked over another's work and found a comment to explain it all. The idea that code should be so awesomely _pure_ that it explains itself is laughable in my experience.

</comment><comment><USER32> In fairness, a good article with actionable, specific observations (and the inline with my vague recollection of recent consensus). Still, posts with titles like this make me think:

\- As a rule of thumb, rules of thumb are useful in many common situations.

\- As another rule of thumb, titles which are stated in fairly absolute terms generate more interest.

</comment><comment><USER33> Lets see.

I think most people agrees on the bad of over-commenting or wrong-commenting.

But I would like to review your reasons:

"1\. They tend to encourage bad code."

I don't think so. I've seen great comments, even if it's not a cool topic.

There is some factors which may change the quality of a comment, a lot of them are cosmetics, but there are other like: the capacity of the programer to empathise with future maintainers/users and think on them, the capacity of the programer to redact good comments and think interesting messages to people following the code, the committing level of the programer with the future of the project, etc...

But I don't see how comments encourage bad code. People can make bad code, and bad comments, and good code, and good comments.

"2\. We spend more time writing and maintaining them."

If a comment is making you loose time, it's a wrong comment. All you use programming is to save time.

The reasons you give there, point more to poor designs or inconsistent project managements.

"3\. Comments are not testable/verifiable."

All is testable, hint: search in metacpan for: test pod

You can introduce deprecation policies, in your code, in your tests and... in your comments. Check for validity, spell, dead-links, text matchings, etc... I don't know why you assert you cannot.

"4\. They are less reliable than the documented code"

That points to wrong comments.

If a comment is wrong, is wrong, the same as if a line of code is wrong, it, is, wrong.

If a comment is in the code, should be because it helps to the usage (typically the maintenance) of the code.

In the case of libraries (typical usage of the code: reuse), it's usual nowadays that what you find in comments, is the metadata needed to build the library documentation.

I think both cases of comments, internal maintenance and public "face" of the code, imho should be always as reliable as the code lines if we want to treat seriously a project. I know it's not, but that's just lazy/ego/copy people.

"5\. Some comment styles can fill a lot of screen space"

That's not a reason to not use them. If they fill screen space with _useful_ information.

Your programming oriented text editors, eventually can (un)collapse comments.

So, that is my review to your reasons.

I could have write:

0\. On bash, long comments slow down execution (measurable at big scale).

1\. Wen I code for myself, I don't comment.

2\. As we now there is not going to be time to document this project, we just "do it".

That are valid reasons for me.

Best regards.</comment>


Congressman suggests poor Americans should give up iPhones for health care - <AUTHOR> http://www.theverge.com/2017/3/7/14841736/chaffetz-says-americans-must-pick-between-iphones-and-healthcare <comment><USER2> theverge.com's clickbait title drops "new" ("a _new_ iPhone") from the quote.

Anyway, Obama himself made a similar statement, only more broad in scope (give up cable TV and/or cellphone _in general_ ):

To quote Obama: "Knowing you can offer your family the security of health care -- that's priceless. Now you can do it for the cost of your cable bill. Probably less than your cellphone bill. (Laughter and applause.)"[1]

[1] [https://obamawhitehouse.archives.gov/the-press- office/2013/0...](https://obamawhitehouse.archives.gov/the-press- office/2013/09/26/remarks-president-affordable-care-act)</comment>


USB Power Supply/Charger Test - <AUTHOR> https://lygte-info.dk/info/usbPowerSupplyTest%20UK.html <comment><USER2> Summary: most no-name USB chargers are shite. They don't put out the rated amperage, and even if they do it's so noisy that you won't want plug anything into it that you care about. Oh, and a lot of them stand a non-trivial chance of running mains voltage where it shouldn't be.

The author did find three good ones, though. I think today's task is to dig through that box of USB chargers and throw 2/3 of them away.

<comment><USER3> That may be the summary of the linked page, but Henrik, the writer, has been testing voltmeters, battery and USB chargers for years. He's crazy methodical about it as well. I only buy chargers that he or Benson Leung tested.</comment></comment>


Brainstorming Will Kill Your Team's Creativity - <AUTHOR> https://growthhackers.com/brainstorming-will-kill-your-teams-creativity-3-alternatives-to-spark-fresh-ideas Brainstorming hides two major problems:<p>1. No-one is clear on the structure of the session and it becomes a waste of time, rather than a way to stimulate ideas 2. Brainstorming does not prepare to the next steps: prototyping, testing, and implementing <comment><AUTHOR> Brainstorming hides two major problems:

1\. No-one is clear on the structure of the session and it becomes a waste of time, rather than a way to stimulate ideas 2\. Brainstorming does not prepare to the next steps: prototyping, testing, and implementing

</comment><comment><USER2> Great article from @guerric - a nice take on creativity and innovation for teams!</comment>


Semantically speaking: Why CSS frameworks make sense - <AUTHOR> http://blog.newint.org/tech/2009/04/08/semantically-speaking/

<comment><USER2> _Many of the leading minds of the "semantic Web" movement, like Jeffrey Zeldman and Andy Clarke ..._

Jeffrey Zeldman and Andy Clarke are _phenomenal_ designers in favor of semantic HTML elements, but they have absolutely nothing to do with "the Semantic Web."

</comment><comment><USER3> They do not. CSS is for presentation, and presentation usually differs from site to site. That means that you either have to tweak a lot, in which case using framework does not make much sense, or you have a lot of unused code in your CSS which makes the "maintainability" point moot.

In my view CSS frameworks are the crutch for CSS challenged (as WYSIWYG HTML editors are for code challenged) and should be avoided.

I also have no idea how the word "Semantically" made its way to the title. So far from I have seen CSS frameworks add very little to the semantics, take more away, and are very likely to induce an acute case of clssitis to you HTML code. Not to mention "CSS reset" which I think was stupid idea from the very beginning.

<comment><USER4> Frameworks abstract core functionality. How much innovation do you need in making a 2-column layout?

<comment><USER5> This is true; not every little catalog site is cutting-edge design. (From experience, a lot of small companies certainly won't pay for the cutting edge.)

<comment><USER3> Who talks about cutting edge? The simpler you design is, the more overhead you get from using a framework.

<comment><USER5> You'll have to explain what you mean by "overhead" in this context. Time to build? Bandwidth? If the former, certainly wrong. If the latter, whether it's meaningful overhead depends on the framework.

Also, unpack "simple".

</comment></comment></comment></comment></comment><comment><USER6> _I find it hard to imagine that any experienced Web producer these days wouldn't have some "sensible defaults," or templates, to work from in Illustrator, Photoshop, or – more precisely – for developing HTML and CSS._

Then he must have a weak imagination.

<comment><USER5> The mistake of conflating "experienced" with "clueful". :)

There's nothing like going to visit your client and realizing that their longtime programmer built the application that processes the billing info you're sending them in I-shit-you-not _GW-BASIC_...

<comment><USER6> Actually, I meant that you can do very good work without defaults, as most designs require very different layout approaches. It takes far less time to build a layout from scratch than to override existing code. I notice that, for most developers, this results in a torrent of "!important"s.

<comment><USER5> You can, but you can do it more quickly with defaults if you're _not_ doing a number of very different layouts. Not all web producers are trained designers.

<comment><USER6> I've always found pre-written CSS to get in my way, but then again, CSS is practically my first language (with clean, semantic HTML).</comment></comment></comment></comment></comment>


Fossil: A decentralized version control, bug tracking, and wiki software - <AUTHOR> https://www.fossil-scm.org/ <comment><USER2> Many previous threads:

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=comments%3E2%20Fossil%20scm&sort=byDate&type=story)

</comment><comment><USER3> How is it decentralized, I did not find that out from the homepage.

<comment><USER4> By the looks of it, the same way git is decentralized.

You can hook up your local to a central server or you can choose not to.</comment></comment>