The Effective Engineer

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

How Do You Know When It's Time to Leave Your Job?

How Do You Know When It's Time to Leave Your Job?
Photo credit: Frits Ahlefeldt-Laurvig

A number of red flags should cause you to reconsider your position at your current company, including:

  • being compensated unfairly.
  • being mistreated, undervalued, or disrespected.
  • disagreeing with the fundamental strategy or practices of the company and not being in a position to change them.
  • failing to get along with your manager and your teammates.
  • failing to fit in with the company culture.

These types of reasons aren’t too hard to identify. They provide concrete justifications for trying something new.

What Qualities Make a Good Startup Engineer?

What Qualities Make a Good Startup Engineer?
Photo credit: dierken

Not every good engineer makes a good startup engineer. Some of the most promising candidates that I’ve interviewed in the past six years across three startups (Ooyala, Quora, and now Quip) would bring 5+ years of experience from a top engineering company like Google, only to do poorly during our interview processes. Usually, the candidate wasn’t a bad engineer; in fact, he might have even excelled at his current job. We just thought he wouldn’t make a particularly good startup engineer.

Having spent many years interviewing candidates and training and mentoring other engineers, I’ve found that certain qualities do make engineers more likely to succeed within startup environments. Ultimately, these qualities stem from a few key aspects of how working at a startup differs from working at a more established company.

How a Strong Tribal Identity Can Bind Your Team Together

How a Strong Tribal Identity Can Bind Your Team Together
Photo credit: Pascal

The other day, I had a conversation with a friend about how to keep great people excited about staying on a team. The issue isn’t just an important one for managers. Even as individual contributors, most of us would also like to create the type of environment where we’re excited to come to work every day.

Many teams know to focus on hiring great people, and they spend large amounts of time and resources sourcing new candidates, recruiting at career fairs, flying promising candidates out for interviews, interviewing potential hires, and debriefing to make hiring decisions. Hiring great people is difficult, but it’s also high leverage.

How Modeling the Value of Your Time with a Single Number Can Simplify Decisions

How Modeling the Value of Your Time with a Single Number Can Simplify Decisions
Photo credit: Tax Credits

My friend carried a box of her used cans and bottles into the Safeway and waited at the customer service counter. Minutes later, a customer rep tallied up the 5- and 10-cent containers, double checked the math, and rewarded my friend with a dollar and change for her 10 minutes of patience. My friend’s frugality and thriftiness – no doubt passed down from her Asian immigrant parents who had painstakingly saved their way into the US middle class – made it difficult for her to simply discard her 5- and 10-cent container deposits, money that she viewed as rightfully hers. And so she dutifully made the trip every few weeks.

The part that didn’t make sense? My friend worked at Google as an engineer and earned over $60 an hour. But each of these excursions valued her time barely higher than minimum wage. It took some convincing before she agreed that she ought to break the habit.

What Google Taught Me About Scaling Engineering Teams

What Google Taught Me About Scaling Engineering Teams
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.