The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact

210 Pages·2015·2.17 MB·English

by  Edmond Lau

THE
EFFECTIVE
ENGINEER
THE
EFFECTIVE
ENGINEER
How to Leverage Your Efforts in Software Engineering to Make a Disproportionate and Meaningful Impact
Edmond Lau
The Effective Bookshelf
Palo Alto, CA
THE EFFECTIVE ENGINEER.
Copyright © 2015 by Edmond Lau. All rights reserved.
Published by The Effective Bookshelf, Palo Alto, CA.
Visit the website at: www.theeffectiveengineer.com. No part of this book may be
used or reproduced in any manner whatsoever without written permission except
in the case of brief quotations in critical articles or reviews.
For more information, please contact: [email protected].
Printed in the United States of America.
978-0996128100 (ISBN 13)
TO MY PARENTS
whose hard work and sacrifices made my opportunities
possible
Contents

Foreword
Introduction
Part 1: Adopt the Right Mindsets
1. Focus on High-Leverage Activities
2. Optimize for Learning
3. Prioritize Regularly
Part 2: Execute, Execute, Execute
4. Invest in Iteration Speed
5. Measure What You Want to Improve
6. Validate Your Ideas Early and Often
7. Improve Your Project Estimation Skills
Part 3: Build Long-Term Value
8. Balance Quality with Pragmatism
9. Minimize Operational Burden
10. Invest in Your Team’s Growth
Epilogue
Appendix
Acknowledgments
Notes
About the Author
Foreword
S ’ C S
M Y FIRST JOB OUT OF TANFORD S OMPUTER CIENCE PROGRAM WAS AS A
Product Manager at Google. It was an amazing first job. I shared offices
with engineers who had written the textbooks I used in college. I helped
create Google Maps, which is still my proudest achievement as a product
designer and engineer. And I learned how to be effective on large scale software
projects. By the time I left Google to start my first company, FriendFeed, I had
worked on so many projects at scale, I felt extremely confident I could start one
myself.
However, being a product manager at a large company is different than
founding a startup. For one, you are judged differently. While, in theory, product
managers are judged on the success of the products they work on, in practice,
large companies also judge product managers on their ability to manage all the
people and departments that have a stake in a product’s outcome. Did you
engage the PR team enough time before launch? Did you integrate your product
with the CEO’s pet project? Did you convince the competing executive of your
product direction before the big executive review? At software companies that
aren’t as enlightened as Google, product managers are judged more on these
political issues than they are on any aspect of the products they work on.
That’s why so many engineers and product managers that come out of larger
companies have trouble with the concept of leverage that Edmond Lau talks
about in The Effective Engineer. They are effectively trained to care about low
leverage activities because the bureaucracy that trained them values and rewards
them. The most successful engineers I’ve worked with in my career were the few
that were able to see past these bureaucratic idiosyncrasies and recognize the one
or two things that would really impact their product’s success. The engineer that
taught me the most about leverage is, without question, Paul Buchheit.
Paul was one of the co-founders of FriendFeed. He had previously created
Gmail, and while we hadn’t worked together much at Google, we had enough
mutual respect to join forces with Jim Norris and Sanjeev Singh to start a
company together in mid-2007. More than any person I’ve ever met, Paul was
willing to challenge conventional thinking, and he completely changed my
perspective on engineering and product management.
Whenever we would encounter a challenging technical problem, I would ask
“How should we do this?” Paul would respond, often obnoxiously, “Why do we
need to do it at all?” Instead of trying to solve impossible problems, he would
more often challenge the assumptions so we could simply work around them. At
times, it almost seemed like Paul was lazy—given any sufficiently hard project,
Paul would question the purpose of the project. But he was almost always right.
Unless the project was destined to make or break our nascent company, why
spend our precious engineering resources on it?
Working with Paul proved to me through experience that engineering was
much more about leverage than programming ability, and I’ve tried to apply that
lesson to all my subsequent jobs. When I became the Chief Technology Officer
of Facebook after the company acquired FriendFeed, I spent as much time
canceling projects as creating them. At Quip, the company I founded with Kevin
Gibbs in 2012, we felt so strongly that effective engineering was not correlated
with hours of effort that we have proudly embraced a “nine-to-five” culture
unheard of at Silicon Valley companies.
I love the culture of Silicon Valley. I love that young engineers have as much
of an impact on our industry as veterans, and I love how our industry redefines
itself every decade. But I also think the culture of working endless hours is
unnecessary and abused by ineffective managers around our industry. In addition
to being unnecessary, that aspect of our culture is one of the main things that
prevents people from choosing long term careers in software engineering—it is
unsustainable for people with families, and it creates a homogeneous, immature
atmosphere at the companies where it is ubiquitous.
I’m happy Edmond chose to write this book because I think Silicon Valley
would be a much better place for both managers and engineers if people
embraced “working smart” rather than “working hard.” It’s neither
counterintuitive nor hard in practice, but very few people do it, and I hope more
people embrace Edmond’s philosophy and techniques to make their companies
and careers more successful.
— Bret Taylor, CEO of Quip
Introduction