Facebook's code quality problem (2015) - <AUTHOR> https://www.darkcoding.net/software/facebooks-code-quality-problem/ <comment><USER3> I look at programming as all design, whether deliberate or not. Martin Fowler drove the point home for me ([https://www.martinfowler.com/articles/newMethodology.html](https://www.martinfowler.com/articles/newMethodology.html)).

He said that some people drew inspiration from construction, where there are designers and builders. One or two highly paid architects draw up the plans. Then you can hire a bunch of cheap labor to build it, say a bridge. This belief leads to a dichotomy in software companies, where one person is the "architect" and others are just "regular" programmers --- often outsourced to the lowest bidder.

From Jack Reeves he cites the epiphany "that in fact the source code is a design document and that the construction phase is actually the use of the compiler and linker." There is little repetitive, mindless work in programming, because as most of you know, "anything that you can treat as construction can and should be automated." Therefore, "In software all the effort is design . . ."

<comment><USER4> I feel your sentiment, and usually oppose to the construction-driven approach you describe, but it is really easy to play devil's advocate here. I mean, let's just be realistic. There's nothing sacred in programming.

The fault in your argument is that there's no design/construction dichotomy, but rather a gradient: everything can be viewed upon as a design from close enough distance, and everything can be a construction looking from the high above. For business people all the programming is just very, very low-level construction, and there's no design to it. Damn, even hiring programmers and creating companies is just a construction stage to them.

And from the practical standpoint, the truth is that perceiving a lot of programming "just as a construction" just works. For the better or worse. It is cheaper and usually reliable enough to design the system in a way that a lot of the components would be plugins not depending one on the other that can be outsourced to anyone. Even if some fail, the system continues to work while you hire new people to rewrite some components. Sure, maybe it would be more efficient and "cool" to hire a really smart guy (or do it yourself, if you believe you can) to write it as really optimized monolith system, but if this isn't required, it is usually less risky to build something not so sophisticated, and improve it if need be. It is usually ok, that some parts of the system may fail. Fuck it, let's not lie to ourselves: there always _are_ some parts of the system that fail, whether you think it's "acceptable" or not, let's just take it into account.

</comment></comment><comment><USER5> I read Richard Gabriel's "Worse Is Better" essay in my first month hired as a professional programmer, that was almost 12 years ago. Since that time the lessons of that essay have only increased in significance for me, with this FB story as additional proof.

Their back-end code might be bollocks, and I can certainly believe that judging by how sluggish their FB app feels on my phone, but the fact is that they've conquered the Internet (together with Google and a couple of other companies). It's a fact that I personally hate, but they're still winners in the end.

<comment> aaron-lebo But it's not better, it is worse as clearly put forward by this article. ;)

We shouldn't attribute Facebook's success to poor quality code, unless we really believe that 429 people working that that slow sluggish app is productive. Do you?

Maybe Facebook would be in a better situation than they are if they had a firm foundation? What happens when a competitor comes along and knocks on their door? That mess of code becomes an anchor.

They succeeded not because "worse is better" but because ...they succeeded, maybe because they had the greatest social network in the world to expand within, or because of some other reason we don't know. But they didn't succeed because of worse is better, they succeeded in spite of it.

<comment><USER6> No one is actually arguing that worse is better. It's just a catchy title. A more accurate title would be "worse is faster than better, and being fast but mediocre is better than being slow and amazing."

Worse is better makes the observation that doing right thing slows you down. Often, an ok solution is much quicker to get finished than a great one. And it concludes that the projects that prioritize getting stuff done over code quality will suceeed.

Would facebook be as successful as it is today if it had taken longer to ship features, but maintained higher code quality? Who knows.

But the intuition in worse is better, which matches with my own experiences, is that making that trade off would have cost Facebook, as other faster moving projects closed the gap.

<comment><USER7> I agree with you that it's sometimes good to focus on getting things out the door fast instead of the code quality behind it. But surly there must be a point when the pendulum swings back and you should switch focus to quality. I would argue that Facebook have definitely reached the point where they own so much of the market and with their infinite resources they should be able to ship things with good code quality. Sooner or later the costs of supporting all that crappy software will make a dent even in Facebooks chest of gold.

<comment><USER8> They have written their own PHP interpreter haven't they? Thats a pretty good indication that they left some things too late. Saying that, if they have the resources where that sort of decision makes sense, then its probably not going to be too much of a dent in their pot of gold.

</comment></comment></comment></comment></comment><comment><USER9> "Exhibit C: Our site works when the engineers go on holiday"

Is not all so different from "Fewer patients die when heart surgeons are on vacation". Of course your site is going to be more reliable when nobody is changing it! You should be worried if reliable isn't the steady state, and it requires constant changes to stay up!

<comment><USER10> I also took issue with this part of the article; it seems obvious to me that rolling out new features would directly cause reliability issues (and the only alternative, of not rolling out new features, is, obviously, a cure worse than the disease).

<comment><USER11> I am not sure that most Facebook users would actually agree about this.

But then their view is slanted towards UI changes. Performance improvements and other subtleties are features too.

</comment></comment></comment><comment><USER12> It's hard to argue with the business sense of pushing out features quickly at the cost of code quality.

But I've learned that that there are two kinds of development teams:

(A) the teams that are "moving fast and breaking things" while "creating business value"

and

(B) the teams that are "only maintaining legacy code", "not getting anything done", "costing a lot of money" and "complaining too much" about code quality that team A wrote.

As an engineer, I've learned that it's less work and more rewarding to be on the (A) teams than on the (B) teams.

<comment><USER13> I like type (C) whose motto is "move fast and fix things" [https://githubengineering.com/move-fast/](https://githubengineering.com/move- fast/)

<comment><USER14> And yet [https://github.com/blog/2106-january-28th-incident- report](https://github.com/blog/2106-january-28th-incident-report)

<comment><USER15> I like how even the URL has a "bug" (year 2106?).

<comment><USER16> uh no. that's the id of the blog post

[https://github.com/blog/2105](https://github.com/blog/2105) [https://github.com/blog/2106](https://github.com/blog/2106) [https://github.com/blog/2107](https://github.com/blog/2107)

<comment><USER15> Aw, it looked so much like a minor mistake with the Y-M-D date format considering it happened on 2016-january-28th!

</comment></comment></comment></comment></comment></comment><comment><USER17> Some of FB's ~18,000 Obj-C header files from a post linked in the article: [1]

* FBFeedAwesomizerProfileListCardViewControllerListenerAnnouncer.h

* FBBoostedComponentCreateInputDataCreativeObjectStorySpecLinkDataCallToActionValue.h

* FBEventUpdateNotificationSubscriptionLevelMutationOptimisticPayloadFactoryProtocol-Protocol.h

* FBGroupUpdateRequestToJoinSubscriptionLevelMutationOptimisticPayloadFactoryProtocol-Protocol.h

* FBMemReactionAcornSportsContentSettingsSetShouldNotPushNotificationsResponsePayloadBuilder.h

* FBProfileSetEventsCalendarSubscriptionStatusInputDataContextEventActionHistory.h

* FBReactionUnitUserSettingsDisableUnitTypeMutationOptimisticPayloadFactoryProtocol-Protocol.h

oh my god

[1]: [http://quellish.tumblr.com/post/126712999812/how-on-earth- th...](http://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook- ios-application-is-so)

<comment><USER18> Those read like classes generated by tools. Or maybe I really don't want to think humans are capable of such names.

<comment><USER19> These are completely credible class names, just ask any Enterprise Java developer. I particularly enjoy FactoryProtocol-Protocol. Who would be satisfied with just a FactoryProtocol?

<comment><USER20> Yea, I was going to say, Java's almost got them beat with SimpleBeanFactoryAwareAspectInstanceFactory[1]

1: [http://docs.spring.io/spring/docs/2.5.x/javadoc- api/org/spri...](http://docs.spring.io/spring/docs/2.5.x/javadoc- api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html)

<comment><USER21> Invoking the Spring framework here is just cheating -- they have dozens of classes like that! :-)

Just the other day I was dealing with Spring's declarative transactional support. Here's a fun read: [http://docs.spring.io/spring- framework/docs/4.2.x/spring-fra...](http://docs.spring.io/spring- framework/docs/4.2.x/spring-framework-reference/html/transaction.html)

</comment></comment></comment></comment></comment><comment><USER22> I spent a few months at Facebook and left because of that. Not necessarily because of poor code quality but because of all the issues it was causing, and a culture of turning a blind eye to (or worse still, being proud of!) those issues. It's obviously true that quality of their code does not affect their market position, but it sure affects who they hire and who they retain.

<comment><USER23> That may be true. But in the end, does it matter?

Until we see someone taking market share away, I'd argue it doesn't. Facebook still retains top tier people regardless of any perceived quality problems.

Sorry you left. I just started here, and I do agree that what I feel about code quality isn't generally shared here. But as I get older, I start realizing that in the end, as long as things work relatively well at our scale and in our problem domain (we're not medical device software, we can fail) alls well.

<comment><USER24> It matters because profits are lower. 400 devs on an iOS app is not free.

<comment><USER23> But FB is a public company. If shareholders thought that was the case, they could vote with their dollars. Looking at the stock price, they seem to have no problem with the way FB is hiring engineers. The market is okay with it.

There's no reasonable way to say FB should have less engineers without being a high level director of the company.

<comment><USER25> > There's no reasonable way to say FB should have less engineers without being > a high level director of the company

I'm going to assume you don't literally mean only company directors can levy logical criticisms of a company.

Consider the fact that the FB app itself was built with a very small team to begin with and only once it became 80-90% feature-complete did the exponential growth in engineers suddenly become "needed".

I can understand why Microsoft needs tons of engineers. OSes are complicated and have lots of moving parts (drivers, file systems, kernel, etc) that are all absolutely required and must be constantly updated, even without bringing their other products into it. But Facebook? At its core, it's a single webapp that serves simple relatively static pages. Yes, at web scale, so it's not entirely trivial.

My explanation is that Google and Facebook face a similar dilemma: most of their revenue comes from a single, relatively simple core product. To really optimize that core product, they might need a couple of dozen highly skilled engineers, along with a lot of equipment to scale it.

But that's not why they hire thousands. It's because they're both constantly trying to branch out for growth. In terms of revenue it is fair to say that strategy has been a failure for Google and except for a few of the "bells and whistles" FB has added like IM, probably for them as well. This problem is caused by the way that tech companies are primarily valued by perceived growth potential rather than actual earnings. They can get away with hiring lots of useless people because capital costs in this industry are fairly low.

</comment></comment></comment></comment></comment><comment><USER26> It is ironic that a codebase with so many classes is likely to occur precisely because of dogmatic adherence to those "best practices" which were originally intended to improve code quality --- aggressive refactoring/modularisation being a likely culprit. What I think they really need is not more design, not more architecture, not more of anything but KISS and YAGNI.

<comment><USER27> The thing that having an overall architecture buys you is conceptual clarity. That lets someone much more easily understand what is going on. You need to have a minimal set of ideas that are well thought out and explained.

Just saying "YAGNI" and "KISS" doesn't actually make the resulting code simpler. Why? You do have _some_ things to build and refusing to lay out a plan for what that is going to be doesn't stop that. It just means that the complexity doesn't have a clear narrative

</comment></comment><comment><USER28> I would like to argue that, in most of these cases, it's not "code quality" that is at fault, but "design quality" (before coding) - which is often absent entirely.

The problem with design, in software, is not that most people forget to do it. It's that they never learn to do it. It always comes back to bite you.

I don't want to start a discussion on design, and how most people mess it up because of lack of skill or experience therein. But hacker culture seems to be allergic to design, and hacker culture seems to be what everybody strives for these days.

<comment><USER29> I think you hit the nail on the head. My motto for developing code is "make it simple as possible, but no simpler". Whoever, created a design that used 18,000 classes did not follow that rule.

</comment></comment><comment><USER30> I do think that FB, and most large orgs, have code quality problems. But the article does a pretty bad job at making its case.

> _" That's 429 people working, in some way, on the Facebook iOS app. Rather > than take the obvious lesson that there are too many people working on this > application, the presentation goes on to blame everything from git to Xcode > for those 18,000 classes."_

How does the author know that 429 is too many? How does the author know that FB's goals and functionality can be best achieved with fewer people/classes. This just reads like a classic "Why is Google so big, I can do that in a weekend" comment ([https://danluu.com/sounds-easy/](https://danluu.com/sounds- easy/))

> _" Our site works when the engineers go on holiday"_

This is pretty much universally true for any dynamic site where engineers are constantly adding new features. Change always comes with risks. Changing code is always more likely to break something in the very-short-term, compared to not changing code. I have a hobby site (shameless plug, [http://thecaucus.net](http://thecaucus.net)) which has been running in auto- pilot for the past year, and almost never breaks, because there are virtually no moving pieces. The fact that the FB site breaks more often when engineers are making changes to it, is just repeating a universal law of software development.

I do think that the organizational structures at most large companies are bloated, inefficient, non-transparent, and produce sub-par code. I had high hopes when I read the article's headline, but the arguments presented simply aren't very persuasive.

</comment><comment><USER31> I believe "our site works when the engineers go on holiday" thing is not fair. Of course that application is less stable when it's actively modified. There's no way to make it more reliable on weekdays than on weekends except for stopping the development altogether or maybe deploying on weekends.

<comment><USER32> No way at all? FB has a lot of servers and a lot of users. They have opportunities for quality practices that few other organizations get.

Here's a simple example:

Split the user population into 365* groups. Assign them to days of the year. Test new code only the group whose day has come up. Follow them until they stop having problems. Now you can deploy that to a month's worth of groups. All good? Deploy to everyone.

Yes, that means that you can't have more than 365 changes in simultaneous development. Tough.

*Yes, yes, leap years. Take a day off from deploying.

<comment><USER33> They graph the number of incidents. Even if a bad release impact only 0.3% of the user base, it's still an incident.

They have to investigate it, revert or fix the bad code and start the deployment process again.

<comment><USER31> Ack. Also, the system introduces a new problem: If you are deploying on weekend, most devs are not around to help solving the problem. Thus, the outages would be longer.

</comment></comment></comment></comment><comment><USER34> Code quality is important, but for an organization the size of the FB good systems engineering is much more important than good software engineering. If the overall system is organized sanely, failures of subcomponents (which happen due to software bugs, hardware, humans, etc.) can be isolated, firewalled and fixed in reasonable time without bringing the system down.

</comment><comment><USER35> As pointed out this is from 2015 but I'd love to hear some updated. Has any Facebook employee created newer presentations that discussed, say, their 18,000 iOS classes and the fact that in a single week 429 people contributed to the same iOS app?

I'd also love to hear an update to the "Our site works when the engineers go on holiday" claim.

<comment><USER36> I'd bet that the 18000 classes is just Thrift-generated stuff or whatever.

<comment><USER37> You don't have to bet, you can see them here: [http://quellish.tumblr.com/post/126712999812/how-on-earth- th...](http://quellish.tumblr.com/post/126712999812/how-on-earth-the-facebook- ios-application-is-so)

<comment><USER38> Even with a list my imagination is still not powerful enough to understand how an app like FB needs 18000 classes :(

<comment><USER39> It _needs_ them .. to keep all those programmers busy.

</comment></comment></comment></comment></comment><comment><USER40> Well when there is a codebase of the scale of Facebook's, with so many activate contributors of course there will be a code quality problem. I see so much stuff at Google breaking or becoming inconsistent too (away from the core search features).

Even if they didn't move fast and break things, they would still have code quality issues. It's just the nature of a huge codebase like they have. And let's face facts - the development process needs to be suitable to the type of problem being solved. This is not a life and death situation and users would value new features, more than extreme reliability and consistency.

</comment><comment><USER41> It is worth noting that when something goes viral we still don't know why. Facebook represents the ultimate in viral success. Given we do not understand why things go viral then it stands to reason that the underlying software methodology is not causation. This means that the fickle finger of fate could easily be visited upon Facebook the same as with MySpace and Facebook will be in no control. This is independent of the any software methodology they use.

Claims made without evidence can be dismissed without evidence.

</comment><comment><USER42> I believe, from time to time, you just need to stop developing new stuff for a period of time and dedicate the team to improve the overall quality, pay technical depts, hunt bugs, remove legacy code and refactor still existing ones.

<comment><USER43> And fortunately your competitors are always happy to pause and wait while you do that.

</comment></comment><comment><USER44> > The second exhibit is from Facebook Research... wouldn't you just write your > disk files to a ramdisk? Surely they noticed this too

I'm not sure the author understand what a Research team is and what it does. Trying out a new solution to an existing problem is sort of their job. I'm also not sure how a research team publishing a paper discussing an alternate solution indicates anything about the company's "code quality".

</comment><comment><USER45> It also seems that improvements in code quality caused by React happened not because they were driven by management, but because a few "heroic" engineers thought it was an interesting side-project. At least, that's my impression from the publicly available talks they gave.

</comment><comment><USER46> Reality check is that most companies, including most startups, attempting to create software of such size end up tangled in their own mess way sooner and fail. Keeping it maintainable at such scale is not as easy as keeping it maintainable when there are four of you.

</comment><comment><USER47> So?

I've become very cynical since the past year or so because there is a lot of noise/articles on the net, all knowing what's best for you or wrong with what you are doing. Yet without context or true authority to talk about it. My question these days when I read such article, "What has the author done that is equivalent?" There is rarely anything to be found.

Facebook might have a "code quality problem." But until you have worked at an organization that is big like Facebook please hold forth your tongues or fingers in this case. Startup principles don't apply nor academia. Facebook's "code problem" is what really does happen in the real world with such humongous business enterprises. Lot's of moving pieces in code, in people, in ideas and the amalgamation of these results in what most programmers will see as "code quality problem" yet the market sees as billions of dollars.

<comment> aaron-lebo Isn't that an appeal to authority? Because someone hasn't done X they don't have the right to criticize X?

 _Facebook 's "code problem" is what really does happen in the real world with such humongous business enterprises._

But does it have to be this way?

<comment><USER48> Until someone provided s counter-example the assumption is that yes, this is just what happens. We have entire industries of competing methodologies, some almost cult-like in their slavish devotion to "the one true process", and none have birthed any great successes. Why is that?

<comment><USER49> Let me provide a counter example. facebook, revenue in 2016 is $27 Billion, maintains approx 60mil lines of code (incl backend - <USER2> [http://www.informationisbeautiful.net/visualizations/million...](http://www.informationisbeautiful.net/visualizations/million- lines-of-code/) find facebook in the list)

Nasa, budget is $19 billion. I can't find a public official record of their code size, but the IIS is approx 6 mil lines of code, and i don't think the other missions they did (all 33 unmanned space missions in total) are too far off, so lets give each an average of 5mil per mission. That's 165 million lines of code. And arguably, probably more difficult code than facebook's domain.

<comment><USER48> And all of the code for the NASA HR system, and budget management tools, and conference system, etc. The Facebook code base is not just the web pages you see and backend to serve them, but encompasses just about everything used to run the company. It is also built and maintained by a much smaller group of coders for a much more ambiguous target domain. (And no, I do not think that the NASA domain is in any way more difficult than Facebook's.) I guess I have to question the relevancy of your counter-example.

<comment><USER50> > _And no, I do not think that the NASA domain is in any way more difficult > than Facebook 's._

You might not think it, but you'd be wrong. Facebook was for several first years just a set of PHP crud pages and heaps of servers to run them well.

Since then they added their own compiler and such, but the core of what they do is serving web pages at scale.

All known problems, solved by tens of teams all over the world, even at larger scales (Google for one).

NASA's problem on the other hand is quite unique, any errors can cost lives, and their tasks frequently include totally novel solutions for totally novel problems related to space travel, guidance, simulations, materials science, and so on.

Not the same difficulty at all.

<comment><USER51> "Facebook was for several first years just a set of PHP crud pages and heaps of servers to run them well."

Personally, I think we've all got a piece of the elephant here. It is true that there are no known methodologies that could build Facebook at the speed it has been built without producing a globally-incoherent design. Anything that could produce a globally-coherent design would have slowed them down so much that they wouldn't have been such big winners in the first place. (So "globally incoherent" isn't much of a criticism here, really.)

On the other hand, there are options other than "a big set of PHP CRUD pages and heaps of servers" available to us now, too, and I expect those options to continue to advance in usability. Even the various projects that improve on PHP would bring more benefit if you could use them from day one instead of a retrofit.

<comment><USER49> Facebook didn't win because of the software, but because of marketing. At its inception, it felt exclusive. You were special of you got an invite.

The other social networks were open season. Facebook made some good design choices with the simple looking UI, and didn't offer the customisations MySpace had. But that's a design choice, not software engineering choice.

<comment><USER52> > Facebook didn't win because of the software.

Probably true, but it's also important that they did not lose because of the software. There are lot of great ideas that have gone in the drain because of sloppy software.

<comment><USER53> Many successful companies run the worst software you will ever seen. Yesterday there was a post about MUMPS which got me flashbacks of clients that showed me software that ran their entire 100m+ euro / year factory mostly written in MS Access / Excel on a shared drive (with the lovely locking Windows does!) mostly (this particular client had some CRM and an ERP from Dutch companies 'laying on the shelf' but 'never got around to it'). One of the biggest EU factories that creates the belts for conveyor belts runs on the worst PHP code as ERP I have ever seen. Many sites that are not Google or Facebook etc run on hacked together crap in whatever language and tech and do fine.

Twitter was crap at the start, most software in electronics was beyond unusable until recently (in some systems) etc.

You can of course lose because of sloppy software, but if your marketing is done well, I don't see why that would happen. There is an enormous overestimation how much people care about that kind of thing here on HN. From the first decade of the Windows versions to tons of Twitter outages after the launch to getting their computers hacked, passwords stolen, CCs stolen, privacy taken, slow as molasses systems, forced reboots, many crashes, bodged updates, forced updates, virus/malware scanners taking up 50%+ of your /still too expensive/ resources too much of the time, really bad iteration of the Facebook app at the moment (at least on Android), broken airplane booking forms, 404 support pages etc etc etc and yet no-one goes away because most people curse and move on to whatever. Unless your marketing is bad aka no-one uses it, it usually won't fail because of sloppy software.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER54> It's interesting to note though that they have code quality problems but that doesn't prevent them from being massively successful.

<comment><USER55> It's a very hard to swallow pill for engineers, but many (if not most) startup or IT company success or failure is very independant of technological matters.

Once you get to "average" quality, then business and product decisions become far more important than anything else.

<comment><USER56> And it only needs to be average, or approaching average, in your niche. There's a lot of truly awful enterprise software out there, and it gets sold on promises of features and support, not quality.

I wish software engineering had the barriers and requirements of other engineering fields. I deal with industrial control systems, and we have the national electric code, UL, CE, NFPA 79, etc. With all that you can still make a machine that doesn't work well, but at least it's going to conform to certain conventions to make installation and maintenance easier, it will have a robust safety system, and it will be well-documented. Most fields of software engineering have no such minimum standards.

<comment><USER57> > I wish software engineering had the barriers and requirements of other > engineering fields.

It does where I live you're required to be licensed if what you're doing passes these 3 criteria:

1\. any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising (or the managing of any such act)

2\. that requires the application of engineering principles

3\. concerns the safeguarding of life, health, property, economic interests, the public welfare or the environment, or the managing of any such act.

This includes software development. It is illegal to use, "engineer," in your professional title unless your accredited.

I think this is a good thing. Better software that works towards the public interest requires liability and professional accreditation. You can't take the, "move fast, break stuff" approach when your software is being used to monitor and control water filtration plants or food safety processes in a manufacturing facility. That works for the Facebook's of the world but they are by no means the be all and end all of professional software development.

</comment></comment></comment></comment><comment><USER58> But seriously (i.e., ref to my previous comment). All the tools. All the talent. All the leadership and management. All the money. And still even the mighty FB struggles.

Point being: This shit might not be rocket scientist hard, but it ain't easy either. And when you don't have the war chest of the likes of FB you're in for an ongoing and never ending (quality) battle.

</comment><comment><USER59> this strikes me the same way as the story of the guys who figured out where to add armor to bombers during WW2. the places on the plane that had bullet holes after a mission clearly were operational enough to return to base. the places that never had any damage were probably critical, so that's where armor was added.

if a company can make billions with a poor-quality codebase, clearly quality isn't a bottom-line concern.

what is a concern is shipping the damn product.

</comment><comment><USER60> one look at hhvm tells me they have poor quality development practices. :P

i get the impression that they use the struct keyword to avoid having to type public everywhere for instance...

</comment><comment><USER61> code quality can't handle our scale

</comment><comment><USER62> At this point it is clear that software size increase linearly with the size of your software team, whatever the problem you solve.

This affects every organization and is something that should be actively fight against. Having accidental, unplanned, unaccounted costs should not be the default path.

</comment><comment><USER63> Can someone explain the example with the ramdisk? It's not clear to me how a ramdisk is relevant to the problems put forward in the paper, i.e. disk is too slow, they rely on lazy page allocation, and they have insufficient ram to hold two copies of everything simultaneously.

</comment><comment><USER64> > The article moves on, without wondering whether releases regularly breaking > your app are a normal part of the software engineering process.

To be fair, that's absolutely their call to make. Nothing of value is ever lost if your platform does not provide any non-ephemeral value.

</comment><comment><USER65> Makes me wonder how their decision for an open-plan office is related with this...

</comment><comment><USER66> It's important to understand that Facebook is incredibly large, and the fact that any software scaled with them to the point they are presently at, is a "on the shoulders of giants" situation that seems to actually be working well enough for them to become a billion dollar enterprise.

Also, the building of infrastructure that takes on scale that's not yet been required is somewhat inefficient. But it does beg the question: If Facebook is limited by its infrastructure, what responsibilities do they have to build software that continues to scale for future organizations?

</comment><comment><USER67> I don't think all the things discussed are still relevant as it's a fairly old post. Also, "best practices" are not always best depending on the scalability of the problem itself.

</comment><comment><USER68> > From Jack Reeves he cites the epiphany "that in fact the source code is a > design document and that the construction phase is actually the use of the > compiler and linker."

Ha. That is laughable. If it were so, then we would be able to automatically graft features from one product to another. I contend this is exactly how SoC are designed and there's no reason why we shouldn't copy the methods of the digital design community (proven to scale or you wouldn't be reading this).

</comment><comment><USER69> I was doing iOS dev three years ago, and the Facebook lib for iOS was the worst piece of shit I ever had to deal with.

Their app also used to be unbearably sluggish despite not doing anything too fancy.

<comment><USER70> I thought the joke was that they had interns write that? I remember an API that would hold onto completion blocks and call them repeatedly instead of just once. They would also accidentally make non backwardly compatible changes to the API.

They didn't care since that API period propelled them to more dominance and growth for awhile. After they shut down the viral channels, the developer ecosystem died...but it had proven its usefulness.

The only issue now is developers don't trust them and they can't get enough developers to build atop them.

</comment></comment><comment><USER71> > The "Hack" and "Move fast and break things" culture must make it very hard > for developers to focus on quality.

Well, yeah, that's what the "break things" part means. The problem is when people/companies try to have it both ways. "Move fast and have high quality" isn't possible.

</comment><comment><USER72> I recommend reading They Write the Right Stuff[1] to anybody interested in NASA's approach to writing software.

[1] [https://www.fastcompany.com/28121/they-write-right- stuff](https://www.fastcompany.com/28121/they-write-right-stuff)

</comment><comment><USER73> Anecdotal evidence, but I have a friend who complained that some critical parts don't have tests, and a lot of developers are loathe to write them. He got bit by it when he made a change in an area with no test coverage and broke the spam filter.

</comment><comment> alex- > "when Facebook employees are not actively making changes . . . the site > experiences higher levels of reliability."

This seems like a great thing to me. i.e. The system is stable and the error budget is being used to facilitate change.

</comment><comment><USER74> bob martin a.k.a uncle bob always says that people consider patterns like mvvm,mvc,mvp etc as Architecture which actually are just for the ui layer.It happens commonly in mobile development.

</comment><comment><USER75> Rub lavender oil on the servers, say "web-scale" 3 times, click you heals and everything will be OK. Oh wait, but the Russians.

</comment><comment><USER76> Only Kent Beck can save them. :)

</comment><comment><USER77> What's the point of an app? Generating high quality code or generating revenue? Until you hit intersections where revenue can be increased by changing code, the priority will always be on new or changed features.

</comment><comment><USER58> Move fast...and just leave things broken. Users be damned.

</comment><comment><USER78> links to slides are all dead... in parent articles and reference articles

</comment><comment><USER79> While the author wrote this article FB made millions of dollars.

</comment><comment><USER80> [2015]

</comment><comment><USER64> If a company hails React as a sane way to develop software, you know where it stands.

<comment><USER65> Just trolling or could you argue that?</comment></comment>


Tis' Death to Counterfeit: New England Counterfeiters in NY - <AUTHOR> https://newyorkhistoryblog.org/2018/04/30/18th-century-warning-tis-death-to-counterfeit/ <comment><USER2> The jurisdictional dispute was interesting to read about. I knew there were issues with agreeing exactly where borders lay in the past or people not realizing they had crossed the border. I was unaware of any instances where states outright declared they we're enforcing their laws in other states territories.

I would be interested in reading other examples of such debates if you happened to know of any

<comment><USER3> This actually happened in te 19thh century:

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

TL;DR, Michigan and Ohio almost fought over who got the city of Toledo.

<comment><USER2> That's fascinating. I can't even imagine what the federal government's response to an event like this would be nowadays. Arresting the governors? Deploying the us army against the state militias?</comment></comment></comment>


China uses Hong Kong security law against US and UK-based activists - <AUTHOR> https://www.theguardian.com/world/2020/jul/31/china-hong-kong-security-law-american-citizen-exiles <comment><USER2> This seems like a risky move for China that will only hurt them.

I'm not an expert but open targeting people who are citizens of other countries feels like, for lack of better terms, war crimes or diplomatic warfare. It doesn't feel like it will achieve much. The US government will strongly protect anyone targeted in such a way and only retaliate and apply sanctions if they continue, right?

<comment><USER3> It seems doubtful the US government, on general principle, would be against targeting people who are citizens of other countries.

<comment><USER4> Given you are talking about a country which had no qualms about kidnapping people from other countries and also holds people indefinitely without trial, I suppose you are right.

</comment></comment></comment><comment><USER5> Whether this is enforceable is another question entirely and will reveal the extent of China's influence. Much like how Canada's response to America's extradition request of Meng Wanzhou shows Canada solidly within the American sphere, we can use successful extraditions to China to map out a Chinese sphere.

</comment><comment><USER6> Okay but to play devil's advocate, how far up the chain does it go? Did some low-level journalist-grabber accidentally add them to a list, and the bureaucracy is such that it can't be undone easily?

</comment><comment><USER7> I remember last year on youtube stumbling across a research presentation being given by a phd candidate(?) at an Australian university, about using social media posts and community mapping to track down and identify members of the international Uyghur diaspora activist community. The presenter seemed to be presenting it from a kind of neutral ethnographic research stand point. It was kind of a shock to think of this happening at an Australian university.

</comment><comment><USER8> If ever there was a chance for the EU to capitalise on China trying to capitalise on Trump, now's the time.

<comment><USER9> Could you elaborate on what you mean by this?</comment></comment>


How America's back-to-the-land movement gave rise to the geodesic dome home - <AUTHOR> http://www.curbed.com/2016/5/11/11645002/buckminster-fuller-back-to-the-land-dome-homes <comment><USER2> The domes of Drop City were neat, but the mathematics of the geometry they used, which Steve Baer called Zome ("zone" + "dome") is also fascinating. [https://en.wikipedia.org/wiki/Zome](https://en.wikipedia.org/wiki/Zome) [http://22.214.171.124/images/resources/-DomesZomes.pdf](http://18.104.22.168/images/resources/-DomesZomes.pdf)

In short, it's what you get when you try to turn the icosahedron and dodecahedron into a practical construction toolkit. Everything fits together remarkably well, using struts which scale in length using the golden ratio τ = ½(1+√5). Indeed, every point you can construct using the system lies on a "golden integer" grid, with x, y, and z coordinates some integer combination of 1 and τ.

I recommend anyone interested in geometry, or anyone who knows some 8–18 year old kids, buy some Zometool toys, [http://zometool.com](http://zometool.com), which are really fantastic tools for learning about geometric modeling for mathematics, physics, chemistry, architecture, computer graphics, .... [The company site doesn't have the best pictures IMO, but check out a google image search [https://www.google.com/search?tbm=isch&q=zometool](https://www.google.com/search?tbm=isch&q=zometool)]

By the way, for anyone interested in manufacturing, the Zometool spheres are pretty ridiculous (basically impossible, but somehow they did it) to injection mold. Check out this amusing essay [http://bridgesmathart.org/2011/cdrom/proceedings/135/paper_1...](http://bridgesmathart.org/2011/cdrom/proceedings/135/paper_135.pdf)

Also check out the fun related papers people have been putting out at the Bridges Math + Art conference every year, [http://bridgesmathart.org](http://bridgesmathart.org)

</comment><comment><USER3> Geodesic domes are great, in theory. Once you live in one you may not subscribe to that theory anymore.

The natural cooling only works(?) until you put objects such as people, partitions & furniture in it that disrupts the efficiency of said airflow. If you seal it and heat/cool with conventional means, you get temperature layers as you rise up in multi-level units.

They leak. Period. No matter if it's shingles or rubber or any other coating, domes shrink & contract with every sunrise/sunset. Then when it rains, it rains inside your home.

Try maximizing space in a round room sometime. Sure custom made & high-end offerings are to be had, but where's the simplicity & savings in having to replace all your possessions? Then there's a lot of wasted space above your head that you have to heat/cool for no additional benefit.

Yes, I lived in one for several years. The property was fantastic, the dome was "tolerable", at best. YMMV.

</comment><comment><USER4> Making livable structures is not hard, geodesic or not. The problem is bums and druggies and petty crooks, as the article details. Figure out a way to banish them and we can live cheaply and peacefully.</comment>


Ask HN: Founders – how long did you test if your cofounder would work out? - <AUTHOR> <comment><USER2> In my first startup it was just too much, it took me over one year. Nowadays, I'd say that a couple of months is more than enough!

<comment><AUTHOR> Can you explain more?? Why did you spend a whole year at first? How did you go about vetting them?</comment></comment>


Be yourself. Abnormal people create abnormal returns. - <AUTHOR> http://42floors.com/blog/be-yourself-abnormal-people-create-abnormal-returns/ <comment><USER2> What's so phony about dressing up for investors? VCs live in suit land, so they certainly wouldn't get far with a visceral reaction to a dress shirt. I suppose a hoodie and sandals would show off how unique and eccentric you are?

If anything, dressing well will set you apart from the herd in the Valley.

</comment><comment><USER3> return False;</comment>


From $150,000 Painting Homes to Social Startup Urban Orca - <AUTHOR> http://nextmontreal.com/andrew-sider-urban-orca/

<comment><USER2> _> "In 2010... 'For some reason, there was no digital product to help meet new friends'"_

There are _tons_ of digital products to help meet new friends. Did he not even check Meetup? This just seems naive.

<comment><USER3> I've used Meetup in two cities now (Seattle and SF) and I don't consider it a great platform for meeting friends. It's a great platform for people with common interests to go out and do X, but I find its convertibility into actual friendships is really low.

The organizer-driven flow also means that if the group organizer slacks, the whole community goes kaput. It's rare to find a group with a dedicated enough organizer pool to keep things going week after week.

It's ripe for disruption really.

</comment></comment><comment><USER4> Wait, he has a startup that is basing product features on analytics on user data? How is he getting a statistically significant sample size for something that appears to be pre-launch?

<comment><USER5> Testing in private beta with real users :)

<comment><USER4> I've never had enough traffic during a private beta to hit a 95% confidence level. That's pretty amazing! I can't even imagine finding tens of thousands of people that would log in every day in order to hit it.

<comment><USER6> Haters gonna hate ... keep hustling Andrew.

</comment></comment></comment></comment><comment><USER7> $150,000 in sales not profit, big difference.</comment>


Ask HN: Should I leave my company? - <AUTHOR> Hi there,
I'm in a complicated situation and don't know what to do:
I work as a developer for an outsourcing company and I have been without an assigned project for the last several months, at first I didn't worry because there is always some downtime between projects but now its been too long, I'm worried how this affect my career because I'm doing basically nothing(I use the time to work in some pet project)
I have had several times when I was about to get into a project but for different reasons it didn't prosper.
What would you do? Would you stay in this comfortable(because I get paid for do nothing) but probably bad in the long term situation or find something else?
Thanks! <comment><USER2> As an ex-owner of an outsourcing company, I've been on the other side of this. Without any disrespect intended in asking this, is it possible you've been without a project for so long because you don't have the most flexible skillset?

I can say that, in my company, when business was slower, we would often see the same few people constantly without work because they were either too inexperienced, too limited in their capabilities, or too inflexible in what they were willing to do.

We worked hard to try to give them opportunities--having them shadow more senior engineers on projects (the extra project help also gave our clients more bang for their buck and made us look even better as a group), getting them training, having them work on internal projects, etc. Not all companies will or can go this extra mile to find opportunities for you, but might be receptive if you structure and propose something that uses your down time to your mutual benefit.

If they're not receptive, or if you can't structure something like this in your environment, then you might consider moving on.

Edit: Actually, as others are mentioning, it was also way easier to staff people who were actively involved in the sales phase of a program. Volunteering to do research, prototypes, etc. was a great way for motivated people to help out during this phase. Since they were effectively already working on the program by the time it started, they were usually the ones who would wind up staffed on the program.

</comment><comment><USER3> Been there... Without project for a year+ a few years ago. I had the same concerns you're having now.

Being there is soul-sucking, I know, but you have to be proactive and ask for projects to keep showing that you're willing to work, and that you're flexible.

Meanwhile, from my experience my suggestion is: dedicate yourself to opensource. Try to bring some value to your name and maybe company's name if it fits their goal. This can also lead you to new projects.

And the most important advice is: Doesn't matter if you decide to leave or to stay, DO NOT SPEND TIME DOING NOTHING.

<comment><USER4> That last sentence is definitely good advice!

Working on open source during the time is a great idea, but make sure you clear it with your employer first. By default, they would have copyright claim on work you do during time and with facilities they are paying for.

</comment></comment><comment><USER5> Can you build infrastructure for your company's internal processes or marketing? If so, building something that has a net multiplier on your company is very impressive to employers and shows your value. Do so with a hot new technology you want to learn and it's win win.

As an alternative, use the time to contribute to popular open source projects. That will build yor developer cred and make you more attractive to future employers.

Or take on your own freelance work and get paid double.

</comment><comment><USER6> It's healthy to worry about your career.

Think about why your current company is keeping you on the payroll. Since it's a business and not a charity, they must believe you're valuable and will have work in the near future in which your skills will be required. If that's not the case then they probably won't keep you on very much longer.

If your employer treats you well and up till now you enjoyed working for them, I suggest you focus on productive ways to help them and keep your job. Remember they've made an investment in onboarding and training you. As others have suggested, working on internal projects or building out sales/training material has a force multiplier effect which makes you even that more valuable to them.

If you don't like working for this employer then go find a new one. From an employer perspective, there is nothing worse than an employee who isn't happy, not being productive and isn't helping the situation. Do everyone a favor and take control of the situation.

Don't forget that the grass isn't always greener on the other side. Trading one employer for another isn't always viewed well from an employers perspective.

</comment><comment><USER7> You have the most valuable resource of all: time.

I think if you take a step back you've hundreds of things you could do that you didn't think of.

I'm jealous.

<comment><USER8> Right, but does he/she own any of it when the job ends? If not, what's the point?

<comment><USER7> Ownership in earning money of it? Or intellectual ownership? Or ownership as being a benevolent dictator? Or copyrights?

I think if some of these are important to him/her, it might be a good topic to discuss with the company.

</comment></comment></comment><comment><USER9> I had bench time when I was a "consultant." I used it for skills improvement (like learning a new framework or billable service), creating and presenting training materials for formal courses we offered, interviewing candidates, creating white papers, creating internal training materials on new frameworks or new versions, and infrastructure work like pulling cables, setting up hardware, or working on internal tools.

If you're still getting paid, they likely see you as a valuable asset for future projects. It can't hurt to ask if you can help with sales calls to build new skills and relationships, or if there are smaller projects where you can be billable.

</comment><comment><USER10> I don't feel like this is enough information to give any proper advice, it depends most on factors you haven't outlined.

What is the main reason they're keeping you on, do you think? Are they not paying attention and not accounting for costs, or are they interested in reserving your time and having you owe them some hard work as soon as it's there?

What is your mean reason for staying at this particular company, aside from getting paid to work on pet projects? Are they smart, honest, good people that you're learning from, or is it a paycheck and nothing more?

Have you reached out to your manager and asked for a project repeatedly? Do you have co-workers you can help, even if you're not asked to? What is your main fear, will doing nothing for the company lead to no promotions or less pay or a bad reputation? Will there be repercussions for future jobs if you keep going with this one, or can you get another job easily regardless of what this company thinks about you?

Does getting paid to work on your pet project have more value than working for the company? It's a pretty good deal for you if they don't care about paying for your downtime.

Last time I was in a similar situation, I spent my time doing research and programming competitions. My employer was okay with it, work eventually picked up again and I didn't lose any status in the organization. In the mean time I got to learn a lot, and travel to Spain to present my paper. I had a blast, and I super appreciated the opportunity to explore. I told my employer that, and I worked hard once work picked up, so I walked away with nothing but a positive experience. I was also really lucky.

</comment><comment><USER11> During slow periods I would pick a technology I wanted to work with (within reason), and begin working on something I figured would be an improvement on our current systems. I ended up writing a lot valuable stuff that was highly praised but never would have been approved if I had first asked permission.

I did this a few times, not so much to advance my career but because I enjoyed the work and I wanted to learn and be useful. Unfortunately it got me promoted into project management -- which I accepted because I have two young children -- and now I miss my old job.

</comment><comment><USER12> Yeah, find something else. Some folks are jealous that you're being paid to do nothing, but it really is harmful over the medium and long term. You do have the flexibility to not accept a bad deal, but you should at least be actively looking for something that is clearly better. Part of feeling happy is feeling productive.

</comment><comment><USER13> Since you are doing nothing, you have time to look for a job IMO. The better question to ask is "Why should I not look for a better job?" If there is no good answer, then you should.

<comment><USER14> This. Op, answer this second question... maybe you didn't give us all the information.

</comment></comment><comment><USER15> Utilise this time to learn and prepare for interviews. Its the best time, believe me. You can direct your undivided attention to prepare and interview across different companies as per your skillset. Over time not being in projects or working with real world business problemscan make it hard to get back to the 'zone'. You mentioned pet projects. Collaborate and github to take it to the next level in case you arnt already. This will help you stand out in these interviews. Unless ofcourse if you have been on back to back 'near death march and brutal deadline projects' its good to take some time off. Just my thoughts based on similar moments i have gone through. Cheers and good luck!

</comment><comment><USER16> I challenge the idea that it will be "probably bad in the long term." Because 1) there won't be a long term, and 2) what happens, is up to you.

1) No company can afford to keep you on the payroll indefinitely when you're not generating revenue for them. If (after some amount of time known only to them) they can't put you to work, they will have to let you go.

2) How you chose to spend this time, how well you took advantage of this opportunity currently presented to you, will determine the whole good/bad thing. If you play video games and wait for a phone call, it will be bad. If you do things that get your name out there/increase your visibility, or that increase your skills, or both, it will be good. Ways to accomplish that would include working on open-source projects, creating classes/tutorials for Udemy or the like, going to local networking events or better yet giving presentations at them, and so on. Basically I would act as though you are actively looking for something else, without actually leaving. It needn't be a bad faith thing... who knows, you might end up getting some company interested in you, and having them hire your employer to get your services, thereby getting a new client for your employer.

</comment><comment><USER17> If want someone to give you permission to leave, you don't need that. The question you are asking is its own answer. What you are looking for is not advice but for someone to indirectly assure you that you aren't crazy in feeling this way. I know it sounds harsh for me to point that out, but it's something you should bring into full awareness.

I haven't been in quite the same spot, but I did work for a company that really didn't know what it wanted, so there were long period of either no work or short periods of sudden enthusiasm behind X idea followed by an immediate "no, that's costing us money. kill the project immediately." While it would have done me a disservice to have left the company too soon, I was there for a year before I decided to leave, and even that was too long in retrospect. As others have said, it's soul-sucking and just a waste of time even when you're contently complacent. You have a limited life time and a small supply of creative energy, neither of which your company may deserve. That's just my perspective.

</comment><comment><USER18> I'd say stay, but make sure that if they cut you off quickly you either have some $$$ saved up to sustain yourself or another job prospect to go to.

Anyway, don't worry about your job stagnating. It's just programming... career progression is usually lackluster anyway (don't know your case personally) Also you can always get creative with your CV later on (as you know, work expands to fill the allocated slot).

Think about this you're getting paid to work on your code! What could be better? Just cover your tracks and don't get into any IP dispute over your code ;-)

Edit: If you wanted to use the time for something that could possibly look good on your CV or your employer would appreciate, you can look for some internal software problem to solve, Or make a demo app using your employer's technology stack.

</comment><comment><USER19> As someone who's been in a similar situation - being paid to support software that had two minor issues in two long years - I'd say: leave.

You are absolutely right about your career stagnating. Unless you are working on some kick-ass side-project that is making a difference (whether as extra revenue or a useful piece of open source software), you'll probably grow bored and restless. The longer you stay in that state, the longer it'll take you to go back to being functional in a day-to-day team environment. It's not fun.

And always keep in mind: you don't need to make the jump in a vacuum. Use your current situation to your advantage: take your time to find the perfect company for you, with similar compensation and challenging work that'll keep you engage. You won't regret it.

</comment><comment><USER20> If my employer paid me to work on my pet projects, and the pet projects involve things that keep me interested and grow my skills in ways that are beneficial to me and my career prospects, I'd stay put.

It'd be a different matter, if you truly weren't doing anything worthwhile or working on something that is not progressing your skills in a good way.

If you can get paid more to do what you do now on your pet projects, I'd obviously jump if I were you. I'd also spend this downtime looking around and potentially getting some practice on interviewing. Put your resume out there, and see if anyone bites. Even if you don't get offers for better jobs, you're getting a good idea of what employers are looking for, and keep your interviewing skills up-to-date.

</comment><comment><USER21> Search for a new job immediately. Be silent and publicly patient, but when nobody watches you continue searching. Stop spending unnecessary money and grow your emergency fund (3, much better 6 months of costs on saving mode).

This kind of situation can turn bad quickly when your bosses start to think why they pay you and how they can use your situation to their advantage in other ways.

It is not a problem as long as another source of money covers your income, but as a coder, how can you know when this source dries out? Timing, knowledge and financial power is against you. Turn away quickly. (speaking from experience if that's not clear enough already)

</comment><comment><USER22> I think it would be wise to try start scouting for opportunities outside of the company. This will also give you a clear picture on what your skills are worth in the current market and if the problem is basically with the company or your profile. If you are not being assigned to any work, it's not really a good sign, so it's better to always keep your options open. Having another offer in hand would also give you some leverage if you want to bring up the topic of unsatisfactory work with your boss in your current role.

</comment><comment><USER23> There's a bunch of great, thought out answers here. Don't TL;DR them.

However asking the question as you have done makes me think that you've already made your mind up (even if you haven't admitted that to yourself yet) and you need validation.

You shouldn't require validation from strangers off the internet, just get up and do something that makes you feel fulfilled. Identify, plan, execute. Your self esteem will thank you. Your SO will thank you, if you have one. The (new) people around you will thank you. That'll be all the validation you need :)

Good luck!

</comment><comment><USER24> I would actively seek assignment to a project! At least in the case that you want to stick around and be valued by your employer. I always am searching for more work at work whenever My current project(s) are in a lul. Employers value self motivation.

On the other hand, if none of the work available at your company interests you enough for you to want to pursue it, you probably should be looking for a new job.

Also, I limit my side projects' leakage into the work day to a few peeks into API docs or datasheets, anything more is inviting trouble.

<comment><USER25> Generally: If none of the work is interesting, you should be looking for a new job _anyways_ (if feasible)

</comment></comment><comment><USER26> I was in a similar situation with my first job out of college, except I was basically benched right after being hired - I was never on a project at all. I jumped ship after it was pretty clear that they weren't really trying to find me something to do. It was nice being paid while searching for a job, as I was able to hold out for a better offer.

In retrospect, I suspect that they hired me so that they could say they were hiring Americans to justify getting more visas to bring offshore workers into the states.

</comment><comment><USER27> Depends on your financial situation. If you have no savings then you should start silently finding another job today.

If you can afford to not have this job tomorrow you might try to start your own Gig. Many of us would kill for lot of downtime to start our own company.

I've also had friends who are able to start a new job and work both. This might be questionably legal/ethical depending on how you do it and how well you can keep secrets.

</comment><comment><USER28> Spend the time learning a new programming language or framework. by doing so you are helping both yourself and your employer at the same time by increasing the type of future projects that you would be a good fit for. Also spend some time learning about effective software architectures,patterns, tooling and processes.

</comment><comment><USER29> Have you told your boss you have time to do more? Tell us about your interactions with your direct supervisor.

</comment><comment><USER30> If you're worried about your resume, just use the down time to pad it with new skills.

Maybe something like this? [https://www.coursera.org/specializations/scala](https://www.coursera.org/specializations/scala)

</comment><comment><USER31> I would definitively take this time to hone my axe and get a side project going. Also doing some exercise.

Beware that your contract might include some clause which automatically gives your company ownership of whatever you produce while working for them.

</comment><comment><USER32> I suggest that you move on. Staying in your current position is not good for your self esteem. It might make you or your brain lazy. This will make it harder to find a new job. And of course there is so much (fun things) to do out there. Take the high road.

Good luck,

Stephan

</comment><comment><USER33> There's a third solution to your situation: keep your current job and take freelance/remote projects. You make way more money, you have things to do and show, and you can always decide to leave this position if it stagnates.

<comment><USER34> I can't believe more people aren't suggesting this.

It happened to me and after going through similiar feelings and almost quiting I started learning everything I wanted to but never had the time. Then I got involved with a local startup and now I have two jobs.

Never worked on the second job during company time for the first but being able to de-engage and saving the mind for the second job makes it possible.

</comment></comment><comment><USER35> If you work remote, go for the two full time jobs route

<comment><USER36> Just two? Rack em up.

</comment></comment><comment><USER37> As they are paying you I would do a course or learn anything I wanted to learn. It can be related with your career, so you don't get stuck.

</comment><comment><USER38> I would focus on a side project that challenges your technical skills. I would put those down on my resume as projects at your current company.

</comment><comment><USER39> Nope you should leave and find something more stimulating. You can sit around and get paid for doing nothing when you're retired.

</comment><comment><USER40> Simple, take their money and improve yourself. Spend time doing things that make you happy and content.

</comment><comment><USER41> haha thats a perfect opportunity to earn two salaries instead of one. just go do some templates for some client. yes its not allowed. but who is gonna notice.</comment>


YC Demographics - <AUTHOR> http://blog.ycombinator.com/yc-demographics

<comment><USER2> I wonder what the _age_ distribution is? (Not just gender and race...)

<comment><USER3> Exactly. They ask for age in their application and not gender or race.

<comment><USER4> Not a YC partner, but I help review apps... when I look at age, it's not so that I can discriminate based on it, it's so that I can see how impressive a person's accomplishments are in light of how much time they've had to achieve them.

<comment><USER5> The problem is that this can be very skewed, especially for younger people by their economic background.

<comment><USER6> For example, I know of someone that changed careers into the tech industry in his mid-30s. He should not be disadvantaged because he entered into the industry later than peers.

Additionally, I can think of countless examples of "slow starters" that didn't really get good at something until there was something that caught that person's interest.

At best, this is a flawed metric with many nuances to consider. So many that you could probably make the same determination by removing age from the application.*

* If you want to collect demographic data, you can just ask for it in the submission form but not show it in reviews.

<comment><USER4> Interesting... I'd be curious to hear which successful startup founders fit this pattern?

<comment><USER7> I'm not a founder [but that doesn't mean I wouldn't potentially found a company someday] - I worked in hospitality management until my early 30s. If I were to apply to YC I wouldn't expect you to be interested in my previous career so I wouldn't include that. If I understand you right you're saying you'd look at what you see I've done [in the ~3 years I've been a developer] and be less impressed because it's coming from someone in their mid-30s instead of their early 20s.

Sorry to break it to you, but factoring that into your decision is the very definition of [age] discrimination.

<comment><USER4> Sorry, I didn't mean to give the impression that I only look at technical accomplishments. I like to look at whatever accomplishments that person has, regardless of what field they're in. So if you've worked a lot in hospitality management, then great, let's hear about your accomplishments there.

<comment><USER8> >> I only look at technical accomplishments

Without age discrimination

>>accomplishments are in light of how much time they've had to achieve them

Age discrimination by definition

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> How large is the random sample? Since that you're asserting that YC does not discriminate because the actual proportion of female entrepreneurs funded is more than the number that applied, the conclusion is open to variance.

EDIT: Originally incorrectly said "sampling bias."

<comment><USER10> for gender, it's the entire applicant pool (we ask for gender so that's easy to compute.)

for race, it's a bit harder. we don't ask for it, but we looked through hundreds of videos and made our best guess (it's also why we left the number as approximate, as of course there are cases where we got it wrong.)

<comment><USER9> Ah, that clears up the sampling bias.

I might have asked the wrong question. What I meant was "how many people are 5% of YC applicants" that were used to calculate a representative proportion? Let's say 2000 companies apply each with 2-3 founders, so 4000-6000 founders total. 5% of that is 200-300, which can result in a reasonable margin of error for the conclusion proportion but may not be perfect.

<comment><USER10> more than 10,000. still, definitely small enough for random variance.

</comment></comment></comment></comment><comment><USER11> Great to see this data, thanks for releasing it.

</comment><comment><USER12> How about the non-hispanic, non-black minorities?

Or even more interesting to me, how about the distribution of education level and background?

<comment><USER13> Data on citizenship would also be interesting. How many founders are foreigners and how many are US citizens?

<comment><USER10> for last batch, more than 40% of the founders were born outside the US.

</comment></comment></comment><comment><USER14> Why sample as opposed to looking at the whole population? The typical reason is, "because it's difficult to survey the entire population". But in this case I'd think that it'd be easy because I assume you have all the data.

<comment><USER15> They likely don't record the team composition, so this would require hand- labeling of any data points.

Do we know total applicants? I'd like to know what n produced a 5% sample.

</comment></comment><comment><USER16> It would be interesting to have some more insights, like how many of rhw minority groups ( black or hispanic as the article says ) were funded, also more meaningful like:

Race/Sector of interest Age/Sector of interest Gender/Sector of interest People with Higher Scholar degree/ Sector of interest Startups funded by sector

</comment><comment><USER17> Good to know that YC doesn't seem to be affected by biased selection process. The low overall percentage of minority or female founders is a reflection of the current state of society, which, alas, isn't where it could be.

</comment><comment><USER18> It would be interesting to see the proportion of foreign entrepreneurs (applied from abroad).

<comment><USER19> Sam answers this in a different point in this thread -- [https://news.ycombinator.com/item?id=8889333](https://news.ycombinator.com/item?id=8889333) (40% are born abroad)

</comment></comment><comment><USER20> the big question is of course about self selection: how many nonwhite, female and non-Stanford entrepreneurs would like to apply for YC but don't because they think their chances are basically zero?

</comment><comment><USER21> I really want to see what percent introvert founders take.

I have been reading articles saying introversion is not good for entrepreneurship. I wonder if this is true.

if it is true, will VCs treat introvert founders like they do to minorities?

<comment><USER22> Some types of discrimination are not "fashionable" enough. If you are not of right color/gender you are out of luck as a minority.

</comment></comment><comment><USER23> Socioeconomic diversity is the elephant in the room.

<comment><USER5> How could YC even be able to calculate that?

<comment><USER23> It's pretty easy to figure out what class people are in if you actually care to know.

> _Competition is extremely high to enter Stanford, with an admit rate of 7.2 > percent. And those who make it in are, as a group, financially better off > than the rest of the American population. According to Director of Financial > Aid Karen Cooper, the median family income at Stanford is approximately > $125,000; by contrast, the median family income in the United States in > 2008, the last year for which data are available, is $61,521._

[http://www.stanforddaily.com/2010/08/12/diversity-remains- on...](http://www.stanforddaily.com/2010/08/12/diversity-remains-ongoing- struggle/)

[http://en.wikipedia.org/wiki/Household_income_in_the_United_...](http://en.wikipedia.org/wiki/Household_income_in_the_United_States#Social_class)

Now try to guess what class these people were born into: [http://www.ycombinator.com/people/](http://www.ycombinator.com/people/)

I'm still a huge fan of YC (very much not a hater) but on this rather large issue I think they're on the wrong side of history. A truly good actor compared to most, but far short being egalitarian.

<comment><USER5> I very much doubt that YC is in a position to ask every applicant for proof of their family's income and assets , another factor to note is that many applicants are from overseas.

<comment><USER23> I guess you're right, it's simply not possible and they should just not worry about it.

</comment></comment></comment></comment></comment><comment><USER24> It's not like the number of entire YC 2015 winter applications is super large. Why take a sample?

</comment><comment><USER25> > this will not be a zero-sum game

Is there some kind of rule at YC that mandates that blog posts must insist that nothing is a zero-sum game?

<comment><USER26> yes! It is the same rule that says that we must be sad that 50% of all applicants aren't women.

</comment></comment><comment><USER27> The post does not add any value -- "you are not at a disadvantage" means we are evaluating everyone with the same scale. Why should this be a surprise? this is the least we would expect anyway.

</comment><comment><USER28> "The good news is that there is no disadvantage to applying to YC as a female or minority founder."

I don't understand why that's good news.

It'd be good news if YC were actively preferring female and minority founders. Everyone acknowledges the glaring diversity problem in tech, but apparently YC is happy standing on the sidelines.

<comment><USER29> From the OP:

> _" We want to be sure we're not discriminating against founders in our > funding decisions at YC"_

This is not an affirmative action program. YC is an accelerator, not a charity. It primarily seeks long term positive returns, and to do that you have to evaluate people and their ideas based on merit, not their gender. Having more female founders would probably be better for the startup ecosystem as a whole, but "actively preferring" a class of candidates based on attributes poorly correlated with their probability of success would be bad for YC.

<comment><USER28> Look, whether we like it or not, VCs prefer white or asian founders over black or hispanic founders. That's fact, not conjecture [1]. I understand that YC is an accelerator. It's also a cultural institution. Blacks and hispanics are at a disadvantage when raising because VCs DON'T evaluate strictly on merit; they evaluate on a whole host of characteristics, many of which are subject to bias.

The YC stamp of approval is a valuable badge when fundraising. I'd like to see them find a way to use this to combat the inherent bias that women, blacks, and hispanics face when fundraising.

[1] [https://www.cbinsights.com/blog/venture-capital- demographics...](https://www.cbinsights.com/blog/venture-capital- demographics-87-percent-vc-backed-founders-white-asian-teams-raise-largest- funding/)

<comment><USER5> The YC article suggests that black and hispanic founders are slightly more likely to be funded by YC than other ethnicities. 3% of applicants to the batch were black or hispanic but 7.7% of funded founders in the batch were black or hispanic.

The article you linked does not seem to adjust for demographics of the applicants, it only discusses those who were funded.

</comment></comment></comment></comment><comment><USER30> The question is, would this post still be made publicly, in the same manner, if the data actually found serious discrimination happening?

Who knows, maybe YC is actually divinely meritocratic and there are no biases. Maybe they are transparent enough to make their biases public if they were discovered, and I absolutely admire that YC takes the initiative to check.

But if we were to be scientific about it, having YC take a look at discrimination within YC wouldn't be considered a reliable experiment that you could draw any conclusions from.

</comment><comment><USER31> Michael, I think you should really ask yourself: what good can come of this? It doesn't really demonstrate anything about YC's fair-opportunity goals, and it opens the topic up for significant scrutiny--both by rights activists, and now (even worse?) by stats majors who are always looking for an opportunity to tear apart someone's oversimplified models.

<comment><USER32> >Michael, I think you should really ask yourself: what good can come of this?

I got this one!

The good that comes is you solve the current status quo, where on a thread like "Why silicon valley works" people make comments and genuinely feel like this: [https://news.ycombinator.com/item?id=8552487](https://news.ycombinator.com/item?id=8552487)

>If you are a white male, in your early 20's and went to Stanford, go for it. If you're not, don't even try to play the game; it's rigged to use you, not help you.

or up-thread someone else

> Complete and utter bull. Maybe in [YC's] world, sure! White? 20-something? > No-kids? Harvard/Stanford? B2C? Let's chat! > Early-40's/Late-30's? Not- > white? Married w/ kids? Not-Harvard/Stanford? B2B? Nope. (Don't bother to > apply to YC either).

Theirs is a strong argument when 0.0% of founders are black. When it's 4%, man, 1 in 25 is better odds than 80% of the things you're doing to build a $100M exit anyway. You'll go for it and apply.

I gave up as I'm in a hurry, but search 'Hackernews search' (hn.algolia.com) for white/asian, "bother to apply" and similar words - there are a _ton_ of comments by people who think they shouldn't because it's 0%. They should!!!

This blog post is totally great, and a bit surprising. Kudos.</comment></comment>


Running R on AWS - <AUTHOR> http://blogs.aws.amazon.com/bigdata/post/Tx3IJSB6BMHWZE5/Running-R-on-AWS

<comment><USER2> very useful article! two other options I used before are just installing base R on EC2, or using this RStudio AMI I found from a Google search: [http://www.louisaslett.com/RStudio_AMI/](http://www.louisaslett.com/RStudio_AMI/)</comment>


MYOPENID WILL BE TURNED OFF ON FEBRUARY 1, 2014 - <AUTHOR> https://www.myopenid.com/

<comment><USER2> I suppose this means I'm not its only remaining user. Has any of you found a decent self-hosted alternative?

<comment><USER3> If you own your own domain and have a website, add this:

        <link rel="openid2.provider" href="https://www.google.com/accounts/o8/ud">
        <link rel="openid2.local_id" href="https://www.google.com/accounts/o8/id">

That will allow you to use your domain as OpenID, redirecting to Google endpoint.

<comment><USER2> Yes, except that I think Google already has enough data about me.

</comment></comment></comment><comment><USER4> stackoverflow (which was the only place i used this) have their own provider that you can switch to - [http://blog.stackoverflow.com/2011/05/stack- exchange-is-an-o...](http://blog.stackoverflow.com/2011/05/stack-exchange-is- an-openid-provider/)

</comment><comment><USER3> Why was there a need to capitalize? This "news" was around yesterday (and nobody cared).

<comment><AUTHOR> Sorry about the capitalization, its a paste from the original website where it's upper case as well.</comment></comment>


Ask HN: Did opeid run out of steam? - <AUTHOR>

Did openid run out of steam?
If so: 1. what were the lessons learnt? 2. What were the successful features? 3. What should openid have been? <comment><USER3> What's wrong with OpenID? We just implemented it on our new site and it works just great.

I suspect that many start=up sites just fail to notice it or feel they want more information about a user than they are guaranteed by the OpenID process. We request a new user's email address but can manage just fine without it - <USER2> also provide a user profile page where users can opt to add more details about themselves to "fill in the blanks".

<comment><AUTHOR> There is nothing wrong with openID. just that it has not taken off on a large scale as one would want. I suspect OAUTH to have become more prevalent.

<comment><USER3> I can see OAUTH working for apps/mashups - but not sure how that goes for humans.

</comment></comment></comment><comment><USER4> The lesson learned is that even very technical folk do not understand "logging in with a URL".</comment>


Reddit's plan to tackle trolls and beat Facebook - <AUTHOR> http://www.telegraph.co.uk/technology/2016/11/13/reddits-plan-to-tackle-trolls-and-beat-facebook/ <comment><USER2> /r/the_donald has taken over Reddit. I do not think there is any way to go back.</comment>