Could San Francisco Automate Strike-Threatening Train Drivers? - <AUTHOR> http://techcrunch.com/2013/10/17/could-bart-automate-train-drivers/ <comment><USER2> This is a rhetorical question. Of course it could. I've ridden driverless trains in at least three countries - the technology is unquestionably available, proven, and safe.

Is it possible politically? That is the real question. Perhaps not, but let's not pretend it has anything to do with technology.

<comment><USER3> I cannot speak for BART, but in NYC the MTA has been trying to automate its trains for many years (since the early 90s for the latest effort) and has only barely been able to keep everything working on the one line chosen for the pilot program -- and that is one of the simpler routes in the system. While I am sure that automation is _possible_ and that the technology is _available_ , the MTA seems to be making all the wrong choices, and I would prefer to have human operators until some minimum technical competency can be established (we can start with this: trains that can reliably announce their position on the line, without needing a human being to set things up -- one would think this is a bare minimum for automated service).

<comment><USER4> So ... lots of people have a financial stake in automated trains _not_ working, and for some reason MTA is moving in a direction that consistently doesn't work. Quite a coincidence there.

<comment><USER3> It is a coincidence only. The MTA has been engaged in various labor-reduction initiatives and has been steadily reducing the size of its workforce for years. Beyond automated trains, the MTA has been building "master towers" (with a long term goal of having a single control center for the whole system), repeatedly trying to remove the need for conductors (and then being told by the fire department that one man is not enough to evacuate a train quickly enough), removing token booths, etc. The real pattern with the MTA is _hiring incompetent engineers_ , particularly software engineers -- their payroll system is in a miserable state, they have yet to computerize their system for recording when trains arrive in stations, bus stops still lack information about when the next bus will arrive or even where that bus is, and the attempt to modernize their communications system went bust in just one day, leaving everyone running back to their older office (across the city) just to handle the radio traffic. You might say that there are financial interests in holding back _some_ of these projects, but for the most part the MTA's M.O. is to hire contractors who fail to deliver, then pay them more to continue to fail to deliver, and then abandon the project and hire the same contractors to fail elsewhere.

</comment></comment></comment></comment><comment><USER5> I wonder if TechCrunch articles could be automated. Have the TC editors ever bothered to ask, or are they too afraid of the interests of the contributors to explore the question?

<comment><USER6> If everyone could just email their PR pieces to a common techcrunch email address, someone could write a bit of code to check any links and then bung the text and pictures into an article template on the homepage.

<comment><USER7> Just to start (I call it BotoCrunch)

Mailgun In -> TextTeaser API [1] -> Mailgun Out to reader mailing list/Deploy to S3 site.

[https://www.mashape.com/mojojolo/textteaser](https://www.mashape.com/mojojolo/textteaser) [1]

</comment></comment></comment><comment><USER8> BART is already automated. The "drivers" just make announcements, check that the doors don't close on someone's leg, and press the emergency stop button if the computer goes badly awry.

<comment><USER9> This is the same kind of "automation" that is in place at most mass transit systems in the US (sans DC, which still uses human operators).

The requirement of having that human operator is typically born strictly of labor requirements first, and not necessarily the need of having someone's hand over the "Oh shit" button.

<comment><USER10> The 'Oh shit' button is not something we can reasonably expect the driver of a 'partially' automated train to be able to press: humans just aren't good at maintaining attention for these sorts of tasks with half-second reaction times once every fifty years of service. They can occasionally make useful decisions about edge-cases that represent small chances of failure (like wet-rail operation), that it is possibly for the automated operators to fail to account for.

The human driver instead serves as a sort of last-ditch assurance that the transit company values human life sufficient that a jury wouldn't destroy them in the event of an accident. He performs a sacrificial function by being the first one to die in the event of a crash, at which point it becomes a tragedy for the operator company, _milliseconds before_ the people behind him die, at which point it becomes a tragedy for the passengers. There is no point, therefore, at which a disaster can be seen as a tragedy for the passengers but not the operating company, a position which is fraught with political-legal consequences in the US corporate and municipal environment, ever obsessed with liability. The driver's failure to respond adequately is implied to be at least partially the fault of the late driver, sufficient to draw fire until the panic dies down.

Absent liability issues, we would all be riding perfectly safe labor-less cars and trains, which were perfectly safe because _we insisted on using them once they were mature enough to be safer than individual automobile drivers_ , and learned from each crash that happened afterwards, and improved our algorithms iteratively. Instead, every time we have a crash we blame the algorithm's existence rather than tweak it, switch to using a more human-intensive mode, let the automated infrastructure rot, add weight to our trains, and decry the tragic no-fault coincidence of driver inattention and algorithm failure that doomed the driver and the passengers.

The DC Metro was designed for full automation. Rather than implement the automation and improve on it over time, the predictable initial failures resulted in scaling back the automation partially and later fully and now it's not even a realistic capability, the infrastructure has degraded.

</comment></comment></comment><comment><USER11> They should be. Artificially keeping jobs alive that are better, safer and cheaper performed by machines is bad for everyone in the long run, even the train drivers.

<comment><USER12> So let's train the train drivers to be train automation experts.

<comment><USER13> BART is already almost automated: the train drives itself. The "drivers" only close the door, and stop the train if something unexpected happens. Some other light rail systems around the world run with no drivers on board at all.

The progress of automation will certainly result in complex social issues, and the entire concept of employment may have to be rethought.

But keeping _a small number_ of people pointlessly in their old jobs is not the right solution. Why should a few people receive $66-92k per year in welfare just because they used to drive a train, while other unemployed people and the homeless do not? It would be more fair to share the tax funds between all unemployed, regardless of whether it was due to a new automated train system or not.

</comment></comment></comment><comment><USER14> This could be answered as yes and also no.

Since 1985, Vancouver has had a 100% automated metro system ("SkyTrain") which has expanded to three lines (soon 4) and about 65 KM in track (soon to be closer to 80).

Almost any metro system could be converted to be automated but SkyTrain was built to be 100% computer-controlled from the get go. To switch from manual to electronic control would likely lead to enormous interruptions and it is unlikely that the unions in charge would accept it. It also isn't a matter of just updating the trains but it also means building sensors at all stations to detect intrusions and it also means changing signal controls. Needless to say it would be a bad idea and likely would just cost money.

In 2001, we suffered a prolonged transit strike that stopped all local bus and ferry service. However, the SkyTrain system continued to operate as normal albeit without any staff at any of the stations.

</comment><comment><USER15> I would like to see all forms of transportation automated as long as it is proven safe. Trains have to be one of the easiest to automate since it runs on a track. If Google can automate a car which needs to avoid potholes, idiot drivers, construction, snow, rain, etc, I think we should be able to automate trains.

<comment><USER16> _If Google can automate a car which needs to avoid potholes, idiot drivers, construction, snow, rain, etc_

Google hasn't done that (yet). [http://googleblog.blogspot.hu/2012/08/the- self-driving-car-l...](http://googleblog.blogspot.hu/2012/08/the-self-driving- car-logs-more-miles-on.html)

<comment><USER15> Thanks for the link. I stand corrected.

</comment></comment></comment><comment><USER17> The technology already exists. Take the money that's saved and invest it back into the system. Run trains more frequently and have them run 24 hours.

[http://www.bart.gov/guide/latenight.aspx](http://www.bart.gov/guide/latenight.aspx)

</comment><comment><USER18> I'm not from the bay area-- do the train operators seem to have any public support? I feel like it's hard to sympathize with striking workers who are already among the highest paid in the country for this line of work.

<comment><USER19> I'm not from the bay area either, but have you see the rent prices out there? Just seeing how much rent prices over the last 20 or so years have increased, mostly because of the tech industry, it's easier for me to sympathize with them.

<comment><USER20> Speaking as someone who tried to use the godawful abomination that is Caltrain, I have no sympathy for any Caltrain employees, and never will.

You could replace the entire staff with San Francisco homeless and it couldn't get any worse.

<comment><USER8> What's the problem with Caltrain, exactly?

<comment><USER20> Caltrain seems to operate on the principle "users are the enemy".

I wanted to travel between San Francisco and Santa Cruz, where my family is. Driving, that takes about 2.5 hours depending on traffic. In theory, the mass transit way of doing things is to take Caltrain from SF to San Jose and then a bus over highway 17.

Here are some of the problems I encountered.

\- Caltrain leaves once an hour. This is forgivable, but incredibly inconvenient, and the express train (same distance, half the time) leaves much less often. It would matter less than it does, except...

\- I once arrived at the station on time, saw people being let through the gate, bought a ticket, and was turned away from the gate by the guard. The people I had just seen were clearly visible on the platform, walking to the train. But hey, why not make me sit in the station for another hour.

\- Multiple times I experienced indefinite delays as the train just sat on the track in the middle of nowhere, unmoving. No explanation was given.

\- Caltrain arrives at (and leaves from) Diridon roughly once per hour. The highway 17 bus leaves from (and arrives at) Diridon roughly once per hour. They've been anti-synced: the bus leaves about ten minutes before the train arrives, and the train leaves about ten minutes before the bus arrives. The only explanation I can even imagine for this is that whoever set the schedule specifically hated the passengers.

The upshot is that you spend the better part of your day on what would have been a 2-2.5 hour drive. It's not even feasible to make the trip both ways in a single day.

<comment><USER21> The frequency of the trains will be increased once the trains are moved from diesel to electricity (will take 2 more yrs?), since the operating costs will decrease.

Whether the Caltrain schedule matches the highway 17 bus's schedule is not solely the fault of Caltrain -- it's either a 2 way street, or else they're both neglecting it, unless you have proof otherwise.

I have ridden MTA (NYC) and BART when they have stopped the trains in unpredictable locations for various reasons. For short stoppages, they don't say anything, but for stoppages more than 30 secs, they typically say something.

<comment><USER20> > Whether the Caltrain schedule matches the highway 17 bus's schedule is not > solely the fault of Caltrain -- it's either a 2 way street, or else they're > both neglecting it, unless you have proof otherwise.

You're talking about a bus route with two stops. The only thing it does is travel between Diridon station and downtown Santa Cruz. I'm assigning responsibility for the station's scheduling to the station, which is Caltrain.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Tangential point: I once got speaking to a taxi driver who used to be a tube driver. He said if you ever want to commit suicide, do it on the Victoria line. Although the traines have a driver in the cab, they are automated so the driver will be paying less attention and less likely to stop in time.

I'm not sure how this came up in conversation.

</comment><comment><AUTHOR> If BART became automated they could afford to run more trains, especially later at night, as they do in Vancouver: [http://www.humantransit.org/2010/02/driverless-rapid- transit...](http://www.humantransit.org/2010/02/driverless-rapid-transit-why- it-matters.html)

</comment><comment><USER23> My understanding has been that the a significant role of a BART driver is crowd control as people get on and off. Some of that seems less automatable than the travel itself. I could easily be wrong about that, though, or automating the rest might be worth doing anyway.

</comment><comment><AUTHOR> Plus there is the zoom and whoosh factor, which BART already has: [http://www.humantransit.org/2010/01/transits-zoomwhoosh- prob...](http://www.humantransit.org/2010/01/transits-zoomwhoosh-problem.html)

</comment><comment><USER24> Shorter TC: "Hey, that crab is near the top of the bucket! PULL HIM DOWN!"</comment>


Institutional memory and reverse smuggling - <AUTHOR> http://wrttn.in/04af1a <comment><USER2> I've seen memory drains during down-turns in the economy. The company will offer the oldest, most-experienced, highest paid employees a buy-out or they'll offer them five years extra pension/retirement if they leave now. Mgt figures that consultants can be hired if they ever need X, Y or Z done again at a fraction of the cost of the employees.

Many senior employees accept the offers, and then later mgt realizes that 95% of their Fortran or Cobol (or name your old programming language/product) experience has vanished. Thank god the software is mostly in maintenance mode, but client problems do still arise and what once took 15 mins to fix, now requires a week and phone calls to retirees begging them to help fix a client problem. They'll pay them loads of money too just for a few minutes of work.

Consultants turn out to lack the domain specific knowledge required to fix the problem.

Bottom line is that sometimes, mgt is so focused on hitting short-term financial goals, that they lose site of the big, long-term picture. Business needs less 20 something MBAs who only see this quarterly report and more managers who understand that business is a decades long proposition and that senior employees are key to maintaining an edge and passing along knowledge.

<comment><USER3> It's easy to blame the popular meme of "short sighted management", but they aren't necessarily as short sighted as you think.

Often management gets rid of the old guard because the old guard actively prevents the business from improving it's processes. I know someone (maybe multiple people) who works at a large financial institution. A particular department there is running on ancient systems using ancient processes, most of which can and should be properly outsourced to $BIGVENDOR. The fed agrees, and is constantly hitting them with MRIA's (Matters Requiring Immediate Attention).

But right now there are many managers of 50-100 employees who will become redundant when 49 of their employees are replaced by a few servers in NJ. These people tend to passive aggressively slow down the replacement, hoping to delay it until they retire. There are other people who have stable jobs, based not so much on competence as the fact that they hold lots of institutional memory. They don't want to help build a system that will make their knowledge obsolete.

When management fires these people, it doesn't do so because it doesn't understand their value. It does so because they are actively hindering the company from moving forward.

Sometimes this process fails as you describe. But when properly managed, this process results in a streamlined department half the size it was before, processes properly documented, everything automated, where people are fighting to improve efficiency from 99.7% to 99.9%.

<comment><USER4> I downvoted you for framing someone's observation as a generalization, and then trying to argue about it.

<comment><USER5> I upvoted you because you explained your downvote. Anonymous voting is what I like least about Hacker News. I prefer that people vote publicly. On my own site, I'm about to start offering actual cash (very small amounts, mere pennies) to people who explain their votes.

<comment><USER6> I would be interested in learning how that experiment goes. Social hacking fascinates me and at one time I spent quite a lot of time performing "private" experiments/tests with regards to influencing forums/email lists. I would be especially interested in seeing a write up done _beforehand_ as to your logic/reasons for doing it and what you hope to achieve and then a write up _afterwards_ to see what the actual results were. The information is a lot less valuable/interesting to me if there is no _beforehand_ piece of it, put in writing before actual implementation. However, it probably should not be published until you get results, just written down. Publishing it could contaminate the data as it could influence the outcome and make it impossible to tell if the money or the article was driving change.

Best of luck.

<comment><USER5> That is a great idea. And I understand the need to keep the prediction secret till later. I just wrote this up and sent it to you as an email. We will see how things work out over the long term.

</comment></comment></comment></comment></comment></comment><comment><USER7> This is sad, scary, and as far as I've seen an inherent part of any long running engineering project. As software developers, we have a hard time understanding the rationale of some of the code we wrote last week, let alone someone else's code from a year ago (I don't want to imagine any of my company's code running 30 years from now!).

In a recent series of design meetings I was running for a large project, I started to tackle some of these problems by emailing out the final decisions we had made at the end of each meeting. The following week we'd still have problems in understanding/remembering the chain of arguments that led to the final decisions, and we'd lose some time re-tracing our steps. So I then adjusted to not only summarizing the decisions at the end of each meeting, but noting step by step the arguments/debates that led to it. Then at the beginning of each meeting I'd review them to the group. This worked, but it was an awful lot of note taking.

I almost wonder that now that more and more of these discussions are done through work email, IM, version controlled documentation (and code), the job of future archaeologists will be much more manageable (though still hard and fraught with risk). Maybe more and more tools will develop to piece together a project's evolution, rationale, and implicit assumptions and decisions.

<comment><USER8> The problem with going through people's old email and such is the signal/noise is extremely low, and often of a timely nature, and may not represent the final outcome, especially if work has been done on a system after the fact.

What we need is _testable_ documentation. I do IT work most of the time, and document using a mashup of Markdown and text snippets in a specific format for network documentation, all kept in version control.

I then have a motley collection of scripts and tools that run against my text files and do simple testing like pinging all the hosts mentioned, checking DNS entries, etc. Frequently I'll write up docs before I start work, then by the end of work, all the tests will past. It's TDD applied to network design.

<comment><USER9> Right. Here's my script for this sort of thing: <https://github.com/darius/tush>

</comment></comment></comment><comment><USER10> In theory some quality systems (ISO 900x etc) should help with institutional memory.

Bob has a job; he performs a series of tasks to do that job; he writes down what he does for each task, including what information (also product) comes in (and who from) and what information (also product) goes out (and who to), also including all the documentation he needs to complete for each task.

Someone else edits that puts it in the company QA manual. In future new employees just read that documentation, and maybe do a bit of shadowing of existing employees.

Unfortunately, that's not what happens. What happens is that Bob has a job, but Charles (Bob's boss) writes a bunch of stuff that he thinks Bob should be doing. And he doesn't write sentences like "Set the machine for 190 degree Celsius. Place widgets in machine when it's at temperature. Leave widgets in machine for four hours." but he writes abstract ambiguous business speak that people can't use to actually do the job. Then Edwin (Charles's boss) adds another bunch of stuff. Then that gets edited into a god-awful mish-mash. The people who did the software (with the "help" of Edwin) add some stuff about information. Bob gets to work to an impenetrable document that bears little relation to his actual work flow.

<comment><USER4> My first job out of college was at an ISO9000 certified place. It was weird. If I wanted any documentation, I had to go to a specific desk and fill out a form, checking all the documents I wanted. She had to go make copies, mark me as having them "checked out", then, after a few days, I finally got the documents that I requested. Of course, often they turned out not to be the documents I actually needed, so the process started over again.

I'm sure ISO9000 is an improvement over the worst-case, but dang if it doesn't introduce an amazing amount of bureaucracy into just getting things done. Not to mention adding bureaucracy to documenting things once you've done them.

In my experience, the best thing for institutional memory and process documentation in general is an internal wiki. Syntax can me learned in minutes, the barrier to documenting is extremely low, reorganizations are easy, and old versions are archived.

<comment><USER11> ISO9000 doesn't require what you describe, though. It requires that you have documented processes for quality management of processes, for recording exceptions, and for communicating exceptions to involved parties (including customers).

The process you describes sounds to me like a measure put in place because there is a requirement that documentation be kept up to date. I did a contract once to streamline updates to the ISO 9001 quality handbook for a large company, and part of the hassle was that while they mostly relied on an electronic copy on their intranet, they also needed printed versions and they needed to be kept in sync.

They wanted to minimize the use of the printed version exactly because they had to keep track of the copies and ensure every one of them were updated (or destroyed) when there were changes, so that everyone were working from the current versions. When I was there, they had ca. 300 ring binders of printed versions, and every time a page was added, removed or changed, someone had to track down all of those 300 ring binders to update them...

All of this hassle was down to the paper versions - the intranet version was a simple set of documents with some basic hyperlinking, and the update criteria were satisfied by simply prohibiting making copies of it.

You could likely satisfy ISO 9001 documentation requirements with an internal wiki - none of the bureaucracy it introduces prevents it AFAIK. What it does prevent is taking a lax attitude to updating that wiki.

</comment></comment></comment><comment><USER6> I've been in the same job only five years and I have newer people coming to my desk asking "what do they mean by that?" because these emails get sent out with instructions that don't really make sense with current processes. I can infer what folks above me are trying to tell me to do, but the phrase used is a case of institutional memory and the process described/referenced is obsolete. No one has bothered to update the phrasing to fit the current situation and newer employees then don't get a detailed explanation of what it means (what the goal or purpose is) so it is slowly turning into gibberish. Over a longer scale, I can well imagine this can get much uglier. And I have an entry level job, not some high paid job with super specialized training and all that.

<comment><USER12> This is like a family of 1st, 2nd and 3rd generation immigrants. The 1st generation (the managers sending down gibberish instructions) use language that most people don't understand and refer to people, places and customs from the old country that have no meaning to anyone here.

The 2nd generation (you) are responsible for keeping communication going in both directions, and making substitutions and translations in both directions, sometimes changing words and orders into something that makes sense even though it wasn't at all what was asked for.

<comment><USER6> That's an excellent analogy but I don't agree that it _should_ be on me to clarify instead of on the better paid, more powerful "first generation" folks to stay current and make their instructions legible and coherent and stay in touch with the processes of their people, especially since those new processes get handed down from on high. I assure you, we folks at the bottom aren't making them up for shits and giggles.

Suffice it to say that if I could find a means to monetize my websites, I would be gone. And it's a good company to work for. It really is. I occasionally note that if this is an excellent workplace environment, god help the world if you put me in a bad one cuz I will go postal and show up with a machine gun one day. I have little patience for such things. I was a homemaker, full-time parent and homeschooling mom for years. I am used to an environment where I am in charge and I have the power to effectively implement my "unreasonable" (high) standards and expectations. "A reasonable man conforms to his environment. An unreasonable man expects his environment to conform to him. Therefore all hope lies with the unreasonable man." The Fortune 500 company I work for seems disinclined to bend to my will (what with me having an entry level job and zero authority). If I can cross the chasm between here and monetization, I will be happily on my own at some point.

Take care and happy holidays.

<comment><USER12> "I don't agree that it should be on me ..."

Oh, not at all. It just reminded me of the many immigrant families I've known, especially how the middle generation acts as a bridge between old and new.

"Take care and happy holidays."

The same.

<comment><USER6> My mom is a first generation immigrant. I often let her assumptions and misunderstandings of my sons simply stand. My sons tend to get a lot more of those explanations out of me, though sometimes only months after the fact (long, machiavellian story there). A similar pattern is emerging at work. I do explain stuff at work when asked. But I guess my policy at work mirrors my policy at home: I explain it to people I trust and who ask nicely.

</comment></comment></comment></comment></comment><comment><USER13> Side note: The scrolling on this page is horribly broken on Android. I can't even read the whole article because I can't scroll down.

After loading the article on m laptop I must say that it is a fascinating article and will change how I think of documentation. For example, soon my company will be making a change that will render the old wiki url's incorrect, the problem is that many older documents will still refer to the old url's. I think we should have some sort of list of the old wiki url's (there is an even older set of url's as well) to help future archeologists in piecing together the information.

<comment><USER14> hi - any ideas how to fix it? wrttn.in is my site and i can make a change to the css or rendering if necessary...

<comment><USER15> (I am a Chrome developer.)

I glanced at your scroll.css and saw a bunch of rules that attempt to fiddle with the overflow/position attributes. This sort of thing confuses all browsers. Why not just use a normal scrollbar? It's fine to change the way it looks it if you want using the -webkit-scrollbar stuff you've done, but hacking out the normal web page scroll bar confuses everything. There are, for example, optimization opportunities in web rendering engines that only hit when the page is "normal" (which probably explains the poor performance other people are encountering).

(I noticed even on desktop Chrome the scrolling isn't smooth, unlike other pages. Probably for the same reason.)

<comment><USER14> thanks, this is incredibly helpful, and one of the reasons i hang out here. i'll remove some of that and post up a version later today...

</comment></comment></comment></comment><comment><USER16> I'm sure they saved money in the short run by going with the cheapest option each time they tried to manage their documentation the last time around. On the other hand -- at the time, they didn't know which parts would be valuable, and which parts would be wasted effort, so it probably was the right choice. However, if a major incident were to happen around that plant, could the company tell the emergency responders what they would need to know?

</comment><comment><USER17> Original link and discussion here: <http://news.ycombinator.com/item?id=3311015>

</comment><comment><USER18> Lack of a succession plan is plaguing many industries. I am in the category of grey hair, no hair, written a book. When I die, the code dies with me

</comment><comment><USER19> Can we learn anything from legal discovery processes?</comment>


Show HN: Initiator Creator – Curated links for side hustlers - <AUTHOR> https://initiatorcreator.com/ <comment><AUTHOR> Hi, I'm Saurabh Y (@savydv), co-creator of PeachBlack.co, Themesfor.app, Engigogo.

I'm a serial entrepreneur who makes small startups and micro-projects. And work as a full-time developer, designer, marketer, content writer for all my endeavours. This newsletter is for the people of the same breed who handles all things as indie makers, member of a small team or early-stage startup.

Initiator creator is a weekly hand-curated newsletter full of interesting articles, links and resources divided into developer, designer, marketer, entrepreneur and must-read categories for easy digest.

You can read the Sample Issue here: [https://ckarchive.com/b/n4uohvhv430n](https://ckarchive.com/b/n4uohvhv430n)</comment>


Google News adds Achievement Badges - <AUTHOR> http://latimesblogs.latimes.com/technology/2011/07/google-launches-sharable-news-badges-for-google-news-readers.html

<comment><USER2> Achievement Badge: Add achievement badges to everything.

That was my second reaction. My first reaction was "Die in a fire."

</comment><comment><USER3> Soon everything will have a badge! I'll get a badge for emptying the trash. A badge for adding a bookmark. A badge for gaining a badge. It'll be like the boy scouts, except completely devoid of value.

Seriously though, a badge for reading news? That I can share with people? And why would anyone care? Giving someone a badge for something that requires little to no skill to achieve isn't rewarding. Especially if everyone has them! It isn't something to flaunt. It doesn't even boost my ego.

Not that it won't work if done in a way that causes neurosis in users. Effectively that's how modern "social" games work.

</comment><comment><USER4> The Problem with badges, Farmville-dollars (or whatever they are called) and similar things is that they are unreal things in an unreal world. Unless there's anything useful that can be done with it (say, like with StackOverflow-Karma that may help to connect people to open source projects or get a new job), I wouldn't bother.

</comment><comment><USER5> There was some discussion on this a few days ago: <http://news.ycombinator.com/item?id=2765834>

</comment><comment><USER6> I could see it being interesting if you got achievements for scoring highly on comprehension tests on the news stories you read. But not if they're just awarding the badges for generating page hits.

<comment><USER7> Yup, at first I was excited. They're gamifying and rewarding people for being aware of the world around them, and getting involved in the world! And then I realized that you could probably write a greasemonkey script to grab every badge in a single afternoon.

I wonder if there's a badge for that.</comment></comment>