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

How Facebook Ships Code

framethink.wordpress.com

Post reply on HN
Print view View original

81–90 of 116 posts

Re: How Facebook Ships Code

#81

Post by sreyaNotfilc »

crazygringo wrote: post #72
sreyaNotfilc wrote: post #40

This may be my favorite quote... "Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between. If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on. Same for Architect help. But in general, expectation is that engineers will handle everything t…

I dunno. I personally am a full-stack guy. But when I work with back-end developers who don't know MySQL inside and out, and they write a query that works fast in development but slow in production because they didn't realize the column index they specified won't work because of a string collation incompatibility between tables, and they've never even heard of this kind of problem before... Then I wish they'd stick t…

My point is that sometimes you don't have the luxury of having x amount of DB people and x amount of js folks and x amount of server side guys and so on and so forth. I'm coming from a place with very low resources (I'm the only developer at my job right now, we use to have 4).

(I wrote this stuff before but for some reason it just didn't go through)

As far as testing wise and building things, I believe it is best to have an engineer that is able to fulfill those roles for the following reasons... 1) They understand the structures and what it is that makes an application do what it does. 2) Its a very good learn tool. If you mess up you know exactly why. You'll be able to constantly adapt yourself to become better. 3) Waiting for your "role" to be utilized within an organization may sound great because you have free time, but it causes stagnation and "Diva-ism". That is the whole "Its not my job, so I don't care about your problem" or "You need me more than I need you" attitude. 4) You can move relatively quickly since the code and logic is coming directly from you.

Yes, specialists are very important. For large organizations they are very needed. But, to get things to work right now, you need to be flexible and open-minded. Look at Facebook's UI, its not the prettiest (blue bar at the top and 3 columns), yet its an extremely popular product. Most users just want the damn thing to work.

I'm no web designer, but I understand that a clean UI is needed. I'm not a DB guy, but I can figure out most problems. Etc. etc.

I think that's what Zuck actually wants in his engineers. Guys and gals that can see a problem and fix it on their own. Guys and gals that can think of a cool idea, test it, and have it released for that 1%.

Code reviews and peer help will smooth things out. I believe it was Jamie Zawinski's interview in the book "Coders at Work" that had the same mantra when he developed Netscape. Just get the thing out fast. You'll get more eyes on it. And you can always make it better the next time around.

It seems like a lot of shops do that. Its a cut throat world and if you spend too much time trying to be super clean and precise, you'll still be on version 1 while your competitor is on version 10.

Re: How Facebook Ships Code

#82

Post by Silhouette »

chris_wot wrote: post #77
Silhouette wrote: post #64

Earlier quoted context omitted.

Where HTML5 is concerned, Chrome is by far the most buggy browser. I agree, though FWIW I'd say it still takes more work to support Safari on iOS because of all the odd quirks. Apple might not consider them bugs. They're entitled to their opinion. ;-) It surprises me that we've reached this point, but several of the web-based projects for business users that I work on professionally now recommend IE9 and won't offici…

I'm interested in that... What breakages stop folks from using Firefix?

The most recent major one I know was the LTS release, in which they seriously broke embedded content like Flash and Java applets.

The issue was known and in the bug tracker several days before the release, yet they went ahead and released anyway. Consequently many sites and browser-hosted user interfaces across the world were broken.

It was then a very long time before another patch was pushed to fix the regression.

I'll leave it to you to decide whether it's worse that such a serious bug could get into the repo in the first place, that they still pushed the update to everyone even though they knew about the problem, or that they allowed sites that rely on these technologies to be broken for so long before correcting their mistake.

Re: How Facebook Ships Code

#83

Post by getsat »

piggity wrote: post #18
gouranga wrote: post #2

What a crock of shit: after boot camp, all engineers get access to live DB I can understand on a startup or small org but an organisation of that size, there should be very tight access control. Despite what anyone says, the probability that someone does something bad increases in larger groups. Security should be on a simple need-to-know basis and nothing else. I build BIG financial software and we have certain audi…

You finance and billing guys will never understand. These are rockstars . They work for facebook. They would never ever type UPDATE users SET email = username || '@facebook.com'; WHERE username == 'john.smith';

>implying this was an engineering team decision

Re: How Facebook Ships Code

#84

Post by alttab »

sreyaNotfilc wrote: post #62
alttab wrote: post #51

Earlier quoted context omitted.

I agree. Specialists are really just full stack engineers who haven't fulfilled their potential. Why hire a self-proclaimed UX guy? Unless I have all the amazing engineers I need for my team (99% not the case), I'm looking for someone who can do multiple things. The best ones are ones that can do schema design, query design, system and model architecture, front-end wireframes, javascript, and implementation. That sai…

What I mean by "tightly woven" is that you know exactly what values/components/types need to communicate with each other whether its the front end or the back end. You're not wasting time trying to match a spec sheet or fulfill a precondition to an existing back-end procedure (cause honestly those things just don't fit right in). That is, you're not spending time trying to put a square peg into a round hole.

Ah I getcha now. I think my point is still valid though - and in fact full stack engineers are more likely to write a spaghetti code mess from the back to the front because they control the entire feature and may see the code in its entirety as one "feature" and thus one code base.

Re: How Facebook Ships Code

#85

Post by darkarmani »

gaius wrote: post #55
gouranga wrote: post #2

What a crock of shit: after boot camp, all engineers get access to live DB I can understand on a startup or small org but an organisation of that size, there should be very tight access control. Despite what anyone says, the probability that someone does something bad increases in larger groups. Security should be on a simple need-to-know basis and nothing else. I build BIG financial software and we have certain audi…

Right. FB doesn't get that all they have is the user experience, and it is bad user experience if I drop out of a conversation I'm having because their DBA-free database has decided to simply, silently drop my last comment. Or if it takes me several attempts to post a photo. Or if I invite someone to an event, and they never get the invite. You can do all sorts of amazing things if you just don't care if your code ac…

> Grown-up companies have full-time professional DBAs

I don't know if I'd call them "professional," but they definitely have full-time DBAs. ;)

Re: How Facebook Ships Code

#87

Post by underwater »

crazygringo wrote: post #72
sreyaNotfilc wrote: post #40

This may be my favorite quote... "Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between. If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on. Same for Architect help. But in general, expectation is that engineers will handle everything t…

I dunno. I personally am a full-stack guy. But when I work with back-end developers who don't know MySQL inside and out, and they write a query that works fast in development but slow in production because they didn't realize the column index they specified won't work because of a string collation incompatibility between tables, and they've never even heard of this kind of problem before... Then I wish they'd stick t…

Facebook has a good abstractions at all levels of the stack. This allow engineers to work on all parts of the stack without having to worry about low level implementation details. I have not written a line of SQL while at Facebook.

If there is some domain knowledge needed then I can just rope in an engineer from the appropriate team to review my diff.

It's also worth noting that on product teams engineers tend to gravitate towards the parts of development they are more comfortable with, or enjoy the most. They are not forced to work with te full stack just for the sake of it.

Re: How Facebook Ships Code

#88

Post by sreyaNotfilc »

alttab wrote: post #84
sreyaNotfilc wrote: post #62

Earlier quoted context omitted.

What I mean by "tightly woven" is that you know exactly what values/components/types need to communicate with each other whether its the front end or the back end. You're not wasting time trying to match a spec sheet or fulfill a precondition to an existing back-end procedure (cause honestly those things just don't fit right in). That is, you're not spending time trying to put a square peg into a round hole.

Ah I getcha now. I think my point is still valid though - and in fact full stack engineers are more likely to write a spaghetti code mess from the back to the front because they control the entire feature and may see the code in its entirety as one "feature" and thus one code base.

You are valid. I wrote a whole post about this but the reply didn't seem to work so I lost the full reply.

I did write most of my ideas to "underwater"'s comment.

Basically, my position is more on the fact that if you need things done quickly, then a full stack guy is the one you need. You can fix/abstract the code later. In fact, I encourage that. But to get the ball rolling, you're gonna need some quick and useful (sometimes ugly spaghetti) code.

Its a trade off that must be made, especially you're rapidly building your product.

Re: How Facebook Ships Code

#89

Post by tedunangst »

mgkimsal wrote: post #38
TazeTSchnitzel wrote: post #14

Earlier quoted context omitted.

Not sarcasm. Of course you should reproduce in a development environment, but for some issues, looking at live DB is the only way to see what is wrong.

A system I work on has grown a lot over the last few years (data for 2000 users is now data for 50,000, rules have been added, etc). Example story: We had an issue that was only coming up on production. I could not reproduce it in a dev environment. Worse, we didn't even notice it for a long time because it was a nightly job, and people were not reporting an absence of their notifications. (nightly job to email repor…

Adding on top of that was my own dynamic language background not mapping well to the JVM - one bad address in the middle of a loop doesn't just get skipped and logged, but the entire process now stops.

Makes me wonder what dynamic language you're used to. An uncaught exception in both python and ruby aborts the program, not just the tiny inner loop that happens to be running.

Re: How Facebook Ships Code

#90

Post by damoncali »

chris_wot wrote: post #78
wpietri wrote: post #57

Earlier quoted context omitted.

"Broken" seems strong. I'd agree with "has flaws", but every system has flaws. If I were Zuckerberg, I'd be terrified of slipping into a premature complacency or a heavyweight process that prevents change. After years of social network king-of-the-hill, Facebook seems to be set up for the generational dominance of a Microsoft or a Google. But it's not locked in yet. Sure, current practices risk irritating users or a…

If I were Zuckerberg, I'd be terrified of slipping into a premature complacency or a heavyweight process that prevents change. He just listed Facebook on NASDAQ - cant think of a single business decision that would do more to cause this result than that!

To be fair, he really had little choice.
Post reply on HN