mcgwiz

Well, I personally agree with you, but my significant other likes to view social network content through it in certain circumstances, particularly at the end of the day after getting in bed. But that's the saving grace of Flipboard; it's there if you want it, but it's not forced onto anything.

The whole point of Flipboard is to add a magazine layout to existing content. As important is the fact that Flipboard allows you to choose what content sources to apply their layout to. In this regard, it leaves the whole issue in the hands of the user, who is always right :)

Pinterest works for the average Pinterest user primarily because it fits into the metaphor of the site (items pinned on a bulletin board) and therefore enhances the information architecture of the site. This acts as a functional multiplier across the entire site. The fact that the content is visual falls out from this but is not necessary; many pinned items are actually primarily textual. Sign up flow, email notifications, etc are tertiary.

Generally, a non-traditional layout (where traditional is flat list or tree-based) should be chosen if it is compatible with or can even reinforce the information architecture. E.g. if you're site is based on the idea of building a house out of bricks, a 'mason' layout would work :)

I didn't take away from the article a denouncement of all criticism. Perhaps I read into it what I believe, or was more charitable/liberal in interpreting/extrapolating the intended meaning from the clumsy wording.

Either way, my take away was that honest feedback and delivery/tone are orthogonal. You can be harsh in your feedback/criticism/expression-of-opinion, or you can do so in a way that disarms the other and is trust-building. The former is more likely to be ignored or misinterpreted, the latter is more likely to be understood. (The article presupposes this, and I agree. And one person's ability to take harsh criticism well does not translate to people receiving harsh criticism from that person also having the ability to take it well.)

If and only if you cannot find a way to convey your feedback in a trust-building way, the author asserts that your will be counter-productive in helping the other. Thus there are practical benefits to remaining silent, including: save your time/energy, not risk burning a bridge, not pointlessly inflict emotional harm (ok, the last one is not so practical as it is considerate).

But that's a very specific and unlikely circumstance, and the author explains in the article many simple techniques not to find yourself in such a circumstance.

Uh, the only people you trust to work on production code are those that think their work is "ugly" (which, in the context of the article, was a euphemism for harsh, one-sided, a-hole ripping condemnation)?

Oh, but you cited evidence. Assuming you trust yourself to work on production code, it's a universal truth that all trustworthy people must think they're spawn is ugly because you yourself were able to do that with your son. Congratulations?

Either way, there is more to it than Dale Carnegie.

Honesty comes first, definitely agree. I don't think that was ever questioned. What was questioned was delivery. Delivery is important because it overcomes the innate skepticism of many people (which can also have emotional and professional ramifications). Honesty and delivery are orthogonal concerns.

Also, the article is about giving feedback, not taking it. The fact that you prefer to take harsh/honest criticism rather than overly-friendly/dishonest feedback is irrelevant (and is also a false dichotomy). You appear to state this to refute any a need to be concerned with delivery at all; your personal preference doesn't change the reality for the rest of society.

So, regarding giving feedback, if your objective is to improve the recipient's chances of success, it behooves you to communicate your (honest) feedback in a way that reduces as much distrust as possible. Techniques for this are given in the article.

But again, I agree, honesty underpins all of this.

Good point. Best to be one-sided and myopic than risk being too kind!

Yeah, the author used some strong language. He obviously should have started off each sentence with "In my humble opinion".

"Effective" is a value word, so no study can prove it without first defining it (which would probably require 4 or 5 studies itself). However, I believe he's merely referring to cognitive dissonance, which can be briefly stated as the reason we tend to resolve mental stress by ignoring logic.

Also he said it "can" have a horribly diminishing effect. He might only have been claiming 1 in 10922. That's a pretty weak proposition, ergo there are dozens of studies that proved it. In my humble opinion.

This is patently absurd. The author fleshes out a rich and detailed argument for comparing/contrasting rather than one-sided criticism as a way to provide feedback, but your best refutation of it is to point at the one sentence in which he cited someone you feel is of dubious credibility and proclaim "Therefore he's dumb!"

Oh, but you said "proper" criticism. I get it now.

No it's not your only hope. Your other hopes are:

- hiring developers that appreciate and obey the conventions, or

- reducing the weight of the conventions.

Simply put, if you have conventions that the developers aren't following, you're organization is dysfunctional in some way. Management should include the team when crafting the conventions, and management should take efforts to give the team time/resources to obey them.

> The worst thing is that there's no way of enforcing these workflows or practices other than out-of-band social conventions.

False. It's called the Dictator and Lieutenants workflow. It's costly, but if you're in a position where you don't trust your own developers or your conventions are severe, then it's a price you have to pay.

If you can't afford it, hire trustworthy developers or dial back your conventions.

Perhaps human error with the USPTO data entry system. Or, as others have said, as a joke.

"Oversold" is the key word here. And that's a marketing concept. To dig deeper, the problem has and always will be that MongoDB toes the line between a caching product and a database product, yet 10gen markets it simply as a database product.

MongoDB is flexible and fast, but practically speaking it's a hybrid product that defies simple categorization. That means it must be well understood to leverage it. Ultimately that may also be it's Achilles heel, but in the short term, it's extremely frustrating that 10gen can't embrace this fact. Instead they perpetuate marketing that causes the product to be perceived as flawed by their target audience.

Once you've discovered this, you can use it appropriately (either by overriding the default silent failure to use it as for durable persistence, or only using it for caching or as an eventually consistent store) to reap it's flexibility and speed.

(Largely quoted from my comment yesterday, https://news.ycombinator.com/item?id=4566518.)

The problem has and always will be that MongoDB toes the line between a caching product and a database product, regardless of what 10gen decides to call it. It's extremely frustrating that 10gen can't embrace this fact, and instead perpetuates marketing that causes the product to be perceived as flawed by their target audience. But once you've discovered this, you can use it appropriately (either by overriding the default silent failure to use it as for durable persistence, or only using it for caching or as an eventually consistent store).

Also, his rebuttal doesn't defend the inclusion of those language features in the first place. If you simply "shouldn't" use a particular feature (e.g. if at the end of an expression), why should it be in the language at all? It shouldn't, ergo the language is nonsense, which was the original claim.

Exactly. Expressiveness refers to the realm of problems a language can idiomatically address, not the number of ways a particular unit of logic can be equivalently written. If that were true, you could simply add any synonym for "if" ("when", "whenever", "assuming", "given" etc) to a language and claim the most "expressive" language.

Perhaps a style guide should just be encoded into the compiler.

I don't want to be misconstrued a "bad HN commenter", so I'll say first of all, technically amazing. Also, UX is consistent and aesthetically pleasing (though admittedly incomplete; lots of actions are unexplained... e.g. what's the difference between Focus and Shift).

Technical and design accolades aside, IMHO I would not call this an improvement on existing discussion forums. In Part 4 of his post "Building a Better Online Community", he implies that a major problem is the signal to noise ratio. This web app has not solved that problem.

The extremely low barrier to participation, while inline with privacy ethics and democratic ethics, unfortunately removes important incentives to creating quality content. It is however, successful at enhancing anonymity and removing the (burdensome?) requirement of identifying oneself.

Let's take a step back and re-assess what we're looking at. It's not an improved discussion forum, it's an improved chatroom app, plain and simple. And for that, I credit it with certain innovation.

Well put. I've been programming professionally for 8 years (and as a student for another 8 years prior--HP48G RPN represent!). And to this day, I find myself regularly attracted to articles, books, and blog posts about "basic" lower-division CS topics: principles of object-oriented design, language design, patterns, compilers, etc. It's the same old stuff, but reading it is more enriching and insightful the more real-world programming experience you have.

It's very troubling, because the decoupling of resources from their representations is so core to HTTP.

A year ago, the maintainers defended Chrome's behavior as consistent with Firefox, and vaguely as consistent with the spec. Since then, more complaints have piled up and those original defenses have been deconstructed (Firefox no longer exhibits this spec-breaking behavior, multiple unmet sections of the spec have been cited). But for the last 9 months, the maintainers have not said a thing, despite doing various house-cleaning chores on the bug report itself.

One can't help but wonder if there's some ulterior motive for ignoring the community and keeping the WontFix status, though nothing obvious comes to mind... The impact this could have and the way they've handled this is reminiscent of how the downfall of a different browser began.

What's all the hullaballoo about?! LinkedIn does the same thing: you can see who viewed your profile if you enable your own views of other profiles to be seen by their owners.

Or do we only get riled up when the perp is a small startup that still holds the promise of cracking the holy grail of sustainability without charging a usage fee? ...Damn sell-outs, it's like all they care about is finding a way to make money.

Completely agree. One of the quickest ways to burn bridges and ensure you are perceived as caring more about your own ego and "needs" than anything else, is to re-implement something without talking to anyone about it, be they the authors, stakeholders or 3rd-party dependents. This kind of "look at me, manager! look what I did!" behavior is the cancerous seed of a team ruled by self-seeking and ego.

If your needs would benefit the whole and are not a mere excuse for egoism, but are not aligned with the company/team, get another job.

In the end, the author learned a lesson, but the wrong one. It's not that you should listen when voices of dissent shout in your ear, but that you should simply foster a general environment of open communication, and discourage action-without-coordination.

Their technique for generating the HTML representation of deep-link into a Meteor app is to run the entire client app in a headless browser and serialize the generated DOM?!

This is an area of vital importance to public, JS-based RIAs, and needs some real innovation. Why even bother delivering this half-baked solution? The processing cost makes it untenable for all but the tiniest of URL-spaces.

"We've launched a mobile site built entirely in AngularJS - thoughts?"

My only thought is title-bait. This is a usability article, with almost nothing to do with AngularJS. But hey, I guess it worked.

Not sure why the author goes through pains not to call out the fact that SO is not secure in the layman sense. In general, if a service requires users to understand the lack of SSL and to take security into their own hands, the service is not secure. Worse than that, SO does not even explicitly communicate this to users.

Also, the author omits a crucial workaround. When on a public network, communication can be made secure if routed through an encrypted tunnel to a known-secure network, such as with a properly configured VPN.

The author's gripe seems to be that the hiding of dotfiles was unintended, ergo dotfiles are Bad. Whether they were intended is irrelevant; their wide usage vindicates the practice. After all, traction = value. The problem of program state/configuration/metadata storage is adequately met by dotfiles.

There are, no doubt, numerous unintended behaviors of programs. Most of these are simply ignored and certainly not leveraged the way the dot behavior is.

People don't go out of their way to abuse an unintended system behavior; they simply leverage all capabilities of a system ("intended" or not) to meet their needs. Had dotfiles not gained traction, some other solution would have been designed (or "engineered") to meet the needs of program state/configuration/metadata storage.

[Tangent: All of this reminds me of grammar freaks that harp on "correct" usage, completely oblivious to the fact that grammar changes, and "correct" is merely a lightweight pointer to the current norm.]

"lack of knowledge about how things work" and "The problem is hosting". Are you people insane?!

An open information policy, regardless of it's supposed higher morality, reduces a social network's ability to compete, because a) it gives competitors an advantage in acquiring your users and retaining them, and b) the vast majority of users do not care about this. We have the current equilibrium in the social networking market because of many forces, including ease-of-use, social feature set, up-front monetary cost, and social group inertia, but information policy has empirically proven not to be one of these factors. It has, however, been an important factor in shaping the self-publishing/blog market. There are different solutions suited to different markets.

And you cannot explain people's indifference to this issue by proclaiming (arrogantly) that they have a "lack of knowledge". People have other more pressing concerns in their lives. Making the rent this month. Dealing with a child who is not performing well in school. Internalizing stress from their job because they are not trained enough to get a better one. Even if the average person did know about information accessibility, privacy, and sale to 3rd parties, why would this issue rise to a level comparable the issues listed above? The fact that they can smile for half an hour when they get home from work by reading/looking at a personalized listing of information they find valuable, and do this for free, is all they need to know about the web. This is not for better or for worse. It's reality in all its complexity.

If or when this free-but-centralized/closed system fails them, by directly affecting their pocketbook or by itself has becoming insolvent, is when they'll take notice. And if this does ever happen, it is probably decades away.

Lastly, if you aim your service at just "the people that care about information access", don't overestimate your market size. You going after a much smaller pool. With social/communication services, we're not just talking about a pool of individuals, we're talking about a pool of friend/colleague/interest groups. In this case, the specific pool is basically all friend/colleague/interest groups which are comprised entirely of libertarian-minded nerds that actually want a communication service beyond email/mailing lists, github, and blogs/comment threads.

Ferchrissake, this comment thread on Hacker News only generated 19 comments; what do we need a whole social networking service for?!

Teams that lack the element of craftsmanship in their culture will likely not care if a programmer knows grammatical rules of natural language (much less if he is a master of natural language). To simplify, whether you agree with the author correlates with what type of programmer you are (or want to hire). In this simplification, I'll call them "productive programmers" and "craftsmen programmers".

Productive programmers ship lots code, create lots of value, and by business standards are model programmers. They're driven by quantity, volume, getting things out the door, and the solvency of the business.

Craftsmen programmers also "produce" and ship code, but they equally value maintainability, and therefore clarity in code. They're driven by the customer as much as the other consumer of their code, the maintainers.

From my experience, these very different types of programmers have very different priorities and values. Generally, the first set emphasizes clarity in communication only as it impedes progress along the critical path. They JIT there eloquence, whether it's essential business communication or unstable/volatile/certain-to-change code. JITing is hard and not guaranteed to produce the optimal (most clear) output. The second group feels obligated to be clear in communication at all time, because any corners cut now may create pain for a fellow down the road. To excel at this, the second group is self-motivated to learn deeply both the spirit and the mechanics of communication (empathy and grammar). They spend more time analyzing the available solutions for potential misinterpretations, and therefore generally produce a clearer output.

Thus, the applicability of the article depends on the culture and environment of the team.

I don't like software architects.

I'd much rather have a team full of A-type engineers that will stop at nothing to force their individual vision into a project.

We can trust that every top-notch developer has the whole project's welfare at heart, and not just the part that they own and whose success impacts their performance evaluation. Ergo, a totally flat team of aggressive rock-star engineers is destined to build their constituent parts in a homogeneous and consistent fashion.

A team of engineering ninjas are bound by a higher power to perfectly coordinate their coding style, core patterns, API design, conventions vs configuration trade offs, third-party dependencies, feature preference, etc., in a way that resonates precisely with the needs of the business and the risks of the industry.

In short, all world-class engineers are business-savvy, have no conflicting interests, never have unresolved disagreements, and are also telepathic. And since all the engineers I work with are obviously world-class engineers, having a single point of accountability and a single vision of quality around is an insulting slap in the face!