What should be considered off-topic? - <AUTHOR>

Many have said that we need more explicit guidelines about what is off-topic. What do you think should be off-topic on news.ycombinator.com? <comment><AUTHOR> <http://news.ycombinator.com/item?id=44000>

My thread about optimal governance had a lot of complaints. Many people think that such discussions shouldn't be allowed and I disagree. The thread was more about economics than politics. It wasn't anywhere close to the day to day politics covered on the tv news. There is no evidence of this site turning into reddit, except for the people claiming it has. Why disallow this discussion?

<comment><USER2> Maybe this is just me, but I come to this site to see new stuff and then read discussions about the current and eventual implications of that new stuff. In ask news.yc threads, I am looking for either new ideas posed as questions or people that really need advice.

What I don't want to see is the rehashing of age-old discussions or endless arguments where no one is going to change their minds. I think your post was an example of both. "What services would the perfect government provide?" I mean seriously, where is that going to go besides get people to write out their entrenched positions and defend them ad infinitum? If people want to read the arguments about different types of government they can go to wikipedia.

I take your point in that it hasn't changed that much yet here. However, if you can nip it in the bud initially you might prevent a slow eventual migration to something you don't want. Hence the suggestion of guidelines displayed on the submit page.

<comment><USER3> There often turn out to be new things you can say about age-old topics. And the smartest people are willing to change their minds about anything. So I don't think we should avoid topics simply because people have said a lot of stupid things about them in the past.

<comment><USER4> The key to getting positive insights out of controversial topics is to raise quality of the discussions rather than to censor them. My instinct was to agree with epi0Bauqu but one of the few stories I've upvoted after reading in the past day concerned both religion and politics [1]. This contradiction had been bothering me. But the situation is much more clear to me now.

An important goal for a community like this is to minimize or eliminate low quality, frustrating patterns of discussion. One can eliminate such patterns by censoring the topics that often lead to the discussions or by changing the culture of the group so that the problematic discussions are minimized.

The posting of libertarian/socialist/etc. aphorisms under the guise of an economic discussion should be discouraged. A relevant aspect of economics is that most interesting economic discussions rely on mathematics or at least a qualitative reference to a mathematical argument. If an intense economic discussion lacks such references it is almost certainly a low quality discussion.

[1] <http://news.ycombinator.com/item?id=44184>

<comment><USER2> Heh, I actually agree with your basic premise that it is better to make detailed and incremental tweaks than use the blunt instrument of wholesale censorship. This whole argument is somewhat ironic too because I like policy discussions and at least once enjoyed religious ones. (After all, I went out and earned a masters degree in Technology & Policy on my own volition and have written religious articles.)

What it comes down to for me, is that I am just heavily skeptical that raising the quality of these discussions to an acceptably interesting level in a relatively open online forum can be done, and so I have been advocating censorship instead. I hope I am wrong.

<comment><USER4> I think the key to making this work without censorship is ruthless downmoderation of low quality, uninterrsting, and annoying discussions. I am often hesitant to downmod but this is the tool that we have to shape the culture. If enough of us who care about having nondogmatic discussions start downmodding the situation might take care of itself.

</comment></comment></comment></comment></comment></comment><comment><USER2> Off topic (imo): old stuff, politics, religion.

<comment><USER5> I'm not sure about old stuff. I think rehashing old topics can be very interesting. You often learn something new about them. Reddit has never been strictly "news", even in its heyday.

Politics and religion are special, they're just such huge topics and they're so personal to people. There's a reason people don't discuss these topics in business much. They're big distractions from the many things we _all_ have in common.

I hope there's a ban on purely political and/or religious topics. This isn't censorship: 1) It's not done by the government. 2) The purpose is maintain focus, not suppress ideas.

</comment></comment><comment><USER6> Anything gaming related (Playstation, Xbox etc.). Doing a gaming startup? Fine, post. Found some crack codes or new screen shots, karma should be put under assault by everyone.</comment>


Health Care's Wireless Future: Vital Signs in Remote Real-time - <AUTHOR> http://singularityhub.com/2009/05/11/health-cares-wireless-future-vital-signs-in-remote-real-time/

<comment><USER2> I love these kind of ideas and would absolutely be in the market for a suite of applications and/or products that would allow me to track how my body is functioning.

I find it unfortunate that I can monitor and tune an enterprise database so closely, but cannot keep track of my heart or liver function.

</comment><comment><USER3> By far the worst consequence of Twitter's popularity is so many authors feeling the need to slip in lines like this: "Think of it like Twitter for your organs."</comment>


Ask HN: Is anyone using FastCGI? What's your experience? - vanilla-almond It seems everyone is using an application server of some sort sitting behind a proxy server nowadays.
But what about FastCGI? Let's say my web app is self-contained binary and I'd like to deploy it to a web server. I'd like to keep the binary running rather than use the start/stop approach of plain CGI. Is FastCGI a good alternative? Or it too complicated? The application server approach also feels like overkill. Or is it?
There seems to be surprisingly little info on FastCGI. The official website doesn't even exist any more, but you can find it via archive.org or via GitHub [1].
If you've used FastCGI using Apache, NGINX etc how did you find the experience? When would you recommend it?
[1] https://fastcgi-archives.github.io/ <comment><AUTHOR> Yes, I'm using it. It's still around, and is one of the most supported web technologies.

FastCGI is optional in my project, but it is one of the ways you can bolt it onto a web server.</comment>


Refactoring Back End Engineering Hiring at Slack - <AUTHOR> https://slack.engineering/refactoring-backend-engineering-hiring-at-slack-b53b1e0e7a3c <comment><USER2> There is one thing mentioned there that I've never considered for some reason (and it's quite obvious in retrospect): Giving a candidate a code review exercise instead of (or in addition to) a code writing one. A code review can reveal a lot of how a candidate pays attention to details, looks at (and deals with) other people's code, reads code etc.

<comment><USER3> Agreed, if hiring processes involved less questions about CS/algorithms, and more day-to-day skills like "use git to do <x>", "how would you unit test this?", or "given these use-cases, how would you design the API?", a lot of places would be hiring better engineers and building better products.

<comment><USER4> I don't think you build better products if you hire someone who knows how to use git. It doesn't fit in with the rest of the skills you're listing.

<comment><USER5> I agree that testing for knowledge of specific tools is probably not what you want, but I find that among people who do have significant experience with git, ability to use it effectively seems to correlate pretty strongly with overall programming ability and productivity.

I mainly have experience with git, but I assume this generalizes to other version control systems. I also think that version control is a pretty fundamental skill for software engineers (comparable to unit testing), so I think substituting that for "use a version control system to do x" would fit in with with other skills.

</comment></comment></comment></comment><comment><USER6> There's been a lot of threads like this recently that discuss changing the hiring process to more closely resemble day to day work and working with an actual codebase.

My question is how does this work for new grads and people that haven't worked in the industry before? Are they using these new techniques to hire recent graduates/people that haven't worked as a software dev before? Does this kind of process adversely effect those who haven't worked as a software dev before?

I'm not trying to say that algorithmic/leetcode type problems are a better solution, but rather questioning whether this form of interviewing has some kind of bias.

<comment><USER3> Currently, the existing form also has a bias - towards CS and top CS universities. Yet I keep working with great self-taught engineers from a variety of disciplines, some of whom don't even have degrees. Maybe a shift in hiring wouldn't be a bad thing.

As for how, you could focus more on logical thinking, user experience considerations, technical writing, or other, softer skills.

For a lot of grads, we already have to re-teach them the language, as universities don't seem to give marks for consistent style/using linters/unittesting/best practices/comments/writing documentation etc. In the time it takes to break these bad habits, you can definitely teach somebody who's technical and done a basic programming course a lot of things.

</comment></comment><comment><USER4> Code review assignments are so much better than coding assignments that for me it's a great sign that your hiring sucks if you haven't switched to them.

If you do a large coding assignment you have to leave the time frame rather open ended to assist candidates that have limited free time. Instead this forces every candidate to spend as much time as possible to get noticed, having an opposite effect. There is no obvious solution to that apart from doing short timed assignments.

But what is even more important, a code review can be tailored to provide the same information on technical expertise, has a more natural effort limit and more importantly, it actually tells you about how that person will act as a coworker.

Will they even explain their work? Will they provide reasonable feedback, and will their way of explaining their thoughts in written word be detailed enough to guide people through?

Not only are code reviews, for myself, essentially part of the documentation of the code base itself, but they are also a very important communication channel. And how one communicates with others through it is a great proxy about how they will handle the rest of their communication.

I've never worked with an engineer that was considerate, kind and detailed (with a focus on being understood) in their review comments or presentation, who turned out to be an asshole when interacting with through other channels.

</comment><comment><USER7> I thought this was a job offer for an engineer whose main job would be refactoring back-end code.

Turns out it's just another article about how to interview people.

<comment><USER8> That would be an interesting idea, having a dedicated refactoring person on a team. I wonder how well that would help with tech debt...

<comment><USER9> I'm working through reading the DevOps Handbook (the companion successor to The Phoenix Project), and in it is an entire chapter dedicated to the necessity of dedicating either the time (measured in 20%) or dedicating a small group of people who's express and specific charge is refactoring and paying down technical debt.

They pointed to Nordstrom as an example of an enterprise organization who did this as a part of their internal devops transformation, and it worked wonders at the time when it was needed.

This team didn't tackle new user stories for feature additions or enhancements, they didn't work on existing tickets. Their role was singularly focused on identifying and making payments on technical debt and operational enhancements.

Not every team can afford to focus an entire group of people to the task of paying down technical debt, but what I did take from it is that every team can't afford to _not_ dedicate _some_ time out of the week or month making critical fixes where necessary.

</comment></comment></comment><comment><USER10> _chief among them is the high cost of hiring the wrong person, or missing out on the right one._

As a hiring manager, I've never cargo culted this particular view. In fact I think it's completely misguided. I always work in at-will states, it's trivially easy to let someone go. I also personally have no problem doing it.

I generally will hire based on conversation alone ( _no_ coding tests). If you ask someone detailed questions about work a candidate has done you can get a really good idea if they know what they're talking about. I know people say that they've interviewed people that can talk a good game but can't code a for loop once in the door, but I've interviewed hundreds of people and I can't say this is often the case.

Easy in, easy out. You know what though? There's very rarely ever the out part. If I can look at your Github, like what I see and you can back that up in a conversation, you're hired. That has worked out really well for me and reduces _a lot_ of friction and wasted time (mine and other engineers') during the hiring process.

The moral of my story is that just because Google or some other tech giant espouses a theory like "false positives are way more costly than false negatives", it doesn't mean it works for all organizations or that it's even true at all.

<comment><USER11> I've worked at places where the managers hem and haw over firing someone even going so far as to use passive-aggression to make them leave on their own. In environments like that, the cost of hiring the wrong person is huge. It could take a couple of quarters to shake the dead weight and the entire team suffers.

I've also worked with managers who have no problem being the hatchet man and it's great. They sniff out the losers, put them on a plan, and they're either out the door soon after or stick around to get fired.

I would rather managers teach each other to wield the hatchet than try to get seven steps ahead of a dud hire during the interview process. "Release early, release often."

<comment><USER10> I totally agree. I think so much of the "it's really hard to get rid of bad people" story comes from weak management. Firing people is part of the job, you need to be comfortable doing it.

Interviewing people is _extremely_ disruptive to an engineer's time and in a large company it could potentially happen a lot. I think that is the metric that should be optimized for, not minimizing firing work for the hiring manager.

<comment><USER12> I wonder about this - am I doing a candidate a disservice by hiring them without knowing that there is a non-trivial chance that they'll be fired within 1-2 months? If someone doesn't already have a job, that's fine, but someone might quit a situation where they are suited for one in which they aren't. Or, if someone is a junior developer, they've just spent 2 months before being let go, and has to explain the situation to the next place.

I care about the people I hire as humans and don't want to put them in a bad situation.

<comment><USER10> I wouldn't say there's a non-trivial chance that they'll be fired in 1-2 months. Being able to effectively screen people is another technical managerial skill. There is a very, very small percentage of candidates that make it through the interview and later turn out to be duds.

I think there are two issues at play:

1\. Ineffective managers are terrified of firing people.

2\. Ineffective managers rightly or wrongly think they can't screen people without code tests, white boarding...

Like I said in my original comment I look at their Github or any other work portfolio they provide and have a deep discussion about it with them.

</comment></comment></comment></comment></comment><comment><USER13> It would be interesting to see a follow up a year or so from now about how candidates that went through this vs. the previous process are performing.

</comment><comment><USER14> > Our take-home exercise, while loved by many, was also time-consuming. Its > open-ended qualities meant that candidates, wanting to show off their best > work, could end up spending many more hours of their own time to complete it > _than we had expected_.

> This was often a barrier for candidates who couldn't afford to invest the > time needed to complete the exercise to _our desired level of quality_.

Isn't there a conflict here? Why are you setting the bar for your own desired level of quality so high that it isn't possible to meet it in the amount of time you expect people to take?

<comment><USER15> Isn't that their point? The article is acknowledging that they had set their expectations too high and so candidates were failing to meet one of the two goals, which is part of why they redesigned the process.

<comment><USER14> But that problem doesn't require a process redesign. You can just lower your expectations.

</comment></comment></comment><comment><USER16> that github api is really interesting. does github never run GC on repos or do they flag the commits you create from the API so they are never GC'd? I guess in a normal workflow and normal git gc options commits that are unrooted would not be deleted because git avoids deleting recent data during GC. however, there doesn't seem to be any warning in the API that your commits might disappear if you don't root them.

</comment><comment><USER17> It gratifys me in some weird way to know that companies stress out about the recruitment process at least as much as I do

</comment><comment><USER18> Would love to work at one of these magical companies that HN posters work for that have zero internal domain knowledge required, zero runway time to the engineers being maximally productive, and zero friction teams where adding or removing any given engineer has zero cost for anyone.

</comment><comment><USER19> The term "signal" is ill-defined in this piece. Are there other posts where they go into this in detail?

The decrease in the hard time-to-hire metric was great to see. This is a real problem with some top-tier shops.

</comment><comment><USER20> "a high degree of craftsmanship"? I know what this means but still, how exactly do you define that and not be biased by how the candidate presents him/herself.

</comment><comment><USER21> Anyone know what kind of review questions work well ? Any rule of thumbs, best practices to create these questions?

Why do they work better ?

</comment><comment><USER22> I was waiting for links to all the awesome [open source] code Slack talks about in this post. I was sad.

</comment><comment><USER23> > it would have taken a year to fill our existing open headcount

Maybe open an office in a different location or hire remote?</comment>


Why you should not worry about Facebook suing you for using React.js - <AUTHOR> Worst Situation <comment></comment><comment>===
If you use react.js code and FB's sues you for a patent and win's. You will still not loose your right to use react.js in your code.
BSD+ license is not to shoot startup's or intellects down. It's for FB to protect their IP. I do not know what IP FB is protecting with BSD+, can anyone list it down here so people don't become miserable thinking too much about things going south. </comment><comment><USER2> I'd be more worried about owning part of a product/company that patents something facebook decides to "compete" by stealing your patented invention then you can't sue because you used react. Especially if your in some kind of VR company.

<comment><AUTHOR> so let's say if it happens FB sues you, what will they sue you for.

1\. Holding a patent on your own IP.

In that case according to FB

3rd point here: [https://code.facebook.com/pages/850928938376556](https://code.facebook.com/pages/850928938376556) "unless your patent counterclaim is related to Facebook's software licensed under the Facebook BSD+Patents license."

How is this relation formed. Only if you have a product in the same vertical as FB and have a similar patent. In that case you should not have used React in the first place use vue.js</comment></comment>


How to Fight Corruption with Game Theory - jim-greer http://www.thedailybeast.com/articles/2014/11/29/how-to-fight-corruption-with-game-theory.html <comment> jim-greer I've posted on here about CounterPAC before. We didn't crush it but we learned a lot for just $500k and we took out one terrible incumbent.

<comment> jim-greer I'll hijack my own comment and post some more good stuff.

Zephyr Teachout wrote a great history of corruption, I'm still reading it now, but you can get a good taste from this NYT review:

[http://www.nytimes.com/2014/10/19/books/review/zephyr- teacho...](http://www.nytimes.com/2014/10/19/books/review/zephyr-teachouts- corruption-in-america.html)

I'll also mention that our biggest challenge to scaling this is money. If you know people who would be interested in donating, please hit me up at firstname.lastname@example.com. You can also send PayPal donations there if you're so inclined!

<comment> jim-greer My highlights of that review are here:

[https://www.highly.co/article/547af11a6c696c7d69220000/user/...](https://www.highly.co/article/547af11a6c696c7d69220000/user/545a6ed56c696c19a8030000/)

If you want you can sign up using code 'hellohighly'

</comment></comment></comment><comment><AUTHOR> Next time you make a donation that could be disclosed, are you prepared to lose your job over it?

Disclosing the sources of campaign funding is not all roses. There are several groups who use that information to intimidate doners. They go after their careers, their businesses, their families, their reputations. They create maps of where "the opposition" lives, and then let the lunatic fringe on their side do what comes naturally to them.

<comment> jim-greer Want to back that up with some evidence?

<comment><AUTHOR> The whole point about disclosure is to enable feedback. The intended feedback may be for people to be able to make informed decisions about who is funding a candidate, but disclosure also enables other kinds of feedback. It allows coercion to be applied to people (donors) once their identities are known. Brenden Eich is one example.

The ability to donate anonymously is an important firebreak. It protects those with minority opinions. It also protects people in general from those who think that coercion is an acceptable means to achieve an end.

I should not have to worry that my boss will see that I gave a donation to his pet political cause in order to keep my job. Likewise, I shouldn't have to worry that my boss disagrees with some cause that I have donated to and fires me.

I also shouldn't have to worry that one of these reprehensible groups who believe in bullying and coercion might decide to make an example out of me just because I supported the side of a cause they disagree with.

Shouldn't a political debate be more about ideas than the people who are involved?

Disclosure seems to enable a kind of intolerance, a kind of "guilty by association" kind of thinking that really has no place in civil society.

<comment> jim-greer > Shouldn't a political debate be more about ideas than the people who are > involved?

What if the idea is "I'd like a big contract for my construction company"

Or, "I'd like favorable regulation for my cable broadband provider".

This isn't just a debating society. It's a market with winners and losers. Donor harassment is a pretty abstract problem, with Brenden Eich as pretty much the only example. Corruption is routine, massive, and very concrete.

<comment><AUTHOR> Having my boss be able to tell how I contributed to a political campaign is not an abstract problem. It's been a big enough problem in the past that there were laws passed to try to prevent it (see for example, the Hatch act).

Mr Eich is the only example I mentioned. In just this one political cause (prop 8) he was one of many people who were bullied.

How about Scott Eckern? How about Jose Nunez?

And, for each example that has been made, how many people choose to remain silent? How does that get measured? Making high profile examples out of people is very cost effective and efficient. It demoralizes and defunds your opposition.

I find whole idea that it is somehow acceptable to enable the bullying of individuals by extremist groups to be deeply unsettling. Anonymous donations prevent this sort of abuse very simply and effectively.

If it's corruption you're after, then go after that. Either limit the power that the elected officials have (term limits, etc) or investigate them.

People with money and power will always find ways to buy certain politicians. If one way is blocked, another will open up. Just look at how many politicians have cushy K street jobs once they retire (provided they do their masters bidding while in office). No campaign donations to trace or disclose.

<comment><USER2> Am I the only one who's uncomfortable with the idea that political speech is kosher, but responding to political speech in a way which is "bullying" is not?

I feel like we should do more to separate the abusive harassment (which is clearly not okay) from other real-life consequences, maybe including losing friends or a job, that come with holding and furthering a political belief. The latter seems like it could plausibly be a feature of a well-functioning political discourse.

<comment><AUTHOR> Why would you think that firing an employee over a political contribution they made or did not make would be in any way acceptable?

Well functioning political discourse is, above all, tolerant. A hallmark of non-functioning politics is the use of coercion.

How would you feel if you worked for one company, and they required you to fund a certain cause. Then, you get fed up with that, but you're now on the officially reported doner list for that cause (which your employer used to ensure compliance), and another employer says they won't hire you based on a simple web search of causes you've "supported" in the past?

<comment><USER2> > Why would you think that firing an employee over a political contribution > they made or did not make would be in any way acceptable?

Why would you think making a political contribution is in any way acceptable? Because we live in a free society. You can't force someone to employ you. We've generally outlined narrow exceptions to that rule, and this generally isn't one.[0]

If you don't support a business's politics, if you don't think they'll use their money for good, you have the right not to give them yours. It doesn't seem at all intuitive to me that that right should disappear when the money's moving the other way.

(Of course that presumes a well-functioning market for labor... If (hah) that doesn't exist, we can only expect workers to be exploited in millions of different ways, large and small, and this is still not a good hill to die on.)

[0] I (and many HNers) happen to live in one of the few US states where political retaliation by employers is actually banned, and while I broadly appreciate the sentiment, I'm not at all sure it's morally superior in the way you're trying to claim. Look at what a huge problem liberal protection of political speech caused in _Citizens United_ , for example.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> A decent idea, but the anecdotal evidence of success seems like feel-good fluff, and not actually relevant.

CounterPAC seems like it's trying to create a spending arms race, but with the basis in simple disclosure, rather than political views. However, that the corporations have vastly higher resources and incentives to spend. Unfortunately, it seems trivial for firms to create a Counter-CounterPAC with the aim at depleting the resources of any successful PAC with these intentions.

From my perspective, this is a long run failing strategy, but has the possibly to succeed in the short run. It would need to hit the reps, and hit hard. Then immediately (within a few election cycles) turn and pass strong disclosure laws to create a change in the way the game works.

<comment> jim-greer Wait, is it irrelevant fluff? Or will it work in the short term?

You say "the corporations" as if it's some secret cabal. Most spending is done by trade associations, not corporations directly. Trade associations like to get their legislation through. But they don't run the show.

Money only matters to the extent that it buys ads that move voters. And there's only a limited amount that matters in an election. If you take a house race and outspend your opponent $10 Billion to $1 Billion, but have a worse message, you will lose.

The total cost of the all federal elections in 2012, including the presidential, was around $8 billion dollars. That's a big number. It's almost a billion dollars more than the worldwide market for adult diapers:

[http://online.wsj.com/articles/as-births-slow-p-g-turns- to-a...](http://online.wsj.com/articles/as-births-slow-p-g-turns-to-adult- diapers-1405554364)

It's a very small number compared to our economy. There's enough good money out there to run our elections cleanly. We just need the will to do it.

CounterPAC is a hack to do that without waiting for congress to act. You can be for it or against it, but it isn't fluff.

<comment><USER4> > Money only matters to the extent that it buys ads that move voters. And > there's only a limited amount that matters in an election. If you take a > house race and outspend your opponent $10 Billion to $1 Billion, but have a > worse message, you will lose.

I found this dubious, so I went googling. I felt I ought to share what I found:

[http://www.benzinga.com/general/politics/14/11/5012697/why-m...](http://www.benzinga.com/general/politics/14/11/5012697/why- money-didnt-buy-the-2014-midterms)

<comment> jim-greer Thanks - my point is actually narrower. It's that if both sides have enough money to saturate the voters with their message, additional money is of low marginal utility. Otherwise we'd have Meg Whitman as our governor in CA. She outspent Jerry Brown by nearly 5x in 2010, and lost by 13 points.

[http://www.huffingtonpost.com/2011/02/01/meg-whitman- outspen...](http://www.huffingtonpost.com/2011/02/01/meg-whitman-outspent- bro_n_816677.html)

</comment></comment></comment></comment><comment><USER5> The thing I've always found intriguing is that the tricks used by politicians and parties to hide the sources of their campaign financing feel like they were adapted from organised crime. (Which politics may well be, but that's another matter.)

* Make sure that individual donations are small enough to avoid the source reporting

* Cycle larger donations through entities that themselves do not need to report their sources

In any other context these patterns would trigger all kinds of money laundering alarms, but in politics it's considered business as usual.

<comment><USER6> I'm always amazed at how people want to fight corruption not really understanding that corruption is inherent to politics and government. You can't fight it. It's like fighting aging with plastic surgery. Sure, it may look good on the surface and it may even make you feel good psychologically, for a while. But you're still aging. Best you can do is accept that and lead a healthy lifestyle.

So, if you try fight corruption, it simply becomes more obscure. Corruption exists purely because governments and institutions exist. If you didn't have those, you wouldn't need to bribe some third party in order to be able to establish a business relationship with someone else (e.g. get a licence, permit, etc).

<comment> jim-greer > You can't fight it. It's like fighting aging with plastic surgery.

It's more like fighting crime. Aging is an irreversible process that happens to one person. Crime and corruption are background processes that happen to societies.

You can fight it. You can't eliminate it, of course.

Here's a good book on the subject:

[http://www.nytimes.com/2014/10/19/books/review/zephyr- teacho...](http://www.nytimes.com/2014/10/19/books/review/zephyr-teachouts- corruption-in-america.html)

<comment><USER6> Crime too. If you look at what are most of the crimes that are committed in any given country, it quickly becomes obvious that those are mostly victimless crimes or crimes that are invoked by governments declaring something to be illegal (while it harms no one): like drugs being illegal provokes a lot of violence, gang culture etc. The only true systematic source of evil in any country is its government. Without it, you'd still have bad things happening, but it won't be on the same level.

<comment> jim-greer Uh, violent crime exists. And it's worth fighting. Right? As is corruption? Or do you think we should give up on both?

<comment><USER6> What I'm saying is, governments foster violent crime by criminalizing many peaceful things. The best thing you can do to dramatically decrease violent crime rates is get rid of governments.

<comment><USER7> You can't get rid of governments though. People would spontaneously form states either to protect themselves, or to take advantage of the opportunity to set up protection rackets and tax others.

<comment><USER8> I find it amusing how people who dislike governments rarely move to failed states. You can easily move to an area without regulation or taxes but there not actually places you want to be.

<comment><USER6> A failed state doesn't mean absence of government. Similarly to how if you burn a church, it wouldn't make all the people in the village atheists.

What people who dislike governments can realistically do is not comply and ask for no permission. Don't pay taxes, use Bitcoin, ignore stupid laws, don't send children to government schools. Peacefully disobey.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> There's a great interview with Jim Greer on the Thinking Poker podcast. It's mainly about CounterPAC without much poker talk. [http://www.thinkingpoker.net/2014/11/episode-101-jim- greer/](http://www.thinkingpoker.net/2014/11/episode-101-jim-greer/)

</comment><comment><USER10> Interesting idea, and I hope it works in the both short term and long term.

As an outsider (and just overall uninformed about politics), since CounterPAC is transparent, is it an additional incentive for politicians to be associated with CounterPAC? And an "anti-incentive"(?) to refuse it, since people will know that they (likely) took dark money?

<comment> jim-greer It's a minor incentive, but honestly candidates mostly care about having enough money to get their message out, regardless of the source.

</comment></comment><comment><USER11> Oh, all we have to do is out-spend the largest corporations in the world. Problem solved...

<comment> jim-greer See my above comment. Elections are about the size of the world-wide market for adult diapers. It's do-able.

</comment></comment><comment><USER12> Jim great idea. How about a extension of this idea of picking close races and trying to get the candidates to accept no money at all with the threat to go thermonuclear on the first candidate that defects?

<comment> jim-greer That's a possibility - we've also thought about imposing a cap on spending and going after the first candidate to violate it.

</comment></comment><comment><USER13> The NRA has been doing this for years.

</comment><comment><USER14> I'm not convinced that you know what game theory actually is...

<comment> jim-greer I'm not sure you do either. Think about the real-life examples here and decide whether what we're doing is in the same category:

[http://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Real- life_...](http://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Real- life_examples)

</comment></comment><comment><USER15> Solving social problems with numbers ? Doesn't seem right.

</comment><comment><USER16> Can somebody explain me why a democracy allows for donations at all? Donations will clearly skew the political landscape towards the people who have money to donate. And those people are more likely to donate with an expected value. So they will try to skew the politics in their favour.

Why would it be bad to forbid any kind of political donation for established parties. I see the need to fund a grow new parties, but established parties should get by with the money they receive from the government.

<comment><USER2> Free speech.

In a democracy, if I have a political opinion, I must be allowed to express it. It follows that I must be allowed to pay a spokesperson to express it on my behalf, and it follows from that that I must be allowed to fund an organization with the mandate of expressing it.

That's all SCOTUS' _Citizens United_ ruling was about; there does not seem to be a reasonable way to limit political spending across the board without at some point allowing an unconstitutional restriction on political speech, and that's anathema to our society. (And as _CU_ has demonstrated, the distinction between that and unregulated campaign donations is academic in practice.)

That's not to say that there's no way to draw a line, but so far the anti- finance crowd has been largely unwilling to engage with this argument, and none has been readily forthcoming.

<comment><USER17> Let's not presume this is all about "free speech". The Supreme Court has placed restrictions on free speech that society has come to accept. (Not that I agree with them).

For example, the supreme court has made exceptions to the 1st amendment for obscenity, of all things.

[1] [http://en.wikipedia.org/wiki/United_States_free_speech_excep...](http://en.wikipedia.org/wiki/United_States_free_speech_exceptions#Obscenity)

Now that we can recognize the Supreme Court has made exceptions to first amendment, it's fair to dispute whether paid political contributions should qualify as free speech or if it should be forbidden as an exception.

The fact that Citizens United already happened should not stop people from disputing it, or the precedent it set.

<comment><USER2> > [1] > [http://en.wikipedia.org/wiki/United_States_free_speech_excep...](http://en.wikipedia.org/wiki/United_States_free_speech_excep..).

 _speech is unprotected if (1) ... and (2) ... and (3) "the work, taken as a whole, lacks serious literary, artistic, political, or scientific value"_

Political speech especially is sacrosanct in US jurisprudence. It's widely held as the reason we even _need_ free speech. On the balance of protected speech, having a legitimate political message is not a thumb so much as a foot on the scale.

 _If_ you grant that money spent to promote a political message counts as political expression, by limiting it we're talking about censoring _a lot_ of speech, across the entirety of political discourse. You will not find any restriction on any speech anywhere in law that even approaches it in scope. And we'll be censoring _exactly_ the speech we feel is _most_ important not to. This will not fly.

So, you need to either come up with a reason _not_ to consider money spent to promote a message as an expression of that message, _or_ come up with a justification for why, despite this being speech with a valid political message, it is _vitally necessary_ that it be censored.

Either of those could plausibly be argued, but the arguments I've seen are mainly along the lines of "Money obviously isn't speech!" and "Clearly, the rich shouldn't be allowed to speak louder than the poor!" In the eyes of Constitutional law, those things are neither obvious nor clear.

</comment></comment></comment></comment><comment><USER18> I know I'm being pedantic, but where is the game theory? The threat of campaign spending as a device to induce a more optimal equilibrium? If that's the case everyone uses game theory, no?

<comment> jim-greer We go into a race and say:

"We would like you both to take a disclosure pledge. If one candidate takes it, and the other doesn't, we may go after the one who doesn't."

Then we see what happens.

<comment><USER19> I still don't see how this is game theory. This just seems like a classic carrot-and-stick approach.

<comment> jim-greer What if I tell two prisoners:

"If one of you informs on the other, he'll get off with a 1 year sentence, and the other goes to prison for 10 years. If neither informs, you both go to prison for 5 years."

Does that sound like game theory, or just carrot-and-stick?

Here are other examples of game theory in real-life. I'd say we're in the same category:

[http://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Real- life_...](http://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Real- life_examples)</comment></comment></comment></comment>


London 'hoverboard' bus crash teenager dies - <AUTHOR> http://www.bbc.co.uk/news/uk-england-london-35068900 <comment> alex- It is very sad that someone has lost their life.

[http://www.bbc.com/news/uk-england- london-2492360](http://www.bbc.com/news/uk-england-london-2492360) states that between 2008 and 2013 their were 1,889 people seriously injured or killed by a London bus.

I can't help but wonder if you might not be safer on a "hoverboard" than on foot or a bicycle.</comment>


Top 10 reasons to have a job - <AUTHOR> http://hunternuttall.com/blog/2007/12/top-10-reasons-to-have-a-job/

<comment><USER2> The condescending and closed-minded tone detract from the author's obvious point (startup GOOD, job bad). A more serious consideration of both sides would have proved more useful.

For example, a very serious benefit of having a lowly 'job' is to have a set schedule and be able to make it to every one of your kid's baseball games. The debate is not a clear cut good vs. evil argument so it should not be treated as such.

<comment><USER3> Not to mention, if it weren't for jobs, who would work at his startup? The 'jobs suck' mentality fails on the criterion of universality.

And, though it sounds boring, stability and routine are big advantages, and they don't necessitate becoming a drone. I find that having a job provides me with a basic structure around which my non-job activities can more readily crystallize.

</comment></comment><comment><USER4> The article is obviously a bit tongue-in-cheek, but there are some upsides to simply being employed. By the time my first startup was crashing, I was so happy that someone offered me a simple "Do this and you get money" option, I nearly gave them a hug after being hired.

Entrepreneurship is an emotional rollercoaster that's a blast to ride, but sometimes you need to step of in order to steady yourself for a bit.

...That said, I'm loving it this time around, and making sure I won't have to stop.

<comment><USER5> Funny, I just wrote about this topic yesterday.

I grew up in business, and I have to say, seeing my Dad change careers after 25+ years of running a fairly large business, was a relief to me.

I think it's a natural part of being an entrepreneur that you're likely going to need a break now and then.

Also, with two small children, insurance, a stable paycheck and dental are worth it to me. My desires to run a business can wait until the risk:reward ratio means less impact on their lives, because really, it would be selfish to punish my children for my own fun.

</comment></comment><comment><USER3> It's also worth noting that there are some fields in which you have to "have a job" in order to be taken seriously. E.g., medicine, academic research, etc.

</comment><comment><USER6> -1 for the annoying javascript overlay that prompts me to subscribe to his newsletter.

<comment><USER7> The NoScript extension avoids that.

</comment></comment><comment><USER8> 11\. Health insurance, dental, 401(k)

</comment><comment><USER9> 1\. False

2\. False.

3\. That's not a good thing.

4\. That's not a good thing, have better aspirations.

5\. ?

6\. This is inherently not better or worse then the alternative.

7\. Get a life, have friends outside of work.

8\. You seriously aspire just to be "normal"?

9\. False.

10\. That's not a good thing.

<comment><USER10> I fear your satire detector needs a tune-up.

<comment><USER9> Crap, I think you're right! I took that seriously.

<comment><USER11> Count myself too. I skim text too much these days to read between lines.

</comment></comment></comment></comment><comment><USER12> It's a zero sum game.

There need to be players that hold jobs, put in regular hours, advance work at a consistent pace, draw a paycheck, sometimes hate what they do and end up on the lower side of risk.

There also need to be players that risk much to not hold jobs, develop ventures, advance things by an order of magnitude, create significant wealth that is far beyond what the player needs, and enjoy relative freedom.

The game will be hugely unbalanced and spiral out of control if one side decides in large numbers to jump to the other. You need both sides.

I think at the end of the day it comes down to whether you're able to enjoy life and find yourself in an environment that is in equilibrium with your inner.

</comment><comment><USER13> So much fluff. Why write when you have nothing to say?

</comment><comment><USER14> Not everyone wants to be an entrepreneur or take the risks necessary to create wealth beyond that of a full-time job.

There are as many reasons for this as there are people but to strike a condescending tone towards their decisions is arrogant.

Some, like the readers here, like to see things succeed by being able to contribute to the success.

I enjoy HN and I try to make it better by creating comments I hope others will read. But I don't spend my day trying to write my own version of HN. I'd rather work on my own stuff.

Employees are the same. Just because they have full-time jobs doesn't mean that's their end-all and be-all.

</comment><comment><USER15> Why not have both? These articles are pretty annoying, honestly. Everyone seems to think you can't do both at the same time. It depends on the start up, and I realize that, but it isn't that clear cut and dry.

</comment><comment><USER16> Top 10 reasons not to have a job

1\. Your boss ran out of Xanax.

2\. You wait 3 weeks for specs then have to have it done in 7 minutes.

3\. It doesn't matter when you are most productive; you will work 8 to 5.

4\. Your project is a slow motion train wreck and you can't jump off.

5\. Your boss's girlfriend got the promotion you were promised.

6\. Microsoft Windows & Office

7\. breakroom coffee

8\. meetings where no one knows what they're talking about

9\. You no longer read Dilbert. You live it.

10\. cubicles

<comment><USER17> 11\. Being forced to use crappy vendor software that they refuse to provide documentation for and then get yelled at when it doesn't work and told that it is your job to MAKE it work.

12\. Blind Carbon Copies

13\. Being forced to do things the _wrong_ way.

14\. Being woken up in the middle of the night and having to walk somebody through how to check if their ethernet cable is plugged in for an hour and a half and _STILL_ being required to be there at 8:00 the next morning.

15\. Providing a "this-must-work-now" temporary hack because somebody can't figure out how to work an excel spreadsheet, then having providing them with this spreadsheet every week become part of your job.

<comment><USER5> 13\. Being forced to work in an environment where people won't even learn the basics of SCM

</comment></comment></comment><comment><USER18>
      1. Find a rich spouse
      2. Choose to have a job or not
      3. ...
      4. Profit anyway

</comment><comment><USER19> Free coffee?</comment>


Attain the cutting edge - Let's build science-technology country (North Korea) - <AUTHOR> http://www.youtube.com/watch?feature=player_embedded&v=xpupc4zxlTo

<comment><AUTHOR> 'Not familiar with Computer Numerical Control? You obviously haven't been to North Korea lately...

For almost two years, citizens of North Korea have been exposed to a lengthy campaign extolling the virtues of CNC.

The song, called "Attain the Cutting Edge," is "available on karaoke machines nationwide" and the lyrics "include reminders that CNC is 'an example of self- reliance and strength' and that 'the people's pride is high…let's build a science-technology great power.'"'

[http://www.minyanville.com/business-news/editors- pick/articl...](http://www.minyanville.com/business-news/editors- pick/articles/north-korea-north-korean-North-Korean/6/22/2012/id/41916)</comment>


Ask HN: How does your company keep track of lessons learned? - <AUTHOR> As a single developer, I would usually just keep a .txt file with interesting things that I've learned throughout my tenure. It's a lot harder to replicate that efficiency for a large team; especially a distributed team. How do you effectively share knowledge with your co-workers? What have you seen work/fail? <comment><USER3> We have an alumni network that any developer can ping via email. The group is comprised of former standout employees who were paid a small retainer at the time of departure in return for their commitment to provide missing details and lore about design choices, missteps, and implementation.

<comment><USER3> actually, I'm unemployed... but in the future when I am running things, this is how it will be done.

<comment><USER4> What a clever comment double tap XD

"...and what do you do for work, Mr. Lebowski?"

"I'm unemployed."

</comment></comment></comment><comment><USER5> We have a directory lessons_learned/ with *.md files.

It's a git repo and everyone can pull/push directly to master.

I skim the commits once a week.

It's basically plain text files. But the md extension triggers some nice eye candy in vim and other browsers.

I think we will keep this structure forever. Maybe we will (additionally) serve the files over http at some point. Maybe we might even add edit / search / push functions over http, but for now I have not planned that.

I have seen CMS come and go. And I'm tired of it. Text files are forever.

<comment><USER6> This sounds really interesting. Do you mind if I ask how it is organized? One of the problems I have with our wiki is that some of this information exists, but I have no way to find it because the search feature sucks, and every person writing something has a different way of organizing/thinking about it.

<comment><USER7> I'm not 3dfan, but it sounds like their methodology avoids being too organized to lower the barrier to writing these things. The cool thing about simple text files is that you can get superb search with grep and similar tools. The git repo also seems more approachable than having to use a website interface.

</comment></comment></comment><comment><USER8> Maybe I'm a pessimist but I don't really think lessons are learned by companies, lessons are learned by individuals.

Postmortems are important to drive home what went wrong, but newcomers won't read them all.

That's why you need people with experience and people with tenure.

What companies sometimes do: They encode lessons into rules, which tend to survive turnover. But that comes with its own set of problems, where you end up having a lot of rules who's reason is forgotten.

<comment><USER9> This has been my experience. I've never worked at a place where the wiki was up to date, or where institutional knowledge was managed in a way that wasn't "ask this person about this, ask that person about that". I think attempts to document things "so we don't forget them" are basically a waste of time for an organization.

Keeping notes for yourself can be handy, though.

<comment><USER10> I agree with keeping notes for yourself. I think the key benefit is from _writing the notes_ more than the resulting document. The act of writing it down helps you learn/remember the lessons I think. I have been keeping records of the trickiest bugs I have come across for over 15 years [1]. I believe this has helped me internalize the lessons I wanted to learn from them, so I (mostly) won't repeat them.

Also, when you leave the company you keep your own notes.

[1] [https://henrikwarne.com/2016/06/16/18-lessons- from-13-years-...](https://henrikwarne.com/2016/06/16/18-lessons- from-13-years-of-tricky-bugs/)

<comment><USER11> Nice sharing. Like the tip on 'Own Tools' that has been applied in numerous situations. Sometimes a quick-and-dirty script(usually bash or python) will accelerate things considerably.

</comment></comment></comment></comment><comment><USER12> Documentation can be nice (it's something to point someone to if in a design review it becomes clear we're about to repeat a past mistake), but the best way to improve based on lessons learned is to bake them into your team's mechanisms.

To describe an example at a previous company from the one I'm at now: I used to work for a startup building a mobile phone network (technically, a Mobile Virtual Network Operator, MVNO, if you care about those distinctions - <USER2> point is that phone calls went through our infrastructure). It was very easy in the process of changing someone's account (porting in a phone number, changing a plan, or something like that) for the different IDs from different systems (phone number, phone's serial number, SIM's serial number, billing system ID number) to get out of sync.

So, we could have documented how to avoid this, and the document would have sat there with no one reading it. Instead we created a nightly job that went through all our accounts and verified that ID numbers were "as expected." It would output to a slack channel with whatever breakages occurred for us to look into the next day. This program also served as documentation - I could look at it to understand what IDs should match to which systems.

My current employer follows the same sort of learn-by-building-mechanisms approach, but at a much larger scale.

</comment><comment><USER13> When I was working in a team, I did Bug's Anniversaries celebrations. It actually boost moral.

February 2th. when I wipe out a production database because the ansible playbooks had hadcorded settings. Since then we use settings repositories and confirmation dialogs when playbooks will run in production.

September 2. They day we realise we are unable to restore old backups because of media paths are not related to the data, so when we move all data from different servers with lost all user's images forever. Since then images are prefixed with the db record id where it belongs, later we added metadata to S3 to add extra stuff like user_id, object_id, company_id, etc. so we keep urls clean

September 10. Inbox carnaval: we have an small hack that added users to BCC to send newsletter, with the time all users where receiving emails 2 times, then 3, then 4, then 10, then 2 again. It was a threading issue where the variable of the BCC was set to global in certain cases and it appended to the list instead of starting again ... 2 full weeks into that. Python3 and typing was the way to fix it

</comment><comment><USER14> We have Confluence pages that no one reads but it's nice we go through the exercise, I guess.

<comment><USER15> Confluence is absolutely terrible. Their accessibility user experience is abysmal. It was designed for people who operate user interfaces with their mouses rather than their keyboards. Not only that, but it seems to be quite unreliable. Seems every other day some random component is not working, like uploading screenshots.

<comment><USER6> Couldn't agree more! Confluence is a steaming pile. Worse, it steals key strokes used by the OS. If I want to search the page, I do Cmd-F and instead of bringing up the browser's search page function, it brings up its own broken "search everything except what I need" function. It's the worst.

</comment></comment></comment><comment><USER16> You know that feeling of "we always complain about the same things, but it never gets any better?" Your question is at the heart of making it possible to escape stagnation and actually evolve the way a team works together.

Sharing knowledge isn't just a matter of tooling, but a matter of principle. Because we want the knowledge we share to not just float out there as a "lesson", we want people to _use_ the lessons and act differently what we're actually talking about here is governance (i.e. law!). This might sound heavy. It's not. It's just a change in orientation from "I'm passively sharing this lesson we learned" to "this lesson we learned changes the way we act."

There are 3 things to do to shift from "lessons learned" to working agreements:

1\. Capture knowledge in the pattern "when this happens, our team will act this way"

2\. Adopt a workflow for formally adopting a working agreement – could be a majority vote, consensus vote, etc.

3\. Keep that knowledge someplace the team can browse, search, and update (e.g. Confluence, Notion, Google Drive, etc.)

If you do this, something magical happens: you'll begin to evolve your knowledge over time.

Have a working agreement that didn't quite cover a corner case? Update it! Have a working agreement that was too restrictive? Nuke it!

It's no less shift in magnitude as when humanity switched from oral tradition to the written word. And guess what? The written word works much better when you're operating remotely.

Our remote team has been operating this way for nearly 5 years at Parabol. It's a common pattern that at the end of every retrospective we have a new working agreement we'd like to adopt. We've even come up with a Slack-based async workflow for adopting them: [https://www.parabol.co/blog/async-decision- making-slack](https://www.parabol.co/blog/async-decision-making-slack)

</comment><comment><USER17> Bluntly: We don't bother. We don't even have reliable mechanisms for collecting feedback from customers.

I'm leaving soon.

</comment><comment><USER18> We have a checklist system. Depending on which files are on your commit or which database objects are modified, you're presented with a checklist specific to the things you're changing. When something goes really wrong, the outcome of the post mortem often includes adding to or changing the checklist for the affected files/filetypes/team/whatever. It's not a perfect system, but it beats reading our long, confusing wiki pages.

<comment><USER19> Can you tell me more - how/where do you present checklist before commit?

<comment><USER18> We use in house project tracking software to manage development, bugs, documentation, Etc. that it's built into. These checklists are verified by another developer as part of code review before the branch is allowed to merge to the release/main branch. There's only a couple of "generic" checks (one for security things, another that's automated that enforces coding standards), at least for our team. A small bug fix may only have 2-4 checklist options, but a larger enhancement may touch enough things that there may be 20-30 checklist options.

</comment></comment></comment><comment><USER20> We don't!

One of the reasons why some people become valuable in long-tenure positions is because of the lessons learned. At a certain point, no one is going to read through every page in the wiki / archive / man pages / whatever is popular this year.

That's where onboarding and process come in: Management needs to make sure that lessons drive improving the process, that newcomers are onboarded with lessons from the past, and that everyone continues to follow the processes.

Now, jokes aside, in my company, the new owners decided they didn't like the people we were outsourcing with, and decided to replace them with their own outsourcing center. Now everyone's re-learning lessons that are probably tracked in our various wikis, repositories, ect. But, the newcomers want to run things their own way.

That's why a few long-tenured people are important.

<comment><USER21> Institutional knowledge. So, so crucial to culture and process.

</comment></comment><comment><USER22> Realistically, the way we do it is we have a team of supervisors who have been around long enough and have seen everything that - as a group - we are the institutional knowledge. We are pretty effective at communicating with each other to bring the institutional knowledge to bear on a problem - we could be better at training our subordinates so that they have access to this institutional knowledge, but the truth is that the training is expensive and not usually well received.

Generally, I don't think efforts to accumulate institutional knowledge on a website work bear fruit - no one really wants to update the website, both because it's thankless, but also because of access time. It is much faster to tap the institutional knowledge in management by sending an email than by paging through the results of a search. For written institutional knowledge to have real value, the access time has to be small, which means someone has taken real care in curating the knowledge so it's easily accessed. Finally, we have the Brian problem. Brian was the person most likely to update our internal websites - unfortunately Brian wasn't very good and had some poor ideas regarding lessons learned - by adding them to the websites, his bad ideas were passed on to younger team members who didn't know better.

</comment><comment><USER23> I work voluntarily at a university radio station. We are a small team of three technicians, but the team changes quite often. I have been there for four years now, which is already quite long as people come and go as they finish their studies. We keep track of everything in a dokuwiki. Often I catch myself not wanting to document stuff, but it is essential for coming technicians to have a place where they can look stuff up. That was the place to learn about how the infrastructure works for me when I was new. The second tool we use is openproject for ticket tracking. We don't delete old tickets, so if a problem comes up again it is likely that there is already a solution for it documented in the ticket system.

</comment><comment><USER24> We used to try and do this in Confluence.

Felt good to know that stuff is neatly documented somewhere, but since no one ever knows where that was, it was of little value and few ever read it. People still tapped on shoulders and repeated the same mistakes.

It baffles me that an established company like Atlassian can't get something as fundamental as search right. I can't even find the content I myself created at times.

We have since switched to Nuclino ([https://www.nuclino.com](https://www.nuclino.com)) and so far are having a better experience. It's as feature-packed, but the basics work as expected and are a lot more user-friendly.

Re-establishing a proper documentation culture in the team is still a challenge, but that's not something a tool can solve.

<comment><USER25> > It baffles me that an established company like Atlassian can't get something > as fundamental as search right. I can't even find the content I myself > created at times.

i agree, indexing and searching could be improved a lot. their editing experience extremely good though.

</comment></comment><comment><USER26> Disclosure: I am a founder at bytebase.io, currently in closed beta. We're building Bytebase with this kind of use case in mind.

Wikis - we found wikis are too heavyweight and formal to be used consistently for recording learnings.

Slack - in our experience, Slack makes capturing learnings easy but organizing and keeping track of learnings difficult.

Our goal with BB is to make recording a learning as convenient as writing a Slack message AND to make organizing and keeping track of these learnings similarly easy.

You can write bytes directly in Bytebase or save them from Slack.

Would love any feedback or ideas. Email me (email@example.com) to get access to the closed beta with HN in the subject line.

<comment><USER27> Possible to use this type of service with another webhook / API a la Hubot for other services? (Say, Mattermost, for example?)

I was tinkering with an NLU-style chat bot (Rasa framework) that allowed for efficient querying of this kind of data via Github Wikis (and a mapping of where this stuff might sit), but quick storage is also a piece that would need to be fixed as lessons were learned. Definitely a problem area for us that is not just solved with auto-responder regex.

<comment><USER26> Thanks for your question! We don't support integrations other than Slack yet but plan to add more soon as well as an API.

Mind shooting me an email so I can learn more about what your team needs?

</comment></comment></comment><comment><USER28> Developing a postmortem culture is important to share the lessons learnt from production. For eg. Documenting and sharing the lessons learnt from a SRE perspective , a google doc would suffice. Some pointers at [https://landing.google.com/sre/sre- book/chapters/postmortem-...](https://landing.google.com/sre/sre- book/chapters/postmortem-culture/) Have seen Wiki being setup and fail and go stale very quickly. Lots of knowledge and learnings are tribal knowledge. Sharing tribal knowledge is effective in person or in a non wiki mode especially through brown bags or chapter meetings etc., Challenge is not everyone has the time or the energy / enthusiasm to be talking in front of a wide audience. Never seen one solution working effectively. You need to figure out the best approach based on the team culture and how the organisation is setup. For eg., some teams are hesitant to share knowledge and learnings with other groups - Conways law comes into play. End of the day it is not up to the company to track lessons learnt. It is the job or becomes the job of the person supporting production to a large extent to maintain it for making it easier to do their job. That being said , that knowledge leaves when that person moves jobs & the cycle continues

<comment><USER29> Similar to that; Post Implementation Reviews (PIRs), then we adapt the relevant documents (processes, procedures, policies, PM methodology, etc.). Usually on the projects the Sponsor is high enough that can approve/influence the changes in the aforemention documentation. On the side, we have a Wiki where every project has its own page (with user access in place because some semi-sensitive info can be found there).

</comment></comment><comment><USER30> I work at a company with ~1k engineers.

Every every system failure, we email the entire org a postmortem google doc describing what went wrong, why, and what we are doing to prevent it from happening again. Postmortems are also as their own JIRA project.

<comment><USER31> That sounds great but if I was mailed postmortem docs every day I'd soon start forwarding them to spam folder. Do you know how many people go through them?

<comment><USER30> They happen about 3-5x month. I typically read the once that are most relevant to my role.

</comment></comment></comment><comment><USER32> At company level lessons learned turn into internal rules. Too flexible holiday time results in more explicit rules about what is and what isn't allowed. The endgame is you become too bureaucratic after enough creative employees.

</comment><comment><USER33> We have implemented an collaborative wiki (wikimedia, like a copy of wikipedia but just opened for internal usage) in 2009, in a company with 200 employee. We engaged people to write everything that they think is good for the others.

<comment><USER34> How often do people read that stuff?

<comment><USER35> How often do people maintain it? My experience with internal wikis is they start off good, but a few years latter everything is obsolete: it is a good things nobody reads it because what was true last year isn't anymore.

<comment><USER33> We create a department with two employees to incentivize and review the articles (correct typo error, writing mistakes and text enhancements). They are hierarchically located in the internal communication area, so the internal weekly e-mail about the news of the company was linked in the Wiki. All the changes that are happening the products, or events, awards and other news from the company were input in this wiki. They got a lot of view incentives from the weekly news of the company. The idea is to document all the projects, steps, actions and mistakes, and all the things that happen in the company.

[Translated from the sustainability report from 2009 - page 31 - GiiMiiPedia] GiiMiiPedia is a free encyclopedia built on the Wiki model (the same as Wikipedia) whose purpose is to transfer Know how. This initiative encourages employees of the organization to contribute knowledge that can be useful in different contexts, optimizing the time of employees. This year, the GiiMiiPedia layout underwent some modifications, with new sessions included, such as: market news, videos and subjects of interest from all areas.

Sorry the report is in Portuguese, we are from Brazil :) [http://www.daiichisankyo.com.br/site/wp- content/uploads/2019...](http://www.daiichisankyo.com.br/site/wp- content/uploads/2019/04/relatorio_daiichisankyo_PORTUGUES_web.pdf)

</comment></comment></comment></comment><comment><USER36> 1\. We are writing detailed postmortems for incidens of medium scale and larger. It is a must read for all the newbies. Postmorteams are always linked to issues to prevent similar situations in the future.

2\. We are diligently linking our issues into a hypertext mesh: what is related to what, what was blocked by what, what was decomposed from what. We are using milestones and epics.

3\. All the commits in all the codebases are linked to issues. There is a rule on a server side that forbids pushing non-linked commits. There is a single exception for firefighting code changes, when there is no time to write a ticket first, but those commits are marked with a special signs and author should create an issue and link to commit when the problem is solved.

4\. Documentation and API specs are laying in the same or adjacent repos and are changing according to same rules.

5\. So, every line of code is linked to the corresponding issue via commit and then to other issues and commits in other repos via hypertext mesh. When your code is clean, it mostly self-documented and becomes a knowledge itself.

</comment><comment><USER37> I established a wiki where I use to work. I was quite efficient about keeping it up to date and well categorized. I found it quite useful for not having to re-work out issues I had already solved. It was easy to search and correctable. I gave the people I worked with full access to it. Most of my colleagues ignored it. A small handful utilized it as much as I did. Some would even go back and edit articles and make it much more readable. I found it to be a very useful tool which increased my productivity immensely. I was somewhat disappointed by the lack of use it got from the majority of the people I worked with. On the other hand they wouldn't utilize the version control system I maintained for us either.

<comment><USER38> Sounds Enterprise

</comment></comment><comment><USER27> Wikis work pretty well for this, provided you use them.

If you can't be bothered to put together documentation as you build the software (sometimes I can't be bothered), you should at least make sure to document as you troubleshoot later so you don't keep making the same mistake. We store these as "Flight Rules" for our application (or error signatures, etc - whatever you want to call them) which provides the team a single location to start their search when things go belly up.

That way, when you run your post-mortem (you run these, right?) you have a place to store the error notes which eventually builds up into a really useful document.

Lastly, I'd say having a team norm that when one person does something the others should also be able to test it (and therefore have the right instructions to do so) is a good one for continuity.

EDIT: COuple other things that have worked: \- Checked-in ".dot" file GraphViz context diagrams alongside your repos are nice and easy to update \- Creating decision documents for a quick run-through of options with your technical team is a great way to run an effective process while also creating a searchable artifact for later, which is great for context / lessons learned.

</comment><comment><USER39> We haven't started using it yet but we've been thinking about using the Architecture Decision Record pattern as presented in the ThoughtWorks Technology Radar [1].

The basic idea is document decisions with a specific structure and keep it close to the code. The thing is any time we can answer "why", it's a form of decision that can be documented somehow. Since it's close to the code, while coding, any search will also land on those decision if the same terms are used.

There are several tools to help with that as presented here [2] and here [3].

[1] [https://www.thoughtworks.com/radar/techniques/lightweight- ar...](https://www.thoughtworks.com/radar/techniques/lightweight-architecture- decision-records) [2] [https://adr.github.io/](https://adr.github.io/) [3] [https://github.com/joelparkerhenderson/architecture_decision...](https://github.com/joelparkerhenderson/architecture_decision_record)

</comment><comment><USER40> My work concerns safety in high-hazard industries, where lessons learned analysis (also called operational experience feedback) is a very important organizational process. It's also well-known to be difficult, not so much related to the technical tools used for recording/sharing incidents and lessons, but mainly in terms of organizational culture (learning, blame, psychological safety and speaking up). Some references from this area:

[https://risk-engineering.org/learning-incidents-accidents/](https://risk- engineering.org/learning-incidents-accidents/)

[https://risk-engineering.org/barriers-learning-experience/](https://risk- engineering.org/barriers-learning-experience/)

[https://risk-engineering.org/concept/psychological-safety](https://risk- engineering.org/concept/psychological-safety)

</comment><comment><USER41> Discuss fervently, make some tickets, writeup in Confluence. Then act surprised when it happens two years from now.

</comment><comment><USER42> At my employer we have two ways:

1\. For large issues visible to customers an incident report is shared inside the company. These are written for general consumption and so lack any technically interesting aspects (they're "dumbed-down" a lot).

2\. Technical "lessons learned" are curated in a Sphinx based documentation website that I started but which is starting to see more and more contributions from other tech heads in the company.

We used to have a wiki but it ossified after years of no contributions. Personally I didn't like the MoinMoin wiki engine that much but this is just personal taste of course. I started setting up the Sphinx site to encourage knowledge retention despite turnover - I kept explaining the same things again and again. Now I just share a URL when such questions come up :-).

<comment><USER43> Great! What's so good about using Sphinx for this?

<comment><USER42> Honestly I think this is personal preference more than anything else, so I'm not sure how useful my answer is, but I thought I should at least try to answer your question :-).

I have quite a few years of experience in using Sphinx to create high quality technical documentation for open source Python projects, which explains why I chose Sphinx for this endeavor in the first place, but that's not an answer to your question.

The following dichotomy that I feel exists may (?) be more useful:

* Wikis tend to grow organically without much restructuring. I don't think this is fundamental to any specific wiki system, more of an emergent behavior, if you will. Enough discipline can surely avoid this, but wiki systems don't exactly make it easy - I haven't seen many "refactoring" tools in wiki engines, though they probably exist (global rename that updates references, moving of sections of text between documents, etc). I have definitely seen quite a few wikis devolve into the documentation equivalent of a "big ball of mud".

* Sphinx being based on a simple directory structure of text files on a local filesystem in reStructuredText format makes it much easier for me to "refactor mercilessly" in order to adjust the structure of the documentation so it keeps making sense as it evolves (e.g. things as simple as "grep -r" and "find | xargs | sed -i" or equivalents built into editors). To make sure no references were harmed there is "sphinx-build -nW".

I've also grown to appreciate the value of generated content. For example we have a dozen software projects and another dozen internal web services. I cataloged both as a directory of simple CSV files that contain details like repository locations, programming languages and frameworks used, type of release management process used, etc. During the documentation build these CSV files are rendered into multiple output formats, for example an overview table that lists the most relevant high level details of each project / service and separately from that the more detailed information about each project / service. The data only needs to be entered once (DRY), but can be rendered any number of times.

</comment></comment></comment><comment><USER44> The answers here are breaking down into two categories:

1\. General business lessons, to which companies generally don't summarise or track them.

2\. DevOps outage post-mortems, which competent companies generally have some sort of process around.

I've never seen a rigorous post-mortem culture in tech outside of DevOps/SRE.

I guess there are a few reasons. One is probably that the DevOps/SRE space is very amenable to encoding lessons learned in scripts of various kinds, so it's actually useful to do a post-mortem exercise because the outcomes are very small, very concrete and will be somewhat actionable. Things like "errors in parsing this file shouldn't cause the server to blow up" are easily corrected and a process (unit test) put in place to formally encode that institutional knowledge.

In regular software development there's way less reflection. This is partly because the tooling is much less home grown and malleable. Lessons _are_ learned and they _are_ encoded, but it happens slowly and through the mechanism of library and language design. It's generally not something you do within a single company but rather, it's an emergent consensus across the whole industry. Additionally, this is harder because lessons learned are often ambiguous or subjective. For instance I learned the lesson, many years ago, that dynamic typing leads to more mistakes than static typing. But you see many programmers still who prefer dynamically typed languages and dispute this sort of conclusion.

In the business world there's virtually never any kind of "lessons learned" repository or process. At most you get something like a formalised interview process, but even then, those are usually baked into a company from day one or never adopted at all. I've heard of very few large companies that adopted a more rigorous approach to hiring than the one they previously used. It does happen but it's rare.

At the executive/CEO level lessons learned get recorded in the form of strategy talks given at fancy conferences, if at all. Often abstracted or vague to the point of uselessness, any insight that is present gets forgotten immediately by the audience who are mostly there because it's easier than doing real work. These lessons learned are things like "innovation is key to the customer experience", which is a genuine learning in a sense (usually from observing the wreckage of firms that went up against a competent tech company). But it's not really useful in the sense of being actionable by normal employees.

</comment><comment><USER45> We're small but sharing post mortems publicly on our transloadit blog helps to a) be transparent towards customers b) have a reference for future team mates / scenarios c) make sure we really understand the issue. Once something works again, the brain is all to eager to accept any kind of summary and move on. If you share your post mortems, you're forced to look deeply at all the assumptions and preconceptions they are built upon, and often (always) that process reveals new insight and fixes. It can be painful and time consuming, but it pays dividends.

</comment><comment><USER25> I've worked at a company that as seen a HUGE amount of turnover.

The things I have learnt are:

\- companies don't learn, people do

\- having an internal wiki/kb helps a lot IF it's structured/indexed well enough that you can actually find information

\- in an ideal world, no project should be considered done if documentation is not written

It's all about people. People learn and can recall lessons learned.

Otherwise you rely on the good faith and will of the next person to actually go through all the documentation that has been left from the people before. This person might not have all the will, or it might not have the time.

</comment><comment><USER46> We, at some point, had a Knowledge Sharing event every week. The goal was just go round the table and every developer would share something they learned that week. As I was the senior developer at the time I would usually bring something that I learned or from CS, like a nifty algorithm or how Hashmaps are implemented in C#. Other people would share some bugs or unexpected behaviour. I liked it a lot and I felt that the team did as well. Sadly we stopped doing it, as there was a reorganisation that impacted our ability to do it.

</comment><comment><USER47> Keeping track is the initial part of the effort. Getting the information from 'existing' to 'integrated' requires a system easy enough to use ( add Bare- bones description of issue, add comments or post mortems, format in ways that highlight core problem/solution) and robust enough to have hooks everywhere an engineer might need to see it.

The negative side of integration is the person with knowledge integrates it in their practice and 'forgets' it is new knowledge for everyone else, thus not propagating the new lesson learned.

</comment><comment><USER48> My company DXC just laid off or let go 99% of my team. I'm the only one left. There's no lessons learned here only the short term bottom line. And the developers are simply a commodity.

<comment><USER49> Professional services companies business is about selling/billing hours. Those involved in the sales are seen as an asset, those involved in providing the service are seen as a cost. They don´t care about the latter.

DXC, Accenture, Capgemini, Indra, etc...they are all the same.

</comment></comment><comment><USER50> Telegram bot with options button.

As the telegram bot are processed by my coordinator website, almost every message sent by any user to the bot are saved in my co's database. There are 2 types of options, the public and private. Public type will be saved in db and tell the whole bot's user about information someone sent, with or without further feedback from other bot users. The private type will be saved in db and only visible to several user specified.

I though it is very versatile for report, lesson learned and etc.

</comment><comment><USER51> We have a git repo (called the devops repo) and we use sphinx to generate the html. We try to document lessons, post-mortems, decisions and tools we plan to evaluate.

Unfortunately, folks don't really read the docs (and I've learned from this thread that we're not alone ;)

Been thinking about this problem and thought to embed something like a quiz in the docs to make them interactive, yet still static - something like howtographql.com. Yet to try that approach, though.

</comment><comment><USER52> As I mature as a developer I'm learning what many of you probably know: effective long term curation of knowledge is really frickin hard. It's the hardest part of my job, especially because it's so subtly important and easily missed. The end product rarely breaks because of a short term lapse in documentation.

I don't have a better answer yet other than making it a personal point of pride that my docs are always up to date and well-organized.

</comment><comment><USER53> Very fragmented all over the corporate network in all kinds of weird tools and applications.

They did make effort to standardize everything, but nobody seems to care.

</comment><comment><USER54> We are building a single open-source repository consisting of markdown good practices from lessons learned and share-code repository.

[https://github.com/pragmatismo-io/pragmatismo-io- framework/t...](https://github.com/pragmatismo-io/pragmatismo-io- framework/tree/master/docs/pt-br) (Currently available in Portuguese)

</comment><comment><USER6> One thing I started doing a few years ago is keeping a debug diary. This helps me avoid mistakes I've made in the past, or at least fix them more quickly the next time they happen. I've actually put the more interesting parts of my diary onto our Wiki and encourage others to add their stories. I think I got the idea for a debug diary from HackerNews years ago.

</comment><comment><USER55> One of the first thing my co-founder and I did when we started our new project is create a table in Notion with all the previous lessons we had from our last company, and have been adding to it as we create fresh, new mistakes. Using tagging to keep it organised and readily available so when we start adding more people everyone has ready access to it.

</comment><comment><USER56> I set up Confluence and used it a lot for "how to do this" and "how to do that" notes for myself. It was helpful to me, and I figure that it MIGHT be helpful to other people. It doesn't HURT to have the information searchable, and with a GUI on it for the less-UNIXy folk. Some people use it, most don't.

</comment><comment><USER57> We use a mix of confluence and slack groups. We have one slack group per type of learning (RCAs for failures, best practices in engineering / manufacturing / logistics, etc., Top of the mind thoughts, interesting reads). We use confluence to do detailed documentation or writing, and slack to share and drive visibility.

</comment><comment><USER58> I used to work for Google as an SRE a while ago.

They have pretty good procedures for keeping track of lessons learned. The book ([https://landing.google.com/sre/sre- book/toc/](https://landing.google.com/sre/sre-book/toc/)) goes into some detail.

</comment><comment><USER59> > How does your company keep track of lessons learned.

The dev overall, across the globe: i find retrospectives after a sprint cycle really good actually, it's a good place to call up where improvements can be made too.

On a personal level: When my mess up/mistake causes grief for someone else, I make damn sure I learn from that.

</comment><comment><USER60> We have a handbook based on Hugo for the tech folks thats editable by anyone and bloomfire for the general masses.

</comment><comment><USER61> At a previous job, we had an internal Wiki with a page titled: "Cow in a ditch" which was specifically for this purpose.

Otherwise, it's mostly Confluence now, but no specific page of lessons learned, instead, those lessons are dotted around in individual documentation pages.

</comment><comment><USER62> We have an active process whereby staff with more experience try to actively pass on that experience, spending large amounts of time explaining that the "new" initiative has been tried before and detailing what happened and why it failed.

Of course nobody takes any notice.

</comment><comment><USER63> We talk about it, some deserve to know, some don't. Some better know, some better not.

Non written education is probably the most effective way to communicate and maintain important information. Writings leave it up to the authors' ability to know where and how to communicate...

</comment><comment><USER64> For an organization, I think it's best to have a company handbook that covers all your standard practices and culture.

And if there are significant failures in policy, you can just put a note after the revised policy that says "we tried X, it didn't work because of Y.

</comment><comment><USER65> I have a question too, but I will put it here instead/before of making an Ask HN entry:

Is there any intersection between "keeping track of lessons learned" and "agile methodologies" or are the two completely unrelated/orthogonal ?

<comment><USER66> Agile methodologies have a regular meeting for lessons learned, the retrospective.

You still have to take care to actually record that knowledge / keep track of it though.

</comment></comment><comment><USER67> I have seen post mortems or "common problems" in knowledge bases, but outside of that the lessons learned were either addressed directly (improved process, fixed code, improved docs) or only in the heads of people involved:)

</comment><comment><USER68> We put it in a write-only wiki.

</comment><comment><USER69> It doesn't sound exactly like what you have in mind, but we have a DFIUA program ("Don't Fuck It Up Again..." ;-) where people do postmortems on serious misses and report it out to the software team.

</comment><comment><USER70> From what I can tell, we keep the best people around, or maintain good ties with them as they are leaving to ensure knowledge transfer. Many come back because they find the work environment to be unmatched elsewhere.

</comment><comment><USER71> Reminds of the ironic naming of the "Lessons learned meeting". If no change is made to what people actually do, it's very hard to say that anything has really been learned, and I would put that first.

</comment><comment><USER72> Daily notes posted in slack where a bot logs to elastic search. Notes reviewed in our retros and the useful/actionable is logged in a wiki and or jira. Wiki notes are reviewed in our annual retro.

</comment><comment><USER73> we have a lesson_log channel [with standard entry format] in slack -- for all Slack's shortcomings, this works great, as the whole team can see lessons learned from every department

</comment><comment><USER11> <sarcasm> My company is awesome in the sense to make sure it doesn't forget, it repeats the same mistakes every couple of years </sarcasm>

<comment><USER74> We keep ours in a manilla folder labeled "Business plan 2021"

</comment></comment><comment><USER75> We have a kss - knowledge sharing system, that looks at patterns in code changes on pull requests and add comments if needed. Anyone can add a rule

</comment><comment><USER76> Keep and share are two different things. You can email or have a small meeting sharing results, but keeping a searchable, updated, database is hard.

</comment><comment><USER77> I use a Histre notebook shared with my team [https://histre.com/](https://histre.com/)

</comment><comment><USER78> we are using a service called [https://www.getoutline.com/](https://www.getoutline.com/)

\+ for being OSS

<comment><USER43> Looks similar to Bookstack [http://www.bookstackapp.com](http://www.bookstackapp.com)

</comment></comment><comment><USER79> We have had a couple wikis over the years. They're rarely updated and even more rarely cited. It really hasn't worked out.

</comment><comment><USER80> Usually through tribal knowledge contained in experienced employees who "retire" when they get too old and expensive

</comment><comment><USER81> \- we're still in business. We learned something.

\- anything written down and not enforced is almost the same as nothing.

</comment><comment> awinter-py tacit knowledge is hard enough for a person to describe, much harder to do in a company context

IMO if the full answer to a question doesn't exist in a single brain, you'll have a hard time reconstructing what really happened without a challenger- level investigation

companies only solve problems temporarily

</comment><comment><USER82> Oral histories of each firing. /s

</comment><comment><USER83> Github repo with TILs (Today I Learned / Things I Learned)

</comment><comment><USER84> we have a wiki in microsoft teams, which no one ever reads...

</comment><comment><USER85> Only by repeating it frequently over span of months.

</comment><comment><USER31> Usually new Tests(Unit or Integration) or monitoring.

</comment><comment><USER86> In "the circular filing cabinet"?

<comment><USER87> Vertically archived

</comment></comment><comment><USER88> via the post mortem process

</comment><comment><USER89> email</comment>


Why note-taking is broken and suggestions towards a solution - <AUTHOR> https://medium.com/@juergenschweizer/why-note-taking-is-broken-9c69e75767d9

<comment><USER2> What did you think of Lotus Agenda's data entry & automatic categorizing?

While inventing new ways of taking notes, please invent a way for someone to indicate on this HN thread that they would like to be notified of your follow- up HN thread :)

</comment><comment><USER3> sounds interesting. Looking forward to the next part and learn more about your solution.</comment>


People are buying Vista on Ebay for $88 - <AUTHOR>

When I finally got around to putting some old parts on ebay I almost didn't even bother with some copies of Vista.  To my shock the first one just sold on ebay for almost $90.
Are these becoming collectors items or do some folks _really_ not want to upgrade in 2013?
Vista rocks? <comment><USER2> People that had Vista on their previous computer and had recently bought a new laptop with Windows 8, and found out that it sucks?

</comment><comment><USER3> I clicked on this thread thinking "Surely they aren't talking about _Windows_ Vista, there must be some desirable product with the same name..."

</comment><comment><USER4> Well, I'd rather have people using Vista and XP. I don't see what's wrong with Windows 7 though if you don't like Windows 8's interface. (Even though there's a few cheap paid and free tools to make it behave pretty much exactly like Windows 7 if you don't want to embrace change).

<comment><USER5> "Embrace change" and "turn my computer into an Xbox" are two different things.

<comment><USER6> Aside from a different start menu, Windows 8 is nothing but Windows 7 with some more fat trimmed. On the desktop, you can't easily tell them apart. Why would you describe it in such extreme terms?

<comment><USER5> It's the new direction Microsoft's taking with their interface formerly known as Metro design theme. The "tiles" concept works well on touch devices, but is a complete failure on large-screen computers with a keyboard and mouse.

I'm aware you can turn it off, but if you're disabling their flagship feature, why even bother upgrading to Windows 8 at all? It's expensive for anyone in Windows 7 with very, very little benefit.

</comment></comment></comment></comment><comment><USER7> A lot of people buy a lot of crap on ebay for outrageous prices. Might be Microsoft trying to prop up the market!

<comment><USER5> Like $50 gift certificates sold for $80.

<comment><USER6> Gift certificates make sense. The buyers are people without credit cards that want to shop at those stores. They can get money into a PayPal account to buy things on eBay, but those stores don't take PayPal.

</comment></comment></comment><comment><USER8> Probably someone who can't use 7 due to missing driver support.</comment>


Why you should quit Porn now - <AUTHOR> http://yourbrainonporn.com/ <comment><USER2> This site is a poor source of information for the current state of understanding how porn affects the brain. Here's a great jumping-off point instead:

[http://www.abc.net.au/radionational/programs/scienceshow/is-...](http://www.abc.net.au/radionational/programs/scienceshow/is- pornography-destroying-our-minds-and-our-sex-lives/6598390)</comment>


How are you using three js? - <AUTHOR>

<comment><USER2> [http://ponderout.cloudapp.net:3000/brainFlow](http://ponderout.cloudapp.net:3000/brainFlow)

Move with arrows jump with z</comment>