chavesn

I haven't even heard of such a thing. I've done a couple written Q&As, but those I think are fair, since I have time to prepare a thoughtful response and don't have to worry about communicating body language to a faceless camera at the same time.

To be honest, it sounds like a net lose -- it's a definite negative for a candidate, with perhaps not much benefit for the company (high noise, high false negatives due to the awkward environment).

My gut feeling is that I would immediately reject any company that asked me to do that, if I had the choice.

If you consider it a "game" you should probably attempt to understand the rules of the "game". In this case, replying to the top comment with a non-sequitur self promotion is going to get you downvoted, and it did.

> What about your cache, should we just introduce HTTP into the caching mechanism and hope that one of your clients has the data you wanted to deliver to someone else?

HTTP caching is a standard built explicitly for this. And it's gotten better at precisely these jobs over the years (substitute for server memory and indexes). So if that "someone" is the user who has the cache, yes.

> Are your clients going to be responsible for ensuring you don't max out your server with the amount of processes your httpd can handle?

HTTP 307 Temporary Redirect. 420 Enhance Your Calm. Keep-alive. Etc. There are many standards in place to let the client participate in not overloading the server. The server must always be willing to deal with a new actor, but that doesn't mean that there aren't systems in place to help clients be nice to servers that are overloaded without breaking other parts of the spec (caching).

> Decades of networking work, by extremely talented individuals, to make sure the client has to do very little lifting at the layers closer to the metal by people much, much smarter than us.

I don't see any evidence that all that networking work is to make sure that clients don't need to do work. Instead, I see many clever systems on both client and server being created to push the boundaries of resource usage past previous limits.

On the server, it sounds like you are familiar with these techniques. Load-balancing, edge-caching, distributed applications, etc.

On the client, it must come about through standards and behavior specifications. If you're imagining a world where servers are placing requirements on clients before they are ready to handle them, I agree, that would be awful. Servers should always have ultimate responsibility for being a good host to any potential connection.

However, once a client behavior standard has been well agreed upon for a significant amount of time, then servers should absolutely take advantage of the behavior. Should programmers of web application skip any of the behaviors above (HTTP caching and REST), or shun JSON APIs or pushState or any of those things?

No way! They should take full advantage, as long as they know what they are doing. And yes, you do have to still be a responsible citizen (for your own good as much as anyone's).

For example, if you use pushState, you still must keep in mind how search engines may observe your pages[1]. Using cache expirations aggressively but correctly still takes some careful planning. And so on.

But the principle of "offloading" as you put brings the possibility of optimization by factor of N, where N is your audience size, instead of some constant K as many other server-side optimization are limited.

This is not "nullifying" anyone's networking work. Clients, under carefully grown and tested behavior standards, _should_ be able to do some lifting.

If you want to talk about user experience, that's a whole other issue. And yes, there is significant evidence (responding to your earlier comment) that things have gotten better -- just a couple years ago, web fonts were almost unusable because of the flicker that happened on load. I am sure some clients still see it, but for my own personal use, the flicker is virtually 100% gone.

If the client can't display the page in a reasonable replacement time for the server, then it's a no-go. But if it can, it's a huge win and IMHO doesn't subtract anything from the (admittedly genius) networking stacks underneath.

Finally, if the technology in these networking layers could so easily be nullified by so-called "ignorant" individuals, wouldn't it be not-so-brilliant to begin with?

[1]: http://stackoverflow.com/a/6194427/143295

What a great idea, I'm really impressed with the cleverness and execution.

A few thoughts and questions for you (you may have already thought of/know about):

- Have you thought about "well-formedness" for the HTML? I realize that adding anything besides the script tag would sort of ruin your point, and it would be nice if browsers accepted that, but also I feel there are sometimes hidden benefits to serving a well-formed document under the correct content type that the server said was being sent (or extension).

- This makes your site awesome to read with a text browser or curl.

- About 1/2 or 1/3 of the times I click "back" or "next", I can't scroll the page after it renders. (Chrome/MacOS)

- The footer support is cool, have you thought about how you would do more extensive template support? (Maybe there's no reason anything extra couldn't be placed in the footer -- analytics, even a header -- although I think a favicon might need to be in a `<head>` tag). Integrating this directly with Markdown, too, could be really cool.

- P.S. Your footer link says "Chanpter" :)

Great work, I love when I find something like this -- really clean, simple, and challenges the norms in a clever way. The result even appears quite polished.

But any point where the strongest examples aren't "technically true" and therefore rely on a common misconception is a pretty weak argument. Either Thiel's point is weak, or he means something else.

I suspect he means doing those things (search engine, OS, social network) in a way no one else had.

You never know for sure, but I believe this happened to me. I had a follow up call with HR about why they weren't continuing with me despite what felt like a good "getting to know you" introduction interview.

The gist of the answer was "we feel that you are in range of [some job level/position] but only the very senior people in that department are paid in the range you mentioned as your requirement."

So they decided not to spend any more time with me because of the mismatch of salary and their perception of my experience level so far.

That's quite generous of you. I don't think there's any more reason to assume they are competent than to assume they aren't.

The fact is that this sucks for the user. It's also a pretty safe bet to say that there are lots of developers putting code into use solving problems outside their competency. You may not want to assume this evidence makes them terrible developers, but that doesn't make the inverse any more likely, either.

Unfortunately the colors of the web-safe color palette that we all know[1] (and hopefully hate) that results from combining 00, 33, 66, 99, CC and FF into triplet permutations has extremely poor color distribution.

Can you find any oranges in that color picker? Maybe 2. What about blues or reds? Pretty much the same. But you can find a ton of teals, purples, and pinks!

This is because producing naive permutations of fixed steps results mostly in muddy hue variance between the primaries. This is not the natural way we see color variance. It results in far too many unique hues and not enough shades of the "good" hues ("red", "orange", "yellow", etc.). We only really distinguish between 7-15 hues at a basic level, but then we are used to seeing many shades of those same hues.

In addition, because the way the permutations are created it would be a ton of work to figure out how to sort them by hue. And if you did, you would notice just how many hues there are (way too many to care about having so many).

A much better color picker will take just a handful of hues (again, 7-15 or so) and then present varying shades (lighter, usually, but also darker for more variance) of them. Another crucial factor is to make sure the color picker includes a row for all shades from black to white (which at least this color picker has done).

For an example of a color picker that does this well with just a handful of colors, see the Google docs color picker.[2] You'll notice how much more pleasing it is to the eye.

[1]: http://en.wikipedia.org/wiki/Web_colors#Web-safe_colors

[2]: https://www.google.com/help/hc/images/docs/docs_1696586_colo...

OT here, but I've used Picasa's facial recognition extensively on a very large library of photos (about 50,000). Anecdotally, I would say it started out very good, but, strangely, it got much worse over time.

Part or all of this effect may have been due to UI bugs or deficiencies that didn't clearly show what it was really trying to tell me (does it really think this is a new person, or separate for some other reason?), or didn't allow for subtle variations on what I was trying to tell it (such as "no, but good guess", or "this looks nothing like the person, but actually is")[1].

I can only guess why this is, but at first it seemed to be quite good at finding new faces that looked very similar to the ones it had found so far. Over time, it's as if the wide variety of confirmed positives reduced the confidence in finding any new faces at all.

[1]: It was somewhat confusing whether I should select and move a bunch of wrong faces to the right person, or just say no and let it try again. It might have also helped if I'd been able to say "yes these are all the same person, but I don't want to name them in my database".

They may not, but I fail to see how that is "as a rule". One of the requirements of featured articles is that they contain media.[1] The review process and competition for main page nomination seems likely to ensure they are at least decent quality.

If you dig around, I also think you'd be surprised how many high quality images Wikipedia and Wikimedia have. There is a Featured Picture[2] process that encourages and curates great images.

Wikipedia basically invented crowd sourcing -- I'm sure editors could handle custom placement, even if it doesn't turn out as perfect as a hired designer would do it.

Overall I can't imagine this is a major problem with this design, even if it doesn't always look as flashy as the mockups.

[1]: http://en.wikipedia.org/wiki/Wikipedia:Featured_article_crit...

[2]: http://en.wikipedia.org/wiki/Wikipedia:Featured_pictures

It's nice to know that the poor experience isn't just a matter of a missing upgrade path. However, having such a limited view of trust -- such as just "being good stewards of data" -- is exactly what causes companies to end up with none and wonder why.

Bugs, bad upgrade paths, adding "features" while losing polish, etc. are all great ways to lose trust.

It's a good thing they didn't use HTTPS. And a good thing that something else doesn't actually rely on samsung.com (listing services, API endpoints, whatever).

This is a cool hack for now but if I had to make a prediction I'd bet there's a future coming where this isn't possible, where the two are even more intertwined -- even though most of us know they don't need to be and wouldn't design our own systems that way.

I agree with your well-placed sarcasm -- this is not a black and white issue.

However, I disagree that there is fundamental value in built-in TV software supplanting third-party devices. That is, unless a software company is making the software.

I have a Roku, and built-in software from Sony on a blu-ray player (on separate TVs). The Roku is so much better that it's painful to use the TV without it:

- The buffering is much worse on the Sony. When it switches between ads and the video it takes several seconds to rebuffer.

- The delay between menus is measured in seconds, while the Roku is almost instantaneous

- It's almost like Sony didn't even have one UX designer working on their project. It will do idiotic things like when Hulu opens, create a modal dialog that says "The internet content is ready" and I must click OK to proceed.

- The remote and other menus are slow and hard to decipher just like you'd expect from built-in software.

The point is that building the user experience of a video client is not trivial. I can't even blame Sony, really -- a non-software company will never do a good job at that kind of thing.

The Roku is a world of difference and until a company like that is building the built-in software, the mainstream of the market will be in third-party devices.

The fact is that Andreesen stands to benefit from claiming this is totally normally and rational.

That means there's a chance of personal bias in his opinions, not that he's automatically wrong.

That really doesn't illustrate anything besides silliness.

It does illustrate how these don't mean anyone actually has $10 billion cash[1], but that wasn't the point here.

[1]: which does still confuse many as shown and explained here: http://money.stackexchange.com/questions/11368/how-are-start...

To be fair, these implementations are only poor in your opinion. And your suggestion might be poor in other ways.

For example, I would suspect far fewer people are willing to invest upfront in a game like yours. It's much easier to find two people who want to play chess against each other where they are fully in control, than two groups getting only one single, slow game out of it.

One way a more thoughtful, strategic game like yours might work would be to achieve critical mass with a simpler, fast paced game and then add depth.

I've thought about this a little bit lately, and I've started to believe that it may be difficult to have both; if you let "funny" start to be valued, then it quickly overtakes the other values.

Having spent quite a bit of time on both Reddit comment threads and HN threads, sometimes on the same topics, I find the earnestness and thoughfulness of HN extremely refreshing. At reddit, I feel momentarily amused but then I'm left empty from the total flippancy and lack of substance.

Yes, the restrictions are interesting -- I've personally noticed (corrections/additions welcome):

- Cannot downvote comments in threads older than 24 hours

- Cannot downvote comments in response to you

Are you saying the are not as pernicious because they are not as common?

I down vote the same as you, but I would hesitate to assume that the algorithms are tuned one way or the other. In reality it's probably more about velocity or even the voter.

I have noticed the absence of low value comments near the top (except in fresh threads) so to me, it's working.

It also appears to be a trimmed mean, removing outliers. That one amazing comment I made didn't seem to matter at all!

I agree, it would be nice to address this, although I have a feeling I really shouldn't care.

I'm so impressed with the UI and execution. Very well done. No complaints, except that it's perhaps the move timer is a little fast.

I first learned about Ultimate Tic Tac Toe here[1]. Might be worth a link to that post -- it's a great explanation with surprisingly satisfying illustrations.

[1]: http://mathwithbaddrawings.com/2013/06/16/ultimate-tic-tac-t...

I always thought the Wikipedia progress animations illustrated the difference between A*[1] and Dijkstra's[2] nicely (and see some variations compared[3]).

[1]: https://en.wikipedia.org/wiki/File:Astar_progress_animation....

[2]: https://upload.wikimedia.org/wikipedia/commons/2/23/Dijkstra...

[3]: https://en.wikipedia.org/wiki/User:Subh83/CommonsContrib#Ani...

I feel like I wasted my time reading that. It amounts to a big "Boo hoo!", makes tons of unsubstantiated and emotional assertions ("I can guarantee you that no one ever really gave any consideration to our arguments", the "the process is bullshit"), and the real solution is to just resubmit the app with a non-spammy description. How hard is that?

The appeal says "We don't profit from it, and thus have no incentive to spam." So change the description!

Some of the comments here claim this is just showing how engineers think they are the only smart ones, or how there's equal frustration pointed back at engineers.

However, this is illustrating a particular problem that only[2] affects engineers -- engineers are the ones at the end of the day who have to make a solution reality. This particular weight doesn't fall on any other role. It's easy for anyone, including engineers, to misjudge a problem when simply talking about it. This makes non-technical meetings about technical problems particularly difficult.

But yes, it's true, every role has stereotypical flaws, and it's healthy to be able to laugh at them[1].

[1]: http://i.imgur.com/YiuSeRE.png

[2, edit to address comments]: Only affects engineers, of all the roles in a work pipeline involving engineering.

Some others have already mentioned that "mind mapping" software is similar, and I'd agree -- just see this image[2]. That image was created with Mindnode[1], which I really like (I've only tried the light version, but that seems to be discontinued).

[1]: https://mindnode.com/assets/images/screens/iphone-1-1136x640...

[2]: https://mindnode.com/

What an incredibly irresponsible post by Yahoo Tech. No disclaimer, and it is written as a how-to!

Am I the only one that thinks that the people at Yahoo Tech should know better than to make de-facto recommendations to their users to install such kind of hacks that are as dangerous to users as they are in violating the TOS of the website target?

The setup for the article theorizes on the cost of lying on the person's stress levels. I'm sure that's a factor, but I think that pales in comparison to the empirical evidence the author has found in her own life -- the benefit of transparency.

There's an episode of How I Met Your Mother where a character always asks "Where's the poop?"[1] when she can tell someone is lying. She had a dog that always made he same face when it was hiding that it had pooped in the house.

I think the truth is that we all know in business there is always some poop somewhere. Whenever we lie, we leave our audience with an uneasy feeling, wondering what the catch is.

When we come right out and tell them what the catch is, we get past that barrier, which builds a relationship of trust from the start and allows the audience to weigh the values of our proposal on its true merits. This is the real power of telling the truth.

[1]: http://how-i-met-your-mother.wikia.com/wiki/Where's_the_poop...

I wanted to like this article, because I agree with the premise, but the author went a bizarre direction in trying to prove his thesis.

As constructed, several far-fetched notions would have to be true to support the conclusion in the way he argued:

- the high failure rate must be due largely to bad ideas and not to poor execution

- sleep deprivation must be endemic at Google, Facebook and Twitter

- Google Glass and Android Wear (and corresponding FB and Twitter projects) must be the product of the sleep-deprived, and shown to be bad ideas (kind of early), and representative of projects at the company.

I think it would be easier to show that lack of sleep just results in poor work. It certainly makes more intuitive sense than honing in on the problem of "crazy" ideas.

I almost made a similar point but didn't want to be too long-winded. But you're exactly right on. Certain idioms develop in every language. In Java there's a culture of favoring verbosity over cleverness. In fact, I think you'll find some Java programmers who hate the cleverness that is often common in other more terse languages. And they'll throw "clever" around as an insult much the way "verbose" is used against Java.

I think overall these cultures don't indicate too much of an underlying problem and aren't too harmful, except when assimilating developers from other language. But to your point, these barriers to entry likely exist for nearly every language (and if not, other barriers do), so on balance, it's largely a wash.

This is one of those criticisms that sounds right if you know a little bit about the topic, and is certainly clever enough in and of itself to make the reader think that it's making a good point.

But it's not making a good point. It's not even close. I wish people would stop voting it up.

- "In Java, you can forget about doing it in the cleanest or the best way, because that is impossible." -- cleanest in any language? Or cleanest for Java? Of course the "cleanest" way for Java is possible, and it does matter -- there is a huge difference between "clean" Java and unclean, and anyone who says otherwise is a Java pretender. And arguing about "cleanest for any language" is just a proxy for a language flamewar.

- "And nobody can glare at you and demand to know why you used 576 classes when you should have used 50, because in Java doing it with only 50 classes is probably impossible." -- The "Har-har-so-many-classes-and-don't-even-get-me-started-on-variable-names" argument. In Java, as in any language, you can over-design, or you can under-design, or you can design just what you need. The number of classes may end up higher than in other languages, but this argument is silly and tired, and yes, length is one of the tradeoffs of Java. An IDE (gasp!) should make that largely irrelevant.

- "The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands." -- This word "verbose" keeps being thrown around as an insult, but nobody brings up the tradeoffs. Verbosity has a purpose, just like brevity and terseness do. And of course it's never out of the programmers' hands. Once given a language, it's all relative.

There's more, but I'm arguing with a person who believes that a question about stdin and stdout is a proper gateway for measuring skill toward any programming problem ever.