Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS at Facebook [pdf]

static1.squarespace.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: iOS at Facebook [pdf]

#101

Post by jonknee »

brazzledazzle wrote: post #89
xenadu02 wrote: post #52

It's all a bunch of bored engineers looking for ways to be clever but without anyone to take ownership of the codebase. There is absolutely no reason for the Facebook app to be so large and have so many classes. The app itself doesn't do that much.

>It's all a bunch of bored engineers looking for ways to be clever but without anyone to take ownership of the codebase. You couldn't think of a more charitable interpretation? I'm not one to care about rules but the hn guidelines on commenting are important for making sure the community doesn't eat itself alive like reddit did/does. >The app itself doesn't do that much. Right, but in the presentation he made it clea…

> Right, but in the presentation he made it clear that it was less about what the app does and more about the number of engineers making changes to it.

Well if it doesn't do that much, why are so many engineers working on it? Perhaps they have so many people working on it because they are all redoing the same stuff and not working together?

Re: iOS at Facebook [pdf]

#102

Post by thrusong »

brodd wrote: post #79

Am I reading this right, there are interns and engineers running PHP in a debugger on production data? How else would he be able to memorialize his own account and trigger the email?

I've seen talks with engineers that say this is this case. I think the one in particular was from @Scale. They've had the occasional issue with an intern dropping a table in production, but they said they haven't really run into issues with granting access to production data.

Re: iOS at Facebook [pdf]

#103

Post by emanuelev »

onewaystreet wrote: post #38
emanuelev wrote: post #31

Can't even imagine the amount of crap in their code-base. I bet that amount of commits is necessary to continuously correct the shitload of mistakes coming from their "Hacking" culture.

They deal with this with automated code review tools like their Infer static analysis tool ( http://fbinfer.com ) as well as abstracting away the Objective-C with React Native.

Yeah that might work for programming mistakes, but not sure it can help with bad design choices.

Re: iOS at Facebook [pdf]

#104

Post by plorkyeran »

gorkemyurt wrote: post #94
zghst wrote: post #91

Earlier quoted context omitted.

It would probably be a huge pain to migrate all 18,000 classes, tests, tools, etc., over to a React Native app. Also JS has less fine grained tooling for performance profiling (try stepping through JS bytecode for performance analysis, it's a PITA). One day it might get there, but not today. If it works, why change it?

I am not talking about migrating the whole app but how about for new features? I noticed that they redesigned their friends request page, why not build that with react native?

The engineers who did that redesign didn't want to use react native or felt it wasn't a good choice. Just because one person at Facebook built a tool doesn't mean that everyone else at Facebook is suddenly required to use that tool where ever possible.

Re: iOS at Facebook [pdf]

#105

Post by Shish2k »

buffoon wrote: post #87
alexpersian wrote: post #57

Earlier quoted context omitted.

I think what it means is that as it stands now, there is no definite good/bad way to make successful software. There are just opinions.

There are definite bad ways. I've watched a few companies go down the shitter using known bad ways.

I've watched a few companies go down the shitter using known good ways; and seen companies with mind-blowingly horrific software succeed based on marketing and contracts. There are a lot of anecdotes, but I have yet to see any data suggesting a correlation.

Re: iOS at Facebook [pdf]

#106

Post by [deleted] »

avinassh wrote: post #80
joeblau wrote: post #66

Earlier quoted context omitted.

What's crazy is that WhatApp has 4 Android engineers and 1 billion downloads.

> What's crazy is that WhatApp has 4 Android engineers Interesting. Any source for this claim? And also what's the full size of Whatsapp team?

[deleted]

Re: iOS at Facebook [pdf]

#107

Post by joeblau »

avinassh wrote: post #80
joeblau wrote: post #66

Earlier quoted context omitted.

What's crazy is that WhatApp has 4 Android engineers and 1 billion downloads.

> What's crazy is that WhatApp has 4 Android engineers Interesting. Any source for this claim? And also what's the full size of Whatsapp team?

Jan Koum on Twitter when their app crossed 1 billion users on the Google Play Store[0]. Not sure what their current team size is, but it seems like it's around 40-50. Last year at Startup School, Jan said the backend team 7-8 people on the backend[1].

[0] - https://twitter.com/jankoum/status/575740639444336640

[1] - https://youtu.be/8-pJa11YvCs?t=1272

Re: iOS at Facebook [pdf]

#108

Post by Shish2k »

zeeshanm wrote: post #48
asdfqwe1 wrote: post #30

Earlier quoted context omitted.

To be fair, most of these specific signs have been removed now/changed (I was an intern there fall 2013). They actually talked about how that used to be a slogan, but breaking stuff isn't really acceptable anymore because facebook is so big. They still wanted us to move really fast though...

From what I have heard they are now expecting their employees to still move fast, break stuff, but be ready to be penalized for it if you do. So, really, they are encouraging their employees to move at a steady pace with occasional hack nights when there is an upcoming release in the near-term. Facebook is growing old.

Trying to correct all the misunderstandings in this discussion would be a little soul crushing; but just picking this one comment as it seems well-intentioned and doesn't go anywhere near anything NDA-covered ;)

> break stuff, but be ready to be penalized

I've seen things break a few times, and the attitude is always "how do we fix this" and then "how do we fix the system to prevent this type of error in the future", never "whose fault is this"

> occasional hack

They seem to happen fairly often

> nights

They're mostly days, since a large number of people have families to go back to; some people stay late with beer and pizza and friends, because that's the kind of thing they enjoy doing, but it's an optional extra. (Technically the hack day is optional too -- if you're not interested, you can carry on as normal)

> when there is an upcoming release

Hacks aren't about video-game-industry style deadline crunches - quite the opposite; a hack day is when you pause your regular work (barring emergencies, ofc) in order to explore and experiment with things you're interested in but wouldn't normally work on.

> in the near-term

Releases are always near (like, multiple times per day).

Re: iOS at Facebook [pdf]

#109

Post by mnem »

bsdpython wrote: post #19

tl;dr Software engineering at extreme edge cases of performance and scalability can look very different than your typical use cases. Don't do this at home (until you have to). Interesting none-the-less.

> extreme edge cases of performance and scalability

That gave me a chortle :)

Post reply on HN