Archive for the ‘Software: Building it’ Category

Ten Things I Hate About Working at Facebook

Wednesday, August 15th, 2012

These past two years at Facebook have been an absolute nightmare, something that I hope never to repeat in my career.  I’ve held my feelings back long enough.  Now that I’m coming upon my two-year anniversary at Facebook, I need to just come out and say it:  there’s a whole lot to hate about working here.  In the interest of brevity, I’ve trimmed my complaints down to just the top ten things:

  1. There is way too much code being committed and shipped.  Over the past two years, the number of engineers at Facebook has more than doubled.  But the rate of source code commits continues to grow proportionally with the number of engineers.  This is in clear violation of the law that Fred Brooks established nearly 40 years ago in The Mythical Man Month.  And that’s exactly what this “supposed” productivity is:  myth.  I see engineers around me committing code all the time, releasing new features onto the site every week, and I just sit back and chuckle to myself.  Happy, happy fools.
  2. There are too few meetings.  This is actually related to, and arguably a prime cause of, #1 above.  There’s even a “no meeting Wednesday” meme in the company, which you might as well call a “failure to communicate” death wish.  Software needs to be talked about and debated, not simply written.  It’s lunacy to be writing and shipping code at a blistering pace, instead of letting things bake a bit in committees representing broad swaths of all semi-affected parties.
  3. Zuck is too involved.  Now that we’re a publicly-traded company, the CEO’s job should primarily be interfacing with the public – specifically the major investors, analysts, and pundits.  Instead, Zuck is still planning upcoming products, talking with engineers, developing the strategy.  This is a complete misappropriation of time.  His job should be pumping up the stock price externally, not “building stuff.”
  4. There is not enough focus on short-term revenue.  This is related to #3:  specifically Zuck’s idealism (perhaps even naïveté) that focusing on building great products will lead to solid long-term businesses.  The stock is down this quarter.  We’re public now – we should be juicing next quarter’s revenues, not building cool stuff.  Seems to me that we show less ad pixels than other major web sites.  We should introduce banner ads (with eye-catching graphics and animations, ideally showing toe fungus or the spontaneous dancing that results from discovering low mortgage rates).  We should sell user data to interested third parties at a decent price.  Nobody in the company seems to be proposing these (admittedly obvious) business strategies, which, if anything, shows a clear lack of business acumen at the highest levels.
  5. The food is too good. What’s wrong with good food?  Well, here’s what’s wrong:  there’s too much of it.  Three meals a day.  Free.  Cooked by award-winning chefs.  And too many choices:  salads, entrees, desserts, vegetarian food, soups, whole grains, usually a second dessert, organic stuff, barbeque, ice cream, fresh-squeezed orange juice.  For someone like me with zero gastronomic self-control, this supposed “benefit” or “perk” is a complete disaster.  Why doesn’t the FDA step in?
  6. Too many decisions are being made by engineers.  Specifically, by just the engineers in the immediate product team of whatever’s shipping.  No one at Facebook seems to understand that hierarchies in organizations exist for a reason, one of which is to make sure people higher up can override decisions they don’t like.  I’ve seen decisions being made by lone engineers.  Or an engineer and a designer over lunch.  Or by interns.  All without telling their managers, even.  This sort of autonomous decision-making suggests a complete lack of understanding of how corporations are supposed to work, a disregard for people with titles and broad management responsibilities.  I’ve been preaching a much simpler approach:  always go with the opinion of the person who’s closest to Zuck.  Or the opinion of the person in the room who manages the most people.  No one’s listening.
  7. Too many new ideas are being created at Hackathons.  This is a direct corollary of #6.  I was told the other day that something like 70% of Hackathon projects, which are pretty much projects that engineers in small groups dream up and implement in single-day coding parties, end up shipping on the main site.  I’m all for creativity and supposed “empowerment,” but that’s way too much stuff shipping without being formally outlined and approved by committees of senior execs.  We have execs for a reason.  They should be telling us what to build.  Not the other way around.  Corporations should be autocracies, not democracies.  What – we should all just go off and create whatever amuses us?  Where’s the leadership?
  8. All the internal focus on Mobile and Platform is completely misguided.  I don’t mean to belittle your intelligence by belaboring this point, so I won’t.  I’ll just say this:  mobile devices are self-evidently of no consequence, and it’s ridiculous to give third-party developers the means to build on a common social graph.
  9. There is a fully-working hot tub in the New York office that interviews are conducted in.  I didn’t believe this until I saw the photos on Twitter.  It was billed to me as a way to test candidates’ resilience under pressure.  I was told that it’s used rarely, and only on exceptionally good candidates as a way to probe the extent of their mettle.  This is about the least professional thing that I have ever heard of, and I’m sure it violates laws in several states.  [Ed: This is completely untrue, in case this fantastical point seems plausible at first.  I installed a hot tub (non-functioning) as a conference room in Facebook Seattle.  Interviews are never done in them.]
  10. There is too much internal trust.  People at Facebook regularly assume – I kid you not – that employees they’ve never worked with will excel at their jobs, work hard, and deliver what they promise.  This type of idealism is frankly nauseating.  When it comes down to it, politics and mutual suspicion are ultimately what create the dynamism and drama that make work worthwhile.  Without these, it’s just code, code, code.  Ship, ship, ship.  I get tired just thinking about it.

Consider this fair warning if you’re a software engineer.  I can only call it as I see it.

Effective Communication for Engineers

Thursday, July 24th, 2008

[I originally posted this internally at Microsoft, but there was so much positive response that I’ve decided to also make it available externally.  I hope you find it similarly helpful.]

It’s not possible to lay out all the elements of great communication in one article — the topic’s too rich and I am no expert.  But poor communication has been such a blocker to the careers of many engineers I’ve managed and mentored that I’d like to try to outline some of the tips I give.  Great communication is something that I continue to strive for and struggle with, so please take these suggestions merely as tips from one traveler to another on our collective journey towards awesome communication.

For this article, I’ll focus on interactive forms of communication like meetings, conversations, and emails.  I won’t focus on formal, one-way forms of communication like presentations (or this blog!), which require special considerations.

General Tips

Successful communication requires that the other person internalize what you meant to share.  Too many people assume that communication happens as long as they use accurate words.  This is what leads to conversations where one side keeps saying the same thing.

Joe: “Why did you change this code?”
Timmy:  “Sammy was OOF yesterday.”
Joe:  “I know, but why did you modify this code?”
Timmy:  “I said Sammy was out.”
Joe:  “What does Sammy being out have to do with you changing the code?”
Timmy:  “Sammy’s auto-checkin script broke the build while he was out, so he didn’t fix the build break.  I had to change the code to fix the break.”

Communication hasn’t happened unless the other person has internalized what you meant to convey.  What actually counts as communication is the cumulative effect of your words, tone, and body-language on the other person’s behavior.  The literal, factual correctness of the words you speak are only part of the equation.  Most Americans understand this in the use of sarcasm:  “I just love it when the boss makes us stay on weekends while he parties in Vegas,” actually means you hate it.  (Incidentally, many cultures do not employ sarcasm, thereby underlining this point’s importance.)

I have little sympathy for people who exclusively blame the listener for failure in communication (“I’ve sent Joey at least 5 emails outlining how to fix the build.  He just doesn’t learn!”).  At least some of the fault for each failure in communication must by placed on the speaker/writer.  You’re effective once the cumulative effect of your words, tone, and body-language affect the other person’s behavior the way you intended.

Listening is (at least) half of effective communication.  Shouting matches happen when neither side understands this.  What does the other person want?  What’s important to them?  What is the other person trying to communicate back?  Why does the other person seem not to understand my point?  How can I say it in a way that they’ll understand?  Great communicators have a way of jumping quickly to the heart of the matter.  You may start by discussing something trivial but they quickly sense and raise underlying issues.  They understand you.  You feel a strong connection with them.  When you disagree with them, you continue to respect their point of view because you understand why they feel differently.  Part of what makes these communicators effective is that they listen.

I’m told that good basketball players don’t focus on their opponents’ upper body when guarding them — they watch their opponents’ feet.  Although it’s easy to feign intentions with the upper body, the feet continue to point the direction that the opponent will go.  So great players aren’t distracted by a bunch of upper-body misdirection.  They know where to look.

Great listening is similar.  The literal words that the other person uses are only part of the communication.  You need to watch the body language and listen to the tone.  You need to understand the person’s past experiences and their goals.  All of these go towards a more complete, accurate model of the other person, which then refines how you communicate with them.

Consider the audience.  We’ve all been in meetings where some developer loses the entire audience by using obscure terms and going into too much detail.  The best communicators understand why their audience wants to listen at all — why does the audience care? — and then targets what they say to address their audience’s interests and goals.  They build interest in what they’re about to say.  They don’t spend energy on what ultimately won’t be effectively heard.  They use words that have the right meanings to their audience.

Words matter.  Engineers often err in opposite directions in the choice of words.  Some engineers confuse precision with effectiveness when communicating.  They assume that the listener will receive their message effectively because the words they choose are literally correct and precise.  Other engineers hold the diametrically opposing view.  To them, the words they use don’t change the nature of the truth they’re describing.  It makes no difference to them whether a team is called the “Engineering Process Committee” or the “Engineering Best Practices Community.”

Words matter greatly in that each word causes a different response in a particular listener.  It’s counterproductive to use precise engineering terms with someone who doesn’t understand them.  But when speaking with someone who does understand those terms, it becomes critical to use them.  With such a person, it’d actually cause confusion not to use them.  So to get your point across, you must understand your listener’s model of what specific words mean and conform your communication to their words, not yours.  This is why a pedant’s frustration with “incorrect” word usage suggests a fundamental misunderstanding of what communication is all about.

Tips for Introverts (and their managers)

Considering the bulk of the engineering community is introverted, I’ve included a few communication tips that have been helpful to introverts like me.

Communication needs to be proactive (timely).  Not speaking is communicating. There’s a reason that the smug response, “Well, you never asked!” always engenders frustration.  Silence is communication, every bit as much as shouting.  When a report of mine doesn’t mention a specific feature, I assume that it’s going well.  It’s painful when the burden of successful collaboration relies entirely on your knowing which questions to ask.  It’s important to raise issues as they arise, to speak when necessary even if it’s uncomfortable.

On that note, fall back on the medium that’s easiest for you if needed.  Many people are nervous about speaking in public.  Consider sending your feedback prior to the meeting to the organizer, or noting your feedback using IE’s Discussion feature or Word’s comment bubbles.  Follow up face-to-face with the organizer afterwards.  Contribute actively to email discussions.  Just remember that these are fallbacks.  There will be occasions, e.g. time-critical meetings, where speaking up in a group in real time is essential.

Misunderstandings tend to fester and spiral.  Speaking up at the right times, when a more timid person might choose to remain silent, goes a long way towards reducing misunderstandings.  Almost every Jane Austen novel relies on its main characters not speaking when they should.  It’s a sure way to cause drama.

Address difficult issues openly.  I used to avoid difficult conversations.  Just the anticipation alone would keep me up at nights.  I’ve found over time that conversations are rarely as difficult as we might think, especially when approached openly.  Usually, the more difficult you think a conversation will be, the more tense and awkward it actually ends up being.  Your state of mind makes a huge difference.  Most people are quite approachable, even on difficult topics, as long as they see that you genuinely care about them.  By continually forcing myself to proactively address difficult issues openly, I’ve become far less anxious and far more confident when approaching tough conversations.

A note to managers:  leave “space” for your introverted employees.  Pause a bit longer before moving on to the next topic.  Actively solicit their point of view in 1-on-1’s.  Avoid forcibly “calling on them” in team meetings in order to “motivate participation.”  Provide alternative means to register their views (e.g. email, written comments, post-meeting 1-on-1’s).  It’s not helpful to only set a commitment that says, “Participate more actively in meetings.”  Introverts need to be coached with examples and practical tips.  Fundamental changes like this will take years of practice.  The goal shouldn’t be to change an introvert into an extrovert.  Instead, it’s to make both introverts and extroverts better communicators.

[This post is dedicated to Alec Ramsay, who, amongst many other things, taught me that Words Matter.  I first learned by his example the vast difference between speaking and communicating.]

NextStep Is Born

Tuesday, May 20th, 2008

I’ve started a Microsoft-internal blog called NextStep to augment the content on this blog.  NextStep will focus on engineering, teams, and careers at Microsoft, and will contain the types of company-specific details that aren’t relevant or available to the general public.

In cases where topics are interesting to both audiences, I will post the public version here and the internal version at NextStep.

NextStep will only cover topics related to software engineering, teams, and careers at Microsoft, so you won’t be able to read about, say, body heat there.

You’ve Got Three Hours

Tuesday, May 20th, 2008

Developers often complain that projects slip because managers flat-out override schedules by fiat, the sort of thing that happens on Star Trek all the time:

“Captain, I’ll need six hours to fix the warp drive!”
“You’ve got three.”

I’ve seen breakdown in Management’s interaction with the people producing the estimates for a variety of reasons.  But having been on both sides at Microsoft, it seems to me that root causes for the breakdown are often more subtle than at first appears;  more often than not, the breakdown is with both parties.

There is, of course, the manager who insists against all reality on his/her own ship date.  I seem to remember reading a blog about a Vista VP who had this problem, but I’ll need to dig up that blog entry (wait:  here it is).  I’m told the blogger almost got fired for that posting.  I hope he’s ok.

But I also often find that the developer/project-manager is simply putting too much schedule blame on the manager.  The core of the issue is often credibility:  is the presenter of the schedule credible?  Is there reason to believe the schedule?

Good points were already made below about practical things one can do to improve basal credibility, like documenting assumptions, going deep on unknowns, gathering supporting data, etc.  Those are helpful.

But in times when I, as the manager, have doubted schedules, it hasn’t been about this sort of credibility.  It’s been about other factors:

· How experienced is the developer presenting the schedule?
· How has he/she delivered in the past?
· How transparent is he/she?  How skeptical should I be?

You build credibility by demonstrating a series of repeated successes despite adversity.  You build credibility by being consistently right in your past judgments.  No college-hire is going to have this sort of credibility, at least in the beginning of his/her career.  You can give them the tactical tools and training, but they also need to give themselves time to hone their track records and reputations.

I once got a water heater moved by a plumber.  He estimated two days.  On the fourth day, when he finally finished, I asked him why the actual time was double the estimate.  He answered, full of conviction and without skipping a beat, “This happens every time.”

There are leads I’ve managed in the past who would make similar proclamations without even realizing it.  “I don’t feel comfortable committing to this schedule – in the past three sprints, we’ve always slipped a week beyond what we expected!”  There are other developers who I’d trust with a schedule without even needing to review it.

I think what often gets perceived as “my manager overrode my schedule” is actually the more subtle, “I’m not credible to my manager.”  As I often urge people, first look within.