Why secure systems require random numbers - <AUTHOR> http://blog.cloudflare.com/why-randomness-matters

<comment><USER3> FWIW: I don't like OpenSSL as a CSPRNG; I think you'd generally better off replacing it with direct reads from urandom.

Another useful thing to know: there is lately a push towards crypto constructions that minimize dependencies on randomness. For example, there's "deterministic" DSA that replaces the nonce with a uncorrelated (psuedorandom) bits from digest functions. If you see people talking about cryptosystems being bad or good based on CSPRNG dependencies, that's the idea they're talking about.

This was a good post. For the record, we've been repeatedly trying and failing to hire Daniel Franke ever since that HN hack.

<comment><USER4> Extrapolating a little when you say you don't like openssl as a CSPRNG, do you mean you don't like any of the CSPRNGs or just the openssl one? For e.g. NIST specified some CSPRNGs in the DSA specification.

You don't like them because the application might end believing it has more entropy than it really has or are there other reasons?

<comment><USER3> I don't like the OpenSSL CSPRNG in particular for the same reasons 'rwg cited. But more broadly, I don't like app-layer CPSRNGs. CSPRNGs are one thing that benefits from being centralized on the OS.

</comment></comment></comment><comment><USER5> It's been linked often, but allow me to re-recommend the Matasano Crypto Challenge for learning more. It has a section on pseudo-random number generation. [http://tinyurl.com/mtsocrypt](http://tinyurl.com/mtsocrypt)

</comment><comment><USER6> There are a bunch of cheap, well supported, hardware random number generators out there. For example, the Entropy Key: [http://www.entropykey.co.uk/](http://www.entropykey.co.uk/)

<comment><USER7> "Please note that there is a very long waiting period for Entropy Keys at the moment."

That notice has been there for a very long time, not sure what this period is...

(maybe they have run out of randomness!)

</comment></comment><comment><USER8> Two reasons why crypto needs randomness:

1) You need to generate keys that nobody can guess.

2) Much of modern crypto is built based on probabilistic encryption [1].

[1] [http://theory.lcs.mit.edu/~cis/pubs/shafi/1984-jcss.pdf](http://theory.lcs.mit.edu/~cis/pubs/shafi/1984-jcss.pdf)

</comment><comment><USER9> Notably newer Intel CPUs (iirc, Sandybridge and later) include a true random number generator, but I'm not sure how much software supports it yet.

<comment><USER10> Which people fear is backdoored by the NSA.

<comment><USER11> No, people don't directly fear it's backdoored by the NSA. There has never been any evidence that it's backdoored by the NSA. The algorithm it's documented as using (based on AES) is not the one that was backdoored by the NSA (Dual_EC_DRBG), though you would have to take a look at the chip with a scanning electron microscope in order to verify this.

The kernel developers just don't think it's a good idea to blindly trust unauditable hardware random number generators. Using it in conjunction with other sources of entropy is one thing; just using it on its own is putting a bit too much faith in it, especially because the code that uses it uses a generic wrapper for any hardware random number generation instruction, so if AMD or ARM or MIPS chips later come with random number generators, the kernel will be able to take advantage of their entropy without putting itself at risk if one of them is backdoored.

There's a difference between fearing that something is backdoored, and thinking that it's not a good policy not to blindly trust something.

<comment><USER12> Not sure if I'm reading the code correctly, but it seems like it mixes the hardware random bits with the output of what would be generated otherwise. I.e., Linux does not add the the RDRAND output to the entropy pool.

This means it might take more time to generate the required number of random bits. So not trusting RDRAND means a process might block waiting for random data.

Then again, hardware generators may be affected by external forces - <USER2> than the NSA. For example, CPU temperature.

<comment><USER11> Yes, that's right, the kernel doesn't add it to the entropy pool. RDRAND is a cryptographically secure pseudo-random number generator, it doesn't give you direct access to the full entropy of the hardware random number generator (that is planned with the RDSEED instruction, which isn't shipping yet[1]). RDRAND re-seeds a CSPRNG periodically with its hardware RNG, but it's not appropriate to feed directly in as the seed of another CSPRNG like Linux's /dev/random. Intel does provide a suggestion for how to ensure that it gets reseeded, so you can ensure you have seed-grade entropy in their software implementation guide[2]; it involves either calling it 1022 times, or running it 32 times with a 10 μs wait per iteration.

In Linux, there's a user-space deamon, rngd, that's responsible for mixing hardware random number generator entropy into the entropy pool. That's a more appropriate place to put the logic for adding entropy from RDRAND into the entropy pool; you probably don't want to be doing those 1022 iterations or 32 iterations with a sleep in between in the kernel itself.

The kernel just uses it as a parallel CSPRNG along with its own built in one. It runs its own, and RDRAND, and xors the results together. This allows it to get fast, good random numbers (which are important early in the boot sequence, for things like ASLR) even if its own entropy pool does not have very good entropy yet. This makes its random number generation at least as good as the stronger of RDRAND and the kernel's own CSPRNG. It does mean that if RDRAND (or some other processor's similar instruction, once other processors add it; it would be quite valuable on ARM and MIPS as embedded machines tend not to have very good entropy sources) is backdoored, _and_ the kernel entropy pool has insufficient entropy, it may be possible for someone with knowledge of the backdoor to crack it, with a difficulty equal to the amount of entropy that the Linux entropy pool has. However, this is only true if you are using the non-blocking random number source, which tends to be used by things that need fast random numbers but don't need particularly good seed-grade entropy, like ASLR. If you need high-quality entropy, just use /dev/random and it will block until you have enough entropy to satisfy your request.

[1]: [http://software.intel.com/en-us/blogs/2012/11/17/the- differe...](http://software.intel.com/en-us/blogs/2012/11/17/the-difference- between-rdrand-and-rdseed) [2]: [http://software.intel.com/en- us/articles/intel-digital-rando...](http://software.intel.com/en- us/articles/intel-digital-random-number-generator-drng-software- implementation-guide)

</comment></comment></comment></comment></comment><comment><USER13> I feel there is some relevance to the images in the article that I don't understand..

<comment><USER14> Yes, that first disney image left me confused and slightly uncomfortable! Hovering over it give an indication though, the tooltip says "so random!".

Of course the other images mostly make sense, but it would have been informative to have captions on some of them, such as the the second image, which has alt-text of "the three".

</comment></comment><comment><USER15> who are the other two in the photo? [http://blog.cloudflare.com/static/images/vonneumann.jpg](http://blog.cloudflare.com/static/images/vonneumann.jpg)

(von neumann is on the left, i think?)

<comment><AUTHOR> Feynman and Ulam.

I liked that photo because there's von Neumann who I referenced, Ulam because of the Monte Carlo method ([https://en.wikipedia.org/wiki/Stanislaw_Ulam#Monte_Carlo_met...](https://en.wikipedia.org/wiki/Stanislaw_Ulam#Monte_Carlo_method)) and Feynman because, well, Feynman's cool.

</comment></comment><comment><USER16> Why not use a quantum random number generator? It is truly random, and ones based on photon path output bits.

</comment><comment><USER17> <meta> I didn't expect such a bright topcolor!</comment>


Techiest Super Bowl ever: Silicon Valley's stadium girds for the big game - <AUTHOR> http://www.cnet.com/news/levis-stadium-tech-tour/ <comment><USER2> Too bad the design geniuses forgot that the Sun sets in the West, meaning that the majority of seats are looking into the Sun for entire day games... and given the complete lack of cover, those fans bake (not in the 420 sense of the word) to a degree that sends them fleeing into the shaded concourse during much of August-October games and other day events.

This is why seats on the suite side of the bowl were in such high demand. Out of 90+ seat allocations between myself and peers that I know, not one of us got an allocation out of the sun.</comment>


Web-based clone of Apple's Airdrop built as Progressive Polymer App using WebRTC - <AUTHOR> http://thenextweb.com/insider/2015/12/27/snapdrop-is-a-handy-web-based-replacement-for-apples-fiddly-airdrop-file-transfer-tool/ <comment><USER2> Just posted on RTC.News: [http://www.rtc.news/posts/XmdjfGSergLgKMYEK/capira42-web- bas...](http://www.rtc.news/posts/XmdjfGSergLgKMYEK/capira42-web-based-clone- of-apple-s-airdrop-built-as)</comment>


Jehovah's Witnesses App Garners over 9 thousand 5 star reviews in just one day - <AUTHOR> https://itunes.apple.com/us/app/jw-library/id672417831?mt=8

<comment><USER2> Slight exaggeration: according to iTunes, it has 552 5-star reviews at present. [http://imgur.com/dGDk3CG](http://imgur.com/dGDk3CG)</comment>


Idiomatic Redux: The Tao of Redux, Part 2 – Practice and Philosophy - <AUTHOR> http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ <comment><USER2> Very excellent writeup of some tricky concepts. Nothing in here is terribly new (or, I would even argue, particularly controversial among those familiar with Redux), but until now it has mainly been available through a combination of Twitter threads, Reddit comments, StackOverflow answers, and Gists. I was fortunate enough to have followed Redux from the initial talk releasing it and was able to discover and parse these in real time, but for new users attempting to get up to speed, that's not viable.

To have a pair of documents that consolidates all of the ideas that have trickled out regarding Redux from creators, maintainers, and others who "get" the concepts is absolutely fantastic. Kudos, Mark.</comment>


Manhattanhenge  - <AUTHOR> http://www.haydenplanetarium.org/resources/starstruck/manhattanhenge <comment><USER2> "What will future civilizations think of Manhattan Island when they dig it up and find a carefully laid out network of streets and avenues? Surely the grid would be presumed to have astronomical significance, just as we have found for the pre-historic circle of large vertical rocks known as Stonehenge, in the Salisbury Plain of England. For Stonehenge, the special day is the summer solstice, when the Sun rises in perfect alignment with several of the stones, signaling the change of season."

No, if they notice this they'll go: "Any grid on the Earth's surface has the same effect, it's just question of the angle" and then they'll be quiet about it. Stonehenge is interesting because its alignment is specific to the solstice so anyone digging it up can see that it was built for a purpose. Manhattan on the other hand doesn't seem to have any specific purpose from an astronomical perspective and if you look at the shape of the island you'll see that the avenues were built parallel to the long 'sides' of it. So, I hope future people will be sensible and not start looking for some astronomical significance to Manhattan.

<comment><USER3> Tyson has enough street-cred as a skeptic

<http://www.skepticality.com/neil-degrasse-tyson/>

that I'm sure his tongue is firmly in his cheek when he writes of future civilizations speculating on cultural reasons for Manhattan's grid alignment.

By the way, I especially like the last paragraph of the submitted post, which assumes a readership mostly in the temperate zone of the Northern Hemisphere: "While we are on the subject, when viewed from all latitudes north of the Tropic of Cancer (23.5 degrees north latitude), the Sun always rises at an angle up and to the right, and sets and an angle down and to the right. That's how you can spot a faked sunrise in a movie: it moves up and to the left. Filmmakers are not typically awake in the morning hours to film an actual sunrise, so they film a sunset instead, and then time-reverse it, thinking nobody will notice."

<comment><USER4> Any examples of this on YouTube? What movies have sunrise scenes long enough to see sun motion?

<comment><USER5> Plenty of movies have time-lapsed scenes of the sun going up and coming down. Vampire movies are a notable example, because of the significance of the sun. I'm pretty sure "Blade" had a couple of examples.

Films featuring people trapped and forced to survive in the desert are probably also good candidates. And some romances where the couple watch the sun set on a beach, or possibly watch it rise having had that "first talk" all through the night.

</comment></comment></comment></comment><comment><USER6> See also the poster and concept of the same name by artist Heidi Neilson (2009): <http://www.heidineilson.com/manhattanhenge.php>

</comment><comment><USER7> As an interesting aside -- I visited Ireland last year and became aware of this place: <http://en.wikipedia.org/wiki/Newgrange>

Possibly the oldest 'intact' human built structure in the world. Much older than stonehenge or the Pyramids.

<comment><USER8> FYI it appears these are older: <http://en.wikipedia.org/wiki/Megalithic_Temples_of_Malta>

<comment><USER7> Thanks.

Although now I'm in the wikipedia rabbit hole -- looking at fascinating places like this <http://en.wikipedia.org/wiki/Knap_of_Howar> (potentially older than those Malta temples) and most of the other sites on this: [http://en.wikipedia.org/wiki/List_of_the_oldest_buildings_in...](http://en.wikipedia.org/wiki/List_of_the_oldest_buildings_in_the_world)

</comment></comment></comment><comment><USER9> Obligatory MIT version: MITHenge. <http://web.mit.edu/planning/www/mithenge.html>

</comment><comment><USER10> This is fantastic. For most people, this type of stuff goes unnoticed. However this is great. I think we should start compiling a list of similar alignments around the world?

<comment><USER11> Such as the alleged alignment of the Box Tunnel on Brunel's birthday? <http://en.wikipedia.org/wiki/Box_Tunnel#Brunel.27s_birthday>

</comment></comment><comment><USER12> The difference is that I'm sure that Manhattan is well documented. Where Stonehenge is not.

<comment><USER13> It depends on how much of that documentation will survive.

</comment></comment><comment><USER14> All I see is myself squinting painfully trying to see ahead and not crash.

</comment><comment><USER15> "Future anthropologists might conclude that, via the Sun, the people who called themselves Americans worshiped War and Baseball."

It may not be via the sun but I'm afraid for those of us looking in from outside the fishbowl, the vast majority of Americans indeed worship War and Baseball.

<comment><USER16> s/Baseball/Football/

<comment><USER5> For those of us looking in, we already have a game called football, so s/Baseball/American Football/

<comment><USER16> Fair point. I debated using that phrase to be more technically correct. I opted for brevity at the expense of accuracy.

<comment><USER17> You were still perfectly correct. The name of the sport is "football." If you call it an apple and they say, "no, it's a green apple," then you're not wrong; they're just pedantic.

<comment><USER5> For "those of us looking in" (see parent^5, which this thread is about) it's not just pedantry but a necessary distinction. Although your game's True Name might very well be "football", to all of the rest of us "football" means Association Football (soccer). If you say "football", we'll instinctively think "soccer".

Every. Single. Time.

Sometime's we'll double-take, realise it's an American talking, and they probably actually mean "American Football". But it's not what we think of first, and if we're not sure if it's an American speaking (like you can't on the internet) then it may well not occur to us.

<comment><USER17> 2 more parents up, the topic is about what Americans worship. The context made it obvious which was being referred to.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> To those so socially stagnant to not realize that Neil deGrasse Tyson wrote this for a broader audience, and who feel an intense need to "correct" him regarding details about Stonehenge: grow up.

<comment><USER19> Top comment is basically saying, "your joke is lame, and this devalues the significance of Stonehenge." Some of the "wider audience", who may or may not be familiar with Stonehenge's properties, may in fact conclude, "so Stonehenge is basically BS like this?"

It's a bit of an over-wrought setup for what is basically a tip on when to get the sun just right for a nice photo in Manhattan. Still appreciate the tip, though. The setup is no doubt amusing to some and not others. I feel like for this kind of thing, both camps' opinions are perfectly valid, since it's a matter of personal preference. And that the "negative" opinion was expressed in a HN thread is... not surprising in the least.</comment></comment>


Google's new favicon - <AUTHOR> https://www.google.com/favicon.ico

<comment><USER2> i think the simple it looks the better, i am not sure if google just found out that facebook had a more appealing favicon look and decided to get back to basics.

</comment><comment><USER3> looks better than the previous multi color favicon</comment>


The year in post-quantum crypto [video] - <AUTHOR> https://media.ccc.de/v/35c3-9926-the_year_in_post-quantum_crypto <comment><USER2> The Slide of this talk:

[https://fahrplan.events.ccc.de/congress/2018/Fahrplan/system...](https://fahrplan.events.ccc.de/congress/2018/Fahrplan/system/event_attachments/attachments/000/003/695/original/slides.pdf)

</comment><comment><USER3> Last time I asked what is largest integer factorised using quantum computer. There are multiple answers depending on the algorithm, but for the one that can scale into cryptographic levels, the answer is 21.

<comment><USER4> _High-fidelity adiabatic quantum computation using the intrinsic Hamiltonian of a spin system: Application to the experimental factorization of 291311_

[https://arxiv.org/abs/1706.08061](https://arxiv.org/abs/1706.08061)

<comment><USER3> This algorithm doesn't scale to crypto levels.

</comment></comment></comment><comment><USER5> Terabyte priv/pub keys, "we are the leading pq lattice based implementation", broken implementations, attack scripts. I have the feeling a lot of submissions are the result of pressure on academia to publish...

<comment><USER6> While likely right, that particular entry was more a comedy submission by djb himself, no one is taking pqRSA seriously, the merging of the sig/encryption versions too was itself hilarious and a subtle metajoke about how big the competition is. There's plenty on the line here and govts know it, there's a little bit of a lottery feeling associated with it all.

I do like their honesty about people going after easy targets. The real goal here is breaking some of the big contenders and hopefully more people have a crack.

SIKE and NTRU needs some serious attention/money/cred associated with breaking it

<comment><USER7> The danger is that people, like me, will have literally no idea that this is a "comedy submission". I mean, I know that djb is well-respected in his field and so as an interested layperson I would tend to assume that anything that looks serious is serious. In fact, I did just that when I tried to read the pqRSA paper...

<comment><USER8> Why is that a danger?

<comment><USER9> They might decide to use it, or push for its use in some product. Obviously it's an extreme example, but stuff like that does happen (not that I think cryptographers shouldn't have fun).

<comment><USER8> You don't think that anyone who would non-ironically implement this paper would do just as much damage with every reasonable cryptography paper?</comment></comment></comment></comment></comment></comment>


2008 AWS Start-Up Tour - <AUTHOR> http://aws.typepad.com/aws/2008/08/2008-aws-start.html <comment><USER2> Are any YCers going to the Seattle event? I'm planning on driving down from Vancouver.

</comment><comment><USER3> Anyone going to the LA event?</comment>


No North America in country select - <AUTHOR> http://secret.lgmobile.com/

<comment><AUTHOR> I mean, really....

How hard could it have been to have the label on the far right say "Americas" instead of "Latin America" and just include Canada, the U.S., Greenland, and Iceland in the list?</comment>


Are Indian Programmers not Programmers but just coders? - <AUTHOR> http://brajeshwar.com/2007/are-you-a-programmer-or-a-coder/ <comment><USER2> This post is from 2007. And things have changed drastically since then.

Ok, I am from Bangalore. And let me tell you. Technical skills are in heavy demand now.

To understand what the problem actually is. You need to understand this. Just like the web boom in US, there was an IT boom in India. IT companies witnessed a 100% year on year growth. Their workforce head count was doubling every year. And they really had no other option but to hire people from every engineering back ground. They were forced to promote people regardless whether or not they deserved it.

People became managers within 5-6 years of joining industry. And that is when the meme spread _"Being a programmer doesn't help in IT you have to be a manager"_. We are long past those days now.

The growth has stabilized and I would rather say its completely normalized now. Companies are no longer feeling the need to promote people rapidly. In fact they now have a excess bench strength of managers. And many of them did get laid off in the past few years. Word has it that its going to very difficult for the managers from now on. As they bring little value to the table.

On the other hand the Indian IT industry is plagued by the disease of Job hopping. Absolute utter idiots who can't write a 10 line script now hop every year pocket a 30% raise get a promotion. You will see people who never wrote probably 1000 lines of code are now architects.

Given the scenario the operational efficiency of big IT companies has fallen like a pack of leaves. They are not taking high risk premium projects anymore. As they simply don't have the kind of good people to execute them.

The demand for good people is growing by the day. Most of them I know work at start up's or product firms or they are into consulting/freelancing. There is a lot of money there and there are a lot of tough good problems to be solved.

IT Industry in India is pretty much alive and rewarding, except that those rewards are no longer in big companies. They are else where. And hey, there is a lot of money being a programmer. More than managerial jobs.

You just have to come out of the big IT giants and get into smaller places.

</comment><comment><USER3> I am not sure if the post was troll bait or not. Denying the possibility of truth within the massive generalization in the topic wouldn't be best idea, having said that one has too look at companies like Gluster [Acquired by RedHat] and InMobi to look at some high technology being produced from this part of the world. Given the population of India, there are actually more english speaking people over here than the whole of Britain, similarly even a high number of brilliant programmers would get drowned the chorus of massive coders working for huge outsourcing firms. Since you come from India itself as your blog suggest, and are from computer science related field, and hence would be very well verse with what I have mentioned above, I find digging a five year old post, combining with the topic headline 'Are Indian Programmers not Programmers but just Coders' not in the very best spirits.

<comment><USER4> InMobi is not high technology. It is just another Ad Platform you can buy and install off the shelf. Their business skills can be considered "high".

<comment><USER3> It would be nice to have a look at the ads they server per second. I am coming from the perspective that saying Facebook isn't high technology cause it is merely a social network, would be highly inaccurate. Working at such scale requires its own set of challenges.

</comment></comment></comment><comment><USER5> The post might be old and filled with link bait content.But it has a few valid points. Big companies like TCS, Infosys etc, are destroying the lives of thousands of software engineers. I used to work in TCS about 3 years ago and I knew a guy who had done his Masters from IIT (which has the brightest minds in India). He was hired from IIT for a good pay and he was put on a maintenance project for GE. It was a dumb job where he used to monitor some stuff and call up the responsible guys if he saw something wrong. And he was a mechanical engineer.

So, TCS effectively took a guy who might have done a lot of good in the mechanical field and just wasted him. I am really pained by things like these.

</comment><comment><USER6> I'm from BITS Pilani (yeah, yeah, the BITS and IIT rivalry, yada yada) and we tactically try to keep these companies off the placement process as well.

I'm just glad that there's someone who does see the difference and is willing to talk about it.

<comment><USER2> Which all companies will you try to keep out?

Nearly every big company is plagued by these problems. The problem is even if they take you through tough algo and DS quizzes(Which are irrelevant anyways) most of the work is maintenance.

Whether you do that work in a product company or a outsourced firm. It makes little difference.

This is more of a large company problem, this is not a problem restricted only to outsourcing firms.

<comment><USER6> Where I work now, I do a lot of engineering. By that I would mean designing non-trivial stuff and using technology best suited for the job. (E.g. for async stuff we are using node.js.) Whereas what I would do at these "outsourcing" companies is be forced to work on the MS stack and do basic store in DB, retrive from DB and update the DB stuff. CRUD with no real optimization. The only "optimization" these places offer are not writing bad SQL.

<comment><USER7> or worse, maintenance. I've known guys who's only job is to eyeball a system and if there are any problems, then call up the developer in the US.</comment></comment></comment></comment>


U.S. Oil Production Is 23 Years Ahead of Schedule - <AUTHOR> https://www.bloomberg.com/news/articles/2019-01-24/u-s-oil-production-is-only-23-years-ahead-of-schedule-eia-says <comment><USER2> Wow, if you told me just 10 years ago the US would become a net exporter of petroleum, I'd have laughed at you. The long-term prospects of oil in the US are poor, however. In the next 2-3 decades, renewables and electric cars will start exerting significant downward pressure on prices. US producers, especially frackers, are high-cost. Fracked oil usually costs $50/barrel or more. For this reason, fracking has only become widespread in the last decade, despite the fact that fracking has was invented in 1947.

Saudi makes oil for less than $10 a barrel. They and other low-cost producers are the only ones that will be able to compete after significant demand destruction occurs.

<comment><USER3> Break even prices for the Permian basin:

[https://bioage.typepad.com/.a/6a00d8341c4fbe53ef022ad3566378...](https://bioage.typepad.com/.a/6a00d8341c4fbe53ef022ad3566378200c-popup)

Some of them are in the low $20s.

On the other hand, Saudi Arabia needs oil to be >$80 in order to balance its budget: [https://www.reuters.com/article/us-saudi-arabia-imf/saudi- ar...](https://www.reuters.com/article/us-saudi-arabia-imf/saudi-arabia-needs- oil-at-85-87-a-barrel-to-balance-budget-imf-official-idUSKBN1I30H7)

<comment><USER4> The main issue with shale oil is that many (most?) refineries in the US can't refine it, so it _has_ to be exported, basically. Whereas Saudi oil is "sweet" and pretty easy to refine.

<comment><USER5> That's patently untrue. Saudi crude is primarily heavy or medium and sour (high in sulfur), the complete opposite of what you're saying.

</comment></comment></comment></comment><comment><USER6> People who are curious how we got to this state should read The Prize and The Game by Daniel Yergin. Pretty much all modern oil politics is explained in those two books (the latter covers more energy more generally).

Interesting especially since the first oil production occurred in the US and we played a big role in funding many of the big producers.

</comment><comment><USER7> US mideast policy had been affected for the as long as I can remember by oil and weapons exports. Especially on oil in the 80's with the Oil Shortages[1]. After 2015 congress voted to remove restrictions on Oil production in the US and the boom began. Now that US policy is largely only about the weapons export will we see a different/better middle east situation in the next 25-30 years?

[1][https://en.wikipedia.org/wiki/1970s_energy_crisis](https://en.wikipedia.org/wiki/1970s_energy_crisis)

<comment><USER8> According to wikipedia: "Since the 1990s, the [US] oil market has been free of most regulations."[1] My understanding was that the US oil boom was caused by technological advances that enabled better exploitation of shale oil deposits. Also according to this graph[2], the boom really starts around 2011-2012, not 2015.

[1] [https://en.wikipedia.org/wiki/Petroleum_in_the_United_States...](https://en.wikipedia.org/wiki/Petroleum_in_the_United_States#cite_note- Energy_Regulations-29) [2] [https://en.wikipedia.org/wiki/Petroleum_in_the_United_States...](https://en.wikipedia.org/wiki/Petroleum_in_the_United_States#/media/File:Monthly_U.S._field_production_of_crude_oil_\(January_1920-August_2018\)_\(45664259591\).png)

<comment><USER9> I think the above poster, itissid, was referring to the US domestic oil export ban which was lifted at the end of 2015.

</comment></comment></comment><comment><USER10> And we only have a decade left to save the planet. Time to stop extracting fossil fuels and emitting ancient carbon into the atmosphere.

<comment><USER11> ... And go back to the stone ages.

Fundamentally, there's nothing wrong with burning oil. There are certain applications where it will continue to be the best energy choice.

More important is (a) taxing oil consumption to offset the negative environmental effects & (b) transitioning away from oil _where it makes sense_.

<comment><USER12> >More important is (a) taxing oil consumption to offset the negative environmental effects

And do what with the money raised with those taxes? I don't trust the people in charge to do what's needed to be done. The only positive thing from taxing oil consumption, would be to make it so expensive that people seek alternatives. When US gas prices were near $5/gallon, people sold their gas guzzlers and switched to fuel efficient choices. Once gas went back down, cars were sold off and guzzlers became the choice again. If Americans paid the similar prices to EU prices, things would be a lot different.

<comment><USER13> Usually, Pigouvian taxes like the one OP was proposing are calculated to cover the complete externalized costs of the item being taxed. So in this case, it would include the costs of adjusting to climate change. This would make alternatives relatively cheaper, as well as raising revenue to support research and construction of new energy infrastructure, as well as point addressing of specific projects identified to reduce the impacts of climate change. Of course, this is all if you believe that the current political climate (not only in the US, but in large middle income economies as well) can support such taxes. And then you have to decide what the tax should be! Ultimately, cap and trade turn out to be far easier.

<comment><USER14> one benefit of pigovian taxes is increased revenue to ameliorate the externality, but it's not the main goal of the tax. the cost itself reduces demand to the socially optimal level. the government could well burn the tax revenue (or in this case, recycle the paper) and still achieve the objectives of the tax.

</comment></comment></comment></comment></comment><comment><USER15> Keep it in the ground. Tax carbon heavily to pay for CCS.

</comment><comment><USER16> Anyone remember peak oil? What happened?

<comment><USER17> The same thing that always happens. People make extrapolations assuming that something will continue to grow at it's current rate. They forget that there are dynamic systems and feedback mechanisms at play.

"Ebola is spreading at an exponential rate. There will be 200 million deaths by next year."

"Soviet GDP is growing 10% per year. Their economy will be the largest in the world in 15 years."

"Japanese GDP is growing 7% per year. Their economy will be the largest in the world in 20 years."

"The world's population increases at 2% per year. We'll have 50 billion people in 2100."

<comment><USER18> And what do you have to say about those global average temperature charts?

<comment><USER17> Feedback loops aren't always negative, and even if there is a small chance for a positive feedback loop with respect to increasing temperatures, we should take action now and attempt to reduce carbon emissions.

I also think that if there is a reinforcing temperature feedback loop, this isn't likely to happen to happen fast enough--at least through behavior changes. So we should focus most of our resources on developing better methods of energy production, increasing energy efficiency, and developing technology/methods to mitigate the damage of rising temperatures to human civilization.

</comment></comment></comment></comment><comment><USER19> I assume due to fracking?

<comment><USER20> Shale, and higher prices leading to higher production.</comment></comment>


Encouraging a culture of written communication - <AUTHOR> https://www.mcls.io/blog/encouraging-a-culture-of-written-communication <comment><USER3> I love this topic! A couple of unconnected thoughts on it:

I think one thing that's needed to establish a culture of written communication is getting rid of any cultural elements that allow people to use the _avoidance_ of reading and writing as an expression of power. You can frequently determine the balance of power between any two people in an organization by seeing which one has to read and prepare organized documents and presentations, and which one can simply speak and be spoken to. People want to paint pictures of themselves as being able to synthesize knowledge and ideas instantly, utter commands in real time and see them turned into action. In the other direction, they have no time for reading - you must request an audience with them and survive their real-time verbal sparring and probing questions to have your ideas received and considered.

My other musing on this is that I've always wondered if there would be value in teams establishing an internship or low/mid level position for a technical writer to serve as a _team librarian_. "Easy to search" is good, but "search" itself is not sufficient for many situations - what you need is a person who can answer questions while taking context into account. If I was running a technical team, I'd love to experiment with hiring someone whose primary accountability is _answering everyone else 's questions_, not generating output. In the same way that a good dev needs to organize their workspace and build tools/scripts to be successful, this person will end up organizing the team's information to better accomplish their job.

<comment><USER4> I would _love_ to do this kind of work. Aside from a general passion for writing and editing, I enjoy describing problems, characterizing existing solutions' strengths and weaknesses, writing docs and user instructions, organizing information, etc. I'm a good enough developer to build useful tools and work with more senior engineers, and my favorite part of working in scientific research was being a force-multiplier and hindrance-destroyer so subject-matter experts could focus on using their skills.

If anyone reading this is in a position to hire for a "technical writer/librarian/secretary/developer assistant," click my username and send me an email. We can try a short-term contract and see how it goes.

<comment><USER5> I don't know if you've ever considered a position in pharma or biotech, but clinical research has a career like this called Clinical Trial Associate, and their entire job is to organize information, prepare instructions and documents for the research sites, organize and run the eTMF aka "Trial Master File" and other documentation tasks. Our CTAs start at 95k and make up to 125 for senior level. From there onwards you have a good career path of Clinical Trial Manager and leadership- might want to check into it.

<comment><USER4> I appreciate the tip. As it happens, my last full-time position was in clinical (computational linguistics) research.

I've definitely applied to positions similar to what you've described, but as cold applications, they went nowhere. If I decide to return to regular W2 employment, I'll be sure to keep an eye out.

</comment></comment></comment></comment><comment><USER6> Posts like this are published with regularity. And like all things that must be said again and again ("stay off the grass", "we're in this together"), we can assume the opposite somehow true: Most teams do not write much or do not write well.

What posts like this do not address is the root cause of the problem: Writing is hard. Why is it hard? And how can people learn to write better? Those would be worthy topics for a longer post, which are not addressed in this one.

Writing, like code, takes time to produce and consume. Like a product with friction in its onboarding, this decreases the likelihood that many people will ever reach the goal of writing clearly.

Unlike code, most people think they _can_ write. But the difference between writing, and writing clearly, is large.

Unlike code, almost everyone has been "taught" to write, often by teachers who themselves do not write well, or do not have time to truly teach them, so they have a lot of bad habits. These include a reliance on cliches, ambiguous diction, and poor organization. The first flaw makes the reader zone out, the second vastly increases the amount of time it takes to consume and respond to writing, since the feedback loop is delayed.

Personally, I do not believe that many people will ever learn to write well; I also don't think it's worthwhile to make them try. I think that organizations, in order share information well internally, should make certain people "writers" who get extract information from their colleagues and convey it to the team. They would be like the secretary in a meeting, but more ubiquitous. This would be part of their job description and KPIs and compensation.

<comment><USER7> _> Why is it hard?_

It is an incredible mental balancing act when you think about it. Your goal is to get some information into someone's head. To do that, you need to actually simulate _their_ brain using yours. You have to think about _how_ that person learns, what they already know, and how to incrementally build up your information in a way that makes sense to them. You have to think about what words and idioms they're familiar with, whether they learn top-down or bottom- up, etc.

In order to get into their mindset, you have to temporarily pretend to _not_ know the thing you are explaining. At the same time, you are explaining it, so you have to simultaneously hold that very same thing in the forefront of your mind.

Now consider that each potential reader learns differently and knows different things so when imagining your audience, you have to do the whole process above in parallel for a number of different imagined audiences.

Doing this well requires a lot of theory of mind skill, and that's something that I think a lot of technical people are not very good at. My experience is that a lot of people who are drawn to tech are that way because they've found it easier to get along with machines because machines "make sense" and are simpler, which to me points to less theory of mind ability.

<comment><USER8> great point. i don't generally buy the argument that coding is drastically different from writing, insofar as it's laying out symbols in a way that can be understood (and followed) by another actor. that's a technical skill that's fairly transferable between the two.

but it is drastically different in how it's interpreted by that other actor: computers are (designed to be) fairly rigid in interpretation (the frontier of that not being so is fascinating but in its infancy), so that there's little- to-no variance in the output. people are completely flexible in comparison. inputs can generate a wide range of outputs, and there's little control over that range within the writing itself. that seems to frustrate many coders.

even the purpose can vary. coding is generally imperative in nature: do what i tell you to do. writing is generally persuasive (here's what i think, why i think it, and why you should think it too), since it's hard to force the imperative.

writing is necessarily harder than coding, because the target has so much greater complexity.

<comment><USER9> > i don't generally buy the argument that coding is drastically different from > writing, insofar as it's laying out symbols in a way that can be understood > (and followed) by another actor. that's a technical skill that's fairly > transferable between the two

That's a great observation. A bit of a tangent, but I enjoy writing code with a tight feedback loop. Either with a debugger, a set of unit tests.

With writing, the feedback loop is not there. It's not clear whether the message achieves the desired effect.

Framing writing this way, explains why it's such a challenging activity. At least in my mind.

<comment><USER10> If you write code intending it to have good human readability - and you _really_ should - you have the same problem writing code.

I spend a lot of time rereading my code imagining I'm someone else who's never seen it before. Not sure everyone does.

</comment></comment></comment></comment></comment><comment><USER11> Related challenge: encouraging a culture of reading.

I've invested a great deal of effort in writing documents in the past only to realize that very few co-workers were taking the time to read what I'd written.

There are workarounds for this. The most famous I can think of is the Amazon culture where each meeting starts with 10 minutes of quiet reading, to ensure everyone is on the same page.

I imagine it's part of a writing culture though. Once people understand that an organization values writing, they'll take the time to read.

<comment><USER12> > The most famous I can think of is the Amazon culture where each meeting > starts with 10 minutes of quiet reading, to ensure everyone is on the same > page.

As an American, I've never heard of this, and can't even imagine it.

<comment><USER13> It's not like, 100% adopted at literally every single meeting, but it's pretty common across Amazon. Some orgs will do it more religiously than others, but no org will look at you funny if you request for a 5-10 min doc read before you start the rest of the meeting.

<comment><USER14> (Never worked for Amazon)

Is it literally a quiet-read time where everyone just sits there silently reading a shared doc? Or is it what Ive seen happen in a lot of companies where someone projects the doc, and walks through it, reading/summarizing it aloud to attendees. I like to call that activity "executive storytime", since it's often underlings reading status reports to execs.

<comment><USER13> As the other poster said, it's meant to be silent reading time.

Some reasons why (loosely paraphrasing internal guidance on how to run meetings and why writing culture matters):

\- PowerPoints are lazy/evil, and not good formats for conveying complex ideas; by nature, PPT's encourage shallow thinking, and is thus antithetical to the goal of having rigorous analysis/deep-thinking in making complex tech/business decisions

\- Docs should stand on their own, without needing to be presented or walked- through by a person; forcing you to explain your ideas and support them in such a way that any sufficiently motivated reader can follow along and work out what they mean on their own, is again a way to encourage you to be rigorous and thorough (but limiting you to 6-pager format, for brevity)

\- Writing long-form paragraphs and full sentences forces you to take time to refine your ideas

\- Forcing people to take time to digest the doc first, gives everyone a chance to take notes and formulate ideas/responses to the info/arguments presented; this saves a lot of time as compared to, walking through a doc/slides for the first time, and having a roomful of people encounter those ideas for the first time and to ask questions in real time as they encounter them... reading the doc should hopefully already address the most common questions/critiques, and so you can spend more time on 2nd/3rd-order more advanced decisions or arguments

</comment></comment></comment></comment></comment><comment><USER15> > As much as possible, encourage people to post anything of interest to the > public channels. Notice that I'm saying public channels, and not private > messages, because we don't ping anyone unless it's necessary. We just want > to make the information available.

This. Every time you send a private message is Slack or send an email to just one other person, it's like taking a $100 bill and lighting it on fire.

Just because only one other person needs that information right now doesn't mean that in a couple years some new hire won't spend six months just staring at their monitor and not writing code because they can't figure out wtf is going on.

<comment><USER16> > Every time you send a private message is Slack or send an email to just one > other person, it's like taking a $100 bill and lighting it on fire.

Maybe, but with a public channel, it's a stack of $100 bills, for the time of everyone who doesn't need it now and won't recall it or be able to find it when they do.

"Spam everything to the public channel" is the equivalent of "send everything you find interesting to the All Staff email distribution list".

There's good ways of preserving information that multiple people on a team are going to need at different points of time in the future, but posting them to a public Slack channel is pretty far from the target.

A team wiki is among the many better options.

<comment><USER15> > A team wiki is among the many better options.

Wikis are generally useless unless you have people whose job responsibilities explicitly include creating content for them and keeping them up-to-date. In my experience, if you have your PMs do this then each PM can cover 8 - <USER2> developers. Whereas if your PMs are just creating and pointing tickets but not also spending a good percentage of their time on longterm documentation, they can cover more like 12 - 16 developers.

Well maintained wikis are fantastic, but you almost never find them because for even a mid-size startup that costs hundreds of thousands or millions of dollars per year. That's the reason for public mailing lists and other email archival products, because you're getting _most_ of the value a well- maintained wiki but with mainly only the nominal cost of paying for the software to keep it running.

I've thought a lot about this (obviously, given FWD:Everyone is in this space), and figured out the actual reason why email is so much better than Slack for knowledge retention; it's because with email you're forced to create the metadata before having the discussion, and then the discussion keeps going until people no longer have anything to say that matches the metadata -- subject, participants, visibility level, etc. (Discussions occasionally go off the rails, but less than 5% of the time as long as the organization provides some basic guidance on expectations for communication.) This metadata is key though because not only does it help you find what you need to do your job, but it helps you figure out what you don't need to read, which is perhaps even more important.

Whereas with Slack you just start talking, and their software tries to figure out what you were talking about after the fact. But despite having an AI team working on this and having invested millions and millions of dollars into the problem, their software doesn't really work at all, most likely because the problem is basically impossible to do a good job of solving from a computer science perspective.

edit: Obligatory self-promotional link: [https://www.fwdeveryone.com](https://www.fwdeveryone.com)

<comment><USER17> Years ago I tried implementing a wiki at work as a knowledge base. While the user base remained reserved to select members of the team, everything was great. But the success of the wiki then became an invitation to the rest of the company. And soon knuckleheads were simply uploading Word documents to the wiki. So, instead of getting transparent, searchable content, we reverted to /index.html, circa 1992.

</comment></comment></comment></comment><comment><USER18> GitLab team member here. Written communication is vital in a remote company, and makes all types of companies operate more transparently and efficiently.

At GitLab, we don't just document to document. Instead, we recommend a "handbook-first" approach, which we outline here in our public handbook: [https://about.gitlab.com/company/culture/all- remote/handbook...](https://about.gitlab.com/company/culture/all- remote/handbook-first-documentation/)

We're also articulate about what we expect in terms of writing style guidelines, part of our Communications handbook: [https://about.gitlab.com/handbook/communication/#writing- sty...](https://about.gitlab.com/handbook/communication/#writing-style- guidelines)

<comment><USER19> This is a great resource! I hope I can convince my team to implement something similar.

I see that the handbook is mostly focused on company level procedures and "What we do". Doe GitLab folow similar principles for documenting code? E.g. Update the documentation for the design before writing code?

<comment><USER20> Not yet, I'm advocating that our issues for new features should read like the eventual text in the release post.

</comment></comment></comment><comment><USER21> In the software industry, these are several problems that prevent the success of written communication culture:

\- Most of the dev are not trained for that. They're trained for finding shortcuts (Google, SO), rushing the deadline and fix the code with any solution they can find. People tend to follow the easy path (fix and forget) rather take time to write good docs (code comment, commit message, wiki, ...)

\- Some people have good writing skills, some have good technical skills. The ones who are good at both are rare. So some time the docs are confusing, misleading.

\- We're lacking good tooling for writing docs. At my work, people prefer to write on Confluence for its inline-comment feature (before, they write in Google docs). But Confluence (and Google docs), IMO, are terrible editors for technical heavy docs and they can't work offline, don't have desktop, can't be used with external editor (I'm a die hard vim fan). Another example: tools for drawing diagram. The plain text solutions (PlainUML, mermaid) I've tried so far don't work well for big diagrams. The non plain text solutions can't be tracked in git, thus defeat the point of single source trust.

I believe if someone can build a product solve my points on tooling, their product will beat Confluence easily. I don't have any ideas to fix the other 2 points, though.

<comment><USER22> > Some people have good writing skills, some have good technical skills. The > ones who are good at both are rare.

In my experience this is not the case: good programmers are typically good writers. I think it's due to clarity of organization and of understanding "the problem to be solved"

<comment><USER21> I got the opposite experience. People with good technical skills often write dense, skip explaination of topics that they find easy to grasp, assuming the reader also find them easy (which usually is not the case).

<comment><USER23> I used to do this too - write dense essays and documentation that took forever to read. Then I took a class on business writing at my local university. It was well worth the time. It helped me focus on writing short, terse language that was simple and quick for the reader. If your organization does struggle with producing easy, well written communications I would highly encourage considering they enroll in some sort of 12-week long course with an experienced instructor who can provide direct feedback.

</comment></comment></comment></comment><comment><USER24> I work in a team with some people who are dyslexic. I've noticed they don't communicate over written communication as much as some others, even preferring to create voice recordings or videos to share their thoughts. I definitely prefer written communication, but I think neurodiversity is one reason it's tough to make it a policy.

<comment><USER25> This is a very good point. There seem to be a non-trivial number of dyslexic engineers out there (I've worked with at least 3-4 over my career), and they struggle a lot to write - although they'll hide it out of cultural taboo. They tend to have excellent verbal communication skills though and seem to handle coding perfectly fine - one of them being one of the best engineers/mathematicians I've worked with. I wonder how we can better accommodate it, especially in a remote environment.

<comment><USER23> > I wonder how we can better accommodate it, especially in a remote > environment.

Perhaps improving speech-to-text programs will help a lot? Maybe they can record what they want to document in a lecture-style way. Give them a white board or paper, set them up with a good microphone, and get a program that records their voice to a video / mp3 file. Then process their lecture through a speech-to-text program and have another team member format it to match the wiki. That way all the other team members are doing is light editing of an existing document.

Now that doesn't fix the issue of the dyslexic team member having trouble reading. Maybe they can use screen readers like JAWS to quickly have knowledge bases read to them? That way it is no different than an in-person phone call?

</comment></comment></comment><comment><USER26> Be aware that going towards a document heavy culture doesn't make the smarmy types any less smarmy, it just changes how it is manifested.

You'll still have those who use the "can we get on a call and discuss" trick so that no decision or todo item for them is seen in a public channel.

There will be those why try to kill a conversation in a channel by replying in a thread.

Often you'll see the thread reply too when its the poor employees answering a question hours/days later and then they'll point to it as giving $teammate all the info they need.

And the ever-present "oh, its in the wiki/knowledgebase/faq/whatever" but links are never sent, nor is anything ever actually there.

All in all it a different medium, but most of the same kind of team dysfunctions continue to exist just fine, and if anything it is tougher to spot them.

</comment><comment><USER27> > You should try to have a single source of truth as much as possible. If you > have many places where information can be found, it will affect both people > writing the documentation and those trying to find it. The writers will have > yet another blocker to just getting stuff written down. The readers won't > know where to look and will have to interrupt people in Slack, as opposed to > referring to the knowledge base themselves.

Agree x1000 with this point, with emphasis on the point about readers. The probability that someone will write down an important piece of information (and will do it well) is proportional to their perception of the benefit from doing so. If the would-be author thinks nobody would read it, they won't write it down in the first place. If they think team members will find it and read it 1,000 times in the next 3 months, then they're very likely to write it down.

> I believe it has to be easy for people to write a document without having to > worry too much about where to put it. Therefore, I believe it's better to > have a tool with good search functionality rather than investing in having a > perfect information architecture. In the latter case, we're putting up extra > roadblocks for the writer, because then they'll need to spend extra time > figuring out where to put their writing in the first place.

To make this work, I think you need to designate certain documents and locations as sources of truth. If any random Google Doc that someone drafts can be considered a source of truth, then gathering the "canonical" information about any topic ("what's all the customer feedback from Acme Corp?") becomes extremely difficult, especially to newer team members who haven't fully internalized the communication practices yet.

Here's our handbook page that describes what has worked for us (at Sourcegraph): [https://about.sourcegraph.com/handbook/communication#sources...](https://about.sourcegraph.com/handbook/communication#sources- of-truth). Only very specific Google Docs are sources of truth; all others are just ephemeral scratchpads.

<comment><USER28> > _a single source of truth_

Naturally, these have been called "bibles": Unix Bible, Linux Bible, Linux Command Line and Shell Scripting Bible, etc.

</comment></comment><comment><USER29> Here's what I did on my previous team to encourage writing and documenting while keeping the barrier low: use the internal/team blog feature in Confluence. I had a team of 5 so posting to that blog did not "spam" a lot of people, and you had to watch the "space" to get notifications at all.

I encouraged the team to write blog posts on anything they didn't know and took time to figure out, or if they stepped through a process for the first time that wasn't already documented, or ran into some dev VM issue that they fixed. Crucially, I made clear that a "blog post" could be as little as 1 paragraph and a code snippet, it didn't have to be big.

Blogging had the following advantages: 1. No need to think of "where to put this in the wiki" – just write it in the blog & if we decide to put it in wiki we can move it later 2. Blog posts naturally "go away" over time, so it's clear that something written a year ago might not be current 3. It was regular writing practice for everyone on the team 4. It allowed others on the team to learn from someone's experience & improved information sharing & collaboration 5. If I figured out how to solve some issue and someone else ran into it, I could say "go look at this blog post" 6\. When we had a new person join the team, during orientation I'd say "read the last 6 months of blog posts (might take an hour or two) and that helps them understand the team culture & norms _way faster_ than they would otherwise 7. It gave me (team lead) more visibility into what people were doing & allowed me to step in and help when appropriate. 8. It "forced" people to structure their thinking & clearly define the problem they were facing and the solution 9. It allowed people to "get credit for" work that might otherwise be invisible (e.g. spending a day debugging some webpack issue or researching options for an upcoming feature).

Over a year or so this became a major part of our team's practices, and there were countless times when someone on or off our team would say "how do I do X" or "why did you chose to do Y" and I'd say "good question! Go read this blog post."

Currently I have google suite instead of confluence and I seriously miss the blog feature. If someone knows a good, _small_ , private (not public but easy to share internally) "team blog" platform, let me know. (I tried blogger but sharing is a pain in the butt.)

<comment><USER30> What are the blog features you actually need?

If instead you used a wiki (e.g. MediaWiki), with the convention that all blog articles are prefixed by "YYYY-MM-DD USERNAME" and linked from the top of the "All Articles" page, what functionality you want would be missing?

<comment><USER29> Hm that sounds like a good solution. It's a bit more friction as I must ask people to make sure they follow a specific format (and don't forget to add it to the index page!!) rather than just clicking "new post" button and it doesn't have a "small team/space" feature like in Confluence, but it could work. These may seem like very small hurdles, but when you're asking people to do something they might not do on their own, every little bit of friction makes it less likely they'll actually do it, or more likely they'll be frustrated & resentful if you insist they do it.

I do like the date metadata & sorting from a blog like wordpress or confluence: automatic grouping by year, automatic ordering, as well as features like tags etc.

</comment></comment></comment><comment><USER31> At my fully remote startup we operate a variation of this that I think can feel less onerous than a culture of verbose written communication.

\- We create living documents / whiteboards on Miro (formally Realtime Board) that relate to the features we're working on. Things like pictures, architecture diagrams, draft db schemas. All at WIP stage.

\- When we need to create communications (like requests for comment, demos etc) we record a short video using Loom. The video usually centres round some area of the whiteboard or in the IDE.

\- We post this both on a notion page and in slack (using a public channel as to article suggests), tagging those that need to know or would find interesting. Keeping a long list of previous videos in notion helps find useful data later.

I think the low barrier to entry for recording video over the top of documentation thats "just good enough" to get the idea across has lead to universal uptake across our team. It's also easy to slot in reviewing these videos and responding during natural breaks in flow.

For more critical areas of the code / operations we document more formally towards the end of a feature development cycle.

<comment><USER32> I'm building a product that combines screencasting with git, so you can talk about code as you work and discover it in your git history. I like how you describe it as "over the top," I think the biggest advantage is that video can be created _while you code_ rather than writing which typically occurs _after I 'm done_. The product is in beta and you can sign up here:

[https://paircast.io](https://paircast.io)

<comment><USER33> That looks cool!

How does this compare to livecoding on a streaming platform?

<comment><USER32> It integrates with code. The transcript on the right side is a combination of git diffs and audio transcription which is generated from your cast. Each git diff automatically commits to your git repository so you can reference the video from your git history.

</comment></comment></comment></comment><comment><USER34> Prior to quarantine, I had never heard of the concept of async communication. It felt like a fancy way of just saying "document more". Now that my whole department is WFH we've tried using Notion as our central repository of information. I don't think it lands every single feature described in the write up (e.g. search could be better), but, it has enough features to create write-ups and RFCs that are visually appealing to help get the point across.

We still hop on a quick Zoom 1:1 if we can't find the words to discuss over text.

<comment><USER35> To build on this -- for me async communications means not having to jump on so many meetings, and being able to organize/prioritize/delay stuff to respond to and batch them.

Email is the quintessential async tool. Slack isn't really even that async -- people still expect quick responses (it somehow has that expectation built-in)

For individual contributors, sync meetings really disrupt the flow of the day. Worse are meetings that don't respect your time zone -- either too early in the morning or too late at night.

People don't realize how disruptive it is when someone says "let's jump on a call" for every single little thing. I much prefer them to just "send me an email".

Sometimes sync meetings are more efficient, especially for complex topics or on topics requiring a live demo -- but I find having a sync meeting after an email thread much more effective, because then folks have had a chance to engage with the material.

</comment></comment><comment><USER36> Awesome piece, thanks for sharing. I agree that the key to effective communication is to lower the barrier to writing things down.

In that vein, this piece is missing one thing. It is inherently easier to write something private than to write something shared.

Think of how often you jot things down in Apple Notes, Sublime, etc. as opposed to in your shared space with your team.

A culture of written communication starts with personal (un-shared) notes.

I'm one of the creators of bytebase.io, a notes app that helps people write low-friction, private notes and quickly share with teammates when relevant.

</comment><comment><USER37> I spent several years of my life reviewing corporate documents in an independent assurance role at a large company in the UK. The documents were a mix of bids and research reports intended for external use and internal docs associated with our sales/project process. I raised several concerns about our writing process to management and spent many long hours fixing docs at the last minute. But my concerns didn't get much traction with management.

One day, I discovered that our document identifier issuing system (yes, we had one!) could tell you how many docs had been registered by a particular teams in a given time period. This led me to the finding that our department created a new document something like every 58 minutes of a working year! We weren't a software project group, we were in fact a document authoring function that also emitted software and research as a side effect. That observation got some traction with management, and I was funded to develop some how-to-write guidelines for document authors. Bid teams were particularly interested because the cost of document production in bid development often fell directly to the company, not to the eventual customers.

In addition to providing a basic 'house' style for authors, the guidelines also highlighted the importance of easy-to-use doc templates and training for lead authors (e.g. those collating docs produced by multiple people, sometimes by sub-contractors).

</comment><comment><USER38> > As much as possible, encourage people to post anything of interest to the > public channels. Notice that I'm saying public channels, and not private > messages, because we don't ping anyone unless it's necessary. We just want > to make the information available.

That makes it technically available, but also less accessible than a paper Encyclopedia Britannica. Are people actually going to try and search through the Slack channel for a solution or are they going to continue asking their co-worker in a private chat?

</comment><comment><USER39> > Therefore, I believe it's better to have a tool with good search > functionality rather than investing in having a perfect information > architecture. In the latter case, we're putting up extra roadblocks for the > writer, because then they'll need to spend extra time figuring out where to > put their writing in the first place.

This is exactly the reason why we build Emvi [1]. I've worked with a lot of different tools and none of them really encouraged people to write stuff down. Not because they weren't easy to get started with, or the editor was bad. I feel lost in a big hierarchical structure and was unsure where to put things. I always had to ask someone where to put a new article or where to find an existing piece of information. So a powerful search and focus on writing instead of organizing folders helps a lot. It still requires discipline and if you want a team to write down as much as possible, you need to build the culture. But if you don't feel you're doing something "wrong" in the first place lowers the barrier. Once you have reached the critical mass of articles and put some tags on them, you will start to see connections automatically. Emvi allows you connect everything via mentions (start typing an @).

Check out our upcoming user interface [2], it will take this approach even futher.

[1] [https://emvi.com/](https://emvi.com/)

[2] [https://emvi.com/blog/a-new-experimental-user-interface- QMZg...](https://emvi.com/blog/a-new-experimental-user-interface-QMZgmZG1L5)

<comment><USER40> Hey, the cookie policy on your site appears in black text over a black background on chrome.

<comment><USER39> Yeah that's broken at the moment. We'll fix it soon :)

</comment></comment></comment><comment><USER41> > Based on these stories, you might be determined to demand high writing > standards everywhere, _right off the bat._

...including writing about COVID-19. :) Sorry, couldn't help cracking a joke after being exposed to so many memes.

> I believe this is the wrong approach though. Context matters. In a team of > individual contributors, it's crucial to share ideas early, to iterate and > collaborate on them. Not everyone will have the same level of writing > skills. Improving it can take a long time. Lower the barrier, encourage more > writing, and people will get more practice.

This requires a feedback loop. It's like writing a program and being satisfied with it yourself, and then someone points to a bug or does a code review and points to issues or areas for improvement. Just lowering the barrier to write without a respectful feedback loop isn't going to do anyone any good. There are too many blind spots that writers themselves cannot discover.

> Where you should enforce high-quality writing is broad or upwards > communication, because there clarity is more important than speed and > ideation. Here too, it's important to keep in mind that good writing takes > time.

Yes, it does take time. But being able to write well not only shows the person's ability to write, but also clarity in thought and an ability to communicate thoughts to others. In a world where most of the communication, even before COVID-19, is in written form, it's important to treat every piece that one writes with care. Mastering a language may not be easy. But showing some care while writing is within the reach of many people who need to convey their thoughts to others.

</comment><comment><USER42> I've started working on a Q&A site that parses Slack logs and creates a thread on the site based on me asking people on Slack on how to do different things in our system. The problem with Wikis is friction. I'm hoping that reducing this to copy, paste and click OK will help.

</comment><comment><USER43> Mailing Lists.

Everyone here seems to be conflating good written communication with documentation, but good written communication has happened via a mailing list for decades. Mailing lists provide the many to many interface of a meeting or IRC but unlike those they happen asynchronously, handle many topics, many users and are searchable. Async especially is the key because it allows responses to be informed and well thought out.

This is a proven model in our industry especially, for decades it's been the primary communication medium for large international OSS projects built by teams of people that never met face to face. Imagine where linux would be if Linus was spending his time waking up at 3AM for a face to face with the team in New Zealand and updating wiki articles.

</comment><comment><USER44> I love this topic.

I like writing. I've been writing all my life.

In the last couple of years, I have taken to building a "personal brand," by writing about the way that I design and develop software.

It's been really good for me. I find that it helps me to consolidate and focus my thinking. It also helps me to feel accountable, and I'm a big believer in accountability.

If I write something, it had _better_ be true and accurate.

I often review everything that I write in public, and make even small grammatical corrections (I miss one, every now and then, though).

I also like reading. I _devour_ books; usually escapist fiction. The first non-child book I ever read was _Where Eagles Dare_ , by Alistair MacLean. I started reading because I lived in Africa, and the TV _sucked._

</comment><comment><USER45> Writing is premature optimization.

YouTube is the most important asset on the web.

In fact, we'd be better off if most "thoughts" weren't committed to virtual paper.

In the beginning you want a medium that malleable, nuanced, high bandwidth. Speech. Visual emotion. Voice inflection. How we've evolved.

It's in those moments where ideas are challenged sbd change form quickly.

Then once they're a bit more solidified, take a pass at writing. Which adds further clarity.

I think eventually we find a place again for voice and video for remote work. Something that isn't a huge production but still async.

Yac or Loom look really promising in this area.

<comment><USER11> Different people have different learning and communication styles.

Some people learn best from video content. Others (like myself) would MUCH rather scan through a written tutorial than sit through a 15 minute video (though thankfully I can watch YouTube at 2x speed).

Some people really benefit from interactive exercises. Others find them to be a waste of time.

A big challenge in creating a good internal learning culture at a company is working out how to best address those different learning styles.

</comment></comment><comment><USER46> I think this article puts the cart before the horse. What's the point of good writing? Can you eat it? As argued at [https://news.ycombinator.com/item?id=23147248](https://news.ycombinator.com/item?id=23147248) the goal ought to be _effective remote collaboration_.

I agree with all the child comments questioning whether you can or should inculcate writing skills — they're only one path to success. People with passable or subpar writing skills can find other paths.

</comment><comment><USER47> Written communication is a challenge for some people. Not everyone is as good of a writer and this skill does not map to coding skills. In the team I'm currently in, this is definitely a problem and I notice some people are not used to doing this and are effectively struggling to be part of the ongoing discussions.

I've met more than a few engineers that in meetings don't tend to speak up and in chat channels mostly don't engage. Chat channels tend to be dominated by the same people that are also dominating meetings. This is not necessarily a good thing.

For better or for worse, this causes side channels to pop up and this is where most of the discussion happens. This is a problem because it by design excludes people. But it's needed because you can't speak freely in a channel where everybody in the company listens in, including management, individuals you don't get along with, etc. Pretending this is not a problem is not helpful.

In OSS projects, there's a pattern of frequent contributors to be disciplined about how they use communication tools. IRC historically is the place where people discuss in an unmoderated forum. It's noisy and chaotic and often not pretty. But it's not necessarily there for documenting decisions. That's what issue trackers or mailing lists are for. Those tend to have a narrower scope of what is on and off topic.

Translating chats into actionable items, or documenting outcomes of discussions is the key thing to do. The larger the project, the more obvious this need.

In a corporate setting, the tools for this are comparatively poor and not that good for facilitating asynchronous communication. E.g. Atlassian's tools are pretty popular but not great for async stuff. IMHO Jira is slow to interact with and this obstructs effective communication. It's notifications, default settings, etc. are basically completely wrong and counterproductive. Absolutely everything requires multiple mouse clicks. IMHO Github issues is vastly easier to deal with for engineers; it's also easier to refer to commits and pull requests there. And with github actions integrated, you also get insight into the status of CI. Likewise conflucence is a PITA to use compared to managing markdown files in a git repository or co-authoring a document on Google docs. Slack is nice but way too noisy for communicating things unless you have read only channels that are used for things like announcements.

</comment><comment><USER48> We're having decent success recording and sharing small video presentations. People can speak in their own voice, they can point at things which is sometimes faster than describing them.

I've always been a stickler for clear writing, but recently I decided I will settle for effective communication of any form.

</comment><comment><USER49> Written communication is simply an extension of overall communication.

If communication is only encouraged as a tool to transfer the needs of an executive to teams and then individual contributors, it will wither and die.

To improve written communication, you must improve the culture first.

</comment><comment><USER50> Encouraging a culture of people who now have to work in a cover their ass territory...welcome

</comment><comment><USER51> One of the main barriers to writing things down in organizations is the knowledge that anything written down can be subpoenaed. At least in the US, management of legal liability is a major part of running most organizations.

<comment><USER38> How much of what is written day to day by software developers would be legally interesting?

</comment></comment><comment><USER52> I've worked in places where everything is in email. That's become less common as email discoverability in court has become a thing. It wasn't some magical paradise.

As with all things, there are no absolutes. Don't blame tools for broken process. End of the day, you need to have a common process to debate, make, and memorialize decisions.

</comment><comment><USER53> I'd add: keep a simple text or markdown file with daily notes.

</comment><comment><USER54> As a developer, nothing sounds worse than a bunch of people typefarting and expecting everyone else to read their stupid thoughts.

If you want to type, please do it in an IDE.

</comment><comment><USER55> It has a huge downside. It can be boring and too corporate.</comment>


Californian biopharmaceutical company claims finding cure for SARS-CoV-2 - <AUTHOR> https://investors.sorrentotherapeutics.com/news-releases/news-release-details/sti-1499-potent-anti-sars-cov-2-antibody-demonstrates-ability <comment><USER2> Their stock went up 158% on Friday due to this press release. Seems overly optimistic and speculative; this is a small company and investors have been burned by them before, e.g. [https://www.reddit.com/r/RobinHood/comments/89tnhb/biotech_i...](https://www.reddit.com/r/RobinHood/comments/89tnhb/biotech_investments_gone_wrong_a_sorrento/)

<comment><USER3> perfect time to issue more stock and dilute shareholders at a higher valuation... before the dump

</comment></comment><comment><USER4> So I'm not a biochemist or an MD or similar but this seems to say that they think they found which pre existing human antibody targets a particular covid 19 protein. And since that antibody (like all antibodies) is really hard to manufacture, someone now needs to develop a drug with a similar enough shape to do the same job (while also being non toxic and stable in the body).

We're already harvesting antibodies from people who produce them (people who had covid and recovered) and using them to treat (or prevent) covid in others. But that's expensive so it's strictly for those who can pay...

<comment><USER5> > is expected to be able to produce up to two hundred thousand doses per month > and the Company intends to produce a million doses at risk while seeking FDA > approval

"Is expected" might be the caveat, but does sound promising from a scale perspective.

<comment><USER4> Yeah, I wondered about that: is one dose enough for complete treatment 1 person or is it one "pill" and patients need X pills per day for Y days?

</comment></comment></comment><comment><USER6> this is not a cure, but mAb therapies are a very promising approach for a therapy, particularly because the basic idea already is known to work well, there's been some encouraging preliminary work, and it looks like a good target.

Sorrento are by no means the only people working on this: it's by far the most promising approach we have to give us some breathing room to get a vaccine out.

more mAb reading:

\- [https://blogs.sciencemag.org/pipeline/archives/2020/05/15/go...](https://blogs.sciencemag.org/pipeline/archives/2020/05/15/good- news-on-the-human-immune-response-to-the-coronavirus)

\- [https://blogs.sciencemag.org/pipeline/archives/2020/04/27/mo...](https://blogs.sciencemag.org/pipeline/archives/2020/04/27/monoclonal- antibodies-for-the-coronavirus)

\- [https://blogs.sciencemag.org/pipeline/archives/2020/05/06/de...](https://blogs.sciencemag.org/pipeline/archives/2020/05/06/details- of-a-new-anti-coronovirus-neutralizing-antibody)

<comment><USER7> Aren't mAb therapies very expensive, though? My experience in oncology tells me that some mAb courses (bevacizumab, for example) have costs that go through the roof.

</comment></comment><comment><USER8> >"...expected to be able to produce up to two hundred thousand doses per month "

When the cases are growing 25K/day in the US, so that many new cases in 8 days, it'll take some real testing & focus to start to catch up, but could definitely help for front-line workers. Presumably, if it really works well, could also use/build other production facilities, but it takes time.

<comment><USER9> Maybe also defense production act to swap other production lines to produce either this antibody or one of the many other candidates also announced. Although obviously I think the people taking humira or an anticancer antibody or any of the other antibodues might have some thoughts on their drug not being available so a covid drug can be made available...

</comment></comment><comment><USER10> Misleading title. They found an inhibitor not a cure. The solution would more akin to a nasal spray that prevents infection than a therapeutic avenue.

<comment><USER9> An Inhibitor is a cure, like convalescent plasma. You could maybe use these for passive immunity, but this is clearly pitched as a therapy, not a preventative, with the idea if stopping disease progression by stopping viral replication. And I dont think antibodies can be administered nasally, they're usually injected or intravenous

</comment></comment><comment><USER11> I'm only a layman, but is not true that _in vitro_ results are hardly worth getting excited about?

<comment><USER9> It depends on the in vitro experiment and the context. Something like "kills cancer cell" is nearly meaningless (hence the famous XKCD comic). Here, this is a well known mechanism of action (remember balto and the diphtheria antitoxin and the Iditarod? This is fancy antitoxin kind of). And the in vitro experiment is a test to show that it is a neutralizing antibody that binds to the virus and stops entry. The in vitro model is the exact same mechanism of entry the virus uses in the body. While there are still lots of unknowns and unknown unknowns, and of course sorrento will have to run through extensive (or perhaps less extensive under the circumstances) clinical testing before we know for sure it works, this is more promising than your usual popsci "strawberry shortcake kills cancer cells on vitro" experiment. We also have some human data from convalescent sera I believe, amd this is essentially just controlled, high quality convalescent sera that you dont need to extract from humans, so even more validation there, which is why so many people are excited about and pursuing and antibody approach (sorrento isn't the only one or the first to develop a neutralizing antibody to covid)

</comment></comment><comment><USER12> Just seeing the incredible speed that potential treatments and vaccines have arrived at testing and the accelerated pace they're being put through testing... it makes you realize that in normal time we are operating nowhere near the speed that we could be in tackling other diseases.

I wonder if this experience will change the pace of what people view as possible, like the pharmaceutical version of the Roger Bannister Effect. [https://hbr.org/2018/03/what-breaking-the-4-minute-mile- taug...](https://hbr.org/2018/03/what-breaking-the-4-minute-mile-taught-us- about-the-limits-of-conventional-thinking)

</comment><comment><USER13> Control-f on "cure". Nothing. Very misleading title.

<comment><USER9> It's a treatment that stops viral replication within four days. It might not shut down cytokine storm, but if administered earlier, it stops replication which would be a cure if it works. Biotechs tend to avoid the word cure early on, you'll see the word treatment, because cure is a word that's hard to define and often meaningless or with blurry boundaries.

<comment><USER13> > Among the antibodies showing neutralizing activity, one antibody stood out > for its ability to completely block SARS-CoV-2 infection of healthy cells in > the experiments. STI-1499 completely neutralized the virus infectivity at a > very low antibody dose, making it a prime candidate for further testing and > development. Initial biochemical and biophysical analyses also indicate > STI-1499 is a potentially strong antibody drug candidate.

[https://investors.sorrentotherapeutics.com/node/11241/pdf](https://investors.sorrentotherapeutics.com/node/11241/pdf)

This is as far from a "cure" or "treatment" as the Wright Brothers were from Apollo 11. In vitro results are a necessary, but insufficient path along the trajectory of developing a drug.

Heck, this press release doesn't even mention _in vivo_ experiments. Everything is on cells. Drug development is absolutely littered with the corpses of promising in vitro studies.

Calling the experiments have have been run anything other than "preliminary work" is misleading.</comment></comment></comment>


Pushing to Dokku from GitLab CI - <AUTHOR> http://jeroenpelgrims.com/pushing-to-dokku-from-gitlab-ci/ <comment><USER2> We're working on making pushing from GitLab to schedulers simpler in [https://gitlab.com/gitlab-org/gitlab- ce/issues/3286](https://gitlab.com/gitlab-org/gitlab-ce/issues/3286)</comment>


CalPERS bows out of venture capital - <AUTHOR> http://www.siliconvalley.com/ci_21275244/calpers-bows-out-venture-capital

<comment><USER2> They also lost money on both Enron and Worldcom. In Enron's case they were putting money into the balance shifting shenanigans that were being done, although IIRC they got out of those in time.

All investments have risk/reward tradeoffs. It is debatable whether they should even be in the very high risk (VC) space.</comment>


Facebook brings in payment system - <AUTHOR> http://www.ft.com/cms/s/0/2adf1976-4f91-11de-a692-00144feabdc0.html <comment><USER2> This is powerful, and I believe that the revenue stream will ultimately make up far more than one third of the firm's total sales as the article suggests.

Peer to peer commerce relies heavily on social networks to guarantee quality of goods, delivery, and payment. Taking the social graph of FB and layering its own payment system would allow a big opportunity for improvement in peer to peer commerce. Imagine that you need to buy a used item, say a couch, but like many people you're concerned about buying from a random person on Craigslist. With this, you could search for a couch among your social network plus one or two degrees, and FB would take care of payment. The quality of purchase would be supported by the existing physical social network outside of FB, but mapped out inside FB.

Honestly, I could see this becoming a major competitor, at least in some respects, to what eBay was supposed to do but has started to ignore (peer to peer auctions).

Much more exciting to observe than them trying to monetize ad space.

</comment><comment><USER3> Most surprising quote of the article (IMO): "Zynga, the largest applications developer on Facebook, with 42m users of its games, is reported to be nearing annual sales of $100m. Together, developers working on Facebook's platform are expected to make more than $500m this year – perhaps more than Facebook itself."

</comment><comment><USER4> I suppose it's a step in the right direction, but I don't see this helping in terms of monetizing the vast majority of facebook users.

There does seem to be a core group that love the little games and such. I'm sure those people will pay something. What I struggle with though is how big of FB's user base this core group is, and how stable it will remain.

I remain pessimistic.

</comment><comment><USER5> Good Move, that should end the questions about money in fb.</comment>


Show HN: Simply eat right to fuel your body and mind - <AUTHOR> http://fuel.build/#?##

<comment><USER2> It looks like a great concept. Where are you guys rolling this out? When will you be out of beta?

<comment><USER3> No sockpuppets on HN, please.</comment></comment>


What The Fuck Is My Social Media Strategy? - <AUTHOR> http://whatthefuckismysocialmediastrategy.com/

<comment><USER2> There are only 20 of them.

        function setTextValueByIndex(index)
        {
        	var r_text = new Array ();
        	r_text[ 0] = "Facilitate audience conversations and drive engagement with social currency";
           	r_text[ 1] = "Maximise breakthrough by leveraging influencers";
        	r_text[ 2] = "Amplify word of mouth by motivating influencers";
        	r_text[ 3] = "Humanise the brand by driving the audience conversations";
        	r_text[ 4] = "Harness social currency to drive buzz";
        	r_text[ 5] = "Drive break through conversations with an engaging viral";
        	r_text[ 6] = "Utilise social currency to amplify experiences and drive conversations";
        	r_text[ 7] = "Maximise buzz by driving word of mouth from relevant influencers";
        	r_text[ 8] = "Increase organic growth by exposing audiences to the brand through breakthrough viral communications";
        	r_text[ 9] = "Encourage positive conversations to drive advocacy";
        	r_text[10] = "Target influencers with engaging assets to act as platforms for conversation";
        	r_text[11] = "Provide brand ambassadors with compelling conversation hooks to enter into communities and fuel advocacy";
        	r_text[12] = "Expose new and relevant communities to the brand by providing assets to encourage brand evangelism";
        	r_text[13] = "Enhance the customer experience by facilitating authentic conversations";
        	r_text[14] = "Expose new users to the brand through organic conversations";
        	r_text[15] = "Build loyalty & increased engagement through ongoing conversation and brand experience";
        	r_text[16] = "Strengthen the emotional connection with the brand by building relationship";
        	r_text[17] = "Maximise the customer experience, driving engagement and bringing the brand alive";
        	r_text[18] = "Ignite the existing community and attract new members by amplifying the experience with relevant and engaging content";
        	r_text[19] = "Identify relevant and compelling hooks for the audience, create content around the hooks and integrate it into their social repertoires";
        	r_text[20] = "Activate audience by giving them compelling social experiences, encouraging advocacy";
        	document.getElementById('bigfuckingtext').innerHTML = r_text[index];

        	document.getElementById('bigfuckingindex').href = "http://whatthefuckismysocialmediastrategy.com/index.html?p=" + index;
        }

I was hoping they were generated like the postmodernism generator.

<comment><USER3> There are 21.

</comment></comment><comment><USER4> That site missed one: "Become a grade-A dick by intrusively engaging with people who tweet shit about your shit."

</comment><comment><USER5> On a serious note, everyone wants their business/product to be a trending topic, next to the water cooler, on twitter, on CNN after the superbowl, but especially on any social website where the activity can be tracked and easily converted.

The social web, the very same sites like Facebook and Twitter that are used by individuals, are utilized [if effectively] in a very different way by businesses and organizations. When done successfully, traffic surges and the brand catches. But even when not done to that degree, companies are able to effectively take advantage of relavent discussion and engage potential customers. If you have a solution, nothing beats talking to people who you know for a fact are facing the problem you solve.

With or without the buzz words, businesses such as my employer are very eager to engage potential customers and be louder on the social web than their competitors. It means potential customers turn into sales easily and cheaply. I think it's smart. But I worry about the future of a social web, where our friends get paid to sponsor a message and recommend products to us. The result would probably be mostly noise. I think noise is a problem as data transfer and data storage becomes so cheap. (I'm starting to get off topic but that's why I believe in the longevity of search. Noise needs to be filtered out.)

</comment><comment><USER6> Amusingly enough, I'm seeing some social media marketers tweet this.

<comment><AUTHOR> thats because they are oblivious.

</comment></comment><comment><USER7> This is pretty perfect, but I wish the text was all either 2 or 3 lines, or synced with the 'click for another' link so I didn't have to chase it with my mouse to get more options.

Also, the text could have had a bit better contrast given the typography choices.

Otherwise great.

<comment><USER8> Definitely an important usability tip.

I found this works though: in FF/OSX once you've clicked the link, it stays highlighted and you can use the Enter key to click it again. Hopefully your Enter key stays in one place!

</comment></comment><comment><USER9> Immediately reminded me of Dack's Web Economy Bullshit Generator, a classic from the original web bubble. I'm happy to see that it's still online: <http://dack.com/web/bullshit.html>

</comment><comment><USER10> That's awesome. But I want to submit the crap I have to hear everyday. Where is the submit form? :-)

</comment><comment><USER11> Well, my first suggestion would be to have a shorter domain name, so that the URL is easier to remember.

Maybe WTFstrategy.com - this domain name shows as available at this point.

<comment><USER12> IMO the long domain name adds to the awesomeness.</comment></comment>