The Effective Engineer

A collection of habits, productivity hacks, and knowledge to make you more effective.

What I Took Away From Google's Engineering Culture

What I Took Away From Google's Engineering Culture
Photo credit: Paul Keller

Every week, a group of Googlers would plaster the walls of bathroom stalls worldwide with one-page sheets that shared the week’s testing tip. One week, the one-pager might discuss dependency injection and provide a simple example of how to use it in various languages; another week, it might share how to set up a tool for measuring test coverage of your team’s codebase. The “Testing on the Toilet” initiative was a quirky and fun way to teach engineers something new and useful as they were doing their business. 1 It also highlighted one of the key strengths of Google’s engineering culture: efficiently disseminating a consistent and opinionated set of best practices to a large engineering organization.

I joined the Search Quality team at Google right out of college and stayed from mid-2006 to mid-2008, when the company grew from about 8,000 employees to almost 20,000. 2 3 I worked with two very talented engineers on my first project, and in a short six months, we prototyped, tested, and launched a new feature on google.com to show related searches to many millions of users every day. As the token Noogler on the team, what stood out throughout the experience was how quickly the company could ramp up a new engineer like me to be productive within its environment. Like the Borg, 4 the company had mastered the art of assimilating new engineers.

Beware the One-Person Team

Beware the One-Person Team

“Software development is a team sport,” write Brian Fitzpatrick and Ben Collins-Sussman in their book Team Geek. 1 The two Googlers, who together started the company’s Chicago engineering offices, capture a valuable but often overlooked insight in their tagline: working effectively as part of a team instead of working alone can significantly improve output quality and morale.

Many engineers and managers are familiar with the risks of large teams, a problem that’s well described in Frederick Brooks’s The Mythical Man-Month. A “man-month” or a “person-month” refers to the amount of work that a person can complete in a month. It’s a myth because a software project that takes one person a year to complete (twelve person-months) can’t have its timeline shortened to a single month simply by staffing the project with a dozen engineers. Each additional engineer on a project incurs both communication and coordination overhead with everyone else on the team. As a result, the time to complete a project doesn’t actually decrease linearly with increased staffing. 2 It may even increase, and the notion that “adding manpower to a late software project makes it later” has become known as Brooks’s Law. 3

The Single, Most Valuable Lesson I've Learned in My Professional Life

The Single, Most Valuable Lesson I've Learned in My Professional Life
Photo credit: Jenna Wentz

I worked long hours at Ooyala, the first startup that I joined after leaving Google. There were weeks where my team and I would work 70-80 hours and hardly any weeks where we worked fewer than 60. Like many teammates, I’d work in the office during the day and then continue to work from home after dinner. Even over holidays or vacations, I’d still be chugging away on my laptop or at least be on-call in the event that anything with the product were to go wrong.

After all, we were the underdog in the competitive online video market. We had products to ship and features to build, and there was no time to dillydally. The more that we worked, the more value we could produce and the more likely that our startup would succeed. Or so I had thought.

Shape the Culture You Want through the Stories You Tell

Shape the Culture You Want through the Stories You Tell
Photo credit: David Leo Veksler

When I was 15, my mother told me a story about her teenage life in Communist China. Government officials stormed through her house and seized anything valuable from the family’s possessions. They overturned furniture and rifled through drawers in the name of equality, but in reality, the corrupt officials planned to just keep any valuables for themselves. They didn’t stop at just curtailing her family’s financial freedom.

Until the Cultural Revolution ended in the mid-1970s, at least one teenage child of every urban household was required to leave the city to work in the farms indefinitely. 1 And so the government also mandated that my mother be dispatched to a faraway village in the countryside, to manually toil in the fields from dawn until dusk. Also implicit in that mandate was that she would be denied the opportunity of a college education. She refused, and her family had to leave the country’s Communist rule to Hong Kong, which was at the time a British territory. After I was born, she moved again to the United States to ensure that her children wouldn’t be fettered by the same restrictions she was.

Compile Flight Rules for Your Software Engineering Team

Compile Flight Rules for Your Software Engineering Team
Photo credit: Matthew Simantov

In his book, An Astronaut’s Guide to Life on Earth, Chris Hadfield shares the insights he learned from his seemingly impossible journey to become the first Canadian to walk in space. He tells stories about the realistic simulations he worked through to prepare for space, about his daily life on his 6-month mission in the International Space Station, and even about the mechanics of how astronauts brush their teeth in space.

What left a particularly strong impression on me was an amazing tome of knowledge that Hadfield describes, one that took humanity decades to produce.

10 Ways to Leverage Resources at Your Company to Improve Your Programming Skills

10 Ways to Leverage Resources at Your Company to Improve Your Programming Skills
Photo credit: Dmitry Baranovskiy

An engineer who works at a well-known tech company asked me anonymously on Quora for some advice on how he or she could improve his or her programming skills. If you’ve ever wondered something similar and are looking for some new ways to become a more effective software engineer, you might find the ten suggestions in this blog post helpful.

Start by carving out 20% of your time to devote to your own skills development. If possible, it’ll be better if that 20% comes from one or two hours a day rather than a day a week because you can then make a daily habit out of improving your skills. Your productivity may decrease initially (or it might not change much if you’re replacing web surfing or other distractions), but the goal is to make investments that will make you more effective in the long run.

What research on happiness and motivation can tell us about finding meaning in our work

What research on happiness and motivation can tell us about finding meaning in our work
Photo credit: Nathan Forget

In The Upside of Irrationality, behavioral economist Dan Ariely describes an experiment he conducted to measure how the meaning of work impacts the motivation for work. In the experiment, he recruited Harvard students who loved Legos to build Lego Bionicle robots and paid them decreasing amounts for each additional robot built; the first completed robot earned $2, the next $0.11 less ($1.89), the third another $0.11 less ($1.78), and so forth. The research assistant informed the participant that at some point, the Legos would have to be dismantled for the next participant. In one group, the lab had numerous Lego kits available. The assistant would place each of the student’s completed robots on the desk in front of him, and the Lego robots would accumulate on the desk over the session. In the second group, only two kits were available, so as a participant started on the next robot, the assistant would immediately dismantle the previous robot in the event the participant wanted to continue building. Participants in the first group who didn’t see their work immediately dismantled built significantly more robots (10.6 on average) than those in the second group (7.2 on average). 1 Meaningful work led to happier participants, generated more output, and compensated for lower pay.

The experiment teaches a lesson on the importance of meaningful work: people lose motivation with work that they perceive to be pointless.

Five books every effective engineer should read and the lessons they teach

Five books every effective engineer should read and the lessons they teach
Austrian National Library in Vienna

I love reading and read about 1-2 books a week. It’s nowhere near the volume that some of the world’s fastest readers have been able to soak up books – President Theodore Roosevelt was said to have read a book a day before breakfast during his two terms in the White House 1 – but it’s a healthy rate that I work on maintaining and hopefully increasing over time.

More than just entertainment, the stories in books help shortcut your own learning curve so that you can learn and grow faster. “Learn from the mistakes of others,” Eleanor Roosevelt once said. “You can’t live long enough to make them all yourself.” Books, both fiction and non-fiction, offer a way for readers to learn from the lessons and mistakes of others, so that you can re-apply that knowledge without having to start from scratch.

What makes a good engineering culture?

What makes a good engineering culture?

One of my favorite interview questions that I ask engineering candidates is to tell me about one thing they liked and one thing they disliked about the engineering culture at their previous company. I’ve interviewed over 500 people – many of them from top tech companies like Facebook, Google, Amazon, Palantir, and Dropbox – and over time, this interview question has given me a sense of what good engineers look for and what they’re trying to avoid. Reflecting back on the interview responses and on my own experiences from the past seven years working across Google, Ooyala, and Quora, I’ve distilled ten things that a team can do to build a good engineering culture.

How to build a good onboarding process for new hires at a startup

How to build a good onboarding process for new hires at a startup
Photo credit: Aan Kasman

This blog post is based on a recent answer I wrote on Quora.

“Sink or swim.” They weren’t the most encouraging words that Sean, Ooyala’s CTO and ex-Google co-founder, could have said to me as I was ramping up, but they did set the tone for my onboarding experience at the company and for my first foray into the startup world. No life preserver was coming – the expectation was that I would be struggling and had better figure out how to survive, fast.

From my first day at the 30-something person startup called Ooyala 1, I found myself wading through a codebase laced with technical debt and augmented with little documentation and no unit tests, written in a Java-like language called ActionScript that I wasn’t familiar with. I had two weeks to build and launch a feature already promised to video publishers, a feature that would allow them to schedule when their online videos would go on the air. 2 To hit my deadline, I needed to learn ActionScript, get comfortable with Ruby on Rails, and familiarize myself with Flash video and graphics libraries, all while tracing through code littered with obscure variable names like “qqq” and questionable function names like “load2” and “load3.”