How FriendFeed uses MySQL to store schema-less data - <AUTHOR> http://bret.appspot.com/entry/how-friendfeed-uses-mysql <comment><AUTHOR> Another interesting detail is that this is roughly the 4th iteration on the FriendFeed backend since we launched 17 months ago. If you look at the the graphs at the bottom of Bret's post, you can see that our previous system was about to die -- average pageview latency had increased from about 135ms to 260ms in less than a month! (not a good trend) This new design also accommodates some important upcoming features that would have been problematic in the old system.

This experience reinforces my belief that it's better to be quick than brilliant. If we had wasted a lot of time trying to build some really smart, super-scalable system right from the start, it would have inevitably been over-optimized for the wrong things, since the product and requirements have changed quite a bit since launch. By continually rebuilding the system, it stays relatively simple and close to our actual needs (plus it incorporates everything we learned from the previous iterations).

<comment><USER2> Hi, is there any chance you could have a look at this comment:

<http://news.ycombinator.com/item?id=497070>

and let me know how you resolve this problem in practice? (Or correct my understanding if there is no problem really).

<comment><AUTHOR> Increasing the number of shards is similar to changing the backend infrastructure, but simpler. Downtime obviously isn't acceptable, so when switching from one system to the next, we have a period during which we write to both so that it is safe to read from either one. Other schemes could be used for resharding, but this is simple enough and also works for other changes, and in practice we've changed the schema more often than the number of shards.

Also, keep in mind that it is ok to have more shards than you really need (multiple shards can run on the same machine, for example), so resharding needn't be a common operation.

</comment></comment></comment><comment><USER3> Thanks for sharing. That was very educational.

We store data in a really similar way at Spock, pointing all our reads at a big MySQL table which essentially just has an id column and a really big text column containing all the values, JSON-encoded, w/roughly the same number of rows as the FriendFeed table. Our DBA wrote a blog post about it a while back: <http://www.frankf.us/wp/?p=17>

The way you guys create/delete indices and avoid all the replication nightmares sounds super cool.

All of these solutions ultimately end up sounding like a poor man's Big Table.

</comment><comment><USER4> This is really interesting.

We did something similar for GameClay. I stored game properties as JSON- encoded dicts stored in MogileFS, then had a "regular" MySQL table that would point to the MogileFS key for the file, then the Python code would just read it out, use a JSON library to parse it, and manipulate it as a Python object. We had normal MySQL indexes on all the game metadata that appeared in the UI, so if you want all arcade games that nostrademons has posted, it would do a normal index search on (nostrademons, "arcade"), find the Mogile key for that, and then fetch it.

We never got to the point where we'd need to shard, alas. I'd like to think I would've thought of the index-per-table approach independently, but probably not.

Curiously, I did things this way for ease of development, not performance (and there were probably lots of little things that would've killed our performance anyway - it's really hard to diagnose performance bugs until you have real users banging away). We needed a storage system - MogileFS and MySQL work out of the box. We needed a data format - JSON works out of the box. We needed to be able to change game schemas rapidly, since we kept finding our existing design was not really fun to play with (and that's what killed us, ultimately). The rest of it followed pretty obviously.

<comment><USER5> I just recently wrapped up using a similar "store serialized data" set-up myself. In my example, I'm allowing the user insert/remove/reorder items on a list. This type of operation is pain to do with SQL operations. If you have a list, A,B,C,D,E,F and you want to insert G before C, then you either have to:

      delete all, then insert A,B,G,C,D,E,F.
      set "sortnumber" on G to "3", and increment sortnumber on all >= 3.
      set "sortnumber" of G to be the average of B and C.

The latter is the cleverest, but eventually you run out of space in floating- point land, unless you have a Cron come in and clean everything up periodically. And of course, reordering (the example was an insert), and removing need to be considered as well. So it's a choice between lots of deletes and inserts (but really easy). Semi-annoying logic of reordering/removing and a few updates. Or clever hack that requires a cron to cover your ass.

What I did instead was stored the list as JSON, convert it to an array, and use array splicing functions to reorder things. Then, I convert it back to JSON and store it. It's worked extraordinarily well... It takes a fraction of the amount of time to do native data structure stuff than it does to touch the DB several times.

<comment><USER6> While your approach to do this in JSON is cool, I think you have overlooked the 'direct' solution to do this in a RDBMS - with a linked list. Here is a quick suggestion (works in Postgres):

        create table l (
               id char primary key references l(prev) deferrable initially deferred,
               prev char unique not null references l(id) deferrable initially deferred,
               mydata text not null
        );

then I populate the table with your example items:

        insert into l (id, prev, mydata) values ('A', 'F', 'dA'),
                                                ('B', 'A', 'dB'),
                                                ('C', 'B', 'dC'),
                                                ('D', 'C', 'dD'),
                                                ('E', 'D', 'dE'),
                                                ('F', 'E', 'dF');

let's see how that looks like:

        test=# select * from l;
        select * from l;
         id | prev | mydata
        ----+</comment></comment></comment><comment>+</comment><comment>--
         A  | F    | dA
         B  | A    | dB
         C  | B    | dC
         D  | C    | dD
         E  | D    | dE
         F  | E    | dF
         (6 rows)

to insert a new item into the list, you would do:

        begin;
        update l set prev='G' where prev='C';
        insert into l (id, prev, mydata) values ('G', 'C', 'data for G');
        commit;

so that's one update, one insert for an insertion into the list. Note that the two commands have to be in one transaction, because inside the transaction the foreign key constraint is violated (as allowed by the deferrable initially deferred modifier).

Let's inspect our list again:

        test=# select * from l;
        select * from l;
         id | prev |   mydata
        ----+</comment><comment>+</comment><comment></comment><comment>
         A  | F    | dA
         B  | A    | dB
         C  | B    | dC
         E  | D    | dE
         F  | E    | dF
         D  | G    | dD
         G  | C    | data for G

so the predecessor of G is C, and the predecessor of D is G, like specified.

Of course, you loose the ability to sort with 'order by', but that's no big deal: you know the predecessor and successor of each item, so it's easy to traverse the list in either order. This could be done on the client side [probably the best solution in your case], in the application code, or inside the database with a stored procedure or with a recursive query (coming in PostgreSQL 8.4), in Oracle it could probably be done with 'connect by'.

In reality, you would of course choose other datatypes for id and prev (probably integer), but I wanted to translate your example as literally as possible. Another problem that's easily solved: how do I get all elements of one list? Solution: Either give me one 'starting element' and the list is traversed and returned. Or introduce a listId attribute and select by that, which is probably faster but without sort order.

<comment><USER5> There's one more thing I forgot to mention...

The data I'm having the user order is not only order-specific, but is recursive. That is, one of the items on the list, rather than be a letter like "B" can be a list in and of itself. It's basically like "files and folders"

A major problem isn't only the UI, which took me days to make (drag and drop for files/folders ... anybody seen anything like this done before in HTML+JS?), but mostly is in the updating/validation. I receive information, like "moved item: /path/to/item to before /some/other/path" and I now need to make sure this is a valid action (eg: can't put a folder into one of its own subfolders, can't put a file in a file, etc), and also update the database to reflect this.

I chose to use JSON to encode objects in the DB, then decode them into an array, and do some easy/fast array stuff to perform the action they requested. Just judging on the array code, which does several "isset()" calls and splices, I'd imagine doing this with a DB would be a major heartache... but I have no doubt you'd be able to come up with some brilliant way to do it.

To each their own :)

<comment><USER6> > To each their own :)

yeah, of course! And if it works, then, by definition, it's good for your customers and thus for you! Also, your approach is probably more flexible (no fixed schema for the recursive list structure), which makes it easier and faster for you to iterate and react to customer feedback.

If at some time you want to have a more fixed structure or let the database do some of the server-side validation work of your tree-like structure, here is a good writeup by Phil Greenspun showing how to model and query tree-like datastructures with an RDBMS: <http://philip.greenspun.com/sql/trees.html> (the rest of the document 'SQL for Web Nerds' is also quite good stuff: <http://philip.greenspun.com/sql> )

he uses 'connect by', which is a non-standard Oracle extension, the same thing can be achieved with 'with recursive'-queries, which is standard SQL (1999) and part of PostgreSQL 8.4 Also, Joe Celko's Book 'SQL for Smarties' has a good chapter covering hierarchical data structures in SQL (he also has a separate book about 'trees and hierarchies' in SQL).

Oh, and good luck and much success with your startup!

</comment></comment></comment><comment><USER7> This is great. I sketched out a similar design for the Delicious backend, but the team that built it went in a completely different and stupid direction. Oh well.

Mine also had:

\- some way to do server locality (I don't think FF needs this)

\- some way to do table locality (I don't think FF needs this either)

\- per blob versioning and type

\- a virtual shard layer, so new machines can be added inexpensively

Sorry for any inadvertent whining, incidentally.

</comment><comment><USER8> Excellent article. I work in an environment where we have serious vendor lock- in and the people in charge of infrastructure have a real fear of change. I have free reign to implement in any improvements in our performance and code so long as I don't make things difficult for them.

Thus, the idea of a MySQL cache system is something I've been planning to look at for a while as it plays with the existing infrastructure. This (seemingly proven) system will make things a lot easier, so thanks for sharing.

</comment><comment><USER9> "However, none of them seemed widely-used enough by large sites to inspire confidence. In the tests we read about and ran ourselves, none of the projects were stable or battle-tested enough for our needs"

Ok, just some hour ago I released the beta-3 of Redis (<http://code.google.com/p/redis/> if you care) and I'm near to feature-freeze with exactly with this goal. To make it rock solid (I'm going to use it in my startup's web stuff with a lot of users/month, so I care about stability).

The question is: what's in your opinion the right path to make a system like Redis stable and reliable for the real world usage? What to publish on the site in order to inspire a good feeling about stability? Thanks

<comment><USER10> How is redis different from TokyoTyrant?

<comment><USER9> it's higher level. Not a plain key value stuff. For instance as value you can have a list or a set, push/pop elements, ask the server for all the keys matching a given glob style pattern and so on. Most of this operations are atomic in order to make sure there are no race conditions.

You can read more about the difference between Redis and other key-value stores here: <http://code.google.com/p/redis/wiki/FAQ>

Basically the long term goal is to have something between a relational DB and a key-value DB. Not all the higher level features must be killed in order to be scalable.

</comment></comment></comment><comment><USER11> That's reassuring, I thought I was the only crazy fool who was storing json objects in database columns =). We do something similar for some of our data models at thesixtyone.com. It's really nice for not having to bring down the site for schema upgrades.

<comment><USER12> _It's really nice for not having to bring down the site for schema upgrades._

All the other popular databases let you modify the schema online. This feature has been taken for granted for over a decade.

<comment><USER13> Indeed. This is not a RDBMS problem. Its a MySQL problem and the correct solution is to use a mature DB.

<comment><USER14> Even in Oracle, we've had to schedule downtime for a single column schema change and population for 45 minutes. I would call Oracle "mature."

Note: I wasn't involved in doing the update, so it's possible there was a better way to do it. The table is used by about 50 different applications.

<comment><USER15> Almost all major oracle operations can be done online ... Index rebuilds, table reorgs etc. Depends how much hardware you have how much it affects things ...

</comment></comment></comment></comment></comment><comment><USER16> We're doing something very similar to store RDF data. Our reason for doing it this way isn't performance but rather RDF's pretty intricate schema requirements (and opportunities). The drawback of using this scheme is that it roughly doubles the amount of data stored.

Contrary to Friendfeed, we have to use joins a lot because analysing data is the purpose of our application. We tried to do it with mysql, but mysql turns out to be completely unsuitable for the task due to its lack of merge or hash joins.

I'm quite surprised that someone like Friendfeed would change their entire data model for performance reasons instead of considering a stronger RDBMS (of which there are many). Their problem with index maintainance isn't exactly new. It's a solved problem that needs no wheel reinventing and doesn't merit the increased complexity of asynchronous index updates in my view.

</comment><comment><USER5> Really a great way to do things... thank you so much for sharing this.

I can't really see any disadvantages to doing anything this way. You still obtain access to data in a relational sense, though where normally you compare columns of a table you'd now do joins. For example, you can get the unique users that have submitted a link by joining the index_link table to the entities table, then joining that to the index_user table.

The problem here seems to be that sharding would prevent this type of operation... so how do they get around this? It's possible they just don't need this data, but lets assume they do. I'm presuming they have some slave(s) munging non-realtime-needed data into whatever _real_ relational tables they choose. But, if the problem because realtime, I'm at a loss as to how they'd do it.

<comment><USER4> They explained the sharding in the text - I glossed over it on first read- through too. When they say "join" in quotation marks, they don't actually mean a join in the MySQL sense. Rather, the initial call to user_id_index.get_all reads all entity_ids for that user into the Python code (they say it consults all shards for this, but isn't the index sharded on user_id, so all entities for a given user_id live on one shard?). The Python code then uses whatever shard function applies to the entities table to query its database backends, selecting the relevant entities. Then the Python code filters the returned records by the indexed field (in case the indices are out of date) and returns it.

As for disadvantages - well, it's denormalized, for starters. ("Normalization is for sissies", says Cal Henderson.) If an indexed field changes, you need to update it in both the index and the relevant entities. There're also a bunch of little inefficiencies, places where they traded performance for scalability. Imagine if you naively plugged this engine into an app with only 10 records: instead of a simple index search, it'd have to go to the index table, fetch the relevant entities, go to the entities table, fetch them, filter on indexed value, and then return them all. But then, if your database fits on one machine, you don't have the same sort of engineering challenges FriendFeed does.

<comment><USER5> When they say it's sharded on "user_id" what they mean is that's the field that decides which database the record is stored. It might go something like: if the user starts with 0-8, store in DB1, otherwise, store in DB2. This is up to their Datastore controller to decide how to hash based on the user_id and the number of databases.

<comment><USER4> Yeah. They actually explained that in the article too - the shard number = user_id % num_of_shards. So user 1 is on DB1, user 2 is on DB3, etc. If they have 10 shards, user 11 starts back on DB1 etc.

<comment><USER2> I don't understand how that scheme can work, since changing the number of shards changes the location of most users.

e.g. we have 4 shards, so user 5 is on shard1. If we go to 6 shards, user5 is now on shard5.

I guess it works with downtime to move the users, or another layer of indirection, where the newly created shards can "point back" to existing shards, but otherwise I don't see it.

My understanding of sharding is that it's best to have a global lookup table user->shard. That's not a huge amount of data, even for millions of users.

Anyone care to educate me as to how they get user%num_shards working in practice?

<comment><USER14> I don't see how this scheme can scale simply for the reason that there's no built in balancer. What's to stop shardN from becoming overwhelmed when all the power users end up there, while shardN-1 has no activity?

<comment><USER17> Edge-Case YAGNI. Have _lots_ of shards, put multiple shards on each machine, shuffle the shards around as necessary. Rinse. Repeat.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I like the trick for getting around index creation and deletion, I wasn't aware that MySQL required a full table lock. I checked the docs for DB2, and it allows read/write during index creating -- is this a MySQL only limitation or do the other major databases impose the same restriction?

<comment><USER12> Pretty much it's MySQL only.

Most of the MySQL posts here are actually about clever ways to do things most DBAs and developers have taken for granted for years. Do you wonder why no-one seems to be writing blog posts about "sharding" Sybase or DB2 or Oracle or Postgres...?

<comment><AUTHOR> Actually, they do, e.g. [http://highscalability.com/skype-plans-postgresql- scale-1-bi...](http://highscalability.com/skype-plans-postgresql- scale-1-billion-users)

MySQL is popular with startups though, so it's not surprising that there's a lot written about it.

It's true that MySQL has some lame limitations, but I don't believe that there are any silver bullets out there. Google tried to switch their ads system from MySQL to a "real" database once, and it was basically a disaster and had to be abandoned in favor of MySQL (I wasn't working on it, so I can't really give all the details).

Another problem we had with MySQL that Bret didn't mention was that it would try to be "smart", and sometimes it would "randomly" (from our perspective) choose a very inefficient strategy, and we would have to waste a lot of time figuring out what it was doing and how to force it to do the right thing. The approach Bret describes basically avoid any MySQL "smarts" and treats it as a dumb, but fast and well tested B-tree. This gives us fairly reliable and predictable performance characteristics because we know exactly what it's doing (mostly).

<comment><USER19> No, there are no silver bullets, but it seems to me that people reach for Mysql a bit too quickly, without considering the pros and cons. And while it's improving, Mysql has had many frustrating things in the past... to me it's always seemed like a "worse is better" kind of thing. Sure, it's "fast", but at what cost? Once you go to InnoDB, you lose that speed advantage.

One thing that's not a tech tradeoff, and is generally a Postgres win, is the BSD style licensing. You can take Postgres and do whatever you want with it with no worries.

> Google tried to switch their ads system from MySQL to a "real" database > once,

I hope the part that actually handles money has been fiddled with by Google to be robust.

<comment><USER20> Actually, Postgres doesn't have any great out-of-the-box solution for partitioning the database across machines. The usual suggestion is Slony, but that is no where near as robust and widely deployed as MySQL replication. The GPL licence for MySQL isn't really a problem for webapps anyway.

OTOH, Postgres does somewhat better than MySQL on a single box with multiple cores (it's fairly linear up to 8 CPU, which is much better than MySQL) - mainly because of the work Sun put into scaling it before they bought MySQL. (At least - that's according to some people from Sun who do a lot of performance work with both databases)

<comment><USER19> It's not as robust? Do you have a source for that? You're doubtless right about it not being as widely used.

I've always preferred the fact that Postgres tried to do things correctly. Most recently, I bumped into this with Mysql, and it reminded me why I get irritated when I use it:

[http://journal.dedasys.com/2008/11/11/another-mysql- doesnt-d...](http://journal.dedasys.com/2008/11/11/another-mysql-doesnt-do- that-moment)

I've often bumped into things like that that just irk me.

</comment></comment></comment></comment></comment></comment><comment><USER21> Reading this makes me realize how naive my DB setup is for my startup.

<comment><USER22> Did you read the part where they said this was the third or 4th iteration of their DB backend? Or maybe I read that somewhere else.

Point being, experience will come.

</comment></comment><comment><USER23> This looks better suited to the B-Tree version of Berkeley-db than MySQL.

</comment><comment><USER24> I love this key-value store trend. Looking at CouchDB in particular has made databases are fun again.

</comment><comment><USER25> cool. very interesting.</comment>


Show HN: Reaching $1k MRR with user feedback tool - <AUTHOR> https://owwly.com/product/Upvoty-22/post/Reached-dollar1k-MRR-with-my-user-feedback-tool-74 <comment><USER2> It's the 4th submission of a owwly.com blog post as 'Show HN' in the last 7 days.

"Blog posts, sign-up pages, and other reading material can't be tried out, so can't be Show HNs" [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

<comment><AUTHOR> Ohh sorry for that. You're right, my mistake. In the future, I will more closely look at rules.</comment></comment>


How Do You Stop Sea Captains From Killing Their Passengers? - <AUTHOR> http://www.npr.org/blogs/money/2010/09/09/129757852/pop-quiz-how-do-you-stop-sea-captains-from-killing-their-passengers <comment><USER3> It is easy to underestimate the difficulty of creating the right incentives.

 _In the 1940's, the paleontologist von Koenigswald was searching for early human remains on Java and decided to enlist the help of the locals in his search by offering them "ten cents for every piece of hominid bone they could come up with." Unfortunately for von Koenigswald (and for his findings), he discovered too late that the locals "had been enthusiastically smashing large pieces into small ones to maximize their income."_

From [http://freakonomics.blogs.nytimes.com/2009/10/20/when- youre-...](http://freakonomics.blogs.nytimes.com/2009/10/20/when-youre-paying- per-bone-fragment-expect-more-fragments/)

(The story is from the book _A Short History of Nearly Everything_ , which is one of the best books I've ever read. The amazing thing about the book is that it is in fact a short history of nearly everything.)

Combine the difficulty of getting incentives right with the inherent problems of Government and a dangerous mix results. For example, every time a subsidy is created, a special-interest group sprouts up dedicated to preserving the subsidy in perpetuity, long after it has outlived its utility.

<comment><USER4> > It is easy to underestimate the difficulty of creating the right incentives.

My favorite "Incentives matter" story is FedEx - they were having a hell of a time getting drivers to get packages shipped on time. They tried all sorts of things - threatening, praising, performance reviews, training, etc.

None of it worked.

Then they changed their pay from "per hour" to "per shift" - you work a shift, you get paid a certain amount. Go home when you complete your shift, regardless of how long it takes you.

Right away, their on time rate went massively up - in fact, a lot of shifts started being completed early at that point.

<comment><USER5> The danger of this sort of an incentive is that there may be some hidden externalities that will be exposed. I wonder if the accident rate per shift also increased when this system was established (c.f. Dominos delivery and unintended liability...)

<comment><USER6> I was a driver for a big pizza firm. We were paid bonuses depending on how fast we delivered.

Unfortunately for me, I wasn't close friends with the manager of the store. He gave all the shortest runs to all his mates, making it nigh on impossible to get a bonus unless you suffered his patronage.

</comment></comment></comment></comment><comment><USER7> It's interesting that they tried the tactic of micro-regulating every aspect of the ship captain's business and that didn't work as well as broad incentives.

Today, this micro-regulation is politically popular as voters can more easily comprehend the direct effects of regulation as opposed to the indirect effects of broad incentives. For example, we force drug companies to perform very extensive clinical trials for new drugs and this makes us feel safe. But simply increasing the liability drug companies face for producing harmful drugs may be more effective and would certainly be a lot cheaper (as much as 90% of the cost of a new drug is meeting FDA requirements). But I doubt voters would feel as safe in a regime of broad incentives even if it worked better.

<comment><USER8> It's also driven partly by a preference for that kind of regulation from the companies themselves (though they would prefer less regulation overall). Having to follow a bunch of rules on FDA trials is a manageable, mostly predictable expense; large, nearly unlimited potential liability if a drug turns out to have significant negative effects 10 years down the line is much scarier to managers and stockholders.

That's one reason the health industry is currently lobbying to move it in exactly the opposite direction of what you propose: they want _less_ broad liability, and are willing to accept more FDA micromanagement in return if that's what it takes. The proposed bargain is something like: the FDA should tell us what to do, and if we follow their rules, we should be shielded from all liability.

<comment><USER9> Regulation = Barriers-to-Entry. Businesses accept (and secretly cheer on regulators.) People get this connection, even though it is non-intuitive on the face of it.

What is less studied are the regulators themselves. They rarely impose the kind of regulation that opens industry actions to sunshine and converts them to common knowledge.

There is a substantial body of theory that shows that the price system breaks down in the face of informational asymmetry. But regulators don't go for it since it does not make them more powerful. That's human nature. And it's fine with businesses, who would prefer to answer to the One rather than the Many. Preserves barriers to entry.

</comment></comment></comment><comment><USER10> Charlie Munger: "One of my favorite cases about the power of incentives is the Federal Express case. The heart and soul of the integrity of the system is that all the packages have to be shifted rapidly in one central location each night. And the system has no integrity if the whole shift can't be done fast. And Federal Express had one hell of a time getting the thing to work. And they tried moral suasion, they tried everything in the world, and finally somebody got the happy thought that they were paying the night shift by the hour, and that maybe if they paid them by the shift, the system would work better. And lo and behold, that solution worked."

</comment><comment><USER11> The Maersk Dubai incident is a real-world modern-day story of a captain killing some stowaways:

 _On March 12 1996, two Romanian stowaways, Radu Danciu and Petre Sangeorzan, were discovered on the container ship Maersk Dubai and ordered overboard on a makeshift raft, approximately 70 kilometres off the coast of Gibraltar. On May 18 of the same year, en route to the Port of Halifax, another Romanian, Gheorghe Mihoc, was found hiding in a large cargo container and forced overboard at knife point by Captain Sheng Hsiu and four of his officers. A fourth stowaway, Nicolae Pasca, was discovered by Filipino crew member Rodolpho "Rudy" Miguel and kept hidden until the ship arrived at Halifax, where eight Filipino crewmen (including Miguel) jumped ship and reported the incident to the authorities._

 _Upon arrival in Halifax the Maersk Dubai was stormed by the Royal Canadian Mounted Police (RCMP) and Captain Hsiu and his Taiwanese officers were arrested and charged with first degree murder. The radio operator attempted to escape by jumping into the Halifax harbour and was later arrested. Captain Hsiu attempted to deny access to the ship under international shipping laws..._

[https://secure.wikimedia.org/wikipedia/en/wiki/Maersk_Dubai_...](https://secure.wikimedia.org/wikipedia/en/wiki/Maersk_Dubai_incident)

I learned about this story because it's part of the theme of the concept album _Magellan's Wake_ , by Savatage (which is largely the same as the more popular "Trans-Siberian Orchestra")

</comment><comment><USER12> It should be mandatory for any incoming politician to take a couple introductory economics courses before serving. There are too many laws where incentives are not aligned properly, fundamentally dooming the policy to failure.

A good example of an incentive problem that's recently unfolded: now nearly 50% of US households have no federal income tax liability.

Edit: It's nearly 50%. It was 38% in 2007, 47% in 2009. Also, 40% of households "make a profit from the federal income tax system, meaning they get more money in tax credits than they would otherwise owe in taxes".

[http://www.usatoday.com/money/perfi/taxes/2010-04-07-income-...](http://www.usatoday.com/money/perfi/taxes/2010-04-07-income- taxes_N.htm)

<comment><USER13> Citation on that 50% please. I have never heard that.

<comment><USER14> Well I just googled this: <http://www.msnbc.msn.com/id/36226444/>

Another way to escape federal tax liability (up to ~$90,000 income) is to live outside the US 11 months / year

<comment><USER15> You are probably paying tax in the country you moved to though.

<comment><USER16> Well, if the other country has income taxes. For example, in the British Virgin Islands the income tax rate is zero.

I don't get why more Americans aren't enraged about the United States' treatment of emigrants. For citizens of most other countries, if you don't live there and you don't make money there, you don't pay taxes there.

<comment><USER8> Why would Americans be enraged about that? The U.S. has a long history of distrusting people who leave the country. Sticking it to emigrants (i.e. people who "abandoned the USA") would be popular among both the left and right, and among many social classes. Emigrants aren't very well liked among populists in either the Republican or Democratic parties, sometimes even seen as approaching a mild form of treason, whether they left for draft-dodging reasons (Candada during Vietnam), tax-dodging reasons (BVI & co.), or political reasons (communists who emigrated to Russia). People don't mean "love it or leave it" in the sense that both are legitimate choices!

I say this as someone about to start a job in Europe myself; it's somewhat of a sore point with many people ("America not good enough for you?"). The current economy being bad is really the only thing that makes it relatively easy to smooth over, because I can fall back on, "well nobody in the U.S. was hiring in my area and this opportunity in Europe came up", and people sorta understand because everyone's willing to believe that the U.S. job market is bad right now.

Mostly I can't think of the constituency that would support lowering taxes on emigrants. Republicans are usually the enthusiastic tax-cutters, but emigrants are even less popular among Republicans than among Democrats, partly due to heartland-patriotism type of culture, and partly because the expat vote is skewed Democratic.

</comment></comment></comment></comment></comment></comment><comment><USER17> Sorry for this off topic comment but it's related(kind of): I've always wondered how a crime committed on a ship can be caught. For example, the crew of a ship mutinies against their captain and throws him overboard. When they get back to port, they claim that their captain was swept overboard during a storm. The crew, as one man, sticks to their story. Will anybody ever be able to prove otherwise?

This approaches being the perfect crime as the number of crew members go down, doesn't it?

How is this handled?

<comment><USER18> I suppose the investigators would look for inconsistencies in 'the story' as told by different parties. If 'the story' is true then additional detail will be forthcoming and generally non-contradictory between accounts. If its all a cover-up then individual suspects will invent different details and give themselves away. 'We know at least _one_ of you is lying.' At which point someone will betray the conspiracy for favourable terms, and the police will have a real witness. Maybe also this is the reason for a 'captain's log' - <USER2> that went missing too then there'd be even more suspicion.

<comment><USER17> True, but the lesser the number of crew members, the more chances that they'd have a consistent story.

But good point about the 'captain's log' though.

</comment></comment></comment><comment><USER19> What is stopping the "captain" from taking a little detour to the English country side, better yet, New Zealand, and kidnapping a few farmers?

<comment><USER20> I imagine it's pretty risky, since the local farmers would presumably have weapons, and know the land better than the captain.

<comment><USER21> Eh, lookup the term shanghaied - be good at buying people drinks and voila, free money!

</comment></comment></comment><comment><USER22> I once worked with a guy whose grandparents sailed from Portugal to California. The captain of the ship held food back from the passengers to sell when he got to California. When they arrived in California, the passengers found out and hung the captain. Which is a different kind of incentive.

</comment><comment><USER23> I totally agree that incentives are great, but sometimes laziness beats incentives. I was told by someone that they paid workers in a 3rd world country by the amount they did, thinking they would do more, but instead they did the same amount in less time and then sat around for the rest of the day.

</comment><comment><USER24> There's no denying that incentives matter, but the key difference between the regulations they tried and the financial incentive they finally adopted is accountability. It was easy to hold the captain of a ship accountable for the number of prisoners who walked off a ship in good health, and impossible to enforce regulations about what should happen on the ship itself. The fact that they tied that accountability to a financial incentive is a red herring. They could have just as easily tied it to a regulatory penalty, with similar results.

It's depressing that a professor is using such sophistry to justify his existence to his students.

</comment><comment><USER25> This story seems too cute and oversimplified. Did it really take an economist to figure that out? I'd like to see the real story, does anyone know have a reference?

<comment><USER26> It really does. It's as if I was paying UPS to pick up my packages, but it only delivered 2/3 of them. I wouldn't be wracking my brain very long to come up with the same solution.

My guess is that the problem was that there were no incentives for politicians to think of this as a problem, and seeing as it survived a "scandal," probably some incentives not to care. I'd like to know who was getting the contracts, and who their connections were.

I also wonder if there was some faction screaming about not imposing crushing regulation on the noble businessmen who were providing a crucial and critical function to protect our civilization, and if they overlapped with the connections:)

EDIT: Also, this is a simple matter of paying for what you want. If you want people to get rid of the prisoners, pay them to haul them away. If you want prisoners _delivered_ somewhere, pay them for what they _deliver_.

</comment></comment><comment><USER27> I'm wondering if folks here have any "best practices" they can share for creating the right incentives? (Or should that be a new thread?)

This was something I was very good at figuring out for raising my sons. Thus, issues related to this at my job really get on my nerves (because I am convinced it can be done better). So I am wondering what people know about solving this issue for corporate culture -- or even on the start-up scene.

</comment><comment><USER28> One party (the government) was paying another party (the captain) for their services and then they figured out the best way to do it to get what they wanted. This is not an example of governmental regulation.</comment>


Inside the Fight Over Bitcoin's Future - <AUTHOR> http://www.newyorker.com/business/currency/inside-the-fight-over-bitcoins-future?intcid=mod-yml <comment><USER3> I feel the article does Pieter Wuille a disservice by mentioning the Blockstream/sidechains conflict of interest _without_ mentioning the fact that he is actually in _favour_ of raising the block size limit (albeit gradually, over time) and has authored a proposal to do so: [https://gist.github.com/sipa/c65665fc360ca7a176a6](https://gist.github.com/sipa/c65665fc360ca7a176a6)

What's ironic about this whole affair is that four of the five core developers support raising the blocksize limit (Gregory Maxwell is the sole dissenter, preferring to wait until a transaction backlog develops before taking action) but they diverge on exactly _how_ and how quickly to raise it.

<comment><USER4> I honestly feel that some of the "pro raising" devs aren't actually in favor of raising it anytime in the foreseeable future, and are just dragging their feet in the hopes of that the whole thing will go away.

The whole point of this debate is that we've been litigating this affair for the past three years, each year a several core devs claiming to want to raise it "soon", and then it just gets put down another year.

I'm still not sure about the BitcoinXT gaining consensus, but I'm very glad _someone_ is putting real pressure on the situation, because that's the only way the block size will be raised anytime in the next few years.

<comment><USER3> My take on it is that the key difference is that Gavin perceives a greater urgency in raising the limit before we reach the point where blocks start getting filled up, than Jeff/Wladimir/Pieter do.

I think he got frustrated that no progress was being made, which sparked his decision to add the relevant code to XT, which is what has brought things to a head. I actually suspect that his preferred outcome is _not_ to fork the blockchain into XT and Core, but to put some pressure on the other core devs to act.

<comment><USER5> Would Bitcoin XT exist if there were no need to pressure the other core devs? I.e., does it serve some additional or original purpose?

<comment><USER3> Yes, it's been around for a while and contains various enhancements and patches that aren't in Core. See [https://bitcoinxt.software/patches.html](https://bitcoinxt.software/patches.html)

<comment><USER6> > Yes, it's been around for a while and contains various enhancements and > patches that aren't in Core. See > [https://bitcoinxt.software/patches.html](https://bitcoinxt.software/patches.html)

Only if by enhancements you mean damaging centralization bugs.

TOR blacklisting by default for example

<comment><USER4> I'm still not sure how I feel about that patch, but to be clear it does not blacklist Tor by default. What it does is that if a particular node detects a DOS attack that originates from the Tor network, each node with then down rate the Tor IPs (since that's where many of the DOSs originate from), giving non- Tor nodes higher precedence. And thus avoiding the DOS attach for non-Tor nodes.

Under normal conditions, Tor nodes are fully integrated into the network.

Like I said, I'm still ambivalent about this patch (for multiple reasons), but saying blacklisting Tor by default might give people the wrong impression of what it does.

In the words of BitcoinXT site [1]:

"This patch set introduces code that runs when a node is full and otherwise could not accept new connections. It labels and prioritises connections according to lists of IP ranges: if a high priority IP address connects and the node is full, it will disconnect a lower priority connection to make room. Currently Tor exits are labelled as being lower priority than regular IP addresses, as jamming attacks via Tor have been observed, and most users/merchants don't use it. In normal operation this new code will never run. If someone performs a DoS attack via Tor, then legitimate Tor users will get the existing behaviour of being unable to connect, but mobile and home users will still be able to use the network without disruption."

I've looked at the patch, and that's pretty much what it does [2].

1\. [https://bitcoinxt.software/patches.html](https://bitcoinxt.software/patches.html) 2\. [https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8...](https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23)

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I totally agree with that part of the conclusion that says Bitcoin has failed in regards of it's "no need to trust anyone" goal. It's not a failure for us though. There are so many things we can learn from Bitcoin, like no matter what your technical solution is, you'll always have power bubbles (e.g., for bitcoin the power aligns around the developers and the huge farm owners), you'll always have disagreement in the community no matter how morally high your goals are.

<comment><USER8> > There are so many things we can learn from Bitcoin, like no matter what your > technical solution is, you'll always have power bubbles

If many of Bitcoin's believers had only been less dismissive of the social sciences, they could have known that long ago. In fact, if they had only been less dismissive of politics, they would have known that people who dismiss politics are simply people who don't know what it is, and those are the people who eventually do _bad_ politics.

Politics is a property of any social interaction and is simply _influence over others_ (by any _social_ means -- even technological). As an academic field of study it is the study of the flow of power (simply put -- influence) in a society.

<comment><USER9> I wouldn't lump all us Bitcoiners together. It was very clear right from the start that Bitcoin is just a tool that lets people rearrange and disperse power, not a magic cure-all (even though some people get rather breathless over The Blockchain™).

If you look at the current dispute, it looks somewhat like what an election campaign for central bankers might look like if western countries were to allow for such things. Or rather what the first one might look like, if the current set of central bankers weren't really on board with the whole idea. You've got different groups with differing visions running something that vaguely resembles an election, but the issues are rather wonkish and technical.

Undoubtably many people will look at this whole thing and say, look how much more professional the dollar or the euro is. You never see such disagreements in the Fed! But I think the social failures that are leading to this crisis are actually also present there too: an assumption that experts never disagree, a preference for opaque unanimity, and a strong mental/emotional link between (perceived) unanimity and credibility.

Put another way, it's difficult to imagine a new central banker announcing that his/her predecessors and peers were all wrong and - for example - <USER2> correct inflation rate to target is 0% and not 2%. Even though there _are_ economic papers out there that imply their policies might not be correct (written by economists at central banks, no less), the giant shitstorm that'd unleash would be extremely un-Central-Banker like and be seen as a serious threat to the credibility of that CB or even that country.

Bitcoin, for all its faults, does at least have some kind of mechanism to handle the case where the people making boring technical decisions stop doing it right.

<comment><USER8> > If you look at the current dispute, it looks somewhat like what an election > campaign for central bankers might look like if western countries were to > allow for such things.

But they do (indirectly, of course)! Conformity of thought arises not because of the _rules_ of the democratic system, but because of the way power tends to get concentrated in homogenous groups (another thing the social sciences tell us), unless resisted by some civil action.

> Bitcoin, for all its faults, does at least have some kind of mechanism to > handle the case where the people making boring technical decisions stop > doing it right.

I don't think that the Bitcoin _system_ has any such advantage. The only difference I see is that Bitcoin's leadership are not accountable (even nominally) to any collective social interests that go beyond technical concerns regarding the currency. Whether that's good or bad depends on your ideology.

You cannot fix the bugs in the workings of a system that on paper seems like it should work (i.e. modern democracy) without understanding what the bugs are and how they're created (and even then it's very hard, and entails a lot of politics, meaning influencing people), and you can't learn about those bugs in the mechanism if you dismiss the academic disciplines that have studied it for decades to centuries (depending on the discipline). You certainly can't do all that without an appreciation for politics.

<comment><USER9> > But they do (indirectly, of course)!

Who do?

In all western democracies that I'm aware of, the central bankers are meant to be independent of politicians. Of course you can view this as a fiction, but all the players do seem to believe it and it's exceptionally rare for politicians to directly argue with, let alone override, central bankers.

> I don't think that the Bitcoin system has any such advantage. The only > difference I see is that Bitcoin's leadership are not accountable (even > nominally) to any collective social interests that go beyond technical > concerns regarding the currency.

Of course they are. You don't see developers releasing forks of Bitcoin that try to bring about economic outcomes, because such a fork would be almost certainly ignored by the userbase. But that doesn't mean it's impossible, or that it'd never happen even if the users were collectively strongly in favour.

Besides, the two can't be easily divided. The block size debate is a bizarre witches brew of technical concerns, pseudo-technical concerns and social/economic concerns. The line between them is often blurry. So even a fork implementing a very minor technical change is causing massive uproar. Some people just _really_ like the idea of a central planning committee of experts. Regardless, that's not a technical limitation of the protocol. In theory the fork can work.

<comment><USER8> > In all western democracies that I'm aware of, the central bankers are meant > to be independent of politicians.

What do you mean? They are _appointed_ (and reappointed or not) by politicians.

> But that doesn't mean it's impossible, or that it'd never happen even if the > users were collectively strongly in favour.

The difference is that in a state these things are done as part of bargains, which help prioritize. For example "I'll support your nomination for the chair of the central bank if you support my law allowing same-sex marriage". Sometimes these bargains can take the form of hostage-taking and be annoying, e.g. "If you don't repeal the ACA, I won't vote to raise the debt ceiling", but that's all part of the same process of keeping people in control. That bargaining, BTW, happens regardless of the political system (i.e. even in autocracies), only in a less explicit way and sometimes with different people involved.

Once you completely separate the power structure for the currency from other concerns, you lose that control, and you lose it in a very radical way. Thing is, it's harder to bargain with people with money because they are relatively immune to many social effects. However, one of the classical checks-and- balances mechanisms in history is that of money and violence (and, at some point, religion). The two are both forms of power (i.e. ability to influence), but unlike money, violence is much harder to concentrate in the hands of the few (technology is changing that, but there are other, subtler sanctions at play that resist total concentration of violence). So the rich could starve the poor _and_ had horses and swords, but they knew that if they went too far, they couldn't withstand an uprising.

The state made an interesting deal: a central authority (though ideally not concentrated -- the two are different concepts) would have a monopoly over violence (up to a point), and, in exchange, it would regulate money. It wouldn't let the poor kill the rich (again, up to a point), but, through regulation it would make sure that the rich don't starve the poor. Once you separate the two, and, in the process, make even extreme violence less disruptive, you break a very important balance that has been reached. Like some sort of a MAD doctrine, you _want_ to keep a mutual, implicit threat going.

Which brings me back to the first point about central bankers. Even after their appointment, and even if they're not interested in another term, they still have a responsibility toward their community -- as I hinted at before, democracy only formalizes certain rules that have always implicitly had an effect, and certain sanctions are always at play even if not made formal by the democratic system. Bitcoin breaks that, too.

</comment></comment></comment></comment></comment></comment><comment><USER10> This is very good news (that there is a fight). Open sourced currency that could be forked at any moment is a feature not a bug.

The fact that government currencies can't be forked, and thus never guarantee they stay competitive, is the main reason a bitcoin like currency is nearly certainly the future.

The downside is some medium/long term uncertainty in that exact currency. However this is a NECESSARY component.

<comment><USER11> I've tended to agree. Bitcoin is really just an early iteration of the cryptocurrency concept, and many of its "failures" are, in the long run, successes. This is why the "altcoin" ecosystem is so vital; they're doing a lot of the fundamental experimentation that's necessary for cryptocurrency in general to approach perfection.

Unfortunately, a lot of people fail to realize this, and champion Bitcoin specifically as the be-all-end-all of electronic money despite the sheer number of problems with it. This attitude, while understandable, is regrettable.

</comment></comment><comment><USER12> Bitcoin XT also has other changes decided solely by their two devs without fanfare or discussion; for instance, it disfavors Tor nodes and hampers anonymity.

This is not widely reported but is indicative of what we can expect from such a BDFL model. A BDFL is the end of Bitcoin.

The reason to oppose XT has nothing to do with blocksize and everything to do with control.

<comment><USER13> Interesting, source?

<comment><USER12> [http://cointelegraph.com/news/115153/bitcoin-xt-fork-can- bla...](http://cointelegraph.com/news/115153/bitcoin-xt-fork-can-blacklist- tor-exits-may-reveal-users-ip-addresses)

and

[https://www.cryptocoinsnews.com/privacy-backdoor-bitcoin- xt/](https://www.cryptocoinsnews.com/privacy-backdoor-bitcoin-xt/)

</comment></comment></comment><comment><USER14> This article is already stale: a near majority of the network has voted for BIP100 in the last few days.

[http://bitcoinist.net/block-size-debate-takes-turn-f2pool- re...](http://bitcoinist.net/block-size-debate-takes-turn-f2pool-rejects-xt- adopts-bip100-instead/)

<comment><USER15> "Near majority" or ~25% (i.e., sufficient to win but far from majority)?

<comment><USER14> Ah, sorry. Even the article I linked is potentially stale. Things seem to be moving quickly. The "near majority" statement was based on unconfirmed reports that another large pool has hopped onboard: [https://twitter.com/mkomaransky/status/636534235508178945](https://twitter.com/mkomaransky/status/636534235508178945)

</comment></comment></comment><comment><USER16> The Bitcoin core has definitely left the stage of rapid innovation. Instead, we can expect slow, consensus-based progress at best for the future. This is normal for a successful protocol and happened to html, smpt, tcp, etc. as well. Committees have taken over.

<comment><USER17> _The Bitcoin core has definitely left the stage of rapid innovation. Instead, we can expect slow, consensus-based progress at best for the future. This is normal for a successful protocol_

But that alone isn't indicative of the protocol's success, is it, can't that also be attributed to infighting?

Committees may propose things, but they've not really taken over as it's still the community(those controlling the networks computational power) that decides what changes to adopt right? And the only people who can actually implement changes are those with access to the core right? Or former core people who've splintered off(XT.) So what do committees have to do with this?

</comment></comment><comment><USER18> Suppose a client and server were connected with a connection running with speed of light. Even then, there is some finite limit as to how many bits can be transferred. How do we handle scalability beyond it then? By abstraction. Rather than sending raw data we only send what is relevant & decode it at either ends.

Now transactions are raw data that flows in the bitcoin network, but there will always remain a practical limit. Throughput of the network is number of transactions per unit of time it can handle, which translates to number of blocks per unit of time.

To increase the value of this equation, 3 things can be done: 1.increase block size 2.Decrease block time 3.Abstraction

The problem is that XT side considers increasing blocksize is the only way. The core side has presented sidechains as one of the methods of abstraction, but since they invented it they formed a company out of it and now it appears as conflict of interest. Anyways, XT side is painting the Core side as anti scaling, which is totally untrue, but since sidechains are not even being heard, they are inviting other proposals to be presented at the workshop in Montreal on 12th Sept.

<comment><USER19> What I don't get is how quickly the debate started and then dissolved with a potential hard fork as the outcome.

What was the urgency to make a change? Yes, Bitcoin couldn't scale as it was, but there wasn't even close to enough demand for Bitcoin transaction for the topic to have escalated so quickly.

Are Bitcoin people so delusional about how popular Bitcoin is or will be, that they thought the amount of transactions that could be put into a block was of such dire importance?

<comment><USER20> What do you mean "quickly"? The debate has gone on for years!

How many years do you think we should debate before someone takes action?

<comment><USER19> The debate may be old, fair enough, but the past three or so months, gasoline was poured on the fire and I'm not sure why.

</comment></comment></comment></comment><comment><USER6> The simple truth of the matter is that there is no urgent action required.

Blocks are only just now half full on average.

[http://ozlabs.org/~rusty/diagrams/blocksize- pretty.svg](http://ozlabs.org/~rusty/diagrams/blocksize-pretty.svg)</comment>


HN down? - <AUTHOR> http://news.ycombinator.com/ So... what happened? ;-) <comment><USER2> If it was down, how did ya post? And how would we see your post?

</comment><comment> nono-atwork yeah i saw it :-( and i cried

</comment><comment><USER3> Yeah for about 5-10 minutes. It happened a couple of weeks ago too I believe and it lasted for hours. I thought it may have been a problem on my end because other sites (not all) weren't working either, and I don't think I even saw anyone mentioning it here. Is HN hosted on Amazon?

</comment><comment><USER4> yesterday around 9:30EST and this morning.

Can someone post some info as of what have caused it..</comment>


Minefield - <AUTHOR> http://thedailywtf.com/Articles/Minefield.aspx <comment><USER2> This is a story about a sociopathic middle manager guarding his territory from someone qualified to take his job, but unfortunate enough to be hired below him.

When I read it, the first and only comment under this at DailyWTF was sympathetic towards Peter. I hope that commenter had just skimmed it and missed the point.

<comment><USER3> The blue comments at the bottom of the page are "Featured Comments" chosen by a moderator for being really interesting. The full comments list is <http://thedailywtf.com/Comments/Minefield.aspx>

<comment><USER2> Thank you for pointing that out. I went back and re-read the blue comment and there is more there than meets the eye.

Although Peter is painted to be a sociopath in the article, not every whiz-kid is pushed out because of one.

</comment></comment></comment><comment><USER4> I guess this is fair turn about. I've read plenty of stories/articles from managers and founders about how difficult employees are. Living most of my professional life in the role of manager has taught me a lot, but for my part, I'll never forget what is like to sit on the other side of the desk. I'm an advocate for the people who work for me. The sad thing is, this will probably hold me back. As happy as the ending of the story is, real life rarely lives up to the expectations of story plots.

</comment><comment><USER5> Am I missing the point? Isn't Peter just an asshole?

</comment><comment> brown9-2 In situations like these, how is it that the rest of management doesn't see how toxic "Peter" is? Can everyone really be that blind?

<comment><USER6> Two factors:

1) The overwhelming majority of information they see is information provided by Peter.

2) They don't really care that much as long as it doesn't screw up their universe.

<comment><USER7> True, but in this case they'd have to be totally brain dead not to realize something major was up after Peter got caught in a serious lie, one he'd made a really big deal about (the whole point of the meeting, after all).

Unless he had amazing protection from someone senior and powerful enough, he would be dead meat.

<comment><USER8> > Unless he had amazing protection from someone senior and powerful enough, he > would be dead meat.

You wish. It would be awesome if incompetence was _that_ easy to cull.

<comment><USER7> In this special case, where he called a meeting on the basis of a lie about an important thing and was caught out on it?

I agree, it would be awesome, but incompetence _plus_ industriousness at this at this level is seldom found. He wouldn't have been caught out if he hadn't moved to actively trying to get rid of Bobbie.

</comment></comment></comment></comment></comment><comment><USER9> I can't quite put my finger on why The Daily WTF's writing style reminds me so much of Reader's Digest. Thoughts?

<comment><USER10> It reads quickly and is easily likeable in a third person narrative is my best guess.

<comment><USER11> Also, much like Reader's Digest, the user-submitted anecdotes are typically re-written by the same person to give them all the same, easy-to-digest flow.

</comment></comment></comment><comment><USER12> This is not a true story is it?

</comment><comment><USER13> Peter was doing her a favor the entire time. It's like an M. Night Shyamalan movie with the paradigm shift at the end. She was over-qualified, so he didn't want her to be stuck at a go no-where company. While it does say "She could do Peter's job in a snap." this doesn't mean that he is afraid she will, but that she should be working somewhere more challenging.

He wants to get rid of her to save her.

This is what I thought for a minute after reading the featured comment and justifying his actions. But then I re-read it and realized that Peter is just an asshole and is 90% of the reason Corporate America is a piece of shit that deserves to burn in hell.</comment>


The most bizarre technical interview I went on - <AUTHOR> https://medium.com/@mrjoelkemp/the-most-bizarre-technical-interview-i-went-on-5bf955faf50f#.od2u9kkjv <comment><USER2> _The problem was to write a solution to solve the subset sum problem in polynomial time. The instructions specifically did not want the exponential time algorithm. After playing with the problem for a few minutes, I realized that the necessary solution involved dynamic programming._

Do FB engineering types really think that anyone -- save for mutants like von Neumann and Ramanujan -- is genuinely able to _solve_ problems like these from scratch, _having never seen them before_ , in such ridiculously short time frames? Being as typically they were kicking around as open problems (either in the literature or folklore) for years and years before the optimal solutions were found?

Or that such "tests" are a measure for anything besides rote memorization skills -- and the willingness to suck it up, and cram it out, week after week, specifically for otherwise pointless regurgitation sessions like these?

Really now -- do they?

<comment><USER3> They filter for having randomly encountered this exact problem before. Now, the complexity of the randomness goes way down if the candidate encountered an educational program in which this problem is known to have been exposed.

So it's more like a "clubhouse handshake" than anything else, IMO.

<comment><USER4> The "clubhouse" is "computer science undergraduate curriculum", which is available for free online.

<comment><USER3> So any accredited BSCS program ia guaranteed to have this particular problem in it?

This being said, "use a table" seems a pretty obvious thing.

</comment></comment></comment></comment><comment><USER5> If you're not interested in the algorithm bingo as /u/x0x0 put it (great description, by the way), then I would highly suggest focusing more on working at smaller companies that need intelligent people with experience. They don't care about people who can sort things in polynomial time or whatever; they need people who can hit the ground running and really help them out. And I'm not necessarily talking about the 3-person mom and pop shop down the street. Even companies with hundreds of people are often starving for good employees.

<comment><USER2> FB doesn't "need" people who can actually solve problems like these with a clock ticking (because basically no one can) -- or even people capable of regurgitating the answers. They're just mindlessly following the fad like everyone else -- only they seem to think they're being clever and taking it "up to the next level" by having people live-code NP-complete problems in front of a recruiter.

<comment><USER6> Yeah, these kinds of interviews are epically stupid. What's worse is that practices like this and similar ones from places like Google, etc. give credibility to dumb things that make for a terribly inefficient (at best) or outright toxic (at worst) job marketplace.

Other places follow the same practice because they hold these market leading companies up on a pedestal, which is tantamount to argument by appeal to authority.

But, but, but all the top companies do this and they're successful!!! Yeah, well they're successful despite stupid practices like this, not because of them. Their business models are so resilient that they can tolerate a whole shitload of failures in other aspects or dimensions and still come out on top.

<comment><USER4> Do you think that the people who invented PageRank and planet scale social graphs and virtualized server hardware and advertising auctions and personalizatio models were not capable of solving computer science homework problems?

<comment><USER6> 1\. I'm nearly 100% certain they're not hiring for the position of "Co- founder".

2\. I'm nearly 100% certain they couldn't derive, in real-time and in-scope of the interview, the solution to a PhD thesis problem they had never heard of before, nor previously been given the answer to simply to recall it later.

3\. I'm nearly 100% sure that if they can do #2, then they should be interviewing for #1 someplace else, not trying to become employee # X-thousandth-and-one in a mature enterprise, or that they'd never be asked these questions to begin with because they'd be interviewing for a job that was directly related to and based on their own pre-existing published academic works.

I'll start to believe that these companies are pioneering best-practices around hiring when their frontline recruiters are psychiatrists and psychologists who specialize in proficiency assessment and personality profiling.

</comment></comment></comment></comment></comment><comment><USER7> One of my favorite anecdotes, that I read on hn and unfortunately didn't save, is that a constant space algorithm for loop checking in a linked list was an open question for a long time. The rabbit and hare algorithm was novel enough that it was first published by Knuth in 1969.

So if you're asked that question in an interview, it's only checking if you've heard the answer. Because you almost certainly aren't going to come up with it on the spot.

That said, if you want to work at goog/fb/amazon/et al, you have to study, and that's a common dp problem. Put in your 100 hours of studying and you'll do fine. And before you grump at me, that's not an endorsement of this (I think it's quite silly), but we all know the deal. So stop whining and study before your interview, or don't bother interviewing with the well known list of companies that love algorithm bingo.

<comment><USER8> I agree. This is a sort of meta-interview.

Facebook is looking for (Devs Who Can Implement CS Algorithms) ∩ (Devs who can game the system)

The second criteria is arguably more important when working for FB, than the first.

</comment></comment><comment><USER9> I wouldn't call this bizarre; I'd call it sadly typical. "Write down things that were publication-worthy 40 years ago in a nearly impossible amount of time " is a very common interview technique these days. Even companies that know better do it. And, nobody interviews in a manner other than "write code, under pressure, with someone looking over your shoulder," even if they're not using absurdly hard DP problems.

It's sick how broken tech interviewing is.

</comment><comment><USER10> I recently did a remote interview via webex (not with FB, but with a big-ish tech company) so they could see my screen. It was for a full-stack-ish type job, although they asked me to do some questions in javascript. They said to "do what you normally do."

So I switched screens and googled it. Same for the docs for a few libraries that made things work (like the python csv module).

I not only got an offer, but I was told right up front "your google fu is strong."

I'd almost want to be looking for someone who does research on these problems. Reinventing the wheel is the classic engineering mistake.

</comment><comment><USER11> I had an interview once where the hiring manager asked me to estimate how many gas stations were in the US. I'm certain this was inspired by similar tech firm interviews but I just remember thinking afterwards how hilarious that was as a filtering criteria. Incidentally I didn't pursue the job because my would be manager kept using the word 'retarded' to describe things and I think people with any common sense should know better than that...

<comment><USER12> God I love those questions.

They're essentially essay questions- come up with reasonable-enoguh assumptions and get on with business.

We don't do a -ton- of stuff like that, but I've found that if you can't estimate with any rationale, you're probably just not very good at whatever domain you're asked to deal with.

For example, 'what sort of architecture are we going to use to make this system', 'how many simultaneous users are we expecting', 'how many requests per second can we handle given this hardware', 'how much memory do we really need- if we quadrupled it, what would that get us', etc.

Also- if a person locks up when they're thrown "How would you move mt fuji", there are going to be a lot questions that I'd be concerned about getting answers out of you for...

For a Sr or higher person, I'd hope to get some reasonable answers.

Am I off?

<comment><USER13> You're off. You're confusing Fermi Problems [https://en.wikipedia.org/wiki/Fermi_problem](https://en.wikipedia.org/wiki/Fermi_problem) with computer science algorithm approximation problems.

<comment><USER12> You don't feel that it's appropriate to ask a "Sr or higher" candidate questions such as: "'how many requests per second can we handle given this hardware', 'how much memory do we really need- if we quadrupled it, what would that get us', etc," ?

In addition- do you feel it's reasonable for a "Sr or higher" candidate to lock up (ie- stammer, not be able to come to any sensible conclusion)if one was to be asked a question where they have to use the same tools to answer those questions above when asked a question not in their domain- for example, 'how many pianos tuners are likely to be in this area'?

I'm not arguing in favor of non-domain experience questions like mt fuji or piano tuners- but I can't see hiring a Sr who can't tell give me some Fermi question approximations about how many servers we need.

Maybe I don't know what a Sr is supposed to be capable of doing?

</comment></comment></comment></comment><comment><USER14> What does this even prove an employee is able to do? Read other people's work?

I'm 100% sure that the people who came up with these solutions in the first place didn't take only 20 minutes.

It's also stupid that you can't look up the answer. In the real world I'd rather have an employee who can use google then one that takes 30 hours to find a solution to something complicated.

<comment><USER2> _What does this even prove an employee is able to do? Read other people 's work?_

It would seem so. That, and a willingness to say and do whatever it takes to sit with the "big boys."

<comment><USER14> If that's what it takes to play with the "big boys" as you say then count me out.

I'm not interested in showing solutions for other people problems, I'm interested in finding solutions to problems I need to solve. Problems that might have never been solved before.

I want to think outside of the box and work on providing real world solutions, writing as clean code as I can, and being able to work with others through many revisions of our projects.

I don't want to work some place where I am meant to parrot back information I found from somewhere else.

</comment></comment></comment><comment><USER4> The programming problem was a red herring. The interviewer and the screenshare was testing to see if he was clever enough to use his _phone_ to cheat, to see if he had the mobile-first mentality needed in the modern industry.

<comment><USER15> Well, my feeling is that no programmer worth their salt has only one computer. I have 4 within easy reach at almost any time. :) I guess if you can't "cheat" on this test you don't deserve to get the job.

<comment><AUTHOR> That actively selects for dishonest employees. Then again, it does seem to work for the financial sector.

</comment></comment></comment><comment><USER16> Maybe it was a trick question. Maybe he was just supposed to respond that polynomial solution doesn't exist because this problem is np-complete.

That's what the page he linked says about this problem. Solution he linked doesn't cover case with negative numbers and is at best pseudo-polynomial.

Or is the whole post just satiric bit about the state of recruitment?

<comment><USER13> It's quite common at the major companies to ask a question where the true solution is NP-whatever, but for which a "trick approximation" can get you nlogn solution. If you know the trick, it's easy. If you don't know the trick and figure it out in 30 minutes, you're a genius. If you don't know the trick and don't figure it out in 30 minutes, the interviewer knows nothing at all abiout your ability to contribute to the company.

</comment></comment><comment><USER17> I created some real world interview coding questions based on the work we were doing at a former job. My questions were rejected because the other engineers couldn't answer them because they were too "front-end" in that it required asynchronous programming. But they still got to ask their obscure CS college homework questions despite we never needed those skills.

It confirmed my suspicions of ego is why these questions are asked so often.

</comment><comment><USER18> How do you solve the problem? I'm going to guess there is some ordering involved.</comment>


EFF Is Looking for Staff Technologists, Operations Engineer and a Web Developer - <AUTHOR> At EFF we are looking for amazing people that want to help us keep the Internet free, open and awesome.
https://www.eff.org/pages/working-at-eff
We are looking for: * Staff Technologists * Operations Engineer * Web Developer
These are onsite positions in San Francisco.
EFF has had many Staff Technologists who did not come from traditional academic backgrounds or computer science careers, yet were very successful in making pivotal contributions to EFF's work and the Internet in general. As a result, by far the most important skills we look for in a candidate are the desire to learn, the ability to quickly grasp new technology concepts, a passion for diving into new technical issues and writing awesome code, and of course a dedication to EFF's mission. <comment><USER2> In case this is flagged ...

Please see the FAQ regarding job posts: [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html)

For the latest post, see [https://news.ycombinator.com/submitted?id=whoishiring](https://news.ycombinator.com/submitted?id=whoishiring)</comment>


Derailing illusions that kill: misperceptions at railway crossings (2003) - <AUTHOR> https://www.latimes.com/local/california/la-me-derailing-illusions-that-kill-20150224-story.html <comment><USER2> >"The rat is always right." Green explained: "If you set up an experiment and the rat doesn't do what you want it to do, it's not because the rat is stupid, but because you set up the experiment wrong. It's the same with humans."

I think this is important to remember in our field too. Too often I hear about a user story breaking down because "the user wasn't doing it right".. blaming the user is the wrong way to go -- you just set it up wrong.

<comment><USER3> _blaming the user is the wrong way to go -- you just set it up wrong._

Sometimes the user is wrong. If a person drives their car into a lake and drowns, do we say that cars are broken because they allow this? Or do we point to the millions of other drivers out there and say that driving on roads (and not into lakes) is the expected user behaviour?

An extreme example, sure, but I think it also translates to software. Some people criticize vi/vim for being modal because it confuses beginners. They use this as the basis of an argument that vi is a bad way to edit text or that modal interfaces are bad in general. But tons of other people take the time to learn the vi system of modal editing and they love it so much that they write plugins for everything else in an attempt to replicate that experience. Who is wrong here?

<comment> vertex-four That vim dumps you into a screen with no guidance and where your keypresses appear to do nothing (or apparently random things!) would be the problem here. It would take very little to have it say "type :help to learn how to use this program" in the bottom of the screen when it starts up. It's also confusing because many Linux systems are set up by default to launch vim whenever another application requests an editor, even if the user uses something they are more comfortable with otherwise. This could be resolved by asking "which editor do you want to use?" instead of dumping the user into a randomly selected editor.

You can build powerful systems without confusing people who often never intended to wind up in your program in the first place. You can even build them to show people how to use them.

<comment><USER4> > It's also confusing because many Linux systems are set up by default to > launch vim whenever another application requests an editor, even if the user > uses something they are more comfortable with otherwise.

      export EDITOR=/my/fancy/editor

<comment><USER5> You usually don't figure this out until after you've already run into this issue.

In Windows if you open a new filetype for the first time, it asks you what application you'd like to set as the default type, and on top of that it tells you where to go to change that later. That's what beginner friendly UX looks like, not just throwing the newborn into the pool like Linux does with Vim editing.

<comment><USER4> It is not that I don't understand the "problem" \- after all, I ended my very first accidental vi session with a reboot as well. But that was 23 years ago, long before Linux/GNU distros would be installed with a GUI and then boot into a GUI.

If the "newborn" in 2020 insists on using the terminal instead of the much more beginner friendly options that are the default nowadays... granted, but why compare a terminal editor in unix to a GUI? That is like comparing apples and oranges and then complaining that the strawberries don't taste like bananas.

<comment><USER5> Throwing up a menu to provide context and ask you what you want to do, rather than assuming a default, is not some thing that only magical GUIs can do. CLIs with menus is not some crazy new thing.

As an example of how manually configuring the editor flag can be annoying, consider a job where you regularly ssh into many machines, each that just by default use vim. I know how to use vim, I just don't like it, but pretty much every single machine I have booted into always assumes I want to use vim, and even if you remember to change the flag doing it to many machines all the time is majorly annoying.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> > Even as the train moves toward you, and you move toward it, the train's > image maintains a relatively constant position on your retina[...]

That's funny. The very first thing you learn on a ship is to watch out for exactly this. Any ship that maintains it's position relative to yours is on a collision course!

<comment><USER7> This is how old air-to-air missiles worked. They would steer until the image of the target stopped moving. This was something simple enough that you could make it work electronically in the 1960s.

<comment><USER8> > This is how old air-to-air missiles worked. They would steer until the image > of the target stopped moving.

That seems to be a weird way of describing "steer so the target is always in center of the image".

<comment><USER9> Not necessarily on center. Constant bearing but decreasing range will result in a collision.

<comment><USER10> Exactly! If the target was in the center, that would mean the missile was pointed to the target's current location. The target would quickly drift out of view!

Instead you want to intercept the target. You want to reach the point where the target will be, and at the same time as you. So keep the target to the side, at a constant angle.

<comment> 1e-9 Imaging missiles typically have the sensor mounted on a gimbal so the target can be centered in the image even when the missile body is not pointed at the target. But yes, the line-of-sight to the target will generally be off of the missile boresight.

</comment></comment></comment></comment></comment></comment><comment><USER11> In the Netherlands there was a horrible accident a couple of years ago with children who'd been picked up by daycare staff in a small electric bicycle wagon where 4 of the children were killed. I still remember the feeling of reading the headline. Since then I've read that municipalities are accelerating the transition from railway crossings in urban centres to underpasses, despite the huge cost of this re-engineering. I think the problem with railway crossings is that they are just inherently dangerous, and the severity side of the risk equation if you get a crossing wrong is huge (potentially multiple people being killed).

I like the Dutch approach here: replace them entirely.

[https://www.bd.nl/oss/vier-kinderen-4-tot-11-jaar- omgekomen-...](https://www.bd.nl/oss/vier-kinderen-4-tot-11-jaar-omgekomen- bij-ongeval-op-spoor-in-oss-twee-zwaargewonden-nog-in- levensgevaar~a22f10de/?referrer=https://www.google.com/)

<comment><USER12> Yup. British policy is the same. No new at-grade crossings. Existing at-grade crossings to be closed where possible. Where a crossing cannot be closed, upgrade it to achieve acceptable safety margins, revisit annually.

There are three different examples near me of crossings they haven't closed with very different scenarios.

1\. A large industrial estate built on the tidal river is reached via a road only barely above sea level. The road is used by lots of heavy articulated vehicles (it is after all an industrial estate) yet it crosses a four track railway that serves both freight and passenger traffic to a major city. Result? A major at-grade crossing which is closed to road traffic for about 10-15 minutes at a time as much as three times in an hour. This crossing has full barriers, and a pedestrian bridge (so pedestrians needn't wait for the barriers). There's no way to dig down (it'd flood) and a road bridge would have to be very large to carry those articulated trucks but there's nowhere to put it. I expect this crossing will remain until forces of gentrification some day mean the industrial estate turns into housing and they just close the crossing altogether.

2\. Where that same railway once went through the city to deliver rich people to the ocean liner terminal itself the passenger trains these days are diverted through a tunnel under the city - however a few freight trains per month still make the journey to the docks. So a wide city road goes over an at-grade crossing that is rarely needed, most users probably have no idea it's a crossing. This is a full gated crossing, but it's manually operated. A crew will come out, switch on stop lights, block the road, move the gates, then one train drives in or out of the docks, then they unwind everything. Because it's so seldom used a bridge seems unacceptably costly, and because it's manual I'd guess the residual risk is low so I expect this to remain in use essentially forever.

3\. A rail branch towards another coastal city cuts across a residential street I used to live on. This one I can imagine closing. It's currently using full barriers but has no pedestrian route except to just walk to the nearest bridge. I think sooner or later somebody will get themselves killed, clambering over the barriers or whatever and they'll just close it because there's no way to make it any safer other than closing it.

<comment><USER5> Interestingly enough, Japan has a crazy amount of rail crossings, including smack in the middle of busy districts like Shibuya in Tokyo where the gates are down for the majority of the hour; yet they seem to have less fatal accidents than peers. I wonder what's driving the difference there?

</comment></comment></comment><comment><USER13> This article had lots of echos from The Design of Everyday Things. I highly recommend it if you haven't read it. Before I did "design" was a word meant mostly aesthetics with a little UX sprinkled on to me. This is 100% a design problem, and we have to design systems for people that are stressed, in a hurry, confused, think they are smarter than they are, you name it. The part about differentiating markings for active and passive crossings is especially poignant for me. I ride bikes a lot and cross numerous passive crossings on smaller country roads. It's not that I don't understand how those crossing works, but I'll admit that I often subconsciously think to myself, "they designed this not to kill me if I don't disobey the bells and gates" as I tear past it after a quick glance.

<comment><USER14> One thing I remember from that book that drives me crazy is the bit about push vs. pull door handles. You see handles that you intuitively pull on both the push and pull sides of doors all the time. (Our HQ building is one of them. I'm usually only there once or twice a year and I can never remember to pull or push the handles on both sides of the elevator core.

<comment><USER15> In a sane (or well-regulated) world, all doors would always open outwards, in the direction of the nearest exit. In case of fire, you don't want a horde of people pressing an inwards opening door shut

<comment><USER16> I seem to remember the classroom doors of my elementary school (I'm in my sixties) opening in to the classroom, so that during an emergency they wouldn't be pressed closed by the panicking hords rushing by in the hallway, and so that opening them wouldn't injure those panicking hords.

<comment><USER14> You also often see bathroom doors that open in; I had this random conversation with someone at a conference last year. I assume the theory is (assuming there is one) that there would rarely be so many people crammed in a bathroom that there'd be such a crush to get out that it would be hazardous. On the other hand, even day-to-day bathrooms are sometimes located such that someone quickly walking down the hall looking at their phone could fairly easily be slammed into by a door being swung out into the hallway.

</comment></comment></comment></comment></comment><comment><USER9> I do notice some improvements in a few places over the last 17 years. Many busy highways now have overpasses. Many grade crossings have traffic lights as well. That's good design in my opinion, like putting a stop sign bar on the school bus.

I don't know why grade crossings without gates do not also have stop signs. We have to assume that many drivers are unaware of the rules of the road, either through lack of training, forgetfulness, local culture, or inconsistencies with other countries.

</comment><comment><USER17> "One peculiarity of human perception is that large objects in motion appear to be moving more slowly than they really are" \- Folks, never cross the roads/tracks when you see a vehicle approaching. Wait for it to pass and then cross.

<comment><USER18> Crossing roads is different - and it would be often impossible if you had to wait until no vehicle was approaching.

But as this article points out, you can't use your experience judging car distance/speed to judge train distance/speed.

</comment></comment><comment><USER19> The hell? Just put big automatic gates everywhere. Seems like a simple life/cost estimation exercise.

<comment><USER20> Think about the thing you know best. Imagine an article about a challenging problem related to that thing. A person with almost no knowledge of that thing reads it and says, "Seems simple enough" and presents a solution. Are they likely to have overlooked something? Misunderstood the problem? Be unaware of the challenges in solving it?

<comment><USER21> By my interpretation of the article, it seems to agree that this is the solution. The caveats seem to come mostly from paying for it.

</comment></comment></comment><comment><USER10> For millions of years, the largest moving object humans had to deal was the size of an elephant. You can look at the time the object travels its length in and get some rough estimate of speed from there. You won't be mistaken that much.

Now, take a 50 meter long airplane or 100 meter long train. Or a 300 m long ship. It's not going to work - fatal accidents ensue.

</comment><comment><USER22> TIL: "The rat is always right."

//edit: okay, the above is a bit minialistic, so, in full: The article is a good point on how systems have to adapt to actual human (mis-)behaviour, instead of relying on wishful thinking on how humans should behave.

<comment><USER10> A hundred years ago, tradespeople were often missing fingers. For some reason, it was really hard to sell the idea of safer equipment.

I bet it has something in common about hand washing in hospitals taking some hundred years to become mandatory - or how it was done much earlier in Hungary, yet nobody outside believed in it.

</comment></comment><comment><USER23> Railway crossing design has parallels in software design. Rare events, expensive safety/security mechanisms, expensive redesign, and safety/security mechanisms that are perceived as repetitive irritants rather than timely helpers.

</comment><comment><USER24> This same set of perceptual illusion is the cause of one of the more common motorcycle crashes, colloquially known as the SMIDSY (Sorry Mate I Didn't See You) accidents:

[https://motorbikewriter.com/smidsy-biggest-cause- crashes/](https://motorbikewriter.com/smidsy-biggest-cause-crashes/)

[https://motorbikewriter.com/scientific-studies-explain- smids...](https://motorbikewriter.com/scientific-studies-explain-smidsy/)

Most drivers find it very hard to estimate the closing speed of a 2 wheeled vehicle approaching an intersection.

</comment><comment><USER25> > "Railroad crossing deaths in the U.S. have come down from 786 in 1975 to 315 > in 2001. ... I think this was largely due to the U.S. government's rail- > highway crossings program which since 1978 has injected $4 billion into > crossings improvements"

Cars have become a lot safer in that time. And the number of crossings changed by a factor of 0.68. Both of these could account for the reduction in railroad crossing deaths.

</comment><comment><USER26> > the traditional American crossbuck, the simple X-shaped railroad sign that > warns drivers to yield to an oncoming train.

I would guess that roadway signage in the US runs about 80:20 textual:symbolic, but that the EU runs about 20:80, with much heavier use of symbols, and use of text only to modify or explain something not covered by the available symbolic palette. Could any EU->US or US->EU migratory drivers make their own estimates?

<comment><USER27> "How did you not realize that the empty circle means no parking from the hours of 1000-1600??"

<comment><USER28> Is signage not in the driving exam in your locale?

<comment><USER27> For someone coming to a European country and driving by virtue of reciprocal driving license permission (not having to take an exam), those signs are not at all intuitive.

<comment><USER28> They're not meant to be intuitive, you're meant to learn them.

</comment></comment></comment></comment></comment><comment><USER29> In our country we have unprotected (sign-only) crossings, red light crossings without barriers, red light and barriers crossings and red-white light crossing (with out without barriers). The blinking white light informs the safety system is working and it is safe to cross. Unfortunately, they are actually removing the white lights to match the rest of the EU.

<comment><USER30> Red light crossings seem especially disadvantagous for red colorblind individuals with the addition of white light signals.

</comment></comment><comment><USER31> One could say that these railway crossings are _adversarial examples_ that trigger visual misperceptions in the organic neural networks inside our heads.

</comment><comment><USER32> [https://archive.is/Rynhm](https://archive.is/Rynhm)

</comment><comment><USER33> >The tendency to blame the victim

They're only victims of their own stupidity. The real victims are the train drivers who are often traumatized, injured, or even killed in these collisions through no fault of their own.

The same goes for other occupants of the car. Pretty much everyone but the driver.

</comment><comment><USER34> > _One peculiarity of human perception is that large objects in motion appear > to be moving more slowly than they really are_

Rule #1: if you are at a _railway crossing_ and you see a large object in motion coming down the track, then _stop_ and let that large object pass before you try to cross the tracks!

<comment><USER35> I love how this article tries to make this sound like a complex affair. Only the most ridiculously stupid person would be in a situation where they are continuously trying to judge the position of the train relative to their own position as they attempt to beat a crossing. The only situation where you should ever be remotely in danger is if all of your braking and steering catastrophically fail at that exact moment and there is nothing to stop you from rolling directly into the train.

I also find it amusing that all of the stories regarding train-car interactions seem to occur at crossings with modern signaling devices, rather than "at your own discretion" crossings in the middle of nowhere. This leads me to suspect that the typical human has been conditioned to treat any signalized intersection transition as a "beat the yellow" event, but in the case of a rail crossing the brutal physics equations seem to be conveniently ignored.

Perhaps there needs to be a day in driver's education courses where everyone has to review just how heavy a freight train is and how much kinetic energy must be dissipated in order for it to come to a complete stop. Maybe make them ride at the front of a train to experience how painfully long an emergency braking maneuver takes to complete.

<comment><USER36> In German written driving license test, there is a section literally dedicated for railway crossings.

Edit: Clarified that it is written test.

<comment><USER13> In my state of Georgia it was the only thing I failed on my driving test (we didn't have driver's ed when I a kid, you just practiced with your parents and then took one test). I yielded and looked but didn't come to a full stop. I remember it took 15 or 25 points off of my score, but since it was the only thing I failed, I still passed the exam.

The things is, I don't remember the written test I took having any content at all about railroad crossings.

<comment><USER37> > I yielded and looked but didn't come to a full stop.

Physics tells us that we should accelerate to spend the least amount of time in the danger zone (rail bed). Since the velocities are orthogonal, it doesn't matter if you are hit by a train when your car is going 55 or 5 MPH (probably, unless trees in the resulting vector of your now pulped car).

It never made any sense to me to see school busses stopping at a grade crossing, then taking an extraordinarily long time to cross those tracks. What happens if the engine fails while on those tracks and a high speed train appears.

No, my vote is to make sure you have a clear view of the tracks in both directions and punch it. Less probability of interacting with a train.

<comment><USER13> Thanks, 17-year-old me feels validated.

</comment></comment></comment></comment></comment></comment><comment><USER38> > The tendency to blame the victim in grade-crossing accidents exasperates > cognitive psychologist Green: "That lets the authorities off the hook. Then > they don't have to redesign the system."

And why should they? Some people die, but how many times more people do cross successfully?

<comment><USER39> I mean, you could say that of practically any safety rule. "Sure, some people die of cholera, but most don't, so continue dumping the sewage into the drinking water".</comment></comment>