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

71–80 of 116 posts

Re: How Facebook Ships Code

#71

Post by wpietri »

polyfractal wrote: post #56
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…

Eh, I dunno. I don't want the carpenter designing my house, and I don't want the architect cutting the main support beams. I want both of them doing what they do best, and working together to do it.

I think that's a false dichotomy. The good carpenters I know are all reasonably good designers. And I would never hire an architect who didn't have some experience actually making things; otherwise there's too much risk of getting what software people call "architecture astronauts".

I think the right solution is the approach IDEO takes: teams of what they call T-shaped people: broad general understanding, with great depth in a particular area.

In Facebook's case in particular, I don't think they need a lot of brilliant design as much as they need solid, competent, well-integrated features. Indeed, their latest attempt at design brilliance, Timeline, has been much less well executed than their zillion engineer-led evolutionary changes.

Re: How Facebook Ships Code

#72

Post by crazygringo »

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 to writing their back-end executable code, and have a database guy write their query for them, and have a JavaScript expert take care of the front-end stuff.

It's not a question of intelligence, just a question of experience. You have to have done a lot of JavaScript coding to realize never to call parseInt(x), but always parseInt(x, 10), for example. And the number of CSS incompatibilities between browsers that you need to account for...

Unless someone has a lot of full-stack experience, it doesn't seem that great that they should be pushing out full-stack code on their own at a place like Facebook. Maybe code reviews will catch those kinds of things, though.

Re: How Facebook Ships Code

#73

Post by alttab »

wpietri wrote: post #63
alttab wrote: post #54

Earlier quoted context omitted.

True - but those engineers don't work at Facebook. This isn't no-child left behind. This isn't hand-hold time. This is the most expensive and expansive internet application in the world. If they need time to ramp up, they can do it on someone else's product and come to Facebook when they're ready.

That sounds impressively macho, but it's an attitude that has long-term organizational costs. HN just had a great article on how Microsoft's internal competition deeply harmed the company. The number one complaint I hear from departing Google engineers is the absurd internal promotions system. Years ago I did a gig at eBay, and I thought their macho attitude was a giant source of problems. Plenty of good, sane people…

This is a good lesson. I was straight-forward to get a point across, but it is easy to see how "excellence first" could turn into a poor work environment without moderation.

It also seems that an "excellence first" culture seems to provoke fears that people can't learn, or aren't allowed to make mistakes. Tone and delivery are important here - especially from leadership. My take on excellence first is you don't have to compromise environment for it. Create an environment that fosters excellence, where people aren't afraid to make mistakes but are committed to learning from them. Everything doesn't need to be treated like an emergency, but theres a level of bullshit on a technical level that shouldn't be tolerated. Again, each situation needs to be felt out individually and moderation is always key.

Personally I don't advocate the internal competition aspect of excellence either. The pitfalls of that are well documented as you have pointed out. I'd promote based on team success, and THEN individual contributions. If you can't work as a team then the whole team loses, only once the team succeeds would you start singling people out to see where the best influences were coming from.

TLDR - I think there is a middle ground between not running it like a daycare and running it like a wall street trading firm or gulag.

Re: How Facebook Ships Code

#74

Post by five_star »

"very engineering driven culture. ”product managers are essentially useless here.” is a quote from an engineer. engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime"

Maybe this is why Facebook seems to be chaotic for users. They change and change to whatever design they wanted without much consideration about what the user's would feel about the design. Facebook has now become the combined features of the other existing social media.

Re: How Facebook Ships Code

#76

Post by peapicker »

I stopped reading at "very unique". It is unique, or it isn't. Intensifiers to 'unique' tell me the writing is below par; and I've been correct about this enough over the years that I stopped bothering.

Re: How Facebook Ships Code

#77

Post by chris_wot »

Silhouette wrote: post #64
wilfra wrote: post #50

Earlier quoted context omitted.

Where HTML5 is concerned, Chrome is by far the most buggy browser. It's unfortunate because over 50% of our users are using it now.

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?

Re: How Facebook Ships Code

#78

Post by chris_wot »

wpietri wrote: post #57
Silhouette wrote: post #10

Am I the only person who thinks this whole approach is broken? We have seen the rise of "devops" recently, and big name web companies like Facebook and Google seem to be very proud of how engineer-led they are, how empowered their developers are, how their product managers don't have much real authority, how they push code to production ten minutes before it's even written, and so on. From the outside, I see systems…

"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!

Re: How Facebook Ships Code

#79

Post by mgkimsal »

gouranga wrote: post #69
mgkimsal wrote: post #38

Earlier quoted context omitted.

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 There's your problem...

It's a problem, but it certainly wasn't my only - groovy, to be precise.

Re: How Facebook Ships Code

#80

Post by jbl »

wpietri wrote: post #71
polyfractal wrote: post #56

Earlier quoted context omitted.

Eh, I dunno. I don't want the carpenter designing my house, and I don't want the architect cutting the main support beams. I want both of them doing what they do best, and working together to do it.

I think that's a false dichotomy. The good carpenters I know are all reasonably good designers. And I would never hire an architect who didn't have some experience actually making things; otherwise there's too much risk of getting what software people call "architecture astronauts". I think the right solution is the approach IDEO takes: teams of what they call T-shaped people: broad general understanding, with great…

The IDEO approach is something that I like and look for in the people I work with. When I was teaching I grad school, I'd often exhort my students to think at least one level 'above' and one level 'below' whatever phenomena we were studying that week.

With software, I think it's important to see the forest for the trees, so that you can make the best tree for the forest... (apologies for the tortured analogy)

Post reply on HN