Edmond Lau has experience working at Silicon Valley companies such as Google, Quora and Quip and shares his learnings for software engineers in The Effective Engineer. He talks about the mindset an engineer needs to have by focusing on high-leverage activities, optimizing for learning and prioritizing regularly. Here are some personal highlights:

• To be effective engineers, we need to be able to identify which activities produce more impact with smaller time investments. Leverage is a useful framework for analyzing the effectiveness of different activities. Leverage = Impact Produced / Time Invested
• Three questions to ask ourselves about any activity we’re working on:
  1. How can I complete this activity in a shorter amount of time?
  2. How can I increase the value produced by this activity?
  3. Is there something else that I could spend my time on that would produce more value?
• When you get the important things right, the small things often don’t matter. Make sure effort you invest is proportional to its expected impact. Don’t try to get everything done. Focus on what matters and what matters is what produces value.
• When companies pay you for cushy and unchallenging 9-to-5 jobs, what they are actually doing is paying you to accept a much lower intellectual growth rate. An environment that iterates quickly provides a faster feedback cycle and enables you to learn at a faster rate.
• To invest in your own growth, you should carve out your own 20% time. It’s more effective to take it in one-or-two hour chunks each day rather than in one full day each week. Study code for abstractions written by the best engineers at your company. Ask yourself if you would’ve written similar code. Make sure you’re on a team with at least few senior engineers whom you can learn from.
• Engineers need longer and more contiguous blocks of time to be productive than many other professionals. Employees take an average of 10 to 15 minutes to return to focused activity after handling interruptions.
• Effective engineers invest heavily in iteration speed.
• What’s the scariest part of this project? That’s the part with the most unknowns and the most risk. Do that part first
• When you’re the bottleneck for a project, you lose your flexibility to work on other things.
• Creating a feedback loop is necessary for all aspects of a job.
• Overtime is almost always followed by an equal period of compensatory undertime while the workers catch up with their lives.
• The engineering practices that work for Google would be overkill at a startup or small company.
• A well-designed architecture supports additional growth by adding more of the same type of components, not by introducing more complex systems.
• Slowly failing systems muddy the sources of code errors, making it difficult for us to discover what went wrong. A valueable technique for shortening that feedback loop is to make your software fail fast.
• The higher you climb up the engineering ladder, the more your effectiveness will be measured not by your individual contributions but by your impact on the people around you. You’re a staff engineer if you’re making a whole team better than it would be otherwise. You’re a principal engineer if you’re making the whole company better than it would be otherwise. And you’re distinguished if you’re improving the industry.
• You get more credit than you deserve for being part of a successful company. Secret to your own career success is to focus primarily on everyone around you succeed.

Overall, the book is a good reflection of engineering culture in Silicon Valley tech companies, you may be familiar with most of the ideas if you’ve worked in one of these large tech companies before, but you may still find new ideas so it’s worth checking out …