Why I'm thankful for JavaScript fatigue - <AUTHOR> https://medium.com/javascript-scene/why-im-thankful-for-js-fatigue-i-know-you-re-sick-of-those-words-but-this-is-different-296fae0c888f <comment><USER2> > It's like walking into a restaurant and finding out that they have all your > favorite dishes and every one of them is free and complaining about how long > it's going to take you to read over the menu and make up your mind about it.

I suppose it's a matter of perspective. For me, it's more like walking into used car lot. Most of the cars have lost (or voided) their warranties. Some are certified pre-owned. That one in the corner looks nice, but I don't know how to drive stick, and am not really interested in learning. At least it's not a custom gear box, like this other one.

I can look at the new car lot across the street, but I'm not sure I want to be the first to use one of those self-driving electric smart cars. It's neat, but I'd rather stick to proven standards, and gas stations are more common than charge stations, anyway.

And I could probably get to where I'm going with just a bicycle.

<comment><USER3> Also, the problem with big chain restaurants with a thousand things on the menu is not reading the menu, it's that none of it is very good. Much rather eat at a small restaurant with 5 things on the menu that are all excellent.

<comment><USER4> And the other problem is there are 23 kinds of bespoke artisanal ravioli and maybe it was handmade by a Michelin chef or maybe it's from a bootcamp graduate that spent two weeks learning how to blog, star things on pinterest, and require('can-of-chef-boyardee')

<comment><USER5> You gave me false hope.

       npm ERR! 404 Registry returned 404 for GET on
       https://registry.npmjs.org/can-of-chef-boyardee

</comment></comment></comment></comment><comment><USER6> JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month.

This is why universities teach _computer science_ rather than just programming. Learn about programming language _paradigms_ \- procedural, object-oriented, functional, etc; the language itself doesn't matter. Learn about relational databases. Distributed systems. Computer architecture. State machines. Formal grammars. Language translators/compilers. Data structures. Algorithms. Computational complexity/big O notation. That's the theory side of things.

Understand Unix, version control systems, and how to log into and administer remote systems. Learn about what TCP/IP is and how higher-level protocols like HTTP relate to it. Ensure you're able to write a program in at least one language that can talk to at least one type of database, and present at least some sort of user interface. That's the practice side of things.

These things will pretty much set you up for life. By themselves they're only a start, but you can pick up the rest as you go along, lazy evaluating any expertise you need with specific technologies as you go along.

As far as front-end web development is concerned, all you _really_ need to know is JavaScript, HTML, CSS, and the DOM. Pick an abstraction layer on top of that _if you feel it helps you_ , but don't feel that you need to know about every framework out there, because new ones are being generated faster than you can learn about them.

And yes, becoming good at this takes many years. But ensure that whenever you're investing time to learn, it's something that will last.

<comment><USER7> It's great to know basic principles, and I highly recommend that.

If you want to do frontend though, you need to know some concrete things. And then you choose a framework (or more likely, some frameworks, since there's no 'one-size-fits-all'), and it no longer becomes supported. At that point you begin to feel Javascript fatigue.

 _But ensure that whenever you 're investing time to learn, it's something that will last._

Which web framework is that? Probably none right now. But waiting is not an option, websites need to be built today.

<comment><USER8> You're investing the time to learn the architectural patterns, which will likely either stay relatively similar over time, or morph (which will be easier for you to pick up), or they're drastically change, in which case you'll probably have a level of understanding for why they changed. And yeah along the way you'll implement stuff today and that's an important component, but learning is as much about the long game as it is the short game, and you can play that long game without having too much anxiety over these choices

<comment><USER9> Exactly. I've met too many front-end devs who are unable to separate the architectural pattern from the implementation of the library they are using. They have the larger mountain to climb when needing to learn a new framework.

<comment><USER10> "I've met too many front-end devs who are unable to separate the architectural pattern from the implementation of the library they are using."

That's because front-end development is based on a core of HTML/CSS/JS which itself does not lend very well to architectural paradigms.

People 'starting out' on the front-end, in some ways, never learn how to write propers software. They've been using weird ideas from the start.

<comment><USER11> That's actually kind of interesting. HTML/CSS/JS really are the framework. It's already a great separation of concerns (HTML for data/content, Javascript for behavior and logic, and CSS for presentation). Everything on top of it just seems like implementation details.

<comment><USER12> If you want to display documents, sure, I agree. If you need complex UIs, manually updating DOM without any kind of abstraction is definitely not a right choice.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I'm a prototyper, so people often come to me first to vet new ideas. Often times this means implementing a feature on an existing product platform. When I started doing this 5 years ago, I was working with a new language every month. It was ruby one day, C# the next, and I'd go to sleep every night praying next week wouldn't be PHP.

These days everyone is using javascript. In the last year I've done countless javascript projects and _one_ project in java. I can't tell you how refreshing it is to not have to brush up on syntax and install a suite of tools every time I want to work on a new product. Nowadays it's just clone the repo, do a npm install, and you're up and running for the most part. It's lovely.

</comment><comment><USER14> I agree with his point, but I think he mischaracterizes JS fatigue. He's right that it's exhausting trying to keep up with all of it, and that's part of JS fatigue, but the other side is the endless hype machine that's internal to the tech community, where our media is an endless stream of "look at my new framework!" and "you're doing react wrong!" and "why functional is making a comeback!"

We do it to ourselves not just by continually stuffing the buffet with every possible option, but also by making our community dialogue an endless infomercial, which has a big influence on trying to keep up with it all. We have conflicting desires to contribute and to self-promote, and the result is an aggressive bazaar in which you need to consciously filter out 90% of the noise so you don't get overwhelmed.

<comment><USER15> I agree with you. IMHO I see it as good thing. Maybe 6 projects bring so little innovation comparing to project they're trying to replace. But then somebody will take the good parts of all those projects and create something that is significantly better. Innovation does not grow on trees, there is slow and bumpy road to it. :-)

</comment></comment><comment><USER16> > Nobody is ever going to know everything there is to know about modern web > architecture

I think this is the root of the sentiment that is expressed as "JS fatigue" and bullet train rides etc.

I'm torn though. On one hand, this is equivalent to saying: Nobody is ever going to know everything about an operating system and how a machine performs the operations we expression a high level language like, you know, C!

The thing is, we still were able to teach the abstraction of the single- machine computation model that C is abstracting in a single semester to the point of making new coders _operational_.

But I can't imagine trying to construct a course to teach "modern web architecture" in a single semester.

On the flip side, a lone developer who can chose their _battles_ wisely has more leverage to produce something of value today than was ever freaking possible, ever!

I'm betting on the the new "OS" abstraction as cloud-native services (DB as a service, event streams as a service, mobile syncing as a service, heck, everything but your core logic as a service).

But by it's nature this world is redundant, competitive, multi-vendor, fractal-specialized and I only see that trend increasing.

So yes, one person will never know everything there is to know, the _new_ skill will not be learning every framework, platform or service, but being able to grok the core nature and characteristics of your problem so you can apply the closest matching tool with the maximum leverage.

Essentially, the _new_ skill will be to optimize for laziness :)

<comment><USER17> I am not sure I agree that optimizing for laziness will ever be a skill. But indeed, I am not sure it's possible to know everything there is to know about just about _anything_. How can you ever be sure there isn't still something left to discover?

I am reminded of something I used to hear all the time: you learn something new every day.

<comment><USER16> Ha! Yes, my shorted argument of "optimizing for laziness" doesn't sit right, but the core of it how much your choices matter in what you are _not_ building.

\- Cloud-based apps used to mean managing VMs, keeping kernels up to date, setting security settings on server configs. It doesn't have to[0]

\- Mobile dev used to mean compiling platform-specific code and shipping it to app-store review. It doesn't have to[1]

\- Storing state server-side used to mean running your own DBs and worrying about their persistence and multi-host-scaling. Don't even need a reference here since there a so many choices.

[0] [https://www.ibm.com/developerworks/cloud/library/cl- bluemixf...](https://www.ibm.com/developerworks/cloud/library/cl- bluemixfoundry/)

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

<comment><USER18> > Cloud-based apps used to mean managing VMs, keeping kernels up to date, > setting security settings on server configs.

PaaS offerings where this kind of thing was not required were among the very early dynamically-scaled application platforms to get the "cloud" label. IaaS offerings where this is required and part of the price for greater control exist, to be sure, but have never been the only cloud platforms.

<comment><USER19> Or even the first cloud platforms.

</comment></comment></comment></comment></comment><comment><USER20> Pretty rich coming from the complainer-in-chief of JS, the guy who advises not employing people who don't happen to agree with his personal take on how JS should be written.

</comment><comment><USER21> I think the bigger problem is that we, as developers, don't appreciate risk and how to mitigate it. We always want to play with the latest and greatest tools, technology, approaches, etc, etc.

My advice to the teams I mentor is choose _at most_ 1-2 risky areas and reduce/eliminate risk everywhere else.

If you have a new idea with a new team, stick with established tools. If you have a well-gelled team with understanding of the space, experiment with tools or approaches.

When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, success is unlikely at best.

<comment><USER22> >When your idea is unproven, your team is unproven, your tool is unproven, your stack is unproven, and your approach is unproven, failure is unlikely at best.

Should this be success is unlikely at best?

<comment><USER21> Ha, thanks & corrected. :)

</comment></comment></comment><comment><USER23> One benefit often overlooked is that during high periods of churn in an industry (let's specify JavaScript fatigue as a symptom of rapid churn in Software Engineering for Web Applications). There are more opportunities to quickly speed up your career. Fresh problems call for new solutions and fresh eyes to work on those problems.

The opposite of JS Fatigue is climbing the J2EE certification ladder - if we were all still building Struts/JSP apps then there would be no room for new ideas to flourish. I felt very similarly about Ruby on Rails in 2004, there was 4-6 years where someone early in their software development career to learn a stack, find work doing that tech and manage a team (exactly what me and several of my good friends did).

</comment><comment><USER24> I see the proliferation of JavaScript tools as a massive failure of the vanilla js standard library and ECMA. Most of the stuff out there just rebuilds basic language features that would be standard in other languages.

We wouldn't need node, npm, typescript, angular, react, web pack, or most of the bazillions of libraries out there if vanilla js had reasonable defaults.

It's causing horrid fragmentations probably won't go away until js is replaced maybe 5 years down the road.

The best we can hope for is a c++ style solution. A new language that's basically a massive preprocessor on top of the original that fixes as much as possible. My hope is in typescript for now

<comment><USER24> I think node is the funniest example. "Yay we can run js on the server now! This is the future!"

But wait, what other language can't you run on the server? I can't think of a popular language in existence before js to take so damn long just to have a web interface. It took js ten years! Even rust has a web server and it just hit 1.0. Oh and node is still single threaded, something horrific for servers that usually have 16+ cores.

<comment><USER25> You could run Javascript on the server back in 1996.

Netscape Enterprise Server supported Javascript as a server-side language, similar to VBScript or PHP. They called it Livewire.

</comment></comment></comment><comment><USER26> The problem is very accurately described as people trying to use every framework and every library all at once. Too many developers are neglecting their knowledge of the base language. JavaScript has become incredible in recent years, but you'll still find new projects being built incorporating jquery.

I have tried react redux and seriously people, after all your badgering and all of your carrying on. I still prefer vanilla es2015+ with typescript. I can do everything you can do sans MBs of extraneous client side code. I also have more control.

Use your tools for what they are useful for, stick close to the metal. You'll save yourself tons of grief.

<comment><USER27> React + ReactDOM + Redux is a little over 50kb minified and gzipped. I'm not saying that's nothing, but "MBs" is a strawman.

</comment></comment><comment><USER28> Precisely my feelings about the fake problem of JavaScript fatigue, glad to see it finally make the front page of HN.

<comment><USER29> > fake problem of JavaScript fatigue

Can you elaborate why you called the problem fake? Not disagreeing, genuinely curious as to why you called it that.

<comment><USER28> Its really just an excuse for people who don't like JS to complain about JS being popular. They honestly hate the fact that JS is one of the most popular languages in the world right now.

You don't see a-lot of post making the frontpage of HN complaining about programing language fatigue, car fatigue or anything else with a lot of choice fatigue.

<comment><USER30> Javascript is in the unique position where a lot of people (well, nearly everybody) that don't like it are forced to use it.

</comment></comment></comment></comment><comment><USER31> Agree with the author 100%. We want tons of new JS tools and frameworks out there so we can learn and evolve newer and faster ways of developing. I still remember when jQuery first came out and how earth-shattering that was. This inspired so many more devs to create better and easier to use tools.

<comment><USER10> Were JS and browsers to have been designed 'properly' (or better) with hindsight, 'jQuery' would have never needed to come into existence.

JS evolution is perniciously different than the evolution of most other languages.

<comment><USER17> In hindsight of course it's obvious. jQuery should just have been built-in from the beginning! And all browsers should have always behaved the same and should never break compatibility with never versions. Then jQuery would never have needed to exist in the first place. Problem avoided.

</comment></comment></comment><comment><USER32> > gifts

fuck this dude. typical contractor that doesn't have to maintain unsupported backbone.js based applications. just shits something out using the latest technology then fucks off

</comment><comment><USER33> > and every other exciting, scary, new, hipster Haskell thing that exists in > the web dev world today.

Ha ha! A fatigued JS developer complaining about hipster Haskell things!

</comment><comment><USER34> > From this point going forward, no single human being is ever going to have a > completely full grasp of every corner of JavaScript, CSS, and Web APIs.

What does that mean for security, given that two secure systems combined can result in an insecure system?

<comment><USER35> In general, if I don't use something, if it's outside of my focus, that shouldn't harm security. As an example, given your two secure systems which can combine into an insecure system, if I don't use that second system I should be good. If I do, I better know their interactions.

This argues for a small reliable toolset rather than having every contrivance in the HomeDepot center aisle on my belt.

Not full stack, definitely not fool stack, just stack.

</comment></comment><comment><USER36> In some respects the problem of "too many libraries" is the same issue we have with news headlines, etc.: too much going on, and not enough value placed on curating.

Right now everyone just wants to build things full-time. As an industry, it would make a lot of sense to have expert developers who spend some non-trivial amount of their time just on _curating_ : writing down what actually works, what doesn't, etc. Maybe a "stack overflow" for software packages. And after awhile, it should become expected that you consult _those curated lists first, every time_ before you build anything else.

</comment><comment><USER15> I wish I fully understand what people mean by javascript fatigue. I can translate fatigue to my language, but it still doesn't make sense.

<comment><USER37> The fatigue comes from having to constantly keep up with JavaScript and everything new.

5 years ago building JavaScript page was straight forward. Most of the time you would include JQuery from a CDN, and code in a server side template. If you were really serious, you used something like Backbone Or Ember (both very new). But the options were limited. JavaScript was often limited to AJAX requests, a modal or two, and some JQuery plugins. Very few people were "JavaScript Developers." They wrote JS for their webpages and Ruby/Python/Java/Whatever for everything else.

But NodeJS and ES5 broke open the floodgates for JavaScript Development by elevating Javascript from something only seen in a <script> tag to a fullstack language. With that came a surge of new libraries, frameworks, methodologies, and opinions. It's exciting when a community grows so fast and puts out so much. Many old Javascript patterns and styless were declare obsolete and new ones were created.

A new framework and stack seemed to come out every month. Suddenly Javascript needed build scripts and a pipeline. Grunt came along to solve that problem. Which was replaced by Gulp. Which was replaced by npm scripts. And now yarn? This rapid iteration of technologies appeared all across the Javascript ecosystem. Backbone, Angular, React, Vue, Angular 2. Flux, MobX, Redux. But these switches are as much a change in fashion than real improvements. But either way, the change takes effort to learn and implement.

It turns out learning a new framework, library, pattern every 6 months is tiring. Its fun to learn something new. But having to constantly be learning, and at such a high rate, takes a lot of effort. That is the fatigue. The fatigue of every time you open up HN, there is some new JS library that will replace whatever you are using now. And if you don't switch, you are an idiot using old technology. Or at least the community makes you feel that way.

<comment><USER38> That was a really great writeup of the issue, thanks for that.

</comment></comment></comment><comment><USER34> I think I'm having a case of "JavaScript fatigue fatigue".

<comment><USER39> The next step is not far away.

</comment></comment><comment><USER40> I definitely appreciate the sentiment. Its true, the JS ecosystem has exploded and there's been a lot of shrapnel flying around for quite a while. It feels like the smoke is starting to clear and some different groups of consensus are starting to form about some generally reliable patterns and tools which makes things easier.

For me, having learned web development in a time when it really was the smallest part of what could be considered development, the tooling and techniques are at once awesome and horrifying. :) The browser's transition from a much more useful version of Gopher to a platform in and of itself has created a lot of opportunities and challenges, and while JS still isn't my favorite language by a long shot, its gratifying to see its progress.

</comment><comment><USER41> > I recently built an app prototype in a couple days using nothing but vanilla > JS and the DOM. I was literally two days in before I installed a single non- > dev dependency. Guess what? It was fine.

IMHO a good strategy to reduce the cognitive load (and limit dependencies).

<comment><USER42> I loved this admission. There is a lot of awesome, powerful, fancy stuff out there today, but you can get a lot done with the vanilla approach. I was introduced to JS back when AJAX was 'blowing up', and today still prefer to hack quick ideas w/ at most a jQuery import

</comment></comment><comment><USER43> It's very hard to know everything. I made a programming language and I'd be screwed without the manual to refer to. Recently I was utterly surprised by something that was implemented ("you can do that?").

What was it ... aha, I remember: introspection over exception handling sites. The ability to just get a list of the frames through an API, and then directly pick one and jump to it (regardless of whether it catches the type of exception being passed to it that way).

</comment><comment><USER5> > "From this point going forward, no single human being is ever going to have > a completely full grasp of every corner of JavaScript, CSS, and Web APIs"

This. Reading the comments at HN and other places gives you the impression that there are people who do know everything, but that's not the case. There's just lots of technical people here who are experts in various fields, so there's always experts to comment on things.

</comment><comment><USER44> I picked EmberJS because of javascript fatigue - it makes most choices for me and gives me some guarantee that it will work together.

But even that fails in practice: sourcemaps don't work properly so you don't get to debug your original ES6 code and more issues like that. Meanwhile there's no clear focus on where the framework is really going (routable components? working pods in ember-cli?, etc)

</comment><comment><USER45> Could some of this fatigue be due to to JS being so damn hard to troubleshoot? I'm still struggling with troubleshooting JS after years of using it on and off. I still console log everything and keep refreshing the page. Is there a more sane way of doing it?

</comment><comment><USER46> This article seems to me a self reassuring post written by the author after he suffered himself the JS fatigue.

</comment><comment><USER47> Haskell programmers are hipsters now?

<comment><USER48> Well, they're the ones juggling while riding backwards on a unicycle.

</comment></comment><comment><USER10> JS fatigue is not a fake problem, it's real and different from other forms of fatigue.

The metaphor used in the article i.e. 'learning another language every 6 months' is not apt - because those are not 'new languages' and they are not 'new and critical parts of the landscape' for any specific vertical.

If any one of those languages were to have the same degree of evolution as JS ... then 'fatigue' would also be an issue.

JS has a pernicious problem for a few reasons:

1) The language is quirky, fragmented, there are still no 'agreed upon' approaches to do many things even outside the context of libraries. There are really no analogues to 'prototype' based languages, which possibly makes it great for some things, but it's not great for those wanting to use more classical ways of thinking about information organization.

2) Runtimes, particularly browser - are highly fragmented, and there's scant documentation. Safari docs for Mac/iOS are literally empty in some spots.

3) JS doesn't come with a lot of things 'baked in' to the language that most others support, so discovering those 'standard libs' has been a painful process.

4) Due to the limitations of the browser, we see a lot of churn in frameworks.

Though there is some advantage to 'community participation' \- the pernicious problem is _most of the churn is not fully forward_. It's 3 steps forward, 2 steps back, and a step sideways.

There's a lot of time and investment in learning something new that won't exist in the future - that's costly.

Learning Lambda's for Java 8 is probably worth investing in for Java programmers ... because Java 9 will surely use them as well.

Taken as a whole - there is an enormous amount of inherent 'reducible complexity' in the JS ecosystem, which any JS developer intuitively senses.

If someone were to have made up their mind about JS right from the start, and had come up with some good standard libs ... and the evolution of the language were to have been more 'version' and less 'pick and chose' (Es6 means something different in each environment) ... then the complaint would be valid.

It is what it is ... but JS fatigue is a real thing.

<comment><USER49> one reason why JS is so popular is because there are no standard lib. There would be no nodejs etc.

<comment><USER50> node.js was built from scratch, in C, to resemble javascript syntax intentionally.

<comment><USER9> What? The engine is written in C, but all JavaScript engines are written in another language (C being the most popular) because it is an interpreted language. The engine isn't written from scratch because it is the V8 engine from Google. Of course the system binding and package system is written specifically for Node.

<comment><USER39> C++, actually.

</comment></comment></comment></comment></comment><comment><USER51> You can't learn every library or every tool but you can learn how the language actually works. For example, if you think JS has floats and integers, you have some reading to do. If you think "array" is a type, take heart, because you can learn why that's not correct. If you can't decide whether to use Ember or Angular, maybe you can grasp how closures work.

Before React and Redux and Gulp and whatever else, understand how the language works. Pretty please.</comment>


We Are Built to Be Kind [video] - <AUTHOR> https://www.youtube.com/watch?v=SsWs6bf7tvI

<comment><USER2> The title of the video is somewhat misleading. What he actually says in it is that poor people are kind and rich people are not, and he attempts to back it up with science. A direct quote:

 _" There is literally a compassion deficit that is produced by lots of wealth"_.

Class warfare material starts at 2:20, in a section titled "Empathy deficits".

<comment><AUTHOR> That's actually what struck me about it, and why I thought it worth talking about here. Given pg's recent essay on successful people having high correlation with being nice people (entitled _Mean People Fail_ ), I though it'd be interesting to talk about what the science says (I'm not suggesting pg is wrong; I've met a number of the people I suspect he was talking about, and I also found them to be extremely nice people, generally speaking). But, maybe it's just a difference of definition of what makes people kind, generous, etc.

It _has_ been my experience that some of the most generous people I've met in my several years of traveling almost full-time have been some of the poorest people. Many homeless folks I've met would happily share anything they had, despite having very little. It's an interesting phenomenon.

pg's essay: [http://paulgraham.com/mean.html](http://paulgraham.com/mean.html)

<comment><USER3> anecdote vs. anecdote: I've never been robbed at gunpoint by a rich person. however...

<comment><USER4> They don't need to. They have better ways to rob you and with less risk. Excibit A: Bankers

<comment><USER3> ohh is the existence of the banking system the reason that poor people are always kind and noble? I'm not seeing any connection at all between those two concepts, but whatever makes you feel better while you fight the power is good by me.

</comment></comment></comment></comment></comment><comment><USER5> The animations were very cute (umbrella guy, brain hearts).

</comment><comment><USER6> I wonder if narcissism is a diminished functioning of the frontal lobe.

</comment><comment><USER7> Nice</comment>


How Protein Conquered America - <AUTHOR> https://www.eater.com/2018/2/12/16991634/muscle-milk-protein-culture <comment><USER3> > _Once the niche elixir of powerlifting bros ... about one gram per pound of > bodyweight is the bro's rule of thumb_

> _The company is currently focused on drawing in women, in large part because > they are the primary drivers of lifestyle fitness._

Am I the only one who sees the term "bro" as disparaging? If not, why disparage men who lift by calling them "bros" but women who keep fit "women"? If the article called women "babes" or some "bro" equivalent, people would take the writer to task.

<comment><USER4> I feel like a lot of people that aren't masculine men grew up seeing, both in their lives and as depicted in popular media, masculine men as bullies. As such a huge portion of society - women and men who aren't masculine - grows up with a negative opinion of masculinity.

This bias against masculinity has spread as women and femininity have become more prominent and powerful in society.

The feminine attitude is opposite the masculine in many respects, so it's natural that the two would dislike one another and come into conflict.

As our society shifts to one in which the feminine is embraced rather than rejected, and the masculine continues to be seen as a menace to society, it's considered more acceptable to mock "bros" than a female or feminine equivalent.

Edit: both the feminine and masculine aspects of personality have their strengths and weaknesses. Neither is really better than the other in some objective sense. Different situations call for different attitudes.

<comment><USER5> > I feel like a lot of people that aren't masculine men grew up seeing, both > in their lives and as depicted in popular media, masculine men as bullies. > As such a huge portion of society - women and men who aren't masculine - > grows up with a negative opinion of masculinity.

I could buy this except for the fact that I think there are a lot of "masculine men" who aren't "bros". The word "bro" brings to mind specific (negative) traits of anti-intellectualism, party hard mentalities, and rudeness.

</comment></comment></comment><comment><USER6> This article has a vaguely negative view of the high protein fad. However, if people are even occasionally switching from sugary drinks (pepsi, coke, starbucks, etc.) to protein drinks, that's probably net good for people's health. Not because excess protein is beneficial, but because it isn't as harmful as excess sugar.

<comment><USER7> 'Good healthy' is not always what it seems, there is a disease of orthorexia and 'clean eating' that is notionally very healthy - everything is juiced into kale smoothies (cellulose the body still can't digest...) - and people don't do too well out of it.

As a vegetarian I have had to my own perspective on mankind's obsession with protein for a long time, really it is over-rated as the body makes the proteins it needs from amino acids, not from protein eaten from i.e. a sausage made of pig gristle and shoved in an oven. Or from these whey powder things.

<comment><USER8> The only advantage of a large protein surplus is quickened muscle development. That aside I wouldn't discount the value of dietary protein. Testosterone levels in males this generation are already too low (leading to weakened hearts, infertility and apparently lethargy/depression), and protein is one thing that can help.

<comment><USER9> Protein intake can also protect against lean body mass loss when fasting and losing weight. This prevents the trap of low weight, low basal metabolic rate many people experience after a diet, when they are in great danger of rapidly accumulating the weight back because they also lost muscle with the fat.

For a healthy person following a balanced diet not looking to lose weight or build muscle, protein supplementation is unnecessary and can even be harmful by over-exerting the kidneys.

</comment></comment></comment></comment><comment><USER10> Want protein? Get some nutritional yeast. You can add it to almost anything and get as much protein as you like. No fuss, no mess, no cholesterol, and cheap. No fat too.

<comment><USER11> It's not cost efficient compared to whey protein.

4.5oz Nutritional yeast from Bragg gets you 50g (25 servings of 2g) of protein in the entire container for $7.29. That's about 15 cents per gram of protein.

ON Gold Standard Whey gets you 1776g (74 servings of 24g) for $55.04. Thats about 3 cents per gram of protein.

An entire $7 container of nutritional yeast is also only 50g total which is actually less than an entire days worth of protein for an adult male.

It just doesn't scale.

<comment><USER12> I've found I can get nutritional yeast comparatively cheap from the local co- op bulk bin. But full ACK that not everyone has such an option.

But... you can also get it online for fairly cheap! Here's a pound for less then 12 dollars. IME a pound goes a long way. [https://www.amazon.com/Frontier-Co-op-Nutritional-Yeast- Flak...](https://www.amazon.com/Frontier-Co-op-Nutritional-Yeast- Flakes/dp/B00016XJM4/ref=sr_1_6_a_it?ie=UTF8&qid=1518983986&sr=8-6&keywords=nutritional+yeast)

<comment><USER10> Let's not forget that dairy is heavily subsidized and created in larger scales.

There's also ripple-nutritious pea milk. The unsweetened, original flavor has no carbs and factually more protein than really needed for a bowl of cereal.

</comment></comment></comment></comment><comment><USER13> Is this a sponsored post? Author hammered MUSCLE MILK into my head like 300 times...

<comment><USER14> Muscle Milk is one of if not the most popular protein supplement among the casual lifting and exercise crowd, so it makes sense to focus on it in this context. More serious lifters general do not consume their products because most of them are fairly inefficient from a cost and protein / calorie standpoint.

Optimum Nutrition's products are the gold standard for more serious lifters when it comes to protein powder. Quest bars are probably the gold standard for protein bars.

</comment></comment><comment><USER15> Here's examine.com:

30g of protein in one sitting seems to be a myth: [https://examine.com/nutrition/how-much-protein-can-i-eat- in-...](https://examine.com/nutrition/how-much-protein-can-i-eat-in-one- sitting/)

There's really no suggestion that too much protein is harmful, unless you already have damaged kidneys. What _might_ be is very suddenly drastically increasing protein intake, or taking a _lot_ after prolonged fasting: [https://examine.com/nutrition/can-eating-too-much-protein- be...](https://examine.com/nutrition/can-eating-too-much-protein-be-bad-for- you/)

<comment><USER16> AFAIK high protein consumption without enough water will be bad for you. And most people don't drink enough water. So they need to be aware of this.

<comment><USER15> Do you have a reference for that? I'm interested in learning more. The linked article says:

 _It is generally recommended to consume more water during periods when protein intake is being increased. Whether or not this has biological basis is not known, but it may be prudent to do._

I'm not sure why that recommendation exists if it's unknown if or why it actually makes a difference.

</comment></comment></comment><comment><USER17> This article seems like yet another diet fad article that focuses on one class of food in isolation, despite appearing to be an analysis of such. Of course Americans like to eat protein. I was a vegetarian for several years, and I came to know the feeling of being hungry in a certain way that was not satisfied by carbs or oil... it's the only thing you can't cut out.

It's just that Americans are assessing their diets more realistically these days. The change is really about what they're avoiding – carbohydrates. I know some people who strictly avoid carbohydrates, and their diets are composed almost solely of meat. It's basically the manly American man's dream that this diet now has modern socially justification.

Personally, I have a great interest in protein right now because I am recovering from celiac and have an esophageal dysfunction that makes it difficult to eat anything solid or semi-solid. Also trying to avoid the common 8 allergens (no soy, animal milk, or nuts) so that leaves even fewer liquid protein options. It's easy to get carbs and oils as a liquid, but for protein my current choices, which are almost I can tolerate, are vegan protein powder made from hemp, cranberry and peas, and bone broth. Unfortunately most of these products are geared towards weight loss, which is the opposite of what I need since I've lost 30 pounds since the beginning of the year, but it's easy to add calories as honey or coconut oil.

<comment><USER18> An very underestimated nutrient is fat. The Wikipedia entry on "rabbit hunger" has some very graphic descriptions: [https://en.wikipedia.org/wiki/Protein_poisoning](https://en.wikipedia.org/wiki/Protein_poisoning)

The human body can do without carbohydrates (the Inuit have some evolutionary adaptations towards a mostly-meat diet), but not without proteins or fats.

</comment></comment><comment><USER19> Nice to read an article like this by an actual lifter (who also happens to be a very good writer). I find that product to taste absolutely terrible, and assumed its popularity had to do with anything but its taste. Also I think the name is absolutely horrible. My anecdata has nothing to do with whether it's a good product, clearly

<comment><USER20> I'll plug True Nutrition [0] as probably the best source for bulk protein (and other) powders. Lowest prices, highest quality, and - most importantly - <USER2> product comes in an unflavored option.

Flavored protein products make me want to gag, since almost none of them can get it right. Occasionally a brand has a good chocolate, banana, or strawberry, but day in and day out, even good flavors get gross.

Unflavored protein drink instead of milk over cereal is a revelation, and squirting some chocolate syrup or Mio water enhancer into unflavored protein I find tastes better than any pre-flavored powder.

That said, PEScience peanut butter cup protein [1] is super legit.

[0] [http://truenutrition.com](http://truenutrition.com)

[1] [https://pescience.com/collections/protein/products/select- pr...](https://pescience.com/collections/protein/products/select- protein?variant=185086050330)

<comment><USER21> I've used True Nutrition for years. It's great for bulk protein.

With that said, I'm okay with the MM flavors if I need something quick on the go. I think I've just grown accustomed to eating and drinking things for 'nutrition' that I can get down almost anything at this point.

</comment></comment></comment><comment><USER22> > Concern-trolling attempts ("How much protein is too much?") can only > shadowbox confounding factors, like intake of animal protein (which tends to > be higher in saturated fats).

What does shadowbox mean?

<comment><USER19> Boxing without an opponent. It's a training method and happens to be highly effective at making you fitter, but it's just not good to improve your boxing skills per se.</comment></comment>


Show HN: python-appinsights – Revived Azure Application Insights SDK for Python - <AUTHOR> https://github.com/brennerm/python-appinsights <comment><AUTHOR> Background: Microsoft stopped developing this SDK September last year¹. Right now they are suggesting to use the OpenCensus project². IMO this is too big of a framework if my only use case is to send a few metrics to Application Insights. Furthermore it does not support all features (e.g. tracking availability).

1 - [https://github.com/microsoft/ApplicationInsights- Python](https://github.com/microsoft/ApplicationInsights-Python) 2 - [https://github.com/census-instrumentation/opencensus- python](https://github.com/census-instrumentation/opencensus-python)</comment>


Tradeoffs of marriage. - <AUTHOR>

Hi,
(I wanted to ask this question to hackers, and till now never found a proper place to do so. I hope this is not outside the scope of HN, if yes, my apologies.)
I am working on a PhD (one year to finish) in experimental physics and it is a great time with lots of opportunities. I have a background in electronic engineering and I have taught myself a good deal about computers.
I love to build things, and want to do great work. There are some big challenges that I will be trying to solve. I also get lots of ideas for instrumentation, processes in my work. These are enough to take almost all of my mental space and I try to work on these 12-13 hours each day, everyday. I love working and find it very satisfying (even though failure rate of my experiments is about 75 % or more).
I want help in deciding whether I should marry. I am worried if I will be able to give enough time to either my s.o. or to work. My work doesn't put too many demands on how I live (apart from some discipline and healthy living), while marriage does. Marriage will also restrict my choices in career and movement. With kids, my responsibilities outside work will increase further.
On the other side, marriage is supposed to bring some fulfillment (companion, kids). I do have a need for company, but it is not too strong, and I have now become habituated of my condition. I am writing this as a 30 yr old person who doesn't have a partner, is an immigrant and can have a partner if he desires so. It may also be good for old age. Choosing not to marry will also invoke very strong response from my family and relationships.
If I suffer due to not marrying I can blame myself and others will not face many consequences. With marriage, 2-3 lives will be related strongly to mine, and that is more than I am willing to risk.
I would like to have your viewpoints on this. <comment><USER2> Do you have someone specific in mind? IMO, the decision to get married is a personal one and isn't linked to your career, even though it seems like it. What's the purpose of life to you? If you feel like marrying someone (after giving it some deep thought) then aren't they more important than your career anyway? If marriage is what you want, then yes, you need to spend time with your significant other, and you might need to tone down the time you spend at work. Tell people you have a family - they'll understand.

As a married guy, while marriage is technically a restriction, I don't see it that way at all. It's great having one (or more, when you have kids) other person to share everything with. You'll look at your career a whole different way. It's given me a greater level of focus knowing that peoples' lives are directly affected by my choices. In my experience it's only had a positive effect.</comment>


The desperate fight to keep old TVs alive (2018) - <AUTHOR> https://www.theverge.com/2018/2/6/16973914/tvs-crt-restoration-led-gaming-vintage <comment><USER2> Goodwill won't take them as donations anymore, and it costs money to dispose of one because of the chemicals in it.

The Commodore 8 bit crowd has been buying them up as there are ways to repair the C64 and other units and they used TV sets from long ago.

I remember when I got a C64 I had a Zenith black and white TV to work with it and got a color one later when Magnavox store near us lowered prices.</comment>


META-II in C - <AUTHOR> https://github.com/impeachgod/meta <comment><AUTHOR> Also see: <http://www.bayfronttechnologies.com/mc_tutorial.html> for an introduction and tutorial to META-II

</comment><comment><AUTHOR> META-II paper: <http://ibm-1401.info/Meta-II-schorre.pdf></comment>


Five-year-old boy's 15-page CV grabs China online attention - <AUTHOR> https://www.bbc.com/news/world-asia-46071811 <comment><USER2> The NYT article was more informative.

[https://www.nytimes.com/2018/11/01/world/asia/china-child- re...](https://www.nytimes.com/2018/11/01/world/asia/china-child-resume.html)

> Yong Zhao, a professor of education at the University of Kansas, said the > debate reflected widespread anxiety among Chinese parents about getting > their children into top schools. In China's test-dominated system, exam > scores determine where students go to college and what careers they can > pursue.

It's easy to forget how different other education systems can be.

<comment><USER3> Not that different from the US, outside the hacker news bubble. I have a high schooler and let's just say there's a lot of attention to three numbers right now - GPA, SAT, and ACT. Those numbers will have an outsized impact on my kid's life. Granted though, that there are still paths to a happy life, but just a little more "alternative".

<comment><USER4> I would agree. The west had a chance to reform their education systems to become different with the new information age, but most countries choose not to. In fact they have been going the other way. Today in most countries things like housing, grades, connections and insurance are even more important than it used to be. Turns out people really do not want to compete on similar terms in the open market.

<comment><USER5> You nailed it. I continue to be shocked by the naivete of the West in all things Asia--work practices, education, rule of law, protection of IP, role of women in society. This after having lived and worked in Eastern China for 3 years. Those abroad just don't get it. And with such a behemoth as a world partner, they aren't changing fast nor need to.

</comment></comment></comment></comment><comment><USER6> I read CVs all the time. 15 pages is far too long, he needs to condense it down to 2 pages max, and get a github account demonstrating his achievements. :)

<comment><USER7> Is a CV not supposed to be the long form, while a resume would be two pages max?

<comment> village-idiot Yes, but I'm under the impression that CVs are a few pages and more common for academics with long publishing and speaking histories.

I've never seen a CV in the business world, but resumes are of course very common.

</comment></comment></comment><comment><USER8> > The competition for seats at top schools in China is notoriously cutthroat. > In some cities, the wealthy and well connected pay large sums of money, > sometimes described as "donations," to secure placements in top programs.

So... exactly like the US then? This is how every top tier university operates. Ability to pay is something considered before acceptance for ALL students; and children of major donors are guaranteed entrance. It's not any different at earlier levels of education in the US either - it's pay to play.

<comment><USER9> No, not exactly like the US. Rather, it's similar for some schools. The US, fortunately, has a vast number of extraordinary universities.

At MIT for example, tied for the third best US university [1], they rank #137 on the median family income level among universities. That places them behind such schools as the University of Dallas, Virginia Tech and the University of Charleston.

Columbia is tied for the third best ranked US university. It ranks #89 on median family income. Those students are largely not elite rich families buying their way in.

The University of Chicago is also tied for third best US university. They rank #138 on median family income. Behind the university of Scranton, UNC Chapel Hill, and Xavier.

Cornell is ranked as the #16 US university, and comes in #87 in median family income.

California Institute of Technology is ranked #12. They're #105 on the median family income metric.

UCLA is ranked #19 in US universities, and ranks #353 on median family income among universities.

UC Berkely is tied for being the 22nd best university in the US. It ranks #214 on median family income, behind Babson, Mountain Saint Mary's, Vermont, and Willamette.

Carnegie Mellon is the #25 US university. They're ranked #81 for median family income.

Emory is the #21 US university, and ranks #120 on median family income.

The University of Florida is ranked #36 in US universities, and comes in #322 in median family income. You can go there for $6,000 per year in-state.

There are two dozen other top 50 schools I can add to this list, that rank far below what you'd expect on median family income.

[1] [https://www.usnews.com/best-colleges/rankings/national- unive...](https://www.usnews.com/best-colleges/rankings/national-universities)

<comment><USER8> This article (and I) wasn't talking about median income. At any of the schools you just named, a significant donation means your child is attending. How do you think they afford to give scholarships to so many students?

<comment><USER9> The article and the quote you reference, says that competition for placement is "notoriously cutthroat" and the rich often buy their way in because placement is so limited.

That isn't the case in the US among most of the top 25 or top 50 schools. You can buy your way in to some of those schools, for most of them you do not have to. That's the fundamental difference. The top 50 US schools overwhelmingly consist of middle class and middle-upper class students.

<comment><USER8> Ok, you don't have to buy your way in. But being ranked 300 in median family income out of 3000 universities isn't exactly encouraging. Even at the schools you mentioned, most students still come from the top 20%, save UCLA and Florida, with 48%.

<comment><USER9> It means to hit the median family income at those universities you have to come from the top edge of the middle class at least, that is true. That's not very surprising given we're talking about the median at very highly ranked schools. It's moving the goal posts quite a bit given the difference vs the elite rich having to buy their way in due to scarcity.

If you want to dramatically improve your odds of family success in the US, you want to roughly be in the top half of the middle class bracket or above. At least based on school access.

A lot of the top 50 universities do as well or better at accepting bottom 20% income bracket students, as second tier schools do. For reference, share of students coming from the bottom 20% income bracket (ie poor):

UCLA 8.3%; UC Berkely 7.3%; MIT 6.2%; NYU 6.1%; Florida 6%; Chicago 5.5%; Columbia 5.1%; Rice 4.9%; USC 4.9%; Harvard 4.5%; Boston U 4.2%; Brown 4.1%; Stanford 4%; Carnegie Mellon 4%; Duke 3.9%; Tulane 3.9%; Northwestern 3.7%; Michigan 3.6%

Lower ranked schools (but still top ~15%):

Rutgers 6.8%; Illinois 6.1%; Texas 6%; UMass 5.8%; Florida St 5.3%; Michigan St 5%; Oklahoma 5%; Ohio St 5%; Oregon 4.7%; Georgia Tech 4.6%; Oklahoma St 4.4%; Oregon St 4.3%; NC State 4.3%; Texas Tech 4.1%; Washington St 4%; Arkanas 4%; Texas A&M 4%; Alabama 4%; Pitt 3.7%; Minnesota 3.5%; Kansas 3.2%; Kansas St 3.2%; Iowa St 3.2%; Illinois St 3%; Auburn 2.6%; Virginia Tech 2.3%

As a percentage, Chicago takes as many poor students as Oregon St; MIT takes more than NC State; Harvard takes as many as George Tech; Stanford takes more than Kansas St. And so on.

The schools that rank badly on high median family income and low access for poor students are who you'd expect: Princeton, Yale, Vanderbilt, etc. Notre Dame is a particular standout for being terrible, with a median income at $191,000 and only taking 1.6% from the bottom 20% income bracket.

</comment></comment></comment></comment></comment></comment><comment><USER10> I can't wait to bring china-like jobs to the united states. it will be good, honest!

</comment><comment><USER11> tl;dr bullshit social media story picked up by other media</comment>


The Sparse Manifold Transform (2018) [pdf] - <AUTHOR> https://arxiv.org/abs/1806.08887 <comment><USER2> Interesting. Here is a talk on the topic: [https://www.youtube.com/watch?v=C2_5QFQZGvM](https://www.youtube.com/watch?v=C2_5QFQZGvM)</comment>


The plot thickens for a hypothetical "X17" particle - <AUTHOR> https://home.cern/news/news/physics/plot-thickens-hypothetical-x17-particle <comment><USER2> Recent related threads:

[https://news.ycombinator.com/item?id=21616084](https://news.ycombinator.com/item?id=21616084)

[https://news.ycombinator.com/item?id=21616381](https://news.ycombinator.com/item?id=21616381)

</comment><comment><USER3> Good breakdown of why this is probably just noise [https://www.forbes.com/sites/startswithabang/2019/11/26/this...](https://www.forbes.com/sites/startswithabang/2019/11/26/this- is-why-the-x17-particle-and-a-new-fifth-force-probably-dont- exist/#598bdf3d2e82)

<comment><USER4> I find it interesting that the top voted rebuttal to a CERN hosted article is a Forbes one.

<comment><USER5> You need to look at the source. Most Forbes content is bad, but this is Ethan Siegel's blog, which is usually pretty good.

The CERN article is also good, and the two don't actually contradict each other -- nobody is rebutting anybody else. An anomaly which has only a 5% chance of holding up still _is_ extremely exciting. Probably not worth all the media attention it randomly got, but definitely worth more investigation by physicists.

<comment><USER6> It's that moment where they're about to draw the last number of this week's lottery and you've matched every number so far.

</comment></comment></comment></comment><comment><USER7> > Examining the number of electron–positron pairs at different angles of > separation, the researchers found an unexpected surplus of pairs at a > separation angle of about 140º.

I keep reading about this "angle" in regards to beryllium-8 and X17. Can someone ELI5 for a non-physics person what it means for particles to come off at a certain angle?

<comment><USER8> Its pretty much what it sounds like, when there are particle collisions or decays, the particles come off at certain characteristic angles relative to the beam that are signatures of certain types decay and energies.

[https://en.wikipedia.org/wiki/Rutherford_scattering](https://en.wikipedia.org/wiki/Rutherford_scattering)

In this video, look for the forks that happen in the vapor trails being generated, that is a particle collision, and the corresponding sort of angle being talked about here.

[https://www.youtube.com/watch?v=-B2cvZgLToY](https://www.youtube.com/watch?v=-B2cvZgLToY)

This technique works because the air is essentially super saturated with moisture, so even very slight atomic level disturbances will cause the water to condense to form mini "clouds" (hence the term cloud chamber).

Its difficult to find videos about, but antimatter pair production will cause patterns that look like this for instance

[https://i.stack.imgur.com/9CKRA.jpg](https://i.stack.imgur.com/9CKRA.jpg)

muons, electrons, and alpha particles of different energies will will cause patterns that look like this

[https://i.stack.imgur.com/NwNcS.jpg](https://i.stack.imgur.com/NwNcS.jpg)

and so on.

Check out [http://avtanski.net/projects/cc/virtual_cloud_chamber.html](http://avtanski.net/projects/cc/virtual_cloud_chamber.html) and [https://www.nucleonica.com/wiki/index.php?title=Help%3AVirtu...](https://www.nucleonica.com/wiki/index.php?title=Help%3AVirtual_Cloud_Chamber) and see if you can identify some of the particles :)

<comment><USER7> Thanks very helpful, the angles being signatures to help determine what forced/objects are involved makes a lot more sense to me now. That's always been something I've struggled with in biology/chemistry and physics is the higher level abstractions used to infer smaller phenomenons that are not as easily observable.

I'm too used to compsci where it's more explicit and every "but why?" doesn't lead you down a Wikipedia rabbit hole.

Edit: that cloud chamber video is very cool!

</comment></comment></comment><comment><USER9> I find it interesting that there is no mention of NA64's sensitivity to the particle. Is it possible to say from the Atomki institute experiments what is the rate of production expected at NA64? Somehow LHCb will be able to refute or confirm but only by 2023.

<comment><USER10> This talks might be interesting to you: [https://indico.cern.ch/event/827066/contributions/3590884/at...](https://indico.cern.ch/event/827066/contributions/3590884/attachments/1938785/3213894/gninenko- na64-pbc-05-11-2019.pdf) (see page 10)

There is hopefully also a DarkLight run at JLAB or something similar at MAMI to test the remaining phase space.

<comment><USER9> Thanks!

</comment></comment></comment><comment><USER11> If you understand Spanish, here is a video of a complete and easy to grasp introduction to what this new force is, what it means and how it was discovered:

[https://youtu.be/u_O2hW2J8TE](https://youtu.be/u_O2hW2J8TE)

</comment><comment><USER12> Is there any new information in this article? I'm not seeing anything that hasn't already been reported on.

<comment><USER13> The "plot thickening" is that this is CERN's take on the matter, which has been following it for years -- so to them, the same arxiv article constitutes "new information" that came as just plain news to everybody else.

Other than that, there's nothing here you haven't seen before aside from a few interesting quotes from CERN people.</comment></comment>


Ask HN: Interview Questions for Front End Developers - <AUTHOR>

I am trying to aggregate a list of some good questions that could be asked for a Front-End Developer interview. What questions do you know of or have you used in an interview? <comment><USER2> Create a money exchange calculator, that is bi-directional, as in $ -> €, € -> $. It covers basic arithmetic, event handling and maybe include an API call to one of the exchange rate API providers for ajax / JSON. The HTML / CSS should be based on a popular framework like bootstrap or foundation.

Also some basic questions that test theoretical knowledge like difference between null and undefined, prototype chains, function scope, module pattern etc.

</comment><comment><USER3> How to parse JSON response with jQuery?

The problem with using posted questions or ones from online is that people may have already seen or look up the answer. This could cause problems getting a feel for experience and or skill level. I think for a frontend developer I would like to see what they have built. What frameworks they prefer and why.

</comment><comment><USER4> Create an infinite scrolling effect for an image gallery. This will test out the following:

* Ajax * Event handling (scroll) * Basic arithmetic (e.g. when to trigger a new request based on % page scrolled) * Template/DOM insertion * Thinking about edge cases (e.g. what happens when the page is resized, or the ajax request has no more elements to return)</comment>


Invented here syndrome - <AUTHOR> http://mortoray.com/2015/02/25/invented-here-syndrome <comment><USER2> There's a lot of truth in this post but this line of thinking also plays into our own prejudices. I do often look at third party code and think it's pretty crappy, but then I need to remind myself that my own code is far from perfect!

More importantly, though, we tend to underestimate both how long it will take to implement something ourselves and _especially_ how much it costs to maintain over time. If you can use third party code from a popular and active project you get a huge amount of testing, bug fixing and other maintenance from the community over time. If you implement in house then you've just given yourself an extra burden for the life of your project.

<comment><USER3> > If you implement in house then you've just given yourself an extra burden > for the life of your project.

If you are doing this work for an organisation, you can also argue that it is professionally irresponsible. You are certainly unlikely to be there forever to pick up the tab for that. Coding in house is a toxic line of thought endemic in mid-level developers who haven't yet had exposure to full lifecycle costs of custom code.

(And ironically the problem of so many crappy libraries is precisely due to people succumbing to NIH rather than uniting around a standard solution.)

<comment><USER4> While I agree it'd be nice for their to be unification, rather than a fragmented set of varying libraries, the one size fits all solution tends to be a maintenance nightmare. I guess we just have wildly different experiences, but mine is such that adding a third party dependency is typically a major liability and often originates from less experienced developers.

Adding a dependency is a burden. You don't have direct control over the evolution of that code. You have to keep track of the changes. If you're lucky, the library will have a changelog, but that's sorely lacking in most projects. Blindly upgrading will bite you, so if you have a product that can't suffer downtime, you really need audit that code for every upgrade. Good luck if you've determined that the version you have is sufficient, so you've locked it down, but then a security issue is found . . . winding back patches like that can be an exercise in futility. Oh, and then there's the wonderful world of transitive dependencies.

NIH for everything isn't ideal, naturally. But pushing everything out to 3rd party libs has its own set of problems that in many cases are worse. In my experience, a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain.

<comment><USER3> > a more experienced developer knows when to make the trade-off and solve the > problem in-house with a much smaller body of code that's far easier to > maintain

Indeed, but this is hopefully obvious to all of us. My point is that the cost of maintenance is vastly higher than is ever really understood. Most code is written in the context of delivering a project, and here the highest cost is considered to be getting functional code out of the door (even the first set of bugs is often overlooked).

I'd propose the counterintuitive and unpopular view that the cost of development is the tiniest fraction of the lifecycle cost of lines of code when you factor in things like bugs, keeping up with security, adapting to environment changes, modifications due to new requirements, and probably most importantly the multiplying effect of adding new moving parts which makes each piece of code in a solution more expensive to write and maintain than the last.

I'm perfectly aware that this will seem ridiculous and in some ways it is a little aggressive to make the point, but as evidence I would consider how many work years are spent on libraries which contain a tiny part of the functionality that is contained in useful software.

Therefore the trade-off, while being about the right things, is very rarely correctly sized.

</comment></comment></comment></comment><comment><USER5> I don't know. Based on my experience I firmly believe that between not- invented-here vs invented-here syndromes, many more projects fail because they try to do too much themselves. Especially in startups. For anything that is not the laser-focused core offering of your product, pick a good enough library and be done with it.

Invariably, most problems are such that you can get 70% of the implementation done (the fun part) with a reasonable amount of work, but the last 30% (all the little details that you didn't thought of) take +70% of the time. And you also need battle-test it. For example, React is interesting, because it is battle-tested by Facebook, not just because of the approach it took to the rendering.

Good candidates for underestimating the amount of work:

Anything with i18n and l10n (dates, money).

Anything with threads (futures and promises library).

Anything with small errors causing cumulatively bigger errors (scientific calculation and money).

Anything integrating with the real-world outside of your app (sending email)

Anything with charts.

</comment><comment><USER6> I think the real problem is actually the sunk cost fallacy, where often by the time you discover the integration wasn't worth the effort put into it you feel that you should just move on and leave it be. But in practice, something that's a pain to integrate is usually also a pain to maintain that integration.

In the end you can't really know if something is going to save time unless you actually try it most of the time. But if you try it and it becomes clear it's going to be a drain it might be time to throw it away and do it better.

Of course, there are a few vultures out there that hang on the entire industry because the task they perform is so complex almost any attempt at reinventing their wheel will fail in some non-obvious way. See for example ICU for unicode text processing.

</comment><comment><USER7> I've done this a few times in recent memory and on at least two of them it's bitten me already. In one instance I wanted to use an external service to handle email drip campaigns. It turns out that introducing an external service added a lot of synchronization problems I was not prepared for, and I'm still dealing with those today. In another instance, I wanted to use a workflow management system. The DSL for job specification ended up causing more headaches than it resolved and the tradeoff for the additional monitoring capability it was adding wasn't worth it. I try to think harder about the specific parts that I do want to write and which parts I will really gain from by outsourcing.

<comment><USER8> Email, deliverability in particular, is a rabbit hole.

Its easy enough to get it set up and "basically" working, but not. Basically, you're using in your favorite language's mail sending library to send an email out.

The next level is figuring out all the standards surrounding email that those third party systems know and implement for you. This will help deliverability, to a point.

Beyond that, once you hit enough volume, there's best practices should have always been doing but you learn from experience and need to abide by or else you're not getting anything through even though you do all the previously mentioned stuff.

If I were to develop an app with low amount of sent email, I would be okay with doing the above myself. But I'm also familiar with the process by now.

Beyond that, theres continuous monitoring of deliverability and reputation, tweaking your sending algorithms (you don't just send email as fast as you can generate them, right?), keeping up with how email providers are changing their rules over time, maintaining your relationship with people who work at major email providers, and more I probably never had to get into.

You can easily have a team of people dedicated to ensuring your email doesn't just end up in the spam folder, or being rejected outright.

<comment> lost-theory Agreed. That's why it might make sense to fight NIH on the general problem of sending emails, but to give into NIH when deciding to use an "external service to handle email drip campaigns" vs. building it in-house. That type of problem is much more specific to your needs and attempting to outsource it could cost you more time and complexity than it saves.

Using an ESP for delivering email is a no brainer in most cases.

</comment></comment></comment><comment><USER9> I've seen more junior developers fall prey to this because they were not comfortable writing the functionality. A good engineer balances the two needs and gets it done right. Sometimes that involves contributing to the third party libraries themselves.

</comment><comment><USER10> I'm not sure the authors understands what the NIH syndrome ([http://en.wikipedia.org/wiki/Not_invented_here](http://en.wikipedia.org/wiki/Not_invented_here)) is about. It is about writing everything yourself. IMHO the following paragraphe is highly symptomatic for that:

        A great mass of libraries, modules, code, and other
        software products, available on the net are either
        crappy in their own right, or simply not suitable to our
        project. Forcing things to work together can be costlier
        than simply writing the required code on our own.

In the context of software development, NIH syndrome doesn't mean that you use libraries not invented here but that you re-implement everything on your own.

<comment><USER11> I think the author understands the NIH syndrome just fine, and starts the whole post describing the IH syndrome as the extreme opposite of NIH pretty well, where one is ready bend over backwards to use a subset of a 3rd party library, even if it might be easier and quicker to implement the desired functionality yourself.

        Are you afraid to write code? Does the thought
        linger in your brain that somewhere out there
        somebody has already done this? Do you find yourself
        trapped in an analysis cycle where nothing is getting
        done? Is your product mutating to accommodate third
        party components? If yes, then perhaps you are
        suffering from invented-here syndrome.

<comment><USER10> Could be I got lost between thesis and anti-thesis.

</comment></comment></comment><comment><USER12> I can relate to this. I researched a bunch of Ruby gems for "feature flags" a while back and didn't find any that worked for our needs, so I wrote the code myself, and it was super easy. On the other hand I'll choose Devise over DIY authentication every time. . . . :-)

</comment><comment><USER13> My general heuristic goes on the following questions:

-> _Is this project going to outlast my time on it?_

-> _Is the problem I 'm solving something that can be done in less than a couple pages of code with comments?_

-> _Is there a minimal open-source library out there that solves this problem for my language?_

-> _How many variants of this problem am I going to face?_

-> _Are other engineers than me going to be working on it concurrently?_

-> _If there is a library already out there, does it have good documentation?_

Those usually guide me pretty well, and in the event where I end up writing my own code, I look to either contribute to an existing library (yay pull requests) or to publish my library for other folks to use.

</comment><comment><USER14> One advantage of rolling your own is that you only need to consider your (your own, your employer's, ...) specific needs, and sometimes that added flexibility is well worth the effort.

Especially once those needs change, you can simply change your solution rather than beg some company or open source project to implement that change for you or try to get some patch accepted or maintaining it yourself. _Sometimes_ that is a big advantage.

On the other hand, if your hand-rolled library/application/service/whatever is built by a single person and that person leaves the company, you might be royally screwed. About a year ago I had the, um, honor of taking over maintenance of a bespoke application developed in-house (by a single guy) to make up for some shortcomings in our ERP system (which can, in theory, be customized, but 1. it has to be customized in Visual Basic Script, and 2. the vendor makes no guarantees whatsoever that your customizations will still work after the next upgrade).

It has _mostly_ worked out OK, because the guy that left coded in a very readable style, but when I deployed an updated version of the application, the accounting department complained that things stopped working which _used_ to work. But when I looked at the source code, they should not have worked at all, because the code was not there. So probably the version the accountants had been using before my update was not built from the version of the source code I was given (not to mention that the code was not maintained using any kind of versioning system).

TL;DR - in the case of small-ish applications (depending on how unusual/special your needs are and what amount of resources you can afford to invest) I believe there can be big advantages in rolling your own, but you need to be aware of the risks. I've seen a few cases where companies had kept using bespoke applications for ten years and longer, even though they were clearly broken / out of sync with the company's needs, because nobody was left to maintain them.

EDIT: Just to be clear, I am thinking more at the level of (small) applications than libraries. With libraries, I prefer to use existing solutions, for a lot of reasons, many of which other participants have already pointed out.

</comment><comment><USER15> I've seen this happen so many times. "We can't use X because it doesn't come with library Y!" And then they point to their favorite alternative to X, and note that it does have library Y, and ignore just how _utterly terrible_ that library is.

Sometimes it's better to rewrite a library yourself than use an existing one that gets in the way as often as it helps.

<comment><USER16> > Sometimes it's better to rewrite a library yourself than use an existing one > that gets in the way as often as it helps.

Sometimes, but not most of the time. Most of the time your own library will be just as terrible as the one you were trying to replace. This is especially true when it is done by someone who is not good at designing APIs. In then end you then get something that is barely documented, slow and full of bugs. I would know, I have removed more than my fair share of crappy inhouse libraries from projects.

</comment></comment><comment><USER17> Or maybe different people have different strengths? Look, I like to tinker at all levels of the stack, but I know what it takes to, say, write a correct web server. I am not going to write my own unless I must (did this at least once).

Some people prefer to re-use existing code and are good at integrating existing pieces. Others are good at writing purpose built stuff from scratch quickly. And even that is spread across technologies. I can write an async task manage, but can't easily create a CSS grid system. Just don't get stuck in the "built here" or "not built here" camp and you'll be fine.

</comment><comment><USER18> Additional bonus for rolling your own: not having to deal with restrictive, ambiguous or outright bizarre licensing terms and, in the case of SAAS, that the service or its best API will become unavailable with minimal warning.

</comment><comment><USER19> I haven't yet worked in a shop where I thought they should have spent less time buying products, and more time inventing things. Obviously there have been some library choices that have been regrettable but there is no shop I've been to that has a general cultural problem of not building enough things. (Background enterprise)

But when I have seen someones make an error in judgement, I have noticed that they realize it much more quickly when integrating software then when building it themselves. I suspect because of the attachment that quickly grows for one's own code.

</comment><comment><USER20> My company so prefers outside solutions that sometimes we engineers joke that the best way to get your code used is to open source it and let management think it's from outside the company!

</comment><comment><USER21> Some well structured projects actually _do_ allow you to use only part of the library - in JS-land you can:

        require('library/just/this.js');

Of course, it takes effort to make that work, but I'd still try to do it, because if something is confusing me about almost any library then the answer is a quick Google search away. If I wrote it myself I'm stuck.

</comment><comment><USER22> I briefly worked with a startup that has built their whole system using Python (though they use things like ElasticSearch, so they also run the JVM). The programmers at this startup are very intelligent, and very thoughtful. There are 4 main programmers. Their background is a mix: some of them were initially scientists, some were computer science engineers. They are all in their late 20s and early 30s. The startup began in 2011.

Because they are so thoughtful and talented, whenever they see a flaw in a 3rd party library, they give up on that library, and they try to write their own.

So for instance:

They tried using Chef for configuration, but they didn't like Ruby. Then they tried Ansible, but they found it immature. The tried Puppet, but didn't like that it had a central daemon. So they started writing their build/config system, which they released as open source. Their system has some unusual ideas, a heavy reliance on bash, and an emphasis on supporting a polyglot system. However, this took a lot of time that could have been directed at the specific needs of the startup.

They decided they would need a system of dependency injection. In Python it is common to configure some variables at the level of the module, but they felt this lead to tight coupling. They did not like any existing system for dependency injection for Python, so they wrote their own. They released this as open source. Their DI system borrows a lot of ideas from Angular. It is clever and they have long debates about how to make it better. But this also took time that could have gone to the specific needs of the startup.

They needed a framework that would allow them to serve a website out over Nginx. They reviewed all of the existing Python web/application servers. They found flaws in all of them: Zope, Pylons, Flask, etc. They decided to build their own. They based their work on Flask but they added a lot of their own unique ideas. They released it as open source. It has been a big effort and it is still missing certain features. For instance, they started off assuming that all of the pages of their site would require a login. When they eventually had to add in some pages that did not require a login, they had to re-work the way they were handling security and authorization. All of this has taken time away from the specific needs of the startup. And, of course, their software may have security flaws which they have not yet discovered. Although it is open source, I don't believe anyone else is using their software.

They decided they needed a way to enforce contracts on the structure of the documents moving through their system, and they wanted a system that could work almost exactly the same in Python and in Angular. So they built their own library for validating the structure of documents. They built out a whole vocabulary for the "types" in their system, using types which were generic enough that they could work in both Python and Javascript. It is an interesting system, but it takes at least 25% of the time of the most senior engineer. If they did not write their own system, he would have at least an extra 10 hours a week to put toward tasks that are specific to the needs of the startup.

They wanted to store JSON but they did not like any of the JSON document stores that were available in 2011/2012\. They love PostGres. This was before PostGres had a JSON column type. So they decided they would store JSON in PostGres as a string in a TEXT column. They wrote a library that serializes and deserializes the string. They built this as a layer on top of SqlAlchemy. Their code is very clever: you can query the database with their ORM and you always get back objects, you never have to think about JSON as a string. In some ways, they have reinvented the idea of an "object database" that was popular in the late 1980s and early to mid 1990s. These are clever ideas, though it took time away from the actual needs of the startup.

I could go on. They wrote their own cache system, their own system for transforming data structures, etc.

They are thoughtful. When adding a new feature to one of their libraries, they have respectful debates that sometimes last 2 or 3 or even 4 hours. They release everything as open source. They are trying to help the Python community. But it adds up to a huge tax on their time, and it takes them away from the needs of the startup. The founder/CEO is not technical, and I think they often wonder why things take so much time.

With startups, it is especially true that "the perfect is the enemy of the good." Their perfectionist streak takes them away from the needs of the company. They pursue an ideal of absolute brilliance, though they often don't have the time they need to make their libraries as good as what they dream of.

Having worked with them, I've gained a new respect for the idea that startups should, as much as possible, just use what libraries they can find. All libraries have their quirks, but it is an illusion to think it is cost effective to spend your time re-inventing what's out there.

<comment><USER23> Do you have links for any of these released systems?

</comment></comment><comment><USER24> Here's an analogy: McDonald's Big Macs. Is the code in question part of the Special Sauce(TM), or is it just something like the buns? McDonald's makes the Special Sauce, but I bet they just buy the buns.

If it's not part of your special sauce, if you can buy it, do so. Spend your time on the special sauce.</comment>


Facebook, One Year Later - <AUTHOR> http://www.theatlantic.com/business/archive/2013/05/in-facebook-we-trust-what-really-happened-behind-the-biggest-ipo-flop-of-our-time/275987/ <comment><USER2> I wonder how common this is amongst retail investors: buying things they have no business buying. Whether it's an IPO or an options contract, there's a great deal of complexity behind many financial instruments, and just because your brokerage gives you the opportunity to pull the lever it doesn't mean you're qualified to do so.

On the other hand, it's hard to work up sympathy for the woman in the story. Yes, she wasn't privy to behind-the-scenes details. But it sounds like she put less research into her $200K "investment" decision than she did with the last car she bought. The Atlantic may have left out the details of her late-night scouring of web pages for information, but as a proxy for retail investors in general it's probably accurate.

Here's the only thing a retail investor needs to know about IPOs: FB isn't the exception, it's the rule. Buy an IPO on opening day and the vast majority of the time you're going to lose money. Why? (And I wish I could bold and underline this.) Because the IPO isn't to make _you_ money. Stay the hell away from them unless you know what you're doing. And you probably don't.

EDIT: maybe I'm mis-remembering, but didn't the problem of mobile users and ad revenue come out _before_ the IPO day?

<comment><USER3> It is not the responsibility of the purchaser to know information which is purposefully withheld from them. From the article

> Scott Sweet's multi-billion dollar hedge fund client flipped the stock at > $42. His subsequent short made his firm its "largest profit of the year," > Sweet said. There's "no way" a retail investor could have known about the > lowered projections, unless he or she "had a friend at a multi-billion > dollar institution," he added.

Please explain to me, when information is withheld from the purchasers and only specific clients notified as to circumstantial and meaningful changes to the state of the offering, how anyone could ever "know what you're doing?' In fact, Morgan Stanley was actively misleading investors by continuing to adjust the specifications of the offering to make it look better.

Analogy: If an automaker produced a new car which was _secretly_ designed to become worthless (engine would fuse together) after 3 months and only told one rich people not to buy it, would that be fine? What if there come back was 'you could always open the hood and see our computer components which execute after 3 months, its not our fault you don't _know what you're doing_ '

<comment> UVB-76 My understanding is that the information was not _withheld_ from retail investors; rather, it wasn't _actively disseminated_ to them, and the significance of the information impressed upon them.

The reduced revenue estimates were public information; I recall reading about them myself before the IPO took place. If someone had put me in charge of billions of dollars and told me to take a position on the Facebook IPO, I would have shorted the stock, as many others did.

The crux of the issue is that wealthy institutional investors had analysts at their disposal to point out the revised revenue estimates, and retail investors like Swaminathan didn't. Retail investors were ill-prepared for the IPO, and they got burned.

<comment><USER3> They're ill prepared to consume the information in the format its delivered (if it is delivered at all). Notice, the revised S-1 doesn't say the _amount_ of the adjustment, you had to receive that from Facebook via another channel. So, it doesn't really have to do with special analyst job knowledge, it has to do with special treatment.

I mean, " _actively disseminated_ " seems a bit generous. They call 3 institutions to let them know meanwhile individual (notice i'm intentionally not saying "retail" because thats become some sort of in-crowd, brow beating, bullshit term for shaming regular, non-hedge fund investors) are left to read smoke signals. Its not that the institutional investors "had analysts at their disposal" its that the systems is built to make sure institutional investors and hedge funds get information others don't.

You can say what you want, but the quote from the hedge fund manager seems much more clear then your opinion, and he's a domain expert who took part in the situation.

>"There's "no way" a retail investor could have known about the lowered projections, unless he or she "had a friend at a multi-billion dollar institution," he added."

</comment></comment></comment></comment><comment><USER4> Granted, she was extraordinarily foolish to have gambled her entire life savings on one stock's IPO. However, this is where things fall apart for me:

</comment><comment></comment><comment></comment><comment></comment><comment>

She turned her attention to her computer screen only to realize that there was no sign of her having voided the order. She kept refreshing the page in hopes of seeing the notification. When no cancellation report appeared, she called her stockbroker at Vanguard. "What's going on?" she asked.

If the cancel order was placed, then it's probably cancelled, the broker told her. She got off the phone and went back to her computer screen. There was no sign of cancellation. She called Vanguard again. This time, she says, she waited on the line for a long time, but no one came to take her call.

Meanwhile, Facebook stock opened at 11:30 a.m. The mysterious delay was due to technical glitches. NASDAQ's electronic trading platform couldn't handle the high volume of trades. In the first 30 seconds, around 82 million shares were exchanged.

</comment><comment></comment><comment></comment><comment>

Am I reading this correctly that she attempted to cancel the order and it just failed? Is that really tolerable?

<comment><USER5> She only lost about 10% of her life savings on that trade on the first day.

"Her son advised her to hold onto her shares until she either resolved the matter with Vanguard or the price bounced back."

That would be an interesting malpractice lawsuit, mom vs son. Just sayin.

How dare her trade not profit! I know, file a lawsuit for a 400% rate of return for, um, well, not winning in the casino, thats what.

This is what is known in the business as catching a falling knife. By the time the legal stuff wrapped up, she lost more like 90% of her life savings as the stock cratered. A legal maneuver attempting to cash in on the situation was the gamble that lost most of her money because she caught a falling knife and stubbornly refused to let go. Really its two back to back gambles both of which failed.

<comment><USER6> If she tried to cancel the order, the broker should have been able to cancel the order for her. They had over an hour to work with -- if it were their own money, it'd have been handled in milliseconds.

It's standard to blow up the damages figure in the initial lawsuit filing. Big companies do this EVERY SINGLE TIME. Yet this woman does it and she's the greedy one who won't take responsibility?

Vanguard had one job here, they failed at it, and they should have either settled with her for her first-day losses and no punitive damages immediately or lost in the lawsuit with bigger damages eventually. Of course, the game being what it is, they just won eventually.

<comment><USER5> "Vanguard had one job here, they failed at it"

How so? She clicked buy, did she not? And she got exactly what she wanted. Quite awhile later, she changed her mind about what she wanted. Oh well.

Its like buying a lottery ticket, then after the numbers are picked, deciding you don't want it anymore and trying to return it. You can get away with that kind of stuff at walmart or target, not so much at the lotto kiosk or the stock exchange. She had 12 years of stock trading experience per the article. Not as much as me, but she didn't exactly fall off the turnip truck the day before, either.

<comment><USER6> Oh come on. She changed her mind over an hour before the market opened and they couldn't process her cancellation. She didn't ask for her money back after losing it, she asked to stop the trade before it was executed and they failed at that for over an hour. Are you seriously not getting that distinction?

It's not like buying a lottery ticket and deciding you don't want it after the numbers are picked. It's like starting to buy a lottery ticket, then changing your mind, and the clerk punches you in the face and takes your wallet, giving you your lottery ticket anyways.

I understand that it wasn't on purpose but in most industries if you fuck up and cost your customer a lot of money then they're going to have legal recourse against you.

</comment></comment></comment></comment></comment><comment><USER7> Regardless of you how feel about FB, Banks, etc... In this case, the IPO underwriters DID serve the founders/company, which is their job.

Meaning, a "pop" means the IPO was priced too small, giving the early investors/founders/employees a low price, and giving the first-day IPO purchasers (who did no work, & are just gambling) the benefit of that new, higher price.

No "pop" means it's priced about right, and serves the interest of early investors, who took far more risk & often built the company.

<comment><USER8> The underwriter's job is a little bit more complicated than just maximizing the offering for the company. They actually serve many interests including those of their own clients and stakeholders.

A "pop" does not necessarily mean the issue was underpriced. Besides, an increase in share price _benefits the founders too_

This issue didn't just fail to "pop," it subsequently tanked which suggests that it was overpriced/oversold and while Facebook, Inc. received more cash for the offering, the net value of the enterprise was worth less because of it.

Stock is a form of currency too. For compensation, acquisitions, and more. I think Facebook was out to get all they could, probably still expected a pop (hubris) and the bankers who did the issue let them because they're all shells of their former selves, and they were hedged with the way the deal was structured anyway (greenshoe).

Think of it in terms of taking a cash-out refi on your home with an artificially inflated appraisal. You might maximize the cash you can get, but what's the value of that cash when the actual value of the house is realized and you're at break-even or worse, underwater? Is the bank just "doing their job" structuring deals that way?

</comment></comment><comment><USER9> Investing greater than 10-15% of your net in high risk stocks is crazy. If you look at Berkshire Hathaway 13F Facebook is nowhere to be seen. There is Amex, Coke, WAL MART, IBM... These corporations will probably be here in 2023. I have no idea about FB.

[http://www.sec.gov/Archives/edgar/data/1067983/0001193125132...](http://www.sec.gov/Archives/edgar/data/1067983/000119312513222307/d535016d13fhr.txt)

</comment><comment><USER10> What's the point of discussing how at fault a poor old retired widow is. Why don't we discuss of how deliberately vague the last minute update to S-1 was! (I was a banker who has written a few S-1s and I can imagine what kind of discussions precipitated when Mr. Ebersman dropped the 'bomb' during the roadshow - if only those discussions could be recorded) Facebook and its bankers broke NO law. But IPO investing doesn't have to be this big of a crap shoot for retail investors. The prospectus should put anyone, who cares to read and parse it, at equal footing with the institutional investors. That's where the law is lacking a bit. The prospectus can not include any forward projections and institutional investors get to see all of those BEFORE the IPO (of-course making them available will bring their own sets of problems). I wish you guys discussed that part here as well. Being non-bankers and non- lawyers (for the most part), you can come up with better solution, maybe?

</comment><comment><USER11> Link bait...

For more context, the real title of the article is " _Facebook, One Year Later: What Really Happened in the Biggest IPO Flop Ever_."

<comment><USER12>
      She'd never placed such a big bet on just one stock, but she felt a personal
      connection to Facebook. She had been using the site to connect with family
      and friends since 2009, and almost everyone she knew had an account.

Kind of like feeling a "personal connection" to a TV show you've been watching since the first season.

<comment><USER13> Technically, Facebook was around since 2004 and open to anyone over 12 since 2006, so she jumped in about 5 seasons in.

</comment></comment></comment><comment><USER14> I once read a candid remark by one of the big time players on Wall St. To paraphrase:

 _Only a fool plays the stock market without access to insider information_

</comment><comment><USER15> What the hell that lady was spending half of her retirement account on one investment. That is horrible financial planning no matter how the stock does.</comment>