How the Anti-Vaccine Community Is Responding to Covid-19 - <AUTHOR> https://undark.org/2020/04/16/anti-vaccine-covid-19/ <comment><USER2> There are a couple of other groups I would like to be interviewed as well.

\- Economists who have bought into the crowding out theory. Are they consistent and still oppose government spending? [1]

\- People/corporations who have lobbied for and taken advantage of all kinds of loopholes in taxation as to avoid paying taxes and who think taxation is theft, and are now expecting government to pay them out from this mess. [2]

\- The ones that vouch for strong IP and patent protection. Do they propose to not share any information between research groups and give them even longer patents to incentivize better innovation?

[1] [https://www.investopedia.com/terms/c/crowdingouteffect.asp](https://www.investopedia.com/terms/c/crowdingouteffect.asp) [2] I cite no examples. I am astonished if there is none, though.

<comment><USER3> Your three examples run in a similar vein: individual rights vs the role of government. I think many of those you would see as holding contradictory views would say that government intervention in these areas actually fall under the domain of something they believe is one of the few justifiable functions of government: defense. Only, it's not a war this time.

<comment><USER4> In addition, you can be against something but believe that as long as it's being done it should be done right, or to your advantage.

</comment></comment></comment><comment><USER5> One fair point "Floyd said, "are talking about washing your hands, but why aren't they talking about things you can do to boost your immune system like vitamin D?"

Given that in some countries in the northern hemisphere we are seeing a disproportionate number of ethnic minorities deaths from this, the aspect that vitamin D or lack of, does seem to be a factor and certainly one in which such advice would do more good than any harm I can think of beyond stock pilers effect. Though lack of vitamin D is not something that is the prevail of any pigment, just more likely and given the data, I'm supprised that such advice is not more vocalised. Though for many it will be basic health knowledge akin to basic first aid, that many is not all.

For reference [https://www.ncbi.nlm.nih.gov/pubmed/1211435](https://www.ncbi.nlm.nih.gov/pubmed/1211435) [https://news.sky.com/story/coronavirus-review-to-be- launched...](https://news.sky.com/story/coronavirus-review-to-be-launched- into-why-ethnic-minorities-worst-hit-by-covid-19-11974116)

<comment><USER6> I don't find this evidence convincing. Your first link just lists health benefits of vitamin D, and discusses how different ethnicities absorb it differently, which I don't want to dispute. The second link just states that minority populations are more at risk without making any link to vitamin D.

This is, at best, a correlation (in fact, I'm not even sure the data does go that far) and implies no causal mechanism.

Sure, if vitamin D is healthy, which it probably is, do go outside and get some more (though do beware of sunburns). As it stands right now, I haven't heard of any claims linking this to Coronavirus yet, though.

What's more problematic is the claim that you should "get vitamin D to boost your immune system". Even if that worked (I don't believe it does), you don't want to necessarily boost it because that might lead to bad consequences. [1] In fact, people have died from covid19 in part due to the immune system overreacting. [2]

[1] [https://www.health.harvard.edu/healthy-eating/what-can- you-d...](https://www.health.harvard.edu/healthy-eating/what-can-you-do-to- improve-your-immune-system)

[2] [https://www.newscientist.com/term/cytokine- storm/](https://www.newscientist.com/term/cytokine-storm/)

<comment><USER5> Sure it's a correlation, in much the same way SAD syndrome more prevalent the further North you go. But some things may well have better papers or links, I was just pointing out what seems to be logical - however - watch this please: [https://www.youtube.com/watch?v=GCSXNGc7pfs](https://www.youtube.com/watch?v=GCSXNGc7pfs)

A Doctor who has been doing a fair and most excellent overview with a critical mind upon this whole COVID-19 from early on and focused upon evidence. He covers things in a way that may hold more gravitas to that aspect.

One of the many useful reference links from that video that I think covers all this fair and square.

[https://www.ncbi.nlm.nih.gov/pubmed/32252338](https://www.ncbi.nlm.nih.gov/pubmed/32252338)

<comment><USER6> Thank you for the link. I was not aware of any such suspected connection, now I know better.

The abstract concludes that " randomized controlled trials and large population studies should be conducted to evaluate these recommendations". This seems to indicate that the finding is still quite preliminary (the study is rather new), so in that light it doesn't surprise me that it isn't a general recommendation yet.

</comment></comment></comment></comment><comment><USER7> In one word: predictably.

<comment><USER8> I don't usually award glib posts with upvotes but I did for you.

I think you capture the fundamental issue: who cares what they think? Objectively, we should care less about what they think about covid-19 than _any other group_ because of their track record of scientific illiteracy on the precise subject under discussion.

Aside from anthropological and related disease mitigation strategies, what anti-vax people think about this is not worth a second of attention. The odds favor that objectively ignorant people will continue to make poor assessments based on facts.

edit: thankfully it is flagged.

</comment></comment><comment><USER9> It's amazing how the avalanche of knowledge offered by the internet does nothing to counter even the tiniest seed of doubt planted in these people's minds. Undoing the brainwashing is going to be one of the major challenges of our time.

<comment><USER10> It's difficult to mandate self-evolution through education. Most people just binge-watch vapid fiction after vapid fiction.

</comment></comment><comment><USER11> Often overlooked in commentary on anti-vaxxers, and by the anti-vaxxers themselves, is this:

Freeloading

The anti-vaxxers are freeloading on the herd immunity created and maintained by the smart people.

That herd immunity prevents the regular epidemics & pandemics common before vaccines, when families often had 10 children to see a few survive to adulthood.

There is plenty deliberate ignorance of history, Dunning-Kruger Syndrome, and confirmation bias in their 'arguments', but the root seems to be a (likely) unconscious willingness to freeload on the benefits provided by others.

This is unfortunately coupled with a deliberate ignorance of and/or willingness to deliberately endanger the small subset of people with bona-fide medical conditions that contraindicate vaccination, and so genuinely rely on the herd immunity to survive.

It is far past time to coddle this deliberate ignorance and freeloading. If anti-vaxxers want to stay that way, fine, but they need to choose and not be permitted poison the well - vaccination needs to be required for alk access to public buildings, schools, transport, etc.

<comment><USER12> >That herd immunity prevents the regular epidemics & pandemics common before vaccines

Like Scarlet fever?

<comment><USER11> No.

Scarlet Fever is bacterial, not viral, and are fought by different parts of the body's immune system.

Few if any attempts at creating vaccines against bacteria are successful, whereas vaccines against viruses are typically more successful, although viruses such as Influenza can evolve new versions frequently, requiring new vaccine versions.

</comment></comment></comment><comment><USER10> Vaccines are an absolutely revolutionary technology.

That said, mixing profit with essential medical technology is a recipe for failure.

The first way to make something more profitable is to cut costs.

What corners do these corps cut to up their margins? And how does that decrease health outcomes for some percent of the population?

The bottom-line is that no for-profit corp can be trusted with your health.

Vaccines must be developed and distributed by the government for the benefit of all human beings. Sure, we need to minimize cost but not to enrich the select few wealthy enough to be investors in the first place. If there is a surplus (profit), that money gets invested right back into R&D. No pharma-bros needed or wanted.

I am pro-vaccine and anti-for-profit-corps.

Yes, my kids are vaxed for measles and a few others, but, no, I did not go in for the entire schedule, which is frankly insane. Just compare our vax schedule in America to what they do in Europe. It's maybe 2x. And, yes, we will all get a Covid vax as soon as it is available.

But, remember, selling three of something (ETA: instead of two) that has a little margin gives you a 50% increase in profit. B-School types don't care that that third dose might be too much; besides, they can find/fund researchers to goal-seek safety for that extra 50%.

And, yes, vax is big business, just not as big as other meds.

And, yes, anti-vaxxers piss me off, too, the fucking anti-science morons. But people who trust for-profit corps with their health are stupid marks.

<comment><USER13> There's something very wrong in your message, practically the same bias as the vaccine "denialists".

First you establish your order of trust as:

1\. Government

2\. For-profit-corporations

Then you acknowledge that your actual practisting order of trust is:

1\. Your gut (why is "the entire schedule frankly insane"?)

2\. European Governments

3\. Your American Government

The later ranking is not justified at all by your early statements.

If you trust governments better than corporations as a matter of choice, fine. It may actually be a sensible choice in this bullshit world. If you trust your gut more than governments fine, it may also be a sensible choice, even.

However, be consistent, and realize your biases.

<comment><USER14> I'm in the same boat as OP. The entire childhood vaccination schedule is insane because it lacks longitudinal studies demonstrating effectiveness and safety.

Why is varicella in the schedule? The plague upon our house that is chicken pox will hopefully be annihilated one day, only to reappear in a much more painful form later in life as shingles because you need a constant re-up of the varicella vaccine to keep it at bay. What the actual fuck is going on here and who controls the schedule?

<comment><USER10> Regulatory capture and goal-seeking driven by profit-seeking B-school acolytes.

</comment></comment></comment></comment><comment><USER15> This planet will always have people who are always not happy with something. And don't get me wrong it positive. Even stupid alarming vaccine campaigns caused better results evaluation. And since this is a liberal society where you can't force people to stay at home even if it will cause death, oh well... this is the only way, someone should die without vaccine first.

<comment><USER16> > _Even stupid alarming vaccine campaigns caused better results evaluation._

What does this mean? It doesn't make sense in English, so could you please elaborate?

> _someone should die without vaccine_

This is a fundamental misunderstanding of why anti-vaxxers are a problem.

They don't just kill themselves. They break herd immunity and put other people at risk. They have already caused outbreaks that have killed adults and children who _did_ get their vaccines.

<comment><USER4> I think they mean, the science is more rigorous because they have to deal with anti-vaxxers.

</comment></comment></comment><comment><USER17> This was an interesting read. The style of presentation is quite unique. The overall tone of the article is in favour of vaccination, but it nevertheless provides many exact quotes of antivaxxers and other conspiracy theorists, usually without trying to directly refute what they say.

It's also well investigated, in the sense that caveats to the usual responses to antivaxxers are included.

I personally felt like I came away with a better understanding of what the conspiracy theorists are actually thinking/claiming. I learned some interesting facts about various vaccination campaigns, and overall felt like I came away with more information than I came to the article with.

I'm interested to see where this style of journalism leads.

</comment><comment><USER18> Here is the pattern:

1) Establish a false dichotomy ("All vaccines are good, all vaccines are bad")

2) Come up with a pithy slur for the other side ("Antivaxx")

3) Emphasize the looniest people on the other side, ignore and hide the reasonable people on the other side.

4) Use this slur to browbeat moderates, the skeptical, the unsure and the open minded into silence.

It's very effective.

<comment><USER6> The problem is that 1) is just a strawman no medical expert agrees to.

<comment><USER10> We're not talking about medical experts here.

<comment><USER6> Yes. The article clearly discusses how select individuals disagree with majority medical opinion with basically zero evidence. So the opinion of medical experts matters.

<comment><USER10> That's not who the OP was talking about, not-Einstein. He's talking about the idiots who idiotically polarize needed conversations that need nuance. _a-hem_

</comment></comment></comment></comment></comment><comment><USER19> I can't say as conflating antivaxxers with a pediatrician that recommends a delayed/modified vaccine schedule is exactly productive. Delayed/modified schedule isn't to blame for measles. Pretty disingenuous, IMO.

For those who don't know, there is a camp of people who believe that we're getting vaccinations at way too fast a schedule. Yes, this includes doctors, like the aforementioned pediatrician.

<comment><USER20> > I can't say as conflating antivaxxers with a pediatrician that recommends a > delayed/modified vaccine schedule is exactly productive. Delayed/modified > schedule isn't to blame for measles. Pretty disingenuous, IMO.

> For those who don't know, there is a camp of people who believe that we're > getting vaccinations at way too fast a schedule. Yes, this includes doctors, > like the aforementioned pediatrician.

It is not only "anti-liberal" to shout people down, but it is anti-science to ignore claims on findings and this is how I find the "anti-vaxxer" term to be used.

I can't find the article right now, but I strongly encourage people to be more cautious about throwing the stupid terms around as some people are rather more nuanced.

I am not defending the following claim, but among other claims is one that states a popularly cited measles outbreak occurred with 95% of the people catching having been immunized. The claim is that the immunizations are no longer effective. Again, I am not trying to support the claim, but simply labeling "anti-vaxxer" is not the way to address such claims and will attract an audience who will have no way to counter such claims because all opposition is engaged in schoolyard name-calling activities.

EDIT:

It is astounding to me that the commenters of, at least this article, are unable to distinguish my claim from claims of people discussed in the article.

<comment><USER21> > but among other claims is one that states a popularly cited measles outbreak > occurred with 95% of the people catching having been immunized

Source? Regardless, the large majority of aggregate cases of measles in the United States are among people who aren't vaccinated, which is a massive, massive over-representation and suggests that the measles vaccine is effective, regardless of specific anomalous cases.

I find this take of "being fair" to "nuanced" views quite common, but when I patiently let the whole anti-vax view be laid out, it is generally not particularly coherent nor well-sourced. I think stigma can be an effective way to change beliefs, because people can pretend they never held the belief in the first place. When you have someone lay out their whole argument, they often become more entrenched.

My source: [https://www.cdc.gov/measles/cases- outbreaks.html](https://www.cdc.gov/measles/cases-outbreaks.html)

<comment><USER22> For what it's worth, I'm 34 and had to get the MMR vaccine again last year because blood titers showed that I was no longer producing meaningful antibodies for rubella. Given that the average person has been vaccinated against over a dozen diseases, odds are good that at least one of them has worn off and needs to be re-upped by now.

So that's another reason the herd immunity is so important: If enough people opt out of just getting a simple shot, then now everyone else has to go through the much larger burden of periodic retesting and re-vaccining for them to be safe.

<comment><USER21> Yep, plus the fact that certain vaccines aren't effective in every single person but it is hard to know apriori who those people are.

</comment></comment></comment></comment></comment><comment><USER23> Opinion: Forcing someone else to take a vaccine, if they don't want to, or forcing someone else NOT to take a vaccine, if they do -- is no different than forcing a woman to take an abortion if she doesn't want it, or forcing a woman NOT to take an abortion, if she does want it.

It's no different than forcing a man to join the Military if he doesn't want to join, or forcing the man NOT to join the Military, if he does want to join.

A future Constitution will explicitly support the right to be medicated/vaccinated if one wishes to be, while conversely supporting the right NOT to be medicated/vaccinated, if one does not.

Our current Constitution supports these rights, implicitly, via the 9th Amendment:

"The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people."

(Although, in an increasingly legislative and legalistic society, those rights may have to be asserted, asserted repeatedly, asserted to multiple people who are not aware of them, and asserted hard...)

<comment><USER24> Unvaccinated people put the immuno-compromised, newborns and the elderly at risk. The state doesn't have the right to force you to vaccinate, but they do have the right to force you into quarantine if you're not.

<comment><USER23> I've studied U.S. Law for close to 10 years.

First, please define what you mean by "state".

Are we talking Federal Government, or one or more of the 50 U.S. States?

Next, please explain to me why you think that entity has the power to do that...

Also, please explain to me your understanding of "Consent Of The Governed". What does that term mean, where does that originate from, how does that apply to to the U.S. Federal and State (and also local) governments?

Think of this as a test of your understanding of U.S. Law...</comment></comment></comment>


Drowsiness detection with OpenCV - happy-go-lucky http://www.pyimagesearch.com/2017/05/08/drowsiness-detection-opencv/ <comment><AUTHOR> Is it enough to check if the eyes are closing for long enough? I fear that there is a "pre-sleep" status, where one is unable to drive but not with his eyes closed.

When sleepy and driving I blink more, I feel loss of motor skill, and I may give off other hints well in advance of finally closing my eyes.

When I finally close my eyes it is way too late.

To put it bluntly: I fear that checking if the eyes closed for too long is as useful as checking if the airbag has deployed.

<comment><USER2> Agreed, I usually try to keep my eyes open to fool myself that I'm not sleepy. My face is probably limp though.

From what I've seen from recent neural nets I believe it's possible to detect the pre-sleep phase given a training set of faces prior to dozing.

Seems like that would be a hard data set to come by though.

</comment></comment><comment><USER3> For those with curiosity as to practical use, there are commercial products for this, which initially focused on fatigue in truck drivers.

[https://www.seeingmachines.com/industry- applications/automot...](https://www.seeingmachines.com/industry- applications/automotive/) [https://www.youtube.com/watch?v=gvN1elQ8NLY](https://www.youtube.com/watch?v=gvN1elQ8NLY)

These systems often use IR illuminators, as the contrast between pupil and iris is dramatic under IR. The IR can also be boosted to compensate for other light in the cabin. Spectacles are obviously impediments.[1]

Eye tracking is also great for seeing how people use user interfaces, including VR and AR scenes.[2] Cheap custom systems are available too[3], some of which are open source[4].

1- [https://www.diva- portal.org/smash/get/diva2:306465/FULLTEXT0...](https://www.diva- portal.org/smash/get/diva2:306465/FULLTEXT01.pdf) 2- [https://www.youtube.com/watch?v=rrj1F3rHJd0](https://www.youtube.com/watch?v=rrj1F3rHJd0) 3- [http://thume.ca/2016/03/24/eye-tracker-reviews-pupil-labs- to...](http://thume.ca/2016/03/24/eye-tracker-reviews-pupil-labs-tobii-eyex- eye-tribe-tobii-x2-30/) 4- [https://pupil-labs.com/pupil/](https://pupil- labs.com/pupil/)

</comment><comment><USER4> I've wondered before whether something similar could be implemented to help foster focus & "flow", for those of us working at computers.

By which I mean less measuring actual drowsiness, but more "lack of focus" as detected by your facial expression (perhaps also mouse movements + current open app?). This likely wouldn't be a binary thing but rather a more fluid "guide" which notices you're beginning to lose focus and guides you back to your "best next action".

Obviously intrinsic motivation is far more beneficial than external, but still it seems that something like this could be helpful (to me at least).

</comment><comment><USER5> I experimented with something similar using iOS. Let me know if you want the link to the Github repo.

I realized quickly that lighting conditions have a huge impact on the success of eye detection. My dad suggested that reading the steering sensor is another good way to detect drowsiness. I've been meaning to take another look now that I have a wifi OBDII adapter that will work with iOS, but haven't had the time.

</comment><comment><USER6> [https://www.youtube.com/watch?v=NGCRkPrcQkQ](https://www.youtube.com/watch?v=NGCRkPrcQkQ)

Almost 2 years ago! :)

</comment><comment><USER7> Seems like a good tutorial! The example video is shot during daytime, though.

<comment><USER8> Good point. Night time with glasses and reflections could be a mess.

Might actually be easier with a near IR camera and a couple small LEDs for illumination, as I believe the retina is much more reflective in that range.

<comment><USER9> A friend of mine built one of these 5 years ago with an iPhone and on that hardware the darkness problem was insurmountable.</comment></comment></comment>


MIT Moral Machine - <AUTHOR> http://moralmachine.mit.edu/ <comment><USER3> I don't always understand the focus on this. It's not something people are tested on when learning to drive and not something assessed on your driving test.

How should self drive cars react to this? It should be programmed to not get into the situation in the first place. We should be developing systems that continually monitor vehicles for faults - kind of like an on-going MOT - <USER2> can react to the first signs of something going wrong, rather than waiting for a yearly test. This will stop the breaks failing/accelerator stuck situations more often than not.

Should the car plough into the people or the obstacle? Well it should be safe enough to crash and to cause serious harm to the occupants - which is something Tesla have put a lot of work into - and also not accelerate towards points in the road that can change suddenly. Guy stumbling along the side of the road? Drive as if he'll fall into the road at any moment. Road ahead partly blocked? Drive as if the whole road could suddenly get blocked, and so on.

Driving is all about reading the road and being aware of what can change around you, which is what self drive cars can and should be doing better than people.

<comment><USER4> Yeah, I like that this self driving car is advanced enough to know whether or not the person it's about to run over is fit, or a criminal, but it can't work out that it should slow down before running into a concrete barrier in the same lane it is in. (And how does this moral car know so much about the personal lives of the people it's murdering, when I can't even get my car to consistently play music from my phone?)</comment></comment>


Why you absolutely MUST write an API when you write your next app - <AUTHOR> http://blog.angrymonkeys.com.au/why-you-absolutely-must-write-an-api-before-y <comment><USER2> Don't build an app, build an API, then build an app.

This is what we did with our product, a CMS (<http://www.gethifi.com>). We built a very flexible API that has cool things like permissions, relationships and versioning built in. Then we built our app and interface on top of that.

This turned out to have tons of advantages. Our app development went very quickly. It was much easier to do testing. Improvements to the API are now universally available.

On top of all of that, there is an awesome API available for every site on the system!

By inverting the way you think about the API, (build on the API, vs. build an API for an app) you end up with an API that is much more polished as well.

<comment><USER3> First off, hey Joel!

We do the exact same thing at Flickr. Anytime the front-end needs an method to do something, we'll build it in (though it may not always make its way into our public API).

The nice thing is if we change the behavior of an API method inadvertently, we catch it instantly since the site itself reveals the bugs.

<comment><USER2> Wow -- hey Nolan!

We have the same experience (at a much smaller scale!). We can pull down production sites into a VM to see what happens whenever we make an API improvement. It is a great way to catch subtler things too like performance changes.

</comment></comment></comment><comment><USER4> I wish the startupentrepreneurhackerpainter-scene used more precise terms. This kind of titling makes it all seem so damned naïve.

An API, application programming interface, is an interface presented by some means into some kind of an application, possibly itself. A C library, for example, presents an API. Both external (public) and internal (private) APIs may exist, as well as intermediate forms.

An app, application, is a software program.

Here the advice is of a unified (public + private) web-based presumably RESTish API into a web application right from the start.

Contrary to the author's experience (or nomenclature), it seems to me that engineers typically do ensure their application has an API.

<comment><USER5> I can second your question. When you build an app with a dynamic frontent (i.e. javascript) and a "database" (I don't care what model) driven backend, then you need a way to pass data and commands (e.g. JSON) between the two.

Thus you end up with pages that handle requests and return data in a structured presentation-agnostic fashion. Isn't that already an API?

</comment></comment><comment><USER6> Much of what I read about this talks about, e.g., building a REST API then using that in your application rather than direct database access.

Isn't this largely "Program to an interface, not an implementation" wrapped up in webspeak?

Whenever we start a new web project, we organize our code into groups of services, and use interfaces to represent those groups rather than concrete classes. Where possible, the implementation of the interfaces are direct database calls. When we need to use it externally, we have an implementation that uses remote calls.

So ultimately we program to interfaces which are designed to be automatically exposed as an API call. In some ways the recommendation to rely on your own REST API to build out your application feels like a way to make up for the lack of structure interfaces can enforce. Maybe I'm wrong though.

</comment><comment><USER7> This is essentially bottom-up programming where you build a small language first (could be just functions, not a "real" new language), then build your app out of your new language. Paul Graham advocates/advocated this.

Being able to figure out what primitive pieces are important now and will be important later is something that takes practice and something that I've never ever been able to convince a manager of the importance of and that it's far more important than knowing 25 design patterns or some similar buzzwordy stuff. There are many ways to decompose problems. Bottom-up is the right way, though. Contrast with top-down/stepwise refinement for the wrong way.

</comment><comment><USER8> This was a very apropos read for me, since I'm working on my next app by starting with the API. I have been working with quite a few API's and I've found that a lot of them felt like their creators never used them. So I'm building an API that I would use myself, and I'm forcing myself to live up to that promise by building the rest of the app on top of the API. I'll let you guys know how that goes!

<comment><USER9> The best way to create an API that feels like their creators never used them is to build one that you would use yourself. If you want to build one that others can use and use easily then you need to put yourself in their shoes, not your own. Otherwise it's just one more library built on some one else's idea of a good time. That said if absolutely no one else is ever going to see, let alone use this API, then certainly build what works for you... just remember the maxim of writing as though the person/maintainer after you is a psychopath who knows where you live.

<comment><USER10> Or even better, write the app's frontend using the public API (and only the public API, no cheating).

</comment></comment></comment><comment><USER11> I'm a little more cautious about this and would suggest three caveats:

1\. Building an API from day one can be premature. Typically when you start building something is the time when you know the least about the problem you're trying to solve and the issues you'll face solving it. That problem is subject to much more change early than late. If you build an API on day one may just be creating more work for yourself later on;

2\. If you provide a public API, you are quite possibly exposing your data model and any assumptions that underpin it. This can make it much harder to change later as circumstances change. Think of it as making everything (including data members) public in class. It's abstraction; and

3\. What value does an API provide _you_ as the service provider?

Twitter is an easy example of this: it doesn't really matter where the Tweets (sorry nytimes) come from as Twitter owns the graph, the distribution and the Tweets.

Now consider a site like Stackoverflow. What if you could ask questions, search for answers, vote, view your summary information and so on completely via an API. What value would there be in the SO site? Not much at all and it's the ads on those pages that pay for the site (well that and $x million from USV).

</comment><comment><USER12> The new Twitter.com is using its own API.

[http://engineering.twitter.com/2010/09/tech-behind-new- twitt...](http://engineering.twitter.com/2010/09/tech-behind-new- twittercom.html)

</comment><comment><USER13> This applies to enterprise software as well. I was an architect for a large CRM project with Siebel and software from a company called Yantra (acquired by SterlingCommerce). The difference between the two? Siebel "bolted on" an API layer and Yantra consumed their own API for internal, core functions.

The difference was night and day. As expected, the Siebel API was practically useless. Yantra's was rock-solid. No better way to make sure your API is solid than to use it internally.

</comment><comment><USER14> A big part of engineering is about making the right trade-offs at any given point. His straw-man engineer shows nothing but his misunderstanding of engineering.

<comment><USER15> I think the engineer in his example wasn't meant to be an accurate portrayal, but rather serve to emphasize that his approach is more haphazard.

</comment></comment><comment><USER16> Good thoughts. The article did not say this outright, but it is also nice to build a chunk your app (if not all of it) on top of your own API. Not only is this good housekeeping, it helps in decoupling your code and forces you to keep things in bite-sized, maintainable, testable pieces.

</comment><comment><USER17> I call this WMC (Weapons of Mass Connection)

Edit: Don't know why I got downvoted but I guess the above statement needs some context: <http://000fff.org/the-power-of-digital-ecoystems/>

</comment><comment><USER18> What would you choose to use as a api, something json-based or soap or what? Which is the easiest for the users/other developers to implement?</comment>


Normalized Google Distance - <AUTHOR> http://en.wikipedia.org/wiki/Normalized_Google_distance

<comment><USER2> This is ancient.

It's much more fun to ask the DBpedia SPARQL endpoint a question like

select (count(*) as ?cnt) { dbpedia:John_Lennon ?p ?o . dbpedia:Paul_McCartney ?p ?o .}</comment>


Google could be superseded, says web inventor Tim Berners-Lee - <AUTHOR> http://technology.timesonline.co.uk/tol/news/tech_and_web/article3532832.ece <comment><USER2> Perhaps this is heresy, but I think TBL is overrated. What made the initial web work was simplicity and loose coupling. A lot of what the W3C has done since then seems to be adding layers of complexity where simplicity is best.

And the Semantic Web has been talked about _forever_. The money quote in this article, at least for me, is:

"The challenge, experts say, is in finding a way to represent all data so that when it is connected to the web, links to other relevant information can be recognised and established."

Uh huh. I won't be holding my breath.

<comment><USER3> I agree. I wouldn't be surprised to see RDF creep into a niche of the web where hard-semantic data is already a requirement (and this would just be standardizing it), but I feel like in both psychology and web structure, meaning is something that is an emergent property, not something that's hard- coded into the raw data. Determining meaning from chaos is the impressive feat of modern search and the human psyche.

<comment><USER4> You could say that this is what Microformats are trying to achieve. The problem that Microformats has at the moment is that there isn't enough developers implementing them to make anything particularly useful, which in turn puts off other developers from implementing them as they think "what's the point?". Hopefully in time, Microformats reach a tipping point whereby it's the next hip thing a la Ajax and Rails.

<comment><USER2> Actually, what I'd like to see is web-wide tagging and then let the tags evolve. For example, I'd like to be able to wrap anything in a web page with <tag name="?"></tag>

<tag name="phone">212 555 1963</tag>

<comment><USER5> The main difference between your idea and eRDF or RDFa is lack of namespaces. The "web-wide tagging" and "let the tagging evolve" bits are a huge part of RDF.

</comment></comment></comment></comment></comment><comment><USER6> Bill Gates said the same about Microsoft ten years ago. The only question is when. Apparentely though (hopefuly or not) the money they have will be buying time for them...

</comment><comment><USER7> The only way I see Google being "superseded" is if they cling to their business model to the extent that it jeopardizes their products. Web advertising, in its current form anyway, already looks like a sinking ship. Unlike IBM and Microsoft, Google inherently has much less user lock-in, so it'll be interesting to see what they do if their cash cow begins to seriously dry up.

</comment><comment><USER8> Has there been a term coined for the Internet pervading into our home appliances - like the toilet, kitchen cabinets, the fridge, etc...

Some may sound silly but there are some amazing things going to happen in this space!

</comment><comment><USER9> Google has such good spidering and junk-disgarding capabilities that I think they are more likely to entirely enable the semantic web.

</comment><comment><USER10> I can cook up a whole bunch of metadata to add to my data, too. Now if I can just get everyone else to do it too.

<comment><USER7> Actually, I don't think adoption is particularly important. Really all we need is enough context to probabilistically figure out semantic meaning, and any metadata helps with that. It's not like you need some top-down data schema. Google is already doing it this way already. I don't think semantic web technologies will do much more than make their work a little easier/more accurate.

</comment></comment><comment><USER11> Not to doubt Tim's statement, but I would reckon Google has this technology in mind and will have a plan to put into action when the time comes.</comment>


Are robots actually going to steal our jobs? - <AUTHOR> https://salt.agency/blog/are-robots-going-to-steal-our-jobs/

<comment><USER2> Planet Money did a series of podcast episodes on this which were quite interesting (there were some low points there too, but on the whole I think the series of episodes came out at a net positive).

First in the series: [http://www.npr.org/sections/money/2015/05/06/404701816/episo...](http://www.npr.org/sections/money/2015/05/06/404701816/episode-621-when- luddites-attack)

</comment><comment><USER3> This is a great post. The link at the end of the post gives a great insight of what kind of jobs are going to become obsolete for a human to pursue.

What I think is some of those jobs are already automated in lots of countries. And there are some jobs that are falling in high risk bracket, however, that's not going to happen. For example, poeple argue that in future, waiters will be replaced by Robots and I feel that this is highly unlikely.

<comment><AUTHOR> I don't think it will be unlikely that waiters will be replaced by Robots as it's already happening:

[http://www.theguardian.com/world/2015/jul/16/japans-robot- ho...](http://www.theguardian.com/world/2015/jul/16/japans-robot-hotel-a- dinosaur-at-reception-a-machine-for-room-service)

But we shouldn't worry about it as creating robots are creating more jobs for us and pushing human being from being simple to more complex creatures and think better so its like being competition with someone else and hence pushes us further!</comment></comment>


Doctors ask engineers to spend more time in the hospital before building apps - <AUTHOR> https://www.cnbc.com/2018/12/27/doctors-are-asking-technologists-from-google-to-shadow-them-before-they-build-medical-apps-.html <comment><USER2> Unfortunately the problem is much greater than engineers not understanding doctors and other clinical staff, in my experience. For startups that want to sell to health systems and similar-sized/larger entities (really this is the minimum size that can work for most startups, practice sales usually have more friction than value), you unfortunately have to focus on the buyer, which is very rarely someone who is "in the trenches." Best case scenario, having software that is compelling to the end users can help you get your foot in the door early on, but actual adoption will only happen if you can convince the business stakeholders of your value.

In the US healthcare system, clinicians and the business often have opposing objectives and values. This is starting to change with value based care becoming more popular, but it's still all about providing what the business wants, it just happens to align with the clinicians more these days. You'll still need to support IE9 due to that botched Vista upgrade, build out a custom EMR integration, and deliver whatever random feature the sales folks promised (can you automatically fax things?) before you can move on to the features that the clinicians actually want.

The system itself is how we ended up with billing-driven documentation EHRs like Epic. Paradoxically, due to massive adoption, I think Epic and Cerner are some of the only places where real innovation could happen. I think even huge companies like Apple, Amazon, and Google will have a hard time breaking into the space, no matter how much cash they throw at it. For them, the only answer is to go fully vertical like Kaiser-Permanente, but I doubt they have the stomach for this.

<comment><USER3> I'm sure I'm being naieve, but could we just get rid of billing altogether if we nationalize the health care system? I have to recount an anecdote. My mom was hiking in a foreign country, and got injured. She hobbled to the next town, and found a clinic. They treated her and were ready to let her go. She said:

Q: Okay, how do I pay?

A: You don't _pay_ for health care.

Q: I'm American. I'm not part of your health care system.

A: That's all well and good, but we have no way of knowing how much to charge you, how to take your money, or where to send it. Have a nice vacation.

The clinic probably maintained some accounting records, but they simply had no billing system.

<comment><USER4> Somebody will be paying, and will want adequate and auditable documentation about what they are paying for. The potential for fraud is too great. Medicare and states all have to watch for fraud in their claim payments.

<comment><USER5> Sure, but adequate and auditable documentation need not involve the patient nor money. Just a "here is the medical care we dispersed, on this date, to this person, it took these resources, these people administered the care." No following up every record for payments, no arguing with insurance companies over the price.

And also, what abuse? If medical care is free and drugs are cheap, the only real abuse is drug abuse (by either seekers or medical personnel). With free access to proper care those drug abuse problems will sharply decrease, killing the market (the cause of the other half of drug abuse).

The only reason there is medicare fraud to worry about right now is because not everyone is supposed to be on it, the "fraud" is attempting to get free health care. Which wouldn't exist if everyone had it.

<comment><USER6> > And also, what abuse?

a clinic could mis-report (over-report?) how many patients they treated, and/or the procedure. They can then claim back more money than they actually spent, netting easy profit.

<comment><USER7> Solved by not allowing money to enter the circle. Results in you needing to sell the drugs/things you overcount on, which is rather easy to track and find out.

<comment><USER8> > Solved by not allowing money to enter the circle.

This is not possible without socializing the entire economy. At some point, you have to pay doctors, nurses, staff, equipment manufacturers, etc.

<comment><USER9> If they are public employees, they have sort of a standardized salary coming straight from the healthcare ministry/department/whatever where the specific hospital just administer the HR part. You still think in a for profit manner, where healthcare in most countries is not a for-profit endeavour. As long as it works, it's fine, even if it's a net negative. You try to limit the money you waste and inefficiencies, but not by pulling levers on the staff salaries.

<comment><USER10> >You still think in a for profit manner, where healthcare in most countries is not a for-profit endeavour.

And in the US it's not.

Assuming that you can simply remake a massive chunk of the economy (hospitals, doctors, nurses, clinics, etc, etc) to be government owned is silly. People will protest, lobbyists will be paid and it won't happen. If your only solution to the problems people point out is essentially magic then, no, it's not a valid solution.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I am an orthopedic surgeon during the day and at night I write code. I just don't believe that spending a few hours watching surgery actually helps. You need to really work with the software, a solve daily problems and be aware of what problems are trivial software fixes.

For instance, when I sign lab results I get to see the references for twenty year old subjects. It would be much more helpful to see the patients last lab result (in 60+% of the cases this is available).

Another example is in the ER where we have a list of all the patients. There is a column for my name so that I know which cases I am handling, unfortunately that column is too the far right and only visible after resizing the other columns. This setting is also not saved so each time I open the list I have to resize over and over again. If you could move that column to the left would be great, or even just bold font my patients' name.

The major problem that I see is that we have:

\- huge monolithic software that make any change a living nightmare

\- all changes are treated as we were doing open heart surgery. Most stuff we do is trivial but having a standard that high makes it almost impossible to deploy updates - especially the minor changes that really would change things.

\- 80% of users complain about the software but very few understand the underlying problem.

\- much of our software is spec driven - I can sign my lab results and I can see the patients in the ER, no one bothered to add the last tweaks to actually make it easy.

<comment><USER12> All that you mention points to lack of proper UX design process as part of SDLC. Observation is part this process, it is important and better not to be skipped, because it can provide very useful insights, but it's just a single stage of research - there are more techniques and methods to solve problems that you mention.

<comment><USER11> Yes, there have been numerous people pointing out this in this thread. I think that UX design is viewed as frosting on the cake instead of the thing that actually makes it work. Unfortunately I think one of the issues is that the SDLC is broken.

For some reason we keep getting features that few of us actually requested but that often make sense in that they are life saving, that is if people actually used them. I have a ton of indicators flashing all-over the place and after a while your brain simply adapts and ignores them. I doubt that anyone has actually done any analysis to see if these tools actually save lives.

I've been involved in some projects when I've spent 30 minutes with UX people and then never heard back from them. When the final product arrives it is full of annoying flaws, e.g. the latest software I was involved in the work flow is: 1\. click on "open software" from the patient chart 2\. a new window opens where I manually have to click on "log in" (note, I'm not adding a password) 3\. the UI goes into authentication 4\. the UI goes back to the login screen 5\. the UI asks me a question that I _always_ answer the same thing to 6\. I actually get to the data I was interested in

The most annoying part is number 4 - if I accidentally click on "log in" everything breaks and I have to close the window and redo everything from start.

Most of these UX issues fall under the category - murder by a thousand cuts. It is mentally tiring to be faced with all these issues but none of them is like open heart surgery where one mistake can be fatal. What happens is that doctors/nurses become tired and don't put the effort into the patient interaction where the actual value in healthcare is created. I'm pretty sure that bad UX in the end kills many more patients through this than malfunctioning critical hardware.

I truly wish that people in this forum that create health-care software think of UX and actually use their software more than just "I clicked through and everything works". Your bosses will probably never ask for UX features because they have a deadline, but you are in charge of designing and during that process it is easy to fix many of these annoyances (e.g. just disable the log in button).

</comment></comment></comment><comment><USER13> I am biased, but I spent almost half a decade building/designing systems for Healthcare. I had direct interaction with the users, the vendors and the actual go-live planning for a number of facilities.

Healthcare has a lot of issues, EPIC was a stone-walling garden, Siemens wanted to steal stuff, OpenVista was a non starter, Philips talked a big talk but never followed through, Not everyone was truly HL7 compliant, Users didnt believe on Apps on the iphone/ipod-touch as the screens were too small and the average age of users was ~57, The number of employees in a large hospital is in the thousands, Patient Entertainment systems were snake-oil-jokes, "medical grade" devices were a fraud, and selling into them at this time was a unique process for every hospital -- and while the users (clinical staff) really really want to (and do) provide good care, training 1,000+ Staff/Nurses on your new tech is very daunting.

Obviously we have made a ton of progress in tech in healthcare, but finding a way to consume more time with staff/processes can be a difficult problem to figure out access.

Silicon valley needs an actual research hospital for tech - if I were throwing my billionaire last name on SFGH/UCSF/Oakland etc's hospitals - I'd do a lot more than just buying the name of the building - seeking how to work together to make an SV research hospital happen in an innovative way.

(We had a fully integrated HL7 iphone app which could interact with OpenVista, and other systems like Vocera and Philips and Siemens systems. We had a channel to work with hospitals around here but the screen size and costs of providing handhelds to nurses were too high for 2007. YC Turned us down, Epic and Cerner would allow integrations... We opensourced it to Openvista.)

<comment><USER14> I think eventually we'll have to sidestep most of this fraud entirely by enabling self-serve early diagnostics and cranking up the doctor-replacing technologies to the max. Machines are good at recognizing patterns in non- adversarial environments not starved for compute. There's every possibility that they could do diagnostics better than a human could. Treatment will be up to human doctors for the foreseeable future, though.

Too bad Theranos salted the earth for much of this innovation for the next decade. But it's still happening, starting with EKG and ultrasound.

<comment><USER15> >But it's still happening, starting with EKG and ultrasound.

Whole-body ultrasound? How would an AI understand how to interpret images with low signal:noise? Who will be performing the actual ultrasound image capture? Who will be ordering the imaging tests? How will an AI understand a patient that can't meaningfully interact with an AI?

What's the utility of "EKG" [sic] for diagnosing non-cardiac problems? Or, do you come from the perspective that all medical problems can be diagnosed with an ECG, urine analysis, ultrasound (of what?), blood test, and CT scan? Do you realize that an ECG is more complex than a single vector ECG via Kardia mobile?

I thought we were trying to reduce healthcare costs, but you're recommending over-utilization of expensive diagnostics?

Why are you limiting treatment to doctors only, why not have AI do everything?

Everything you've written demonstrates an extremely limited understanding of the practice of medicine, a characteristic far too common shared by those who are trying to "disrupt" medicine.

<comment><USER14> Sure, I realize there's much that the current tech does not cover. But you gotta start somewhere, and through extremely wide deployment tens of thousands of lives will be saved, and important feedback will be collected to improve products. $400 watch that does a dozen other things and that the user would buy even if it didn't have ECG is not "expensive diagnostics".

This is where things are at, whether you like it or not, especially for the working poor who can't afford to fork over a few hundred dollars every time something feels "off". The current crop of devices is not affordable to them, but 5-10 years from now they'll be bundled in cereal boxes. Hook up sensors to wearables, catch diseases early and at a massive scale, cure or treat them before they get extremely expensive. To me it looks like it's the only way out of the ripoff "healthcare" scheme we're in right now. I'm pretty convinced the solution to the US healthcare problem will be technological in nature.

And don't tell me universal healthcare will fix things. It won't, because US doctors (unlike their counterparts elsewhere) expect to be earning a pretty penny after they go through the trouble (and expense) of educating themselves for a decade, and that's not going to change. There simply needs to be less demand for doctors, and the ones that remain should be able to use their time efficiently.

<comment><USER16> Smart/Self-serving diagnostic tools occasionally fail for legal feasibility reasons before they are adopted by the market. Consider a smart heart monitoring system, maybe connected to a canary that will alert a healthcare professional or first responders if something is amiss. Absolutely nobody wants to be liable for misdiagnosing acute symptoms, which may lead to death or false positives.

It doesn't even have to be acute symptoms, either. A large healthcare company a friend worked at was working on a smart heart monitor that for some reason they wanted to connect to an app. In their head, the app would be used by both the patient and their doctor who would check on the patient. If they have a lot of patients, that's an overwhelming amount of data streaming in 24/7\. The time commitment to really evaluate those data for anomalies was too high, as were the stakes. Doctors were scared that if they missed something they might be held liable for unrelated medical emergencies which is terrifying for them. At the time, algorithms were really not good enough to catch the really subtle markers of an impending medical problem. At least according to the guy that told me this, he was a biomed/hardware engineer not a programmer or statistician by any means.

Even if you had some legalese associated with the product to make this a non- issue, doctors still wouldn't trust the idea. So they pivoted the technology to something else that was more traditional. It is much harder to pursue justice for an algorithm than a human. I guess what I want to get at here is: sometimes the software and hardware are working as intended, but subtleties can be lost on the technical side (programmers, biomed engineers) can kill a product. Stuff like market research, liability and legality, and public perception of the tech.

<comment><USER14> Sure, there will be cases where your device will say "I'm at a loss here, go see a doctor". The point is, right now the majority of (very expensive!) doctor visits are a total waste of everyone's time, and your money.

There's no rational reason why I need to drive to a lab for bloodwork or simple diagnostics, and have a human do it: a robot at a local convenience store should be able to do the job. There's no rational reason why I need a doctor to misdiagnose my elbow pain as something requiring surgical intervention (I just stopped using my laptop in bed and it went away). Another doctor ordered a ($900) MRI to diagnose pain in my left shoulder and then told me I have a SLAP tear there based on extremely blurry results (again $$$$, surgical intervention, and 6 months of recovery). Bullshit, bud, I don't - it's a non-dominant arm, and I'm someone who doesn't do a lot of throwing or work above shoulder level. It was that dang laptop in bed again. Someone with weaker critical thinking skills and google-fu would be thousands of dollars poorer thanks to taking that doctor's "advice". In fact they could end up with a permanently fucked up shoulder and elbow, too.

Did you know that medical errors are the third leading cause of death in the US, right after heart attack and cancer? Seems to me that "human" doctors are also a dangerous proposition.

<comment><USER15> >The point is, right now the majority of (very expensive!) doctor visits are a total waste of everyone's time, and your money.

Honestly, what are you talking about? A doctor's visit costs between $0 and $150, depending on insurance/government, and it is a focused encounter to determine the source of a medical complaint and a most likely effective treatment for that problem.

You want to stick a one-lead ECG on someone and expect that it's supposed to spit out a diagnosis, or heaven forbid, a recommendation to see a doctor who can actually figure out how to diagnose and treat the patient.

Your statement in fact points to the uselessness of this proposed medical device if it can't actually figure out what's going on and instead will send you to an actual expert (physician). How reliable would it be for everything else it "diagnoses"?

<comment><USER14> >> A doctor's visit costs between $0 and $150

And who do you think covers the remaining $150-infinity?

>> You want to stick a one-lead ECG

You're not arguing in good faith. Goodbye.

<comment><USER15> >You're not arguing in good faith. Goodbye.

You haven't come up with a single situation where a non-cardiac medical problem can be diagnosed solely with a handheld single vector ECG.

You don't mention anything about false positives or false negatives, sensitivity, specificity, pathophysiology, anatomy, pharmacology, diagnostics, or medical decision making.

You have no understanding of how your magical tech device would bridge every aspect of the practice of medicine, but you make an audacious claim with a bit of hand waving, saying "this will work better than physicians, and cost far less".

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> I worked a tiny bit over a year around 2013 at a hospital network and was on a team that maintained custom integrations with Cerner, an EHR system.

It was by far one of the coziest jobs I ever had. Low stress environment, redundant meetings, etc. But development of any kind of god awful. It was extremely sluggish, lots of red type, and seemed to follow a manual QA approach over any sort of automated testing. Things were just too lax in general.

Myself and another junior developer left after we noticed that an intermediate engineer on our time hadn't committed in over 3 months.

My point of this story is that hospitals didn't seem to attract/retain passionate software developers. With high turnover or apathetic developers, most software built custom for hospitals is probably Frankensteined.

<comment><USER18> Agreed, this mirrors my experience in healthcare. Hospitals pay the highest amount of money, for the lowest quality of software (regardless of whether developed internal, or purchased through healthcare software vendors).

The jobs are easy, and you can go months without doing any real work whatsoever. The company might not even care (since for hospitals, sales cycles are often measured in years, and minor upgrade cycles are often measured in months).

But this kills any desire to do anything. Almost no developer with any motivation or skills, wants to work somewhere where they do nothing useful and have no real work to do -- even if the pay is good, you can literally feel your brain rot out, and you start to be worried you'll never get hired at a "real job" ever again.

It's just a bad cycle of events all around.

<comment><USER19> This was my experience in government work too. For every three engineers that accomplished nothing, there was one doing real work. Most good engineers would work there for 6 months or less and then flee in boredom or fear of not finding work at a "real job" again. The good engineers that stayed often found a niche they really liked, and were worshipped as rock stars by management and stakeholders, so they were pretty happy.

</comment></comment></comment><comment><USER20> More time? I wish I was given _any_ time with my users so I could actually understand what features would make their lives easier. I actually did get to spend about two hours with some actual users of my software a month ago and I noticed that they were scrolling up and down a lot. I asked if it would make their workflow quicker if I made the save button float in the lower-right corner of the browser (I.e. position: fixed). They said, "you can do that? Oh my God, that would be amazing!" It took two seconds of CSS and has saved them hours already.

<comment><USER21> The problem is that it may take 2 seconds of CSS, but it is a software change that then requires the product to be revalidated, along with the matching paperwork (functional design doc, software design, technical design, customer support documentation and training material) and validation evidence to be submitted to your official document control system. And this process can take days, weeks, or months, depending on how complicated (due to extreme CYA) your compliance department makes the process. And the company compliance folks want to go overboard as they want to make sure the FDA auditors are happy the next time there is a surprise audit.

<comment><USER20> Oh absolutely - it was as simple as a fix can be, given (perfectly legitimate) quality control concerns, but it never would have happened if I hadn't had a rare opportunity to actually observe how they work.

</comment></comment></comment><comment><USER22> From software development classes in School to University, we were told the most powerful method of requirements gathering was observation.

Yet in my whole professional life I've never had a chance to do it despite putting the idea forward.

One of my old colleagues who managed to observe a client was met with hostility and questions from the people he was observing.

Other times clients want to dictate and have no dialogue in defining requirements.

<comment><USER23> When I was developing internal software at a big company, I went to observe some actual users at the company. (I thought what we were building didn't make sense, so I wanted to see if they actually used it that way.) I got a tongue lashing from management for that one! "You're a developer. You're not supposed to talk to users."

The entire project, of course, was eventually cancelled.

<comment><USER24> I see that a lot too. There are a lot of well-paid managers whose only role is to be middlemen between engineers, customers and other departments and they protect that role jealously.

I agree that some developer probably shouldn't be talking to customers but overall they should. I have had many occasions where we received a spec and after discussion with users quickly saw how we could meet their needs in a much simpler way than the middlemen had come up with.

</comment></comment></comment><comment><USER25> My neighbor's son is a doctor who needed some software written. He learned to write the software and now runs a software business (in addition to being a doctor). I guess it was easier than trying to bring developers in. Ive seen the same thing with a pilot who learned programming to write an incident management system for airlines. Only once the software was successful did he seek advice from 'professionals'. Learning to code is not the deepest skill around.

<comment><USER14> >> Learning to code is not the deepest skill around.

Neither is learning to fly a plane. What's prized is the ability to do it in such a way as to not crash. The same applies to software engineering.

<comment><USER26> Healthcare has lots of low-hanging fruit that's solved by simple CRUD apps, and those can be reasonably maintainable (and secure) if you build it using easy frameworks and well-known patterns that are commonly found in tutorials lying about the internet.

It'll be so simple that it's equally maintainable.

The real issue is adoption, but that's expedited if you're a doctor who's also a software developer and makes it easier to sell.

</comment></comment></comment><comment><USER27> I'm not at all surprised.

As a semi retired software engineer and currently 4th year Med student, I still maintain a dream of building a usable EHR that puts the clinical, patient-focused side of things first. Currently implementations allow for increased billing recovery, but at a cost to both doctors and patients.

I just don't know how you'd start in competing with something like Epic or Cerner, from a business side of things.

<comment><USER28> Healthcare is a heavily regulated industry and as such only large companies are able to successfully navigate the bureaucracy. The only way to usurp coercive monopolies is by creatively destroying it (e.g. uber)

<comment><USER29> It's more nuanced than that. I've spent 13 years working for two successful healthcare/biotech companies, both having attained FDA clearance (one class I and two class III devices) while I was there. I was brought on as the 21st employee and then the 17th employee. At no time could these have ever been considered large companies.

Products like LIMS and hospital systems are hard to replace because of vendor lock in and the cost to replace it all, not regulatory hurdles.

</comment></comment></comment><comment><USER30> This is so true.

One of my previous professional experience was working for a company that delivered a complete hospital information system that was used in two of the biggest health institutions in the Middle East.

Initial software development was done offsite, but then, the owner and CTO of the company thought it more wise to bring in the developers on-site. On-site here meant that our team was provided an actual area in the hospital where we were given freedom to observe, collect and synthesize as much information related to the system we were building.

One major challenge we faced was that, for example, we have three doctors all specializing in the same category, i.e. cardiologist. All of them would have different ways of wanting how the technology will support their process. One would want information laid out in a different manner, with quicker access to other information he need from other facets of the system. There's just no way to standardize a specific process. This lead to us delivering solutions that allow the doctors to customize as much as they can of the application based off their preferred procedures.

Being there in the hospital itself I would say has tremendously helped the team deliver a lot of innovative functionality that I have still yet to see at this day and age. I was interfacing HL7 data with Siemens and GE Radiology and providing the doctors to automatically perform dictation through Philips Dictaphone - where the recording is sent to an offshore transcription company in Asia, and the data returned and tied to the actual radiology exam it is designated for - all under intense security, compliance, and anonymity.

I've also observed through working in different hospitals, there is a lot of variations in the workflows, hence the necessity for engineers to actually be present and on-site. This provides the developers a real-world picturesque view of what needs to be built that will make every hospital staff (doctors, nurses, aides) become very productive.

<comment><USER31> A problem with so many local customizations becomes apparent when it's upgrade time. You must do several X the testing and there's a higher risk of something breaking.

<comment><USER30> Customization happens at the user level. We architected and designed the application to allow for this flexibility.

</comment></comment></comment><comment><USER32> Maybe we need a profession, you know, people who create experiences ... maybe we can call them 'UX designers' or 'UI designers' or something. Where they investigate how people use and relate to information before the Engineers build stuff.

Maybe I'm just crazy!

<comment><USER33> They have UX designers. The problem is those designers don't necessarily understand clinical workflows. That takes years of experience.

<comment><USER34> Jakob Nielsen was writing for decades now that the first job of an interface designer is to sit down with future users and see how they do their work. (Always _users_ , more than one.)

It doesn't take years of experience in the target field. It just takes hours of watching and listening and figuring out what people are actually trying to do.

<comment><USER33> I am familiar with Jakob Nielsen's writings, and I stand by my statement. Effective UX design in the medical field takes years of experience. It's far more complex than most other business domains because every medical specialty has different requirements and there are so many edge cases. No one is capable of learning that stuff in a few hours.

</comment></comment></comment></comment><comment><USER35> Worth reading: _How Medical Tech Gave a Patient a Massive Overdose_ (39x)

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

</comment><comment><USER36> I have often wondered if it would be better to just hire professional data entry people to follow the doctor around and enter all the information into the system. Does it really make sense paying someone $500K a year to peck and tap into a EHR?

<comment><USER37> > I have often wondered if it would be better to just hire professional data > entry people to follow the doctor around and enter all the information into > the system.

Those data people are called "medical scribes," my doctor has started using one. Seems like they're mostly pre-med college students looking to get exposure to healthcare environments.

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

<comment><USER36> Sounds ideal - they can even remind the doctors to wash their hands before touching the patient.

<comment><USER37> > Sounds ideal - they can even remind the doctors to wash their hands before > touching the patient.

I don't think doctors (or anyone else for that matter) is going to tolerate being followed around by an assistant who's going to nag them about how to do their job.

</comment></comment></comment></comment><comment><USER38> With any of these tech inroads into non-tech fields, the issue is always communicating to the non-tech people that your solution has value, and not developing the tech solution itself. If you're a salesman walking into a person's house, telling them they live their life wrong, and your (expensive) solution will fix it, good luck with that.

</comment><comment><USER39> It also doesn't help that to break into this market you have to overcome years of customization and millions upon millions of dollars in sunk costs that management isn't likely to throw out for something that "works better for clinicians." Not to mention the cost of retraining entire hospitals worth of staff to use the new system.

<comment><USER40> So true. After over 30 years as a programmer, I recently switched to being a nurse in a hospital where half the day (it seems) is spent charting in the very old DOS legacy charting system. No one would write a system like that today, but with thousands of people muscle-memory trained on the old system, what reasonable argument could be made for a change?

</comment></comment><comment><USER41> Similar problem in the UK [https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark...](https://www.theregister.co.uk/2018/01/18/nhs_buntu_trademark_cease_and_desist/)

The issues the NHS has with IT (with the glaring exception of WannaCry) are related to the vast fortunes they expend with outsourcing companies for custom software that doesn't work. Doing the same thing but on Ubuntu won't be any better. But the engineers don't care, they have an ideological axe to grind so they focus on something irrelevant.

</comment><comment><USER42> Example of a more general problem: developers not understanding the business domain. Developers often blame "poor requirements" for schedule and budget overruns, but they didn't spend any time learning the business domain.

<comment><USER43> If you do learn the business, you have to explain to management why you wasted all that time. You cant say your application is cheaper in user errors, downtime, maintenance, licences, change requests etc... as that would mean all the other expensive software is garbage.

<comment><USER42> Domain expertise is not wasted time. It makes the difference between a useful application and a pile of code. Developers should not assume they know more about a business domain than the people working in it.

<comment><USER44> Isn't that the job of a product manager, though? To figure out what the product should actually do?

<comment><USER45> tacit knowledge especially in an hands-on field like medicine where patients are involved cannot be conveyed by a manager with a power point presentation.

This compartmentalisation in the name of efficiency is actively harmful. Developers should get out more and get first hand experience of the environments they develop software for.

<comment><USER19> Could not agree more. It's a bit like the game of telephone that many of us played as children. The more hops in the connection, the greater ability for knowledge loss and distortion.

I once had a PM tell us to do a feature a certain way, despite engineers saying we thought it was dumb. We shipped and had lots of user complaints, and lost millions of dollars ultimately in lost revenue due to cancellations that we think were at least in part to this. We eventually reversed course but much damage had been done.

Afterward there was a witch hunt (which I staunchly oppose, but I digress). It turned out that the PM had taken the word of another PM who in turn heard from another that had gone on location and misunderstood what the customer was saying. To save a few thousand bucks the company only sent one person and expected them to brief everybody else on their findings. In hindsight I'm sure that skinnier travel budget wasn't so worth it.

</comment></comment></comment></comment></comment></comment><comment><USER46> I work on a telemedicine product using Google Glass Enterprise and the current version of our product was shaped greatly from feedback provided by one early user (physician). It really focused our use cases and made the product much better. That being said, optimizing the current medical process will only get you so far. It will probably not result in large disruptive positive changes. Those will have to come from outside the current process.

<comment><USER47> _It will probably not result in large disruptive positive changes. Those will have to come from outside the current process._

Rest assured that anything that makes a significant impact on health will cause people to completely freak out if it hasn't been vetted via the current medical system, even though this vetting process kills a lot of therapies that people then lament that they wish they had access to.

<comment><USER46> Balancing safety vs progress is tricky. Additionally, people's perception of risk is also really bad so the resulting choices are sub-optimal.

<comment><USER47> I'm well aware of that. I have a form of cystic fibrosis. I used to be on multiple maintenance drugs. I currently manage my condition with diet and lifestyle and no longer take medication.

I also no longer belong to any CF lists. It's too much drama. I was constantly attacked and, among other things, accused of irresponsibly endangering lives for trying to talk to people about what I found helpful.

</comment></comment></comment></comment><comment><USER48> Sounds like doctorsplaining. A better idea would be to hire nurses and technicians who spend thousands of hours in the trenches and let them tell you everything that really goes on.

<comment><USER49> >Sounds like doctorsplaining

Sounds like userblaming. Works wonders when the users aren't the ones choosing the software to use, or have much input.

<comment><USER50> Absolutely. It's vital to listen carefully to users and think broadly and wisely. The programmer must understand what the users have to deal with in order to provide something useful to them. If not, the user will hate the result, it will make them miserable, cost the employer time to redo it and the cost of not being able to do what needs doing (or worse) without software.

tl;dr: get to something most useful soonest by quick, small iterations until it's satisficing. No BDU project fails, and no assumption fails.

</comment></comment></comment><comment><USER51> When I was a programmer at a non software company I would frequently sit with the users and watch how they used the existing software or how they did a task that we were considering creating software to help with. It was a great way to make a useful product right away rather than get back and lot of negative feedback about how it doesn't do what they need or expect if the software was written without that insight.

</comment><comment><USER52> To what extent is this an exclusively American problem? How much of the health care "tech" opportunity is tied to managing the complicated multi-party bureaucracy of the U.S. system?

The article highlights how docs are spending too much time doing "desktop medicine" related to paperwork and billing. There's a whole layer of adminstrative staff at every hospital doing this stuff too.

If we get Medicare For All someday, what will the impact be on the healthcare tech startup space?

For example I met someone at a bar the other day whose startup was all about managing medical bills. Consumers can scan their bills and they'll look for optimizations and payment plans and budgeting or something. This would just go poof under M4A.

</comment><comment><USER53> I managing projects that specifically integrating Epic data with dozens of clinical healthcare applications, HR data, medications access data as well as provider behavior data to offer security, privacy and unified monitoring capabilities for privacy and compliance officers in healthcare.

It really does helps to "eat our own dog food" and spend time in hospitals.

For example I spent few days in large New York hospital studying operations of secure drug dispensing cabinets before building solution for medications security analytics.

Tons of interesting data with valuable insights on how narcotics are secured and accessed.

</comment><comment><USER54> Also true for EdTech startups who have never talked to students or teachers.

</comment><comment><USER55> This is the Design Thinking approach IDEO pioneered and continues to pursue. It's also how Apple approached their retail store, for instance, by composing a team made up not just of the designers, but also people who worked in retail on the ground floor and understood the reality of the problem they were solving.

</comment><comment><USER56> Ideally every developer should have to spend a significant amount of time actually interacting with their customer, and in this case the customers customer. It would give a different perspective about that feature that is being built. It sounded good in a planning meeting and will never be used in the real world.

</comment><comment><USER57> I'm have the desire to make an attempt of developing a new type of EMR system, putting special focus on the documentation part of things.

Is there any health care practitioner around here with time for a 15-minutes phone interview or willing to exchange a few emails so I can better understand his/her needs?

</comment><comment><USER58> One issue with software at hospital is that the various departments buy what's best for them, with little regard to interop needs with other departments.

So, admissions, for example, buys what they want, and don't care about the integration with, say, radiology.

<comment><USER31> You could also make the same complaints about the vendors for each.

It's fun when some systems handle a bed-swap gracefully. But others don't.

Or what happens when you figure out who your John Doe is and how to propagate that.

</comment></comment><comment><USER59> IBM's Watson has killed trust in medical software for a generation.

<comment><USER31> It never got that far in my opinion.

</comment></comment><comment><USER60> And always question assumptions. Those are your enemy and the area where most things are wrong or missed.

</comment><comment><USER61> Hope ML/AI will capture/automate vital/undocumented knowledge that is orally passing thru generations e.g. [https://en.wikipedia.org/wiki/Stereotypes_of_Jews#Jewish_mot...](https://en.wikipedia.org/wiki/Stereotypes_of_Jews#Jewish_mother)

</comment><comment><USER62> This applies to all kinds of "apps", not only hospital-related ones.

</comment><comment><USER63> If any doctors want to discuss app development, I'm very open

<comment><USER47> I'm not a doctor, but I run a small, low activity list called Health Techies. Anyone here is welcome to shoot me a join request:

[https://groups.google.com/forum/#!forum/health- techies](https://groups.google.com/forum/#!forum/health-techies)

</comment></comment><comment><USER64> Engineers ask doctors to spend more time / resources on building healthcare tech.

</comment><comment><USER65> As a programmer, it always flatters me when I am referred to as an "engineer"

</comment><comment><USER66> Click bait title. Actual title should be: "Doctors are asking Silicon Valley engineers to spend more time in the hospital before building MEDICAL apps"

</comment><comment><USER60> Software developers are incredibly poor at gathering requirements. The best choice for gathering those requirements is to have a management consultant who does nothing but study business process and document the current clinical process. Once that's documented then you can discuss what needs to change from that document to extract the core requirements. Having a software person shadow a medical professional will only lead to the medical professional telling the software person what they think is needed.

In other words, decouple system analysis from system design.

<comment><USER67> _Software developers are incredibly poor at gathering requirements._

I've had the opposite experience. Good software developers are good at gathering and understanding requirements. The information loss from management consultants and software developers is pretty nasty. Frankly, if the the people coding the system are going off a requirements document that they didn't have a hand in then you might as well outsource the development. If the software developers don't become domain experts then you should be worried about the correctness of the software.

I often wonder if the general dislike of DSLs is caught up in this separation.</comment></comment>


ISIS hacker group CyberCaliphate hacks Malaysia Airlines - <AUTHOR> http://malaysiaairlines.com

<comment><USER2> LizardSquad is not an "ISIS hacker group"</comment>


Running Consul on Kubernetes and Monitoring It with Prometheus - <AUTHOR> https://www.weave.works/running-consul-kubernetes-monitoring-prometheus/ <comment><USER2> Why not use the etcd built in to Kubernetes instead of Consul?

<comment><AUTHOR> Best practices are not to use that for anything other then kubernetes components - it contains all your secrets in pain text, for example.</comment></comment>


The Art of Failure: The Point transforms into Groupon - <AUTHOR> http://jason.deroner.com/blog/tech/what-happened-to-that-fail-the-point

<comment><USER2> It seems that Andrew is suffering from a form of survivorship bias. They launched The Point with all these different group-power ideas, then struggled until they stepped back and focused on the 1 idea that stuck.

>Andrew: ...You're way too dumb to figure out if your idea is good. It's up to the masses. So build that very small thing and get it out there and keep on trying different things and eventually you'll get it right.

The advice he's giving here seems to be saying two contradictory things. First, you don't know what feature will be the one that puts you on the map. Second, focus on that feature. Wait-- what?

He makes it sound like you should build small idea 1 and see if it works; if it doesn't, build small idea 2, etc. However, what if he followed his own advice from the start? What if they built some other group-centric idea first and that one seemed to gain some minor traction. They'd be faced with the problem of whether to stick with a mediocre idea or ditch it in exchange for a potentially great idea.

It's as if Andrew did a global idea search, found the best, and is coming back saying "If only I'd done a local search in that direction instead!"</comment>


How to Keep Your First 1,000 Users - <AUTHOR> http://viniciusvacanti.com/2011/02/24/how-to-keep-your-first-1000-users/ <comment><USER2> Great list indeed.. And the key points are focusing on a niche (cheap, easy, close, ...) before expanding. BUT even though Foursquare did that in New York to begin with, the speed of expansion afterwards is important too. Foursquare went from 1 city to 100+ in a bit less than a year opening slots of new cities every second month or so. As Groupon did that in a shorter period of time. The conclusion simply being (i guess) : once your model (product, business) is proven locally on a niche, don't wast time and get global fast.

</comment><comment><USER3> Great goal that I believe is skipped over in a lot of "How to" articles.

Getting as many users as possible as quickly as possible not only outstrips your capital to capture those users, but most of them never stay on for long.

Focus on perfecting features and functions that make and keep 1000 users happy. If at first you don't then iterate. Don't keep trying to capture more users when your first 1k are not even using your product.</comment>