Assume positive intent - <AUTHOR> https://rickmanelius.com/article/assume-positive-intent <comment><USER2> _1) It's 100% reasonable to have a high degree of skepticism within a low- trust environment. For example, I would never assume positive intent and allow my daughter to be alone with a registered sex offender just because the person claimed they had changed. I would also never trust an alcoholic with a house full of liquor. Once a person has violated trust against a particular metric, it 's OK to take a different position in order not to put yourself in harm's way._

You can only _assume positive intent_ in situations where intent is not clear and you need to infer or assume. Once there is a proven track record of bad acts clearly establishing intent, _assuming positive intent_ amounts to deluding yourself.

If you don't know, then assuming positive intent and looking to situational factors as the source of problems can be surprisingly powerful. But, once you have affirmative evidence of bad faith, then you need to go with that. Assumptions about motive only make sense under circumstances where motive or intent is unclear.

<comment><USER3> A bit of a nitpick, but

>I would never assume positive intent and allow my daughter to be alone with a registered sex offender

I don't know, prehaps that's true in the case where one doesn't know what the sex offender has done (i.e what crime got them onto that list), but it's not sufficient in general.

Although most people on the list are there for good reasons, there are not- good reasons too, such as urinating in a public park at night, having a lewd picture of your 17 year old girlfriend/boyfriend on your phone, and in some countries possessing/writing certain pornographic comics or stories.

So I think it is too dismissive, similar to how it is also dimissive to say the same thing about an ex-convict.

<comment><USER2> Substitute "known child molester" for "registered sex offender" and see how you feel about that statement. I am sure he also would not want to leave his child with a child molester who was not yet known to be a child molester, but most people have no idea how to effectively screen out such people. So, they use metrics like _registered sex offender._

While I agree that most parents use crappy rubrics for deciding whom to entrust their kids with, I am not really comfortable with arguing in favor of trying to do some kind of justice for some edge case adult over a parent looking out for the welfare of their own child. The parent has a duty to their child. They do not have a similar duty to some guy who took a leak in the park, yet their dream job is babysitting. Depriving public urinators of some right to become a babysitter seems a rather small thing in the name of protecting our children from possible child rape.

The place to fight this battle for justice is with the system that designates public urinators et al as sex offenders, not with parents trying to decide whom to leave their kids with.

</comment></comment></comment><comment><USER4> Hanlon's Razor ('Never attribute to malice that which can be adequately explained by neglect.') is better ... just assume people are not trying to screw you right away.

The lack assumed negative intent is a positive in my book

[https://www.farnamstreetblog.com/2017/04/mental-model- hanlon...](https://www.farnamstreetblog.com/2017/04/mental-model-hanlons- razor/)

<comment><USER5> Came here to say this.

This kind of work irks me. No offense to the author, this is a widespread trend, not a single example.

You write a whole blog-post on a topic and not mention Hanlon's razor. It is inexcusable that you didn't know about it. It was your job to do "literature survey" or some google search, or an intellectual discussion with a handful of people, (ideally all three of them, and more) before you blurt out a whole essay on a topic. And then in the essay you create an image of yourself originally coming up with such a brilliant idea.

This is just a piece of writing (and maybe I am a bit harsh but I'm just trying to point to a trend). We're on HN. This is way worse when it comes to coding/github projects:

You create some kind of code, put it on github, create a blog-post in some shiny flat/material design, grey font, maybe medium or nautil.us posting. And put that posting on tech forums, HN, linkedin, reddit, whatever.

And you fail to mention other projects preceding you on this same exact topic, much less discuss the pros and cons of your approach vs previous approach(es). Who knows you might've ended up finding out your own code was a complete reinventing of the wheel and completely redundant (maybe you're too afraid to find that out). (As an example, look at my recent comment about 'building your own linux' vs LFS [1]).

Creating something new and original is hard work. Part of that hard work is searching for existing efforts, related work, doing a literature survey, and whether or not they were successful, and how they compare/contrast with what you did or are going to do, and so on. Short of that, you're just contributing to the noise, the bloat, and the information overload of your content consumers.

What's worse. Not putting in the full effort works for these people too. More often than not, such people are looking for a quick karma-whoring to meet their immediate objective. A github coder is looking to put something quick on their resume, to land a job interview. It's the job of the interviewer or potential employer to hold such people accountable, but I doubt they do.

I don't know. This irks me to no extent. I'm big on minimalism. I spend a lot of my efforts making sure I don't say something that's already said ('say' = a piece or writing, or a piece of code). I don't like to contribute to information bloat. Maybe it's a self-defeating habit (i.e., if you don't say anything most of time, people think you have no talent, you're a nobody).

edit: It also reminds of NIH (not-invented-here) syndrome, something Google is known for. To be clear, it's worse than when it's done by noobs (e.g., for quick karma-whoring to land a job interview, at least they're desperate). When you're in a position of "status", you definitely can do better. It also reminds of the website LessWrong [2]. Those self-entitled wannabes have created a whole universe of philosophical/logical terminology for themselves without consulting the outside world and trying to find out whether "their ideas" originated elsewhere or not.

edit 2: In case anyone wondering, yes I am advocating the opposite of 'publish or perish'. And 'publish or perish' is part of the reason we have so much information bloat (on the internet, in the libraries, everywhere). And that's part of the reason why I say my approach is self-defeating.

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

[2] [http://lesswrong.com/](http://lesswrong.com/)

<comment><USER6> That's a very low bar for an essay... at least in terms of length. I'd be surprised if this took long to write which isn't a criticism so much an expression of confusion as to why you called it an essay. It's also a little weird to call it inexcusable they didn't acknowledge Hanlon's Razor because it's hardly a common reference. Even the wikipedia page only gives two instances of Hanlon's razor being used and one of them is an acknowledgement that the general idea is very likely much older than the Jargon File glossary entry.

<comment><USER5> As I said, I admit I might be a bit harsh. I took a slightly bad example of what I had in mind and went ahead and said what I wanted to say.

The bulk of my comment is about the general trend, as well as the coding community.

<comment><USER7> I feel you, I do this so often :/

</comment></comment></comment></comment></comment><comment><USER8> I used to think this way, and then I built a house. Try keeping an open mind about that process sometime and see how many supposedly top-notch and reputable contractors fess up to mistakes they've made. By my count, the numbers are reversed - maybe 1 in 25 will come forward and say, "I damaged this and I'm going to have to buy a replacement part. Sorry about that." If you discover a problem and then call them on it, I'd give it 50-50 odds that they will claim innocence and balk at correcting the issue.

It would not have been my first instinct to put professional tradesmen in some sort of low trust category, but that has been my experience, and I don't think I'm alone.

Are they being malicious? No, I don't think so. Just lazy and/or careless - but the aftermath is largely the same.

<comment><USER9> Not to disagree, but once the price on the contract is set and a mistake is either covered by you or them, I think you've entered the realm of a "low- trust environment" which is addressed by the author.

<comment><USER8> I think that just furthers my argument - mistakes get made all the time since we're all humans around here as far as I know. I honestly don't have any problem with people ( tradesmen or otherwise ) making mistakes as long as they own up to them and/or fix them. To say that "once a mistake has been made and a solution negotiated, we're now in a low-trust environment" flies in the face of "Always approach people with optimism".

</comment></comment></comment><comment><USER10> The author discusses some caveats to this approach. We might also take a critical lens toward trust as a default stance by applying an understanding of systems of oppression. I love the way this is discussed in AORTA's facilitation guide ([http://aorta.coop/portfolio_page/anti-oppressive- facilitatio...](http://aorta.coop/portfolio_page/anti-oppressive- facilitation/)):

> There are a few community agreements that participants often bring up that > we don't tend to use or bring with us. Two of the most common ones are > "assume best intentions" and "default to trust." The reason we don't use > these is because when someone is unable to do this (say they're feeling > untrusting of someone, or unsafe), having a community agreement telling them > to do so isn't going to change anything. These agreements aren't always > realistic, especially when we take into consideration that when people have > been harmed by sexism, racism, homophobia, transphobia, classism, they/we > build up necessary tools to care for and protect themselves/ourselves. > Agreements we offer instead that capture the spirit of these are "we can't > be articulate all the time," "be generous with each other," or "this is a > space for learning."

</comment><comment><USER11> I love Linus Torvalds quote on trust (paraphrase, not exact citation):

"People can trust me because they don't have to."

He was talking in the context of Linux kernel, but I think this applies universally. If you are in a relationship where the other side has more power, you cannot trust them. However, if you have equal (or greater) power, and you can walk away, you can trust them.

And again, people intuitively know this, I think, so if you want somebody to trust you, then you should give them enough power over yourself, expose yourself a bit.

<comment><USER12> This is pretty wrong. Hierarchical relationships exist all over the place, and it's still generally fine to trust your boss, or your teacher, or whatever. And in fact you can't run any kind of large organization without hierarchies, and if everyone defaults to not trusting anyone with power over them these organizations would all fall apart.

<comment><USER11> I don't think most people trust their bosses, or HR, and for a good reason. For example: [https://news.ycombinator.com/item?id=15018007](https://news.ycombinator.com/item?id=15018007)

And I think yes, larger hierarchical (actually, authoritarian would be a better word - you can have hierarchy with democracy too) organizations are inefficient, so in a sense, they have already fallen apart.

I think trust implies choice in some sense, and if you don't have a choice, then trust is meaningless.

</comment></comment></comment><comment><USER13> I used to work for Apple a long time ago and this was one of their 10 "core" values (and I'm sure they intended the pun). For whatever reason, this one value really stuck with me because I'd find that people tend to be more honest with you when you assume positive intent. Instead of trying to defend their actions, they explain what their thought process was in making decisions and taking action and are much more likely to admit when something fails. Between "assume positive intent" and "failure is an option and, sometimes, it's the best option", I find that interactions with people are much smoother and far more genuine.

<comment><USER14> This doesn't work for me. I assume so much positive intent that I give people a lot of chances without criticizing them. Even when their story makes no sense, I try to give everyone full benefit of doubt. As a result, they seem to think that I am stupid and try to repeat the same behavior.

<comment><USER13> Those are two different things, I think. Assuming positive intent doesn't say anything about giving people chances. It just means that, when someone does something, you should assume that they didn't do it to be malicious. Multiple instances of something means that they're either incapable of doing what's been asked or they have now shown/proven that their intent wasn't actually positive and your assumption was wrong.

<comment><USER15> I literally saw this headline, and immediately went to the comments to search "Apple" to see if anyone had already written this (another Apple alumni here).

There's also an aphorism with a _similar_ but different sentiment, Hanlon's Razor [1], that states: "Never attribute to malice that which is adequately explained by stupidity."

[1] [https://en.wikipedia.org/wiki/Hanlon%27s_razor](https://en.wikipedia.org/wiki/Hanlon%27s_razor)

</comment></comment></comment></comment><comment><AUTHOR> I didn't write this article, though I posted it. I've found this to be true in my life. If you assume positive intent, that engenders trust, which can actually increase goodwill. The same is true in reverse.

That doesn't mean you should be a sucker. But assuming the best of people has made me happier.

<comment><USER16> I agree in general. People act up at the level you expect them to, it is human nature.

But I also think that evidence comes far before being screwed. Watch how people talk about others. Watch how people treat others. Especially people they don't like. And always remember that you might be one of those people they don't like someday.

Focus on building relationships with people who treat people they disagree with or dislike well. Trust _those_ people. Plus, encourage that culture -- no matter how much power you have you should always treat others with respect and fairness.

</comment></comment><comment><USER17> > Marth Stout claims 4% of the population falls into this category. In short, > if you start from a place of positive intent, you are going to get screwed > over by at least one out of 1 out of every 25 people you encounter because > they literally have no moral compass.

Just a pet peeve of mine: If p% of the population has a certain trait it means that of 100 people, p will have the certain trait _on average_ \-- and not _at least_ p of 100 will have the trait.

<comment><USER18> True. I'd also point out that bad but rare events can potentially have more impact than frequent good events. It all depends on how the expected value turns out, as many gamblers and traders have discovered the hard way.

</comment></comment><comment><USER19> I believe this is good advice, but I think it's just a subset of positive thinking in general.

(Most) humans have very well developed subconscious human attitude detectors. We respond to body language, tone, vocal tension, etc., and we often do it without realizing it.

As an actor in a situation, if you can keep your thoughts focused on the positive outcomes - especially when a lot is unknown and your chance of being wrong is not obviously very low - you will express positive signals. Other people are likely to pick up on these and (perhaps subconsciously) respond in kind.

The reverse is very true, and much easier to observe. If you pay attention to other people having conversations, it's fascinating to see how one's initial approach is often met in kind by the other - whether positive/positive, or negative/negative.

Salespeople learn this, perhaps mechanically, very early. Approach a potential client with an expectation of success and an expectation that the client will want and need what is offered. The prospect picks up on this and responds with more interest, or at least a bit more consideration. Likewise, approaching expecting rejection is more likely to get rejection.

I don't have sources for these "facts", but they are echoed in many books I've read and in my human interactions I've witnessed or been involved in.

Lastly, it's just nicer for yourself if you believe people are good and of good intent. You carry less stress, you smile more (and frown less), and you are less likely to die of heart disease. This is clinically proven :).

</comment><comment><USER20> I love the concept of positive intent since the day I found out about positive intent through another blog post: The power of positive intent[0]. I was always defensive whenever I have to confront with a situation or a person. After I read the article about positive intent, I have been trying not to be defensive and instead, listen to another person first. I think this article "Assume positive intent" really complements the one that I read before.

[0] : [https://m.signalvnoise.com/the-power-of-positive- intent-5d5d...](https://m.signalvnoise.com/the-power-of-positive- intent-5d5d321a1f83)

</comment><comment><USER21> > It's 100% reasonable to have a high degree of skepticism within a low-trust > environment.

And this IMO kills it in an increasing amount of work places. I might be seeing it more pessimistic as it is, but the increased people turnover, team fluctuation, miscommunication and related factors produce a massive drop in trust between co-workers.

> Or we can start from a place of positive intent right from the beginning and > keep it there until they violate that trust.

Additionally, I would search for a way to tell people I work with about this principle. Some people begin to distrust you if they think you are kinda odd

<comment><USER22> Well-said. I worked at a place that had layoffs awhile back and it was a real bummer, in part because of the layoffs, but also because management lied about the reasons for them and the health of the company at the subsequent all- hands. Once management switches to "lie openly and often" mode all the interpersonal behavior incentives change. Like you said, it becomes reasonable to be skeptical and distrustful...

</comment></comment><comment><USER23> > 1) It's 100% reasonable to have a high degree of skepticism within a low- > trust environment.

The problem is that people aren't able to accurately judge when they are inside a low-trust environment when using one of their many digital devices.

People are watching their neighbors return from the mysterious Facebook fog spouting fake-news bullshit like it's gospel. Then they themselves blithely enter the fog with the reasoning that they would never get taken in by something so crude and obvious.

If you've ever watched a shell game in a big city that fallacy will be familiar. You watch a frustrated victim keep losing and notice a subtle thing the scammer is doing to cheat. You then place your own bet and choose the shell where the cheating scammer inconspicuously tried to move the ball.

Then you lose, too, because you didn't consider the possibility that the scammer had yet another trick prepared just for people like you who think you're smart enough to figure out the game.

<comment><USER24> What do you mean by "fake news"?

Is it yellow journalism? Right propaganda, left propaganda? Articles from the perspective of the skeptics, from the alt-right, Neo-Nazi's, communists, cultural Marxists or from radical feminists? Something else?

</comment></comment><comment><USER25> This is terrible math: [...] con artists and sociopaths out there [...] 4% of the population [...] you are going to get screwed over by at least one out of 1 out of every 25 people [...]

On the positive side, we try to put con artists in jail, so that moves the odds a bit in your favor. But con artists and sociopaths continually have to find new people to exploit as they are discovered by and/or burn out the old ones. And the skilled ones can gain disproportionate control of resources, further increasing the odds you'll be dealing with them. As an example, 99.7% of my unfiltered mail is spam, not 4%.

I think you should almost always act as if you're assuming positive intent, because that's how you build good relationships. But in practice, you should always be keeping an eye out for signs you're dealing with one of the many exploiters of the world.

<comment><USER26> > we try to put con artists in jail

or elect them into high offices

<comment><USER25> I guess the upside is that we can keep an eye on them.

</comment></comment></comment><comment><USER27> Ironically enough, the very next headline on HN at the time of writing is 'the incredible shrinking airline seat.'

You should certainly assume positive intent (or one of the many variations discussed here) when you first encounter a problem or conflict of views. On the other hand, you shouldn't cling to this idea in the face of accumulating evidence to the contrary. Some people are in fact assholes and exploit the kindness, patience, and general good nature of others in pursuit of their own selfish ends.

The sad fact is that dealing with assholes is tiring at best, stressful in general, and can be scary at worst. If the cost of accommodation seems less than the cost of confrontation, making excuses and allowances for bad behavior can become a habit. Unfortunately, so too will the bad behavior under those circumstances.

</comment><comment><USER28> There is something to be said when you are the recipient of the assumption. For me, I would make every attempt to fulfill that assumption. This is my experience when extending the assumption of positive intent. It is implicit trust. When you start from a good point, it is more likely to continue. Especially in business dealings. There is a time and place to keep a distance, but on new encounters and dealings, it is best to move forward.

</comment><comment><USER29> call me an asshole but instead of trusting or not trusting people, I trust that someone will always look out for themselves first and others second. I'm never surprised when they act that way and pleasantly surprised when they don't.

<comment><USER30> The problem with that is that it becomes a self-fulfilling prophecy. If you assume bad faith, you're more likely to act in such a way yourself, setting a low standard for the foreseeable future.

A lack of trust will also restrict your options. You'll spend more time making sure all contracts are watertight, or have to pass on opportunities if the legal system (which is the fallback option after 'trust') isn't capable to compensate.

It's also somewhat wrong on the facts: The idea of completely rational and selfish behaviour is called 'homo economicus', and it's among the worst of all the bad assumptions economics has made. Because as it turns out, it's almost impossible to find people acting in such a way outside of mental institutions.

The only rational and selfish test subjects are usually monkeys. Humans are willing to forgo all sorts of rewards for either altruistic or moral reasons.

</comment></comment><comment><USER31> First, thank you. Whether you agreed or disagreed with what I had to say, I'm honored that you would take the time to read what I've written and to speak up to add your own perspective. I've never had an article get 13,000 page views and an experience like this really helps provide a lot of motivation to continue writing.

Second, I completely understand that I could have made this article even better. I could have done more research into the existing literature, which would have resulted in the Wikipedia entries and company culture documents that were specified. When I take another pass at this article, I'll add many of these at the end for further reading. However, I will say that I in no way am claiming this to be a unique thought. In fact, I'm very clear that this was an experience I had during my career that turned out to be quite transformative. Had it been said in another way, I may not have heard it. It was this exact phrasing that both struck a chord with me and it has resonated with others (as it has done here as well). To that end, even if I could have refined this further and made it 10-20% better, it achieved its end goal.

I honestly wish I had time to review and respond to each and every one of your comments, and I will probably get to it here and there as time permits. I've made some life choices where I prioritize time with my wife and daughter after work hours, which is why I need to sneak in my writing when and where I can! That said, this is encouraging, and I thank you all once again.

</comment><comment><USER32> One of Wikipedia's main behavior guidelines is a fairly similar idea, "Assume good faith": [https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith](https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith)

<comment><USER30> Yeah–I was trying to find out what the difference to "good faith" is, and from a bit of googling, it appears to be an attempt to sell the old concept with a new name?

I somehow prefer "good faith", even though it's meaning is harder to parse when you first hear it. The 'faith' does a better job of hinting at the emotional component of the concept.

<comment><USER33> Oh come on — you are violating AGF in guessing about the "attempt to sell…". It's far more likely that this "assume positive intent" idea and post is just by people who were unaware of AGF as an existing principle. Follow AGF and just help point them and everyone here to the worked out Wikipedia concept. No need to assume bad faith of the people writing "assume positive intent"!

</comment></comment></comment><comment><USER34> "Trust by verify" is always useful. In addition to the caveats you usually have a buffer (of time). A well placed email or phone call can go a long way to clear up (or confirm) any assumptions.

Fighting or fleeing without verification is typically going to end badly.

</comment><comment><USER35> I think that 'negative intent' is equivalent to 'being stupid'.

The other thing is that 'positive intent' does not necessarily appear as 'positive intent' to everyone. Today, out walking my sister's dog I/the dog scared a Chinese tourist. There was not any malice in the dog's walnut-sized brain, just a perception problem from one of the many (maybe 25) people I met en-route.

There are also those with some narcissism due to childhood trauma and negative feedback loops. These people don't have friends and don't think to do people good turns. Unless they meet a fellow narcissist that sees the world like they do, they can only expect negative intent from people. Of course the world of sane people only see negative intent in those far up the narcissism scale. It may take them a few seconds, weeks or years to realise but eventually the 'utterly selfish' conclusion is realised.

I spent a lot of time in retail, on helpdesks and other customer facing jobs where it is commonly expected that there will be customers wanting to vent, rant and insult you. This never happened to me, it really has been happy customers all the way, admittedly with a few people let-down with promises not kept.

What surprises me is how rare my 'never treated like scum' experience has been. People with more charm and better people skills than myself have had horrible times with customers and kind of expect it. So if your mindset is to consider customers as 'idiots' then 'idiots' you will get. If you start from the 'assume positive intent' and are happy to live in a world of different abilities where you might have to teach someone 'how to use a mouse' or 'type their own name' then all is good and there is no need to be irate with anyone or for anyone to be irate with you.

</comment><comment><USER36> I used to think this but then I was required to work with two people who have what I understand to be Borderline Personality Disorder. No matter what you think you can do to get along with people with this problem you can't--they will tear you down. The only way to win is to get completely away from them and not have to interact with them.

<comment><USER37> Certainly some people with BPD are as you describe, but personality disorders exist on a continuum and painting everyone with the same brush is counterproductive. Some people with BPD are lovely people who can be difficult at times.

</comment></comment><comment><USER38> Remember, it's just as important to follow such a rule yourself, as it is to admonish others to follow. Let's not fail to hold ourselves to the same standard of behavior we expect from others.

<comment><AUTHOR> Absolutely. In fact, I'd say it is more important to follow it yourself, because:

       1. you can exert more control over yourself
       2. it will have more direct positive impact

</comment></comment><comment><USER39> I like this rule because not only does it seem to make me and the people I interact with happier, when it _doesn 't_ work (rare), I get to enjoy my warm and fuzzy moral high ground feelings. Like my dad taught me, you're never wrong to do the right thing.

</comment><comment><USER40> I think you are better off if you assume self interest and you make sure that the self interest of others serves your self interest.

<comment><USER33> Assuming good faith is slightly different than not assuming bad faith, but it's related. Self-interest and good faith are compatible in many cases. Assuming good faith is a principle worth following as a guideline, and when you recognize that it is in conflict with someone's self-interest _then_ you can be reasonable to at least recognize the likelihood that self-interest wins out.

</comment></comment><comment><USER41> > Chris could have crushed me, and yet he didn't. In fact, he did the exact > opposite and taught me an incredibly valuable lesson. Amidst the bickering > on one phone call, he asked his colleagues to stop this behavior and to > assume positive intent instead.

I think we've all had this feeling - this reassurance - from time to time. It feels great and it's important to internalize. However, with today's economy existing against the backdrop of the seemingly unstable sociopolitical dynamics of the USA, it's a little hard to know when it's truly OK to operate with this as a key assumption.

> 1) It's 100% reasonable to have a high degree of skepticism within a low- > trust environment. For example, I would never assume positive intent and > allow my daughter to be alone with a registered sex offender just because > the person claimed they had changed. I would also never trust an alcoholic > with a house full of liquor.

This is arguably an exception large enough to swallow the rule in some very important and timely circumstances.

The state is as likely to be violent as a registered sex offender, and as likely to pillage as a drunk at a liquor cabinet. In our current situation in the USA, with the state taking on a character of such ubiquity, aren't we always in a "low-trust environment?"

On the other hand, I do always assume (and in fact, almost always find) good intentions from the humans around me. But we are faced with a real need to come together and address what increasingly seems like bad intent on the part of the state, even though its actors are all humans.

How then do we move forward?

</comment><comment><USER42> This article argues that you should assume positive intent in lieu of negative intent. I'd suggest that you remain neutral and avoid making assumptions of any kind.

<comment><USER39> Why?

<comment><USER43> Because:

1) your assumption biases further thinking and perception. 2) you will be less careful (optimism bias) 3) if you're wrong there might be a big price to pay. (Including the ultimate such as life.)

</comment></comment></comment><comment><USER44> Sufficiently advanced incompetence is indistinguishable from malice.

</comment><comment><USER45> I am still waiting for "Presume good faith" to be added into HN guidelines, and I think it would help the HN community improve in terms of quality of discussions:

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

</comment><comment><USER46> The (iterated) prisoner's dilemma is a massively simplified but nevertheless (therefore?) interesting topic. It has captured our human imagination for decades, for better or for worse:

[https://www.wired.com/2004/10/new-tack-wins-prisoners- dilemm...](https://www.wired.com/2004/10/new-tack-wins-prisoners-dilemma/)

I say "for worse" because as with all oversimplified models (aka all models), there's always the risk that someone will take the results out of context and claim "But it's a fact! Science says so!". ...As they did with the original "tit-for-tat" IPD strategy, and as happens routinely with various "evolutionary justification for X" arguments.

</comment><comment><USER47> I actually think there is an extra level to this which is try to understand what people mean rather than way they say.

Way to often discussion ends up in "well you said" instead of actually trying to understand what people are saying.

But Hanlon's Razor already take care of the articles subject.

</comment><comment><USER48> Assume positive intent, but set boundaries. The first part sounds like wishful thinking but it merely reflects the fact that there are no bad intentions, only mistaken ideas about what is good. The second part reflects the fact that some people know more than others.

<comment><USER43> There are objectively bad intentions. For example extreme egoism (intent to gain at any cost) or pathologies. (Criminal notwithstanding.)

<comment><USER48> No I think that people with extreme egoism genuinely think that loving only themselves is the right thing to do.

</comment></comment></comment><comment><USER49> > _Well, there are two different ways. We can start from a place of skepticism > until someone has proven themselves worthy to be trusted. Or we can start > from a place of positive intent right from the beginning and keep it there > until they violate that trust._

I've worked for years in both France and the US, and I feel like it's been a useful simplification that the French start not trusting you until they do, whereas Americans will start trusting you until they don't.

I've heard it described that the French have the latin attitude (shared with Spain and Italy, not with Germany or England), and it's a fun enough explanation that I'm holding on to it :)

</comment><comment><USER50> This only works if the confrontee assumes the same. Which is often not the case. People usually think others can read their mind, and don't communicate their issues sufficiently well. The natural response to that lack of information is to make things up to have a coherent mental model. Over time this model tends to diverge from the ground truth, sometimes exponentially. As a result you get conflict, assumed malice, and other kinds of misunderstanding. The frustrating thing about all this is without grounds to unconditionally assume benevolence of the other party (i.e. without being close friends), this is largely unavoidable.

</comment><comment><USER51> I first came across this phrase a decade ago in Forbes as the best piece of advice Pepsi's CEO ever got. It's one thing that has always stuck with me. We often let our own insecurities misrepresent other people's intentions.

</comment><comment><USER52> Looks to me, the winning strategy. Various strategies around trust have been very nicely gamified here: [http://ncase.me/trust/](http://ncase.me/trust/)

</comment><comment> aaron-lebo He says 1/25 people in the general population are sociopaths.

It would be interesting to know whether that ratio changes as power increases. Maybe execs are closer to 1/10th because sociopaths would both be attracted to control and their lack of scruples is a great advantage.

Of course, if a lot of people in power are sociopaths, than that's a huge drag on any social system assuming positive intent.

<comment><USER53> Sociopaths are violent, the coloquial use is actually reversed from the clinical use. Psychopaths are what most people who use "sociopath" mean. Sociopath != social psychopath. Sociopaths are 100% always violent and zero empathy. Terrifying people. Stab you for your cell phone scary, not politically outmanuever you or work in sales as a profession scary. Psychopathy is the spectrum in question, and it does increase as you get higher power jobs. The recipe for psychopathy would be high cognitive empathy, low emotional empathy, high need to control environment. A low IQ person with those characteristics might be violent or not, and probably adapts to those traits pretty poorly socially speaking. A high IQ person with those characteristics would figure out how to use them to their advantage. It isn't that you have to be a genius psychopath to be successful, it is just that being a genius and removing the constraint of caring about harm to others certainly helps.

<comment><USER54> Interesting, in the colloquial use, I kind of thought it was exactly the reverse, maybe it's the colloqiual 'psycho' in 'psychopath.' I think most people use this colloquially in the reverse, thinking the 'psychopaths' are the dangerous ones.

Hmm, this article suggests that neither one is a technical DSM term _and_ that it's the reverse of what you say, psychopath is "worse".

[http://www.webmd.com/mental-health/features/sociopath- psycho...](http://www.webmd.com/mental-health/features/sociopath-psychopath- difference#1)

</comment></comment></comment><comment><USER55> By nature I assume negative intent and over the course of my life it's probably cost me and possibly others, a lot. But then a small percentage of people think the best of everyone and end up paying for it with their lives.

</comment><comment><USER56> This is also known as the principle of charity:

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

</comment><comment><USER57> OK, so I am guessing they stopped arguing during that meeting, but what was the resolution for the project? Did it get completed?

</comment><comment><USER58> The road to hell is paved with good intentions.

</comment><comment><USER59> ...said the Wolf to the Three Little Pigs.

<comment><USER33> …except in nearly every case there was no Wolf, it was just the Boy Who Cried Wolf.

<comment><USER59> ...in which case it would be folly to "assume positive intent" on the part of the Boy.

Stipulated: undue suspicion is as much a failure mode as insufficient suspicion. _Both_ hazards might be implicated in any particular situation. That's why it's a mistake to make hard and fast rules. A sense of proportion is valuable.

<comment><USER33> Assume Good Faith (I'm not going to go with the "positive intent" version, I'm sticking to the known, better formulated Wikipedia principle) doesn't mean you should blindly truly _assume_ it literally, it means that when you interact with people, you should _consider_ how they could be saying what they are saying with good faith and engage in the discourse with that assumption.

AGF is a rule in the sense that if you don't _know_ someone's bad faith, you must _act_ as thought they have good faith as a rule for maintaining healthy discourse. It does _not_ mean you assume good faith to the point of allowing yourself to be vulnerable or agree to anything based on that good-faith assumption.

In short: Assume Good Faith in how you _communicate_ , but _verify_ good faith with certainty if your decisions rely on it.

</comment></comment></comment></comment><comment><USER60> The comments disturb me:

> Surprising you didn't talk about trusting your gut.

>> I will admit that I struggle with finding a balance between brevity and comprehensiveness. You're suggestion is absolutely right in that I could have put some additional guidance on using common sense and/or trusting one's guts/instincts when something doesn't feel right and it makes more sense to be more cautious.

This seems to be a disturbing trend recently. Inflating people's sense that their biases are not only valuable inputs but actually accurate. This flies in the face of all quantitative studies that show exactly the opposite.

I think the most egregious thing I've seen recently along these lines was a Sam Harris podcast about "the gift of fear"

[https://www.youtube.com/watch?v=Uh9OpbJXOHA](https://www.youtube.com/watch?v=Uh9OpbJXOHA)

<comment><USER43> Somme thoughts are stereotypes and not biases. As opposed to biases stereotypes are widespread averages of observations and likely to be on average accurate... Which is course does not mean they will be accurate for any specific case. There is such a thing as prior knowledge.</comment></comment>


Pichai on Google's Vision, Mobile Revenue, Apple and China - <AUTHOR> http://www.forbes.com/sites/miguelhelft/2015/02/26/exclusive-pichai-on-googles-vision-mobile-revenue-apple-and-china/ <comment><USER2> Dude is a politician. Those were really boring answers.

<comment><USER3> I agree. I am not a stakeholder at google, but I have a pessimistic forecast of google's strategy going forward.</comment></comment>


When should I use Node  for back end? - <AUTHOR> http://www.atulr.com/blog-atul/web/2016/11/05/nodejs-usage.html <comment><USER3> I imagine I'll get downvoted for participating in the language flame wars but....

I've been working on a NodeJS backend at my main gig for the last two years.

For two years before that I was working on an backend application written in C#.

Based on my experience with those two systems, the answer to the question "When should I use Node for the back end?" should be: Only if your main language is javascript and you don't have the time and/or inclination to learn something else.

For me, working with C# was massively more productive. Static typing, robust async/await, and the fantastic tooling you get with Visual Studio + Resharper are huge benefits. Dynamic typing, callbacks and/or weird promise logic, and dodgy open source libraries which may not be very well documented or maintained are huge downsides for Node JS.

I would never choose to write a new project's backend in Node JS.

YMMV.

<comment><USER4> _I imagine I 'll get downvoted for participating in the language flame wars but...._

From the guidelines:

 _Please don 't bait other users by inviting them to downvote you or announce that you expect to get downvoted. _

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

If you think you might get down voted, take extra care to ensure you're expressing your thoughts clearly and civilly. There are those who will down- vote regardless, but you can "decrease the attack surface" by writing the best comment you can.

<comment><USER3> I apologize. I was unaware of that rule. I won't do it again.

<comment><USER4> No need to apologize. Just wanted to bring it to your attention as you'll likely get down voted just for mentioning downvoting.

<comment><USER5> See!

</comment></comment></comment></comment></comment><comment><USER6> I beg to differ with node being the "best choice" for IO intensive ops. Java performance will be better on IO as well, as long as you're using NIO or something like EPOLL native bindings in Netty, which is asynchronous like node but also multi threaded.

The point is that node is not that fast. If performance is paramount don't use it. Node really shines when you need to use client side libraries on the server. The two best uses I've seen is server side rendering of pages and html5 canvas for browser based painting apps

<comment><USER7> In line with my experience as a Java 8 NIO and latest node user, node basically performs identically to the best Netty implementation in IO-bound tasks. That parity could be attributed to relentless optimization of a fundamentally pretty straightforward problem in V8 that finally made it to the latest node.

My experience matches the TechEmpower benchmarks, which you should check out here: [https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/) . They didn't get much discussion when posted.

<comment><USER6> Fortunes is not IO bound. Plaintext bench definitely is and node is around 8x slower than the fastest frameworks.

Node is nowhere near raw netty performance in most situations and will never be. Js is single threaded, dynamically typed, and doesn't have low enough level access to the OS. Netty has a native network IO interface on linux.

Node is pretty respectable but netty is basically the fastest thing there is unless you're doing C. It even uses native zero copy buffers with the ByteBuf implementation, something js doesn't (and cannot) do with its dynamic typing.

The JVM has had a much longer period of relentless optimization and the language was designed to be well optimized. Js will never escape the performance penalty of dynamic typing and other decisions without a rewrite

</comment></comment></comment><comment><USER8> While it's true that node can handle CPU intense tasks with WebWorkers or some other clustering there are also memory concerns. Node _can_ doesn't mean it _should_ with the exception of keeping your stack simpler (a single language). But that's a compromise to achieve a different goal.

I personally like Go more these days because it doesn't have these problems, it's very easy to do concurrency, and it's memory overhead is much lower. This in contrast to my other favorite option, python, which is a nicer language imo, but it's concurrency story is worse and memory overhead is about on par (varying from case to case, but my point being they're both much more than Go).

</comment><comment><USER9> This is why node is powerful when used with AWS Lambda, you can treat CPU bound tasks as if they were IO. You can also do this by routing the job to a different processor on the same machine. Node is best when used as a relay or hub between many services and clients. Let those services do the computing work, let node manage everything and do the IO work.

Node is kind of like an airport. Airports let you order food, alcohol, and even other cities. But as soon as you order, all of the work is offloaded to a third party -- the restaurant, the bar, or the airplane -- allowing the airport to handle someone else.

</comment><comment><USER10> The main point of the article is correct; NodeJS is not for CPU-intensive applications.

Here's a more verbose article on the topic, circa 2013:

[https://www.toptal.com/nodejs/why-the-hell-would-i-use- node-...](https://www.toptal.com/nodejs/why-the-hell-would-i-use-node-js)

</comment><comment><USER11> When your team is composed of node developers.

I would choose it over Python or Ruby, because Typescript and Flow are great type systems.

Source: lead node dev / CTO since it came out. Currently using Haskell for all new projects.

<comment><USER12> I would guess that you'd fall in love with Purescript:

[http://www.purescript.org/](http://www.purescript.org/)

<comment><USER11> I like purescript a lot. But the elm community has won me over. It's well designed and productive.

</comment></comment></comment><comment><USER13> Pardon my ignorance, but does Node improve as the V8 engine (or Microsoft's Chakra engine) improves?

Also, when/if GraalVM becomes public, would Node then be more suitable for CPU intensive apps?

I love javascript but never quite grok'd it as a server side language. I wouldn't mind using it, but have never found a good use case and this article hasn't really convinced me to delve into it.

Edit: I have found that it has been pretty neat for some command line integrations, but lately, I have been falling back to Ruby.

<comment><USER6> Yeah but I doubt it will ever hit parity with c#/Java/go. The lack of static typing and other fundamental languages choices will keep it from ever being as fast as those. V8 and friends were built out of necessity not because js was ever a good lang to begin with.

I really have no idea why anyone would take a language as terribly designed as JavaScript and try to put it everywhere. Non existant typing system, crazy semantics, and lack of true multithreading will always make it second rate to the others

<comment><USER13> Actually, I could be mistaken, but Node on top of GraalVM _should_ give it closer parity with Java.

I saw this video ([https://www.youtube.com/watch?v=lYGfD2H99Ls](https://www.youtube.com/watch?v=lYGfD2H99Ls)) earlier this year, would be interested to see when and if this could be implemented in the mainstream.

<comment><USER6> V8 does almost everything JVM does, the problem is mostly in js dynamic typing and weak object implementation. There's a lot of runtime checks that just can't be optimized out. I would expect js to reach maybe a third of JVM performance but thats probably the limit

</comment></comment></comment></comment><comment><USER14> I use NodeJS like AWS lambda functions but running on my own tiny VPS (Digital Ocean droplets). Why instead of lambda? B/c I have zero restrictions on NPM packages and many other things I can use. Now, I do not write full APIs, instead I use everything a BAAS has to offer (like Firebase) and complement what it lacks. For example:

\- When a Firebase ref changes I listen to the event in Nodejs and update a full text search index elsewhere.

\- When a Firebase ref is created I send the appropriate transactional email/push/sms.

\- Do data validations before pushing to Firebase.

So in general, I do things that cannot/should not be done on the client-side while still opting for _serverless_ architectures.

PS: Parse.com was great in that it had server-side code that was run on events like object updated/created. The code was NodeJS. In sum, it had lambda-like functionality already built-in. But Parse.com closed shop. Not sure if any of its spin-offs are offering a good service at decent prices.

</comment><comment><USER15> I'd still ( and have ) used node for cpu intensive stuff. If you have a long running computation that can be broken down (mine was 500-2000 steps), you can break the single process by `setTimeout(...,0)` the next step, so other stuff can serve pages. Or, you can break it out into a c job.

<comment><USER16> You might want to check out process.nextTick: [https://howtonode.org/understanding-process-next- tick](https://howtonode.org/understanding-process-next-tick)

</comment></comment><comment><USER17> One good spot that comes to mind is when you implement "Backend For Frontend" style APIs for your clients in a microservices environment. Assuming you have a single page app in JS, you can have the front-end team own their specific API implementation and have them work in the language they know best. There's often also the possibility to reuse some code between the two.

Apart from that, I'm a JS hater, so I would personally always avoid Node - <USER2> neither like the language nor the server-side model, I don't think either one scales well, and there are better solutions out there for the server side (besides the JVM and .NET based stuff in the other comments, I like BEAM-based things like Elixir these days).

</comment><comment><USER18> You should use Node.js for back end when you make WEB APPS and want to deliver real time updates and run background processes. Node.js has a very robust ecosystem that integrates well with front end Javascript.

</comment><comment><USER19> When the front-end is JavaScript and may share code with the backend or when you find an applicable package in npm. Or when you know JavaScript better than other languages.

</comment><comment><USER20> There are modules that you can use to make node work for CPU intensive tasks. Search for WebWorkers.

The real idea is don't do CPU intensive tasks in the event loop thread.

<comment><USER21> We all have different performance requirements, but in my experience, when you actually care about the performance of CPU intensive task, child_process.fork or WebWorkers are still insufficient.

Instead, sometimes you use node native modules, sometimes you separate you child_process.spawn something written in Go, C++, or Rust(,etc), and sometimes you set up a separate work "queue" to pass work either on the same machine or over the network. I've used both kafka, zeromq, or even just files on the s3. A linux domain socket is nice too.

<comment><USER20> The performance of the CPU bound task and performing any CPU bound task on the main IO thread are 2 different things. The article was about the problem you face when you do CPU bound task on the main IO thread.

The WebWorkers and other approaches are about how to avoid using the IO thread to do CPU tasks. How the performance of those CPU tasks is depends on other factors. You can use WebAssembly or asm.js code to reach the performance of natively compiled code.

</comment></comment></comment><comment><USER22> Go with Go, my son...

</comment><comment><USER23> Ok, so for me the problem for Node is:

a) So you reimplemented all of the goodness of twisted in javascript? :) b) and you have to debug that new pile of code? c) with a language (in it's original form) that has a bunch of issues, despite being fun to develop in

Maybe Node with an ES6 backend? Maybe that's better. However, from my perspective, event based development works for some apps but is a total PITA for traditional workloads (websites).

I would think about Node for a messaging use case, or message processing.

</comment><comment><USER16> I don't necessarily buy being blocked by CPU-intensive operations as a rationale as to why you shouldn't Node, given that it's pretty trivial to offload these onto a separate process.

[https://github.com/LearnBoost/cluster](https://github.com/LearnBoost/cluster) \- one I've used

<comment><USER6> It is non trivial to share state between node threads. The state is shuffled around outside of the VM unlike go, Java, and c#. In those languages, the overhead of sharing a variable are basically zero.

In node you get sharing at basically the speed of TCP local sockets on the machine. So maybe 5GBps. With natively threaded languages you get sharing at the speed of the cpu cache, orders of magnitude faster

If performance is important enough that multithreading comes into play, don't use node.

<comment><USER19> See `webworker-threads`.

<comment><USER6> They don't share variables low level, so the problem remains. In Java and similar languages the variables are shared at the machine level, including atomics

</comment></comment></comment></comment><comment><USER24> When your boss tells you to.

</comment><comment><USER25> i'm going to get downvoted on this for sure, but basically if you enjoy writing mindless, infinitely nested callbacks then nodejs is for you.

i liked the package manager npm, but otherwise i prefer golang all the way for backend code.

<comment><USER26> I prefer Rails or Elixir, but golang is a solid choice.

<comment><USER25> came from ror/sinatra, but really like the deployment ease of golang, just copy a binary, dont need rvm, ruby interpreter, gems, etc. i think the performance is much better for golang, but i dont like golang's orms and the templating languages really suck relative to haml, etc. i mostly use golang for restful api backends and mobile on the frontend (mobile first), but for dynamic websites, golang is not that interesting.

</comment></comment></comment><comment><USER27> Never

<comment><USER6> I feel you. My god js is still horrible. Why anyone would willing develop more than they have to in it is beyond me.

Yeah we have ES(x) coming and typescript and node yay! All of the stuff coming to js has existed in better form in other mainstream languages for many years. Even stuff js still doesn't even have on the roadmap like multithreading, true static typing, and compilation

Are mainstream js developers really that ignorant of what is out there to suggest running js on the server all the time?

<comment><USER28> > Are mainstream js developers really that ignorant of what is out there to > suggest running js on the server all the time?

No. At least not the high caliber ones.

There are those that know only know JavaScript and will try to make everything fit. Although, you can say that about people who only know Java, or Python, etc.</comment></comment></comment>


Taboo word fluency and knowledge of slurs and general pejoratives - <AUTHOR> http://www.sciencedirect.com/science/article/pii/S038800011400151X <comment><USER2> Somewhat related, it seems like no paper on this topic could come close to the seminally named article, "Fuck", which was downloaded so many times on SSRN that it shot Ohio State University to the top of the law school rankings, which then revealed how flawed the ranking system was and involved editorial censure and the unraveling of said law school rankings, and then was followed up with the hilarious "Fuck and Law Faculty Rankings".

[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=896790](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=896790)

[http://papers.ssrn.com/sol3/papers.cfm?abstract_id=971103](http://papers.ssrn.com/sol3/papers.cfm?abstract_id=971103)

<comment><USER3> Chris Fairman who wrote those papers, was a great teacher, but sadly he died this summer of a heart attack at 54. Thank you for reminding me to review some of his excellent work!

</comment></comment><comment><USER4> Reminds me of this video with Stephen Fry: [https://www.youtube.com/watch?v=s_osQvkeNRM](https://www.youtube.com/watch?v=s_osQvkeNRM)

</comment><comment><USER5> My wife is Chinese and was raised by academics. I have asked her over the years what pejorative words they used for white people or Americans, especially in propaganda. Unfortunately she is so sheltered and nerdy, and her parents so genteel, that the best she could come up with was "ghost" or "Yankee".

<comment><USER6> I don't see the big problem with "ghost"? That was the term Maoist propaganda used, possibly more familiar to you as "foreign devil" 洋鬼子.

I just asked a Chinese friend (who lives now and always has lived in China, and the same one who informed me Indians were called 阿三); here's what she said:

Her:

指美国人??? [referring to Americans???]

美帝算么。。。 [does 美帝 "American imperialist(s)" count...]

Me:

指白种人也行 [or referring to white people]

有吗 :p [is there such a word :p ]

Her:

洋鬼子? [ghost?] [ok, I've editorialized that to match your wife. But I don't see the problem with glossing it that way; 洋 explicitly refers to foreignness, but 鬼 really does mean ghost.]

Me:

你怎么问我呢? [why are you asking me?]

Her:

呃。。那应该就这一个了 [oh.. then it should be this one]

<comment><USER5> I agree! I wanted something juicer...

<comment><USER6> Surely the juiciness is in how it's perceived? What's so juicy about "kike"? It doesn't even have semantics.</comment></comment></comment></comment>


Managing Remote Dev Teams If You're Nontechnical - <AUTHOR> https://youteam.co.uk/blog/7-steps-to-managing-remote-developer-teams-if-you-re-nontechnical/ <comment><USER2> Great article. There is an increasing demand for project management on development but at the same time, too few developers make the switch. As a result, more and more folks are getting technical. The biggest issue I've seen is the lack of control over the development team as a non-technical guy. A lot of entrepreneurs and managers don't know if they're getting their money' worth. Since I've been facing this issue myself along with a good number of entrepreneurs I encountered, I started working on a product to give more clarity. We're still battling with some tweaks here and there but would love some feedback from non-technical guys to further improve it. Feel free to check it out --> [https://waydev.co/](https://waydev.co/) and of course, reply here or grab me by email for any feedback or discussions (firstname.lastname@example.com)

</comment><comment><AUTHOR> OP here: I wrote this post to shed some light on everything I've learned about managing remote developer teams when you're nontechnical (as in you don't write usable code for your product).

I also wrote this to shed light on how we build product at The Lobby, in hopes that it will attract the candidate we're looking for to lead our engineering efforts in NYC.

Happy to answer questions or discuss anything here!

<comment><USER3> Just so you know, in case you want to fix it, a second after the article renders, it moves down such that I have to scroll down to half the scrollbar to see the beginning. That's some 9 or 10 screenfuls.

<comment><USER4> Hi! The publisher is here. Tried to re-produce this bug, but couldn't. Can you give me more details on your browser and OS please?

<comment><USER3> Browser is Firefox 61.0; OS is Archlinux.

        https://s8.postimg.cc/4tz02ffxh/site-top.png
        https://s8.postimg.cc/whbpgkbet/site-4-screenfuls-down.png
        https://s8.postimg.cc/qge0jiz39/site-article-start.png

Note the scrollbar.

EDIT: Just tried with chromium 67.0.3396.87. Same thing happens.

        https://s8.postimg.cc/4wivoy6mt/chromium-top.png
        https://s8.postimg.cc/v4u0ebyg5/chromium-article-start.png

EDIT 2: I noticed the image service down-scaled the images. The size of the windows is 956x979 pixels, if you're interested.

</comment></comment></comment></comment><comment><USER5> Great advice. After having worked with a remote team that insisted on doing everything using waterfall, for months at a time before sharing any code/demos, I would never ever do that again. OP's advice about working in short sprints is spot-on.

<comment><AUTHOR> glad it resonates, painful stuff using waterfall at this stage

</comment></comment><comment><USER6> Naive question, isn't it better for a technical person to lead a dev team ?

<comment><AUTHOR> Probably, but not everyone has the luxury of a great tech person to lead their remote tech team.

Also, if it's a field where the nontechnical person has some level of domain expertise, they arguably have a better sense of product direction, even if they're lacking product dev mechanics.

I hope this post helps them get those mechanics!

</comment></comment><comment><USER7> Hey Deepak, this is really well written and has some great points! Keep it up.

<comment><AUTHOR> Thanks!!

</comment></comment><comment><USER8> Fantastically actionable advice! Love the manual idea testing and leadership tips

<comment><AUTHOR> Glad you like it + appreciate the kind words.

</comment></comment><comment><USER9> Great article.I needed this right now. Coming from a non technical background also this was really helpful.

<comment><AUTHOR> Glad it helps!

</comment></comment><comment><USER10> Great post. Will be forwarding this to all my non-technical founders.

<comment><AUTHOR> Glad it's useful!</comment></comment>


Mapping Drug Use by Testing Sewer Water - <AUTHOR> http://www.schneier.com/blog/archives/2009/07/mapping_drug_us.html <comment><USER2> Expensive to do on per individual basis if it is for government curiosity, but can be used by corporation - let say some company that have unstable staff, such as retailers, fast food chains, installs a device in the bathroom, collect samples and once in let's say month send them to the lab. Can be used for discrimination to enforce occasional drug users to work for smaller salaries...</comment>


Branchless development - <AUTHOR> http://www.tedunangst.com/flak/post/branchless-development <comment><USER3> Branching or not is somewhat of a red herring. If you are working on a commit then while you haven't pushed that commit, you're effectively working on a branch. If somebody else works on the same code at the same time, then those changes need to be merged. Whether your VCS does or doesn't call that a branch is immaterial. What matters is that two developers can work on the same code at the same time, and that you need to solve concurrent editing conflicts (logical ones, not just the textual ones that your VCS will find).

The pertinent question is _how often_ you merge. On one end of the scale you merge on every keystroke. Every time Joe types a character it gets put into Anna's files. Clearly this doesn't work. On the other end of the scale every developer works on their own copy, and all the work gets merged just before a release. Clearly this doesn't work either. There is a scale from maximal disruption minimal effort merging to minimal disruption maximal effort merging. You want to find a point on that scale that minimizes the total amount of work.

<comment><USER4> This is super-important; it is far better for a developer to push a non- working feature on a feature branch than for them to leave it on their machine. They ought to do whatever the equivalent is of a git rebase every morning or evening, so that it is still at least nightly integrated for them.

<comment><USER5> Keep in mind though that if everyone is working on something that takes multiple days to complete (and your definition of non-working is incomplete) then all the work is happening in feature branches and master is quiet. Those rebases are easy because no work is going on there.

Feature toggles remove this problem by keeping everyone in trunk/master. You can then have CI builds with whatever set of toggles you want.

<comment><USER4> Feature toggles are a good option too; I have used that before and like it. The downside is that you can end up with a giant set of feature toggles and very little idea of which combinations work.

<comment><USER6> Use automated integration tests and test every combination.

<comment><USER4> Exponential runtime.

<comment><USER6> Don't overdo it, use coarse grained switches.

Throw hardware at it.

Switches are temporary, with time their number will settle.

<comment><USER7> "It's just temporary" is one of the five famous last words (together with "it worked on my machine"). It can easily turn into one of those projects where someone just shoved in autoconf to turn them into a giant ball of IFDEFs so nobody really knows which combinations work.

Toggling also only makes sense for the cases where you don't change the structure of your data. So be careful, and make sure you have a plan if you decide to do it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> ..and the circle is complete.

If you're a fan of this workflow then I can recommend using Visual Source Safe. It even has exclusive locks which completely eliminate merge conflicts.

I've been building software professionally for almost 20 years, I've seen (and experimented) with almost every VCS/SCM strategy imaginable.

My conclusions:

This only really works for tiny teams - 2-3 people who work very well together. It needs high bandwidth communication.

For teams of 3-10 short lived feature branches are effective with a little bit of planning to minimize merge conflicts.

For larger teams you really have to split the system into self-contained modules or microservices, each module having clear owner. These modules are then shared as source, library or service depending on the actual needs.

I've never had good experiences with longly lived branches. They can work whilst adding experimental modules which require only a couple of tiny API changes to the main system; but then splitting the module into a separate project/repository and making the API changes (behind an #IFDEF) makes more sense.

<comment><USER5> In my experience, if you have high bandwidth communication (e.g. a team room) then trunk based development scales to well beyond 2-3 people. I've seen it work on at least one large distributed teams (3 team rooms, 3 time zones, ~30 developers)..and it regularly works on teams of 6-10 developers.

Regarding VSS and exclusive locks. No. Trunk based development with no exclusive locks is fine. Pessimistic locking was unwarranted pessimism when applied to source control.

Also, note that Google is trunk based...with a single trunk across the whole company. I think Facebook is too?

<comment><USER8> In that case you were absolutely having merge conflicts - only you were forced to resolve them the second you updated your local working copy.

Over the years I've lost so much time to small errors resolving merges - particularly the type which involved cross-file refactoring (where two people have moved methods and then refactored them).

The beauty of using branches - especially with Git - is that you as developer gain a lot of power over how you apply merges. The "pre" state is also under version control, so you can always go back. Plus if you're using Git then you're implicitly doing branch-based development (git clone creates a local branch).

My current team of 6 developers switched from TFS trunk-based to Git with short-lived feature branches and they've not looked back. We've greatly reduced merge issues and downtime caused by bad check-ins. Both still happen, only less than before.

<comment><USER5> Of course we still have merge conflicts. You do too. Or is your work just organized such that no two people are ever working on the same file concurrently? If it is then you'd not have any merge conflicts with trunk based development either.

Fundamentally merge conflicts are unavoidable.

The claim by the trunk based development crowd is that smaller, but more frequent merge conflicts produce fewer mistakes. Trunk based development leads to smaller merges because you do them more frequently. That's about it.

<comment><USER9> Working on the same file concurrently does not guarantee conflicts - <USER2> on the same _code_ does.

We recently switched to short-lived feature branches (short-lived as in a couple of days maximum), and I haven't had to resolve merge conflicts in months. Our feature branches previously used to last around two weeks and merging things in was collectively not looked forward to. Now I don't even have to give it a second thought.

tl;dr not having merge conflicts is an entirely possible happy reality.

<comment><USER5> Sure. My point is that avoiding merge conflicts has nothing to do with your branching strategy...it has to do with what work you parallelize.

</comment></comment></comment></comment></comment></comment><comment><USER10> So if I'm understanding correctly, this terribly written article (he tries to make a point about merging but doesn't actually make it amongst other points he fails to even state) suggests using feature branches inside the code instead of feature branches within source control. It also requires mini code reviews and merging at every single commit. You _cannot_ get rid of merging. Instead of doing it once when merging a branch, however, you're now doing it every commit. Since you're merging smaller chunks, it's impossible to see the bigger picture of the whole feature as you merge/review, and it removes the ability to do meaningful code reviews on features before they actually get into the main code base. Not only that, sometimes you end up in a race with your teammates, knowing that you're working on the same piece of code and that whomever checks it in last will have to merge. Stupid, but it can happen.

To me, the ability to have logical separation of the features being built and do meaningful code reviews far outweighs any proposed speed benefits of not branching, benefits that I assume show up only in larger groups as they certainly don't show up in small groups. Which bring me to my last point, the "slow is fast" section, which doesn't provide any evidence that slow is fast. Other than users not having to decide which branch to run (which takes all of two seconds, BTW), development is much faster with feature branches and the other negatives do not show up in my experience. What I'm trying to say is that "fast is fast." Slow is not fast and the author doesn't make his point there either.

tl;dr: All in all, he points to no actual pros to branch-less development.

<comment><USER6> Heh, there's always opposition to new practices. Branching has been mainstream for a long time, it's only fair to expect resistance to any alternatives.

Give it a few years and everybody will use feature switching, except the old man enterprise dev :)

There are a million things that feature switching let's you do. Enable and disable instantly, enable for .00001% of the users, integration test different combinations, etc.

[https://secure.phabricator.com/book/phabflavor/article/recom...](https://secure.phabricator.com/book/phabflavor/article/recommendations_on_branching/)

<comment><USER10> In my experience, branching has only been mainstream since git became popular a couple of years ago. Before that, when using svn and other similar systems, branching per feature was unlikely in my experience and a major pain.

<comment><USER7> Branching is very well supported in Subversion. There is a reason feature branches occupy a large part of the SVN Book.

I would say feature branches were mainstream usage of CVS too, but SVN made it more popular because merging is more effortless.

Github probably popularized it, because they put a web interface on it (which is great), but that can be said for a lot of things.

</comment></comment></comment></comment><comment><USER11> That's fine until you have a 4 MLoC behemoth with 50 developers (I use that term loosely) that isn't separated into logical concerns properly like your average "enterprise product".

I've seen those things and what you end up with is a dev team in tears because some chump has fluffed the source tree, the integration build is still running so no one else knows and checks out the trunk followed by boom and 2 days of paralysis while everyone works all their changes back into it for a checkpoint build.

All mature products tend to evolve into this state unfortunately.

Ergo, that works on small things but doesn't scale. Minimally, using feature branches and integrating them in turn is the only situation that works on those sorts of products.

<comment><USER12> Facebook seems to be managing with 1k+ developers and 50+ MLoc ([https://secure.phabricator.com/book/phabflavor/article/recom...](https://secure.phabricator.com/book/phabflavor/article/recommendations_on_branching/)).

I'm not entirely convinced either, but the argument isn't without success stories.

</comment></comment><comment><USER13> People in academia have proposed a number of tools & approaches on how to enable concurrent development while mitigating the "risks" of branching.

To name just a few:

* Palantir by A. Sarma et al. [1]

* Crystal by Y. Brun [2]

* CloudStudio (project I worked on); Video demo: [https://youtu.be/R3Fz0Tcdz0Y](https://youtu.be/R3Fz0Tcdz0Y)

To the best of my knowledge, however, none of these projects have found any widespread adaption. A lot of it also has to do - I think - with culture and personal preference.

[1] [https://scholar.google.de/citations?user=shMjCasAAAAJ](https://scholar.google.de/citations?user=shMjCasAAAAJ)

[2] [http://homes.cs.washington.edu/~mernst/pubs/vc-conflicts- fse...](http://homes.cs.washington.edu/~mernst/pubs/vc-conflicts- fse2011-tooldemo.pdf)

</comment><comment> glass- People thinking and saying that this only works for small teams should take a look at how many devs are listed in OpenBSD's latest release announcement.

Hint: it's more than 2, more than 3, and more than 50.

<comment><USER14> How many have direct commit access? If you're sending patches over email, guess what: you're doing merges, whether you call them so or not.

</comment></comment><comment><USER15> I'm also a big fan - for a tight team anyway, might be harder for a more distributed project - you should eat your own dog food - more incentive to not check in crap and an incentive to fix broken stuff fast.

Having an autobuild system to build every checkin is a big plus.

I worked on a chip once where we decided to make everything a branch, at one horrible point we didn't have a mainline, we didn't know what we were building, we had to put people on full time merging trying to figure out what to test.

</comment><comment><USER16> The thesis of this post is that merge conflicts basically negate all of the other benefits a branched workflow provides. I'm not sure how the workflow the author suggests deals with concurrent changes to code otherwise though, and I feel like merge conflicts are preferable to changes that overwrite other changes. Not taking advantage of branching destroys much of the benefit a DVCS provides.

In order for this workflow to be reasonable for any development team of a size greater than about 3, each commit would need to move all the code in to a working state. While a reasonable pattern in theory (Don't TRY commit breaking changes!), it is frequently useful to track code in an intermediate state. Sometimes (read frequently), this code may not be representative of the final state of the technology or may not even work as it should. Not maintaining individual branches means that these changes are exposed to the entire team and can be very very messy.

All in all, what a silly approach to revision control. Take advantage of the latest patterns and a system that provides the loosest coupling and highest distribution. If we do as the author advocates, we might as well all just switch back to CVS...

<comment><USER17> We have a team of 50 and single branch works well for us.

> merge conflicts are preferable to changes that overwrite other changes

Nobody is saying that. The difference is really merging as you go vs doing one big merge at the end. I personally fall on the side that it's far easier to merge as you go.

<comment><USER16> You merge as you go in branched development too?

Master is typically periodically pulled into the feature branch to ensure you're working against the most current version of the codebase.

EDIT: Yes, this can create an ugly revision history, but that's what rebasing is for, right?

<comment><USER5> If everyone is working in feature branches then you're still merging less often. Until you've merged your work into master then I'm not merging it into my feature branch. That leads to bigger merges than if everyone is committing to master all the time.

Pros or cons of each aside, advocates of feature branch based development should recognize that they are merging less often than they would if they were doing trunk based development.

</comment></comment></comment></comment><comment><USER18> I'll fully accept that it's Teds experience that this works for OpenBSD. I'd be hesitant to draw any conclusions from that concerning the viability of the same process for any other project or organisation.

An open source project with highly motivated and capable developers and a benevolent dictator in charge functions differently from other projects and organisations. A process needs to be attuned to the people, and the relations between those involved, involved.

</comment><comment><USER19> For long lived branches, I prefer to track and review the work done on master and merge master into the branch every often, I do every day. You'll handle the conflicts more easily, as they come and you'll get fresh insight/explanation from your coworkers. All at once at the end, and you end up in a nightmare of "Do you remember when you XXXX N weeks ago ?"

Diverge and merge at the end is quite utopist on complex projects.

</comment><comment><USER20> It would be nice to have some kind of monitoring system that warns me when another user is editing (or has edited) the same file(s) as me. Then we could talk, or one of us could wait, to prevent merge conflicts in the first place.

Of course, this would be even more useful if it only alarms the users whenever they have created a merge conflict.

</comment><comment><USER21> Branchless development is a terrible idea. I think what the author is wanting to avoid is long lived branches. Keep your branches small, isolated, get your changes into the main branch as soon as possible, but develop each atomic change independently of it. We do this at Gumroad, keeping our branches as small as possible, and it's amazing.

</comment><comment><USER22> I work without branches but with a large number of good tests, and it works like a charm. On the other hand, I know people who can spend several days to merge their one week changes back to the master which is a great waste of time and really boring.

</comment><comment><USER23> We make tests to solve subtle merge bugs like the article's example about dialogs, and watching what the other team members are merging help miles too.

</comment><comment><USER24> How would this development style be compatible with code reviews?

<comment><USER25> It's not, in my view, unless you count pair programming as a sufficient substitute.

I've seen branch-and-review used in anger. It can easily go bad: it drastically multiplies the inventory of work-in-progress. Everyone becomes blocked on someone else, moves on to another task, then loses context on the previous task or tasks. Stories with soft dependencies wind up sprinkled across several branches, making user testing a bit of a merge-and-pray event.

It sounds great. Reviews! But efficient!

And it turns out to be a tangle of interlocked gears.

I imagine somebody has made it work. I have not seen such a case.

My personal preference is a single development branch^, test-driven, pair programming, with rebase and integration test before pushing.

[^] If it's a private project, this is master. On github, the master branch can't be used as a true master, because it is a de facto release branch.

<comment><USER26> Sounds to me that we work for the same company :)

I bought into feature branches and all that stuff right after uni and tried to apply it at my first job without all the success I was expecting. Then when I moved to my current job in which we do TDD, Pair programming and single branch development I was a bit reluctant. After almost 2 years I haven't come up with a single scenario in which this approach has given us any troubles and in hindsight I think is what I should have proposed at my first job.

<comment><USER25> Until I got to Pivotal Labs, developing on a single branch seemed impossible. Now it seems obvious.

That said, I'm anchoring a project where my predecessors chose a feature- branch model. I have a motto that "sometimes it's better to be consistent than correct". Done properly, it's not too hard, but in practice that's because we don't have a large team and we still rebase on and merge back to master frequently.

<comment><USER27> That's a funny saying. I have a very different saying. It goes like this: "It's always better to be correct than consistent."

<comment><USER26> I will give you another one:

When in Rome do as the Romans.

I think consistency is a best practice with precedence over all the other ones. Having a team agreeing on something and being happy with it is sometimes far more important than that something being the best of the possible choices.</comment></comment></comment></comment></comment></comment>


Coinhive Proof of Work Captcha - <AUTHOR> https://coinhive.com/documentation/captcha <comment><USER2> This seems appropriate, given that proof of work was originally invented to combat spam [1].

[1] [https://en.m.wikipedia.org/wiki/Proof-of- work_system](https://en.m.wikipedia.org/wiki/Proof-of-work_system)</comment>


Show HN: Better code review for GitHub - <AUTHOR> https://www.omniref.com/code_review <comment><USER2> "Code reviews become annotations" \- cool feature, and it identifies a real problem. I don't think it solves it though.

We've learned many times that your source code and its history are _the_ thing you care about. Spreading closely related information across different systems is dicey at best. It never seems to follow the same branching structure as the source code, and external systems come and go. Even for issue trackers, one of the most obviously useful tools we have for software development, it's not obviously a good idea to refer to issue ids from source code comments.

That is to say: if you believe that code reviews are an important part of the code, or at least sometime can be, then you should be getting that information back into the code itself. Show me a way to turn code review into a code comment from the review interface, _that_ would be cool.

<comment><USER3> I agree with this, and recently learned about [https://github.com/google/git- appraise](https://github.com/google/git-appraise) which I believe stores the code reviews in the repo itself.

<comment><AUTHOR> Hi there, author of Omniref here.

There's a substantial difference between what we're doing, and what git- appraise is doing. Git appraise is solving the problem of decentralized code review, but it doesn't solve the problem of making code reviews _discoverable_ , after you've done them: having a directory full of JSON files doesn't make it easy to go from a line of code to the review that created it.

In other words: we're trying to make it possible to look at your code, and see every bit of historical information, in context, that made it as good (or bad) as it is at that moment.

That said, having the ability to export our annotations to a directory full of JSON files is high on the to-do list. You should absolutely be able to work with your own data.

</comment></comment></comment><comment><USER4> This is beautiful and clearly very useful. Some thoughts:

* Business-wise, your main risk is that GitHub agrees how useful this is and builds much of the same features. In a sense, GitHub can improve in this manner, by taking the best features of external services and implementing them directly.

* The killer app here would be if you can integrate this into an IDE. In other words, the annotations are great for code-review, but not _just_ code-review. In general they are essentially _better_ comments. Wouldn't it be great if I saw those annotations whilst coding? I understand that it's not as if you personally could create plug-ins for all existing IDEs. But could you have an API to make that possible for third-parties to author said plug-ins?

* Integrated with code-analysis software could make for a very pleasing automated-code-review service. For example, with Python you could annotate the source with the output of pylint. Obviously, I'm not suggesting that this replaces manual code-review, just that it would be a nice addition. I mean you already have the automated annotations highlighting where a line was affected by a pull-request.

* The tour was really nice, but whenever I was asked to "go ahead and click on the annotation" this did not really work, mostly it just advanced the tour. On that note, it would be good if the tour suggested how far was to go.

<comment><AUTHOR> Hi, glad you like it!

Yes, an API is coming very soon. And hopefully soon after that, some open- source editor integrations based on that API. Do you have an editor/IDE you prefer?

Integrated code-analysis would be cool, but it gets into a messy, language specific area that I'd like to avoid for the time being (these tools can be...flaky...when run at at scale, on lots of strange repos). But I'd like to find a solution -- either, again, via API, or possibly by some sort of jenkins-like service that allows you to run any particular tool you want, and attach the output to the code as annotations. I'd like Omniref to _really_ be a "universal reference" for your code -- not just code review comments, but any sort of information that is relevant to lines of code.

Regarding the tour bug: could you send me an email (firstname.lastname@example.com) with a screenshot of what you saw before/after clicking the annotation button? It might be a client-specific bug.

</comment></comment><comment><USER5> We currently use Reviewable.io. It has a lot of features that I expect from a code review tool, but the UI is just very bad and slow on so many levels.

Will give omniref a try.

@timr, I think you should charge per user, not per repository + per user. In today's micro-service/library/containers age, there a lot of small repositories within companies. Your pricing suggests there's a 2:1 repos to users ratio. Our team, for example, easily has 10:1 repos to users ratio.

<comment><USER6> Hi there, Reviewable founder here. Can you elaborate on "very bad and slow" please? The UI can be polarizing but I'm always open to simplifications / alternatives. As for performance, I'm not aware of any regressions at the moment as long as you're running Chrome 49+ or Firefox 46+ on a decent machine (Safari and Edge have... issues), but again I'm happy to investigate every report.

<comment><USER7> I'd like to echo this comment. Piotr has been amazingly responsive to problems with bugs or performance issues that we have hit (the Mozilla Servo team).

Apart from the UI, Reviewable also handles many of the really ugly "they did an over-under rebase, force-pushed, did another, then flipped back" cases that come up with longer-lived PRs and manages to keep the review state reasonable better than any other tool I've seen. And we've tried quite a few of them :-)

</comment></comment></comment><comment><USER8> Here are two things I'd want from code reviews:

* Editor integration. Let the comments show up in Atom or whatever as inline editor annotations (assuming they're on the right HEAD).

* Inline editing while reviewing. Very often I have to comment on a bit of code with " _this_ is how you should write it". When code reviews are just comments, I have to write that as Markdown, and I often have to copy/paste a chunk of the original code, and it's up to the reader to mentally diff what I changed. I'd rather edit the wrong code directly, and the target user should see it as a third diff pane.

<comment><AUTHOR> Hi, author here.

Editor integration: Agreed. An API is soming soon, which will make it possible for anyone to write an editor integration. Because there are A Lot of Editors.

Inline editing: _interesting_. I'd have to think about how to do that one, but it's a cool idea. Thanks!

</comment></comment><comment><USER9> Oh. My. Word. This is awesome - both the UI and how it works/what it does. Well done!

Having this embedded inside JetBrains IDEs would be fab (no idea if possible via a plugin).

And a slightly-jealous programmer Q about step 10 of the tour ('Reviews stay "stuck" to their line!'): how did you make that work, when GitHub can't?

<comment><AUTHOR> Thanks!

The smart annotations literally require computing a revision history for every line in the code. Essentially, a signature that uniquely identifies the line in time and location. It's a non-trivial thing to compute, and there are a lot of edge cases, so I can understand why GitHub hasn't done it. ;-)

Editor integrations are a super-common request, but because there are as many editors as programmers (it seems), we'll probably start with an API, and then move to creating open-source extensions for the most common editors. But your vote for JetBrains is recorded!

</comment></comment><comment><AUTHOR> Hi everyone, Omniref author here.

Just want to let you know that our repo importing processes are currently being hugged to death. Oops. I'm spinning up more workers now, but we're about 100 repos behind at the moment.

</comment><comment><USER10> protip: make your free option a bit of text with a link instead of highlighting it on an equal basis with your paid plan. People who want a free option will find it while people who are willing to pay you $50 wont think about the free option as much. Also those red buttons are very angry looking. Maybe make them green instead. I don't like clicking red buttons, red buttons usually do dangerous things like delete accounts and launch stuff in production. Green buttons are click magnets on the other hand.

It looks like a really nice tool though.

Good luck!

</comment><comment><USER11> I feel like this could all be done with a polished up chrome extension. I don't see what I'd be paying $50/mo for, which is double what I pay for my company's GitHub account itself.

<comment><USER12> It's a bit non-obvious, but there are some smaller plans. You have to click the arrows on the sides of the box to see them.

<comment><AUTHOR> I updated the page to make those arrows more visible for now. But it looks like I'll have to re-think this bit of "clever" UI.

</comment></comment></comment><comment><USER13> What happened to omniref for Ruby's source code? I can't seem to navigate to it from the main site anymore, I can only find it via Google search linking into the site.

<comment><AUTHOR> It's still there, just on a subdomain:

[https://docs.omniref.com](https://docs.omniref.com)

I'll add a link back to the homepage.

<comment><USER13> Awesome! The interface is great, I always found it the best option for looking into ruby source code. Wishing you guys success with your endeavors.

<comment><AUTHOR> Thanks for the kind words!

</comment></comment></comment></comment><comment><USER14> This appears to hammer GitHub's API pretty aggressively. I attempted to import [https://github.com/cockroachdb/cockroach](https://github.com/cockroachdb/cockroach) and a few hours later my API limit is exceeded.

Seems bad.

<comment><AUTHOR> It's pretty conservative with the API usage, but if you have thousands of pull requests, issues and branches, it will probably hit the limit of 5k requests an hour on first import. After initial import, API usage is very light.

You're the first person to have this problem, but I'll add some logic to throttle the request rate before we run through your allocation. The trade-off is that it will slow down import of pull requests and issues.

</comment></comment><comment><USER15> I would be interested in seeing some screenshots and preferably more details. Looks promising, though. Good work!

<comment><AUTHOR> Don't know if you saw it, but there's a tour that walks you through the major features:

[https://www.omniref.com/code_review/tour](https://www.omniref.com/code_review/tour)

<comment><USER15> Hmm. I'm on mobile right now, maybe it is hidden?

Anyway, thanks!

<comment><AUTHOR> Oh, yeah. It's way too much UI information to work well on a mobile device. I hid it to prevent eyeball bleeding from cellphone users. You'll see it on a larger screen.

I'll have to add some screenshots, but it's just a hard thing to make obvious on a small screen. Thanks for the feedback!

<comment><USER16> You definitely need some screenshots at least on mobile. I skimmed the page and left cause I didn't see anything. Glad I read the comments to see why it was upvoted, now I at least know to check it out later on my main machine. If this weren't HN you'd have lost me though!

<comment><AUTHOR> Yeah, I try to be aware of users browsing on phones, but I slip up sometimes, since, for obvious reasons, I mainly use Omniref on a desktop.

This was a forehead-slapper, though. :-/

</comment></comment></comment></comment></comment></comment><comment><USER17> Is there anyone using this already for a public project that I could take a look at?

<comment><USER18> Yes, the entire Ruby language.

[https://docs.omniref.com/ruby/2.2.3/](https://docs.omniref.com/ruby/2.2.3/)

example annotation: [https://docs.omniref.com/ruby/2.2.3/symbols/Class?#annotatio...](https://docs.omniref.com/ruby/2.2.3/symbols/Class?#annotation=4032498&line=511)

<comment><AUTHOR> Hi, Omniref author here. Thanks for posting those links! Technically, this is an older version of the same software, but it does get the idea across.

The "new" Omniref does a lot of things correctly that the "old" Omniref wouldn't (like working with programming languages other than Ruby...heh.)

<comment><USER18> Great! We're exploring using it for the BioJulia project as a result of this HN post. Thanks for all your hard work.

<comment><AUTHOR> Awesome. I am an ex-computational biologist, myself.

If you have any trouble just send me an email: email@example.com

</comment></comment></comment></comment></comment><comment><USER19> I can't see any reason why Null would break for a surname. You're expecting a string, not a null value. What's hat about?</comment>