Book Review: The Effective Engineer By Edmond Lau, Forward by Bret Taylor.

How to leverage your efforts in software engineering to make a disproportionate impact.

Introduction

The Effective Engineer: How to leverage your efforts software engineering to make a disproportionate impact by Edmond Lau is mostly a non-technical but insightfully written book compiling some of the best practices and lessons learned by the author Edmond Lau, during his impressive career as a software engineer that everyone new to the field of software engineering/development should at least read once in order to improve their skills and become more effective at what they do.

The book

In this book, Edmond shared what he learned in his journey to becoming a more effective engineer.

Even though, barely scratching the surface of the various problems faced by engineers, it still adequately covers a broad range of topics and lessons that can offer young engineers a stepping stone into the software engineering/ development space.

For example;—

• When should we use one technology over another?
• Which programming languages or paradigms are worthwhile to learn?
• Should we work on side projects or focus on skills directly relevant to our jobs?
• How much time should we spend improving our communication or presentation techniques?

Are all a list of questions among many, distilling the best advice & practices to tackle with each one of these questions needing quality time to properly breakdown, considering the best of answers vary based on circumstances, personal preferences, and the engineer/reader’s goals.

Why you should read this book

Even though it may not be very appealing to hardcore/seasoned software engineers/developers, it is still a worthy book, filled with practical benefiting advice on how to get more done or think efficiently as a software engineer or developer.

Considering how engineering and development practices change, not to mention the different industries, or how teams handle their processes differently, books written this way give a better approach to software engineering/development practices, processes, standards rather than telling its readers “ must-dos-set-in-stone”.

The idea is to emphasise “guidance” over “dismissal, cancel & instructions” because what works for one individual or team might not necessarily work well for another.

Key takeaways from the book.

Here are a few things I picked up from the book worth spotlighting;-

• A great engineering culture isn’t built in a day; nor is it already in place when a company first starts. It begins with the values of the initial team members, and it’s a continual work-in-progress that every engineer helps to shape. It evolves over time with the decisions we make, the stories we tell, and the habits we adopt. It helps us make better decisions, adapt more quickly, and attract stronger talent.
• An Engineering culture consists of a set of values and habits shared by people on the team, and a great culture provides a number of benefits. Engineers feel empowered to get things done, which makes them happier and more productive. Happy and productive engineers in turn translate to higher employee retention. The culture provides a shared context and a framework for making decisions, which helps teams and organizations adapt more quickly to problems they encounter. And because the best engineers look for a strong engineering culture, it becomes a useful tool for recruiting talent. Hiring those engineers further strengthens the culture and creates a positive feedback loop.
• The best engineers enjoy getting things done, and the high-leverage investments empower them to get things done faster. The best engineers want to build on top of high-quality and well-tested codebases. They want to have short iteration and validation cycles so that they learn quickly and aren’t wasting effort. They believe in relentlessly automating processes to relieve their operational burden so that they can keep learning and building new things. They know the value of leverage, and they want to work at places where they can create meaningful impact.
• Software quality boils down to a matter of tradeoffs, and there’s no one universal rule for how to do things. In fact, Bobby Johnson, a former Director of Engineering at Facebook, claims that “[Thinking in terms of] right and wrong … isn’t a very accurate or useful framework for viewing the world … Instead of right and wrong, I prefer to look at things in terms of works and doesn’t work. It brings more clarity and is more effective for making decisions.” Rigidly adhering to a notion of building something “the right way” can paralyze discussions about tradeoffs and other viable options. Pragmatism – thinking in terms of what does and doesn’t work for achieving our goals – is a more effective lens through which to reason about quality.
• Sam Schillace, who ran engineering for Google Apps before his role at Box, warned, “One of my counter-intuitive lessons from Google is that all data can be abused … People interpret data the way they want to interpret it.” Sometimes, we pick easy-to-measure or slightly irrelevant metrics, and use them to tell a false narrative about what’s happening.
• You may not be able to test an idea as rigorously as you could with an A/B test and ample amounts of traffic, but you can still transform what otherwise would be guesswork into informed decision-making. Validation means formulating a hypothesis about what might work, designing an experiment to test it, understanding what good and bad outcomes look like, running the experiment, and learning from the results. Given the right mindset —a willingness to test your ideas – there’s little that you can’t validate by building feedback loops.
• Even though, It’s difficult to instill a culture of collective learning into an entire organization, consistent applications of effort can go a long way. Start with small projects that you’re working on with your immediate team; gradually establish the practice of doing post-mortems after larger projects as well. The more you learn from each experience, the more you’ll take with you into your next project, and the more you’ll succeed. Optimize for collective learning.
• A growing organization isn’t going to figure out the most effective product idea, engineering design, or organizational process on its first attempt. If it can continuously learn and adapt from past mistakes, however, then it stands a much better chance of success. That’s more likely to happen if employees challenge each others’ decisions and incorporate feedback into the future iterations. Look for a culture of curiosity, where everyone is encouraged to ask questions, coupled with a culture of openness, where feedback and information is shared proactively. Reflecting on failed projects, understanding what caused production outages, and reviewing the returns on different product investments all help the right lessons get internalized.
• 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, because you can then make a daily habit out of improving your skills. Your productivity may decrease at first (or it might not change much if you’re taking time away from web surfing or other distractions), but the goal is to make investments that will make you more effective in the long run. The solution is to borrow a lesson from Google. Google pioneered an idea called “20% time,” where engineers spend the equivalent of one day a week on a side project to make the company better. Initially, 20% time was a controversial proposal; people doubted it would improve the company’s bottom line. In fact, the investment empowered engineers to create and launch products like Gmail, Google News, and AdSense — which now comprise three of Google’s core offerings. Many other engineering companies have followed suit, adopting similar innovation policies. So what should you do with that 20% time? You can develop a deeper understanding of areas you’re already working on and tools that you already use.
• Interviewers often ask candidates, “Where do you see yourself five years from now?” It’s a tough question, and most people don’t have an answer. But by adopting a growth mindset and optimizing for learning, you’ll be best prepared to make the most of whatever opportunities do come your way. Strive towards embracing a growth mindset in which you’re motivated to learn about the things that excite you.
• Learning opportunities aren’t limited to the workplace. We should always be asking: How can I improve? How could I have done this better? What should I learn next to best prepare me for the future? These questions may not have anything to do with engineering – maybe you’re interested in music, art, sports, writing, or crafts. Some skills we learn could be cross-functional and help our engineering work (increasing his comfort level in conversing with strangers, for example, helped Edmond Lau when meeting and interviewing other great engineers for this book). Other skills might not translate directly into engineering benefits, but the practice of adopting a growth mindset toward them still makes us better learners and more willing to stretch beyond our comfort zone. This itself is a high-leverage investment. Plus, there’s a side benefit: research in positive psychology shows that continual learning is inextricably linked with increased happiness.
• Don’t try to get everything done. Focus on what matters – and what matters is what produces value. When a co-worker schedules you for an unnecessary meeting, a manager assigns you a small bug, or a product manager comes into your office with a shiny new prototype, they’re oftentimes not considering the opportunity cost of your time. Learn to say no. Don’t treat every invitation to do something as an obligation. Explain how the meeting, bug, or project will detract from your other tasks, and discuss whether it should have higher priority. If not, you probably shouldn’t be spending your time on it.
• Along with prioritizing the activities that directly produce value, we also need to prioritize the investments that increase our ability to be more effective and deliver more value in the future. In The 7 Habits of Highly Effective People, Stephen Covey explains that urgency should not be confused with importance. He advocates “putting first things first.” Covey partitions the activities that we do into four quadrants, based on whether they’re urgent or non-urgent and important or unimportant.
• As Peter Drucker points out in The Effective Executive, “If you can’t measure it, you can’t improve it.” —Measuring progress and performance might seem to fall within your manager’s purview, but it’s actually a powerful tool for assessing your own effectiveness and prioritizing your work.
• It’s important to, “Instrument Everything to Understand What’s Going On” because the higher your system’s complexity, the more you need instrumentation to ensure that you’re not flying blind. The easier it is to instrument more metrics, the more often you’ll do it. Adopting a mindset of instrumentation means ensuring one has a set of dashboards/over-site that surface key health metrics of a product, business, team or progress to enable drill-downs into the relevant data if and when necessary.

The Power of good metrics

Given the benefits of good metrics, it’s always worth asking if there is some way to measure the progress of what we’re doing?

Good metrics accomplish a number of goals like helping you focus on the right things, not only confirm product changes — but also ascertain that all the effort you’ve put in are actually achieving your objectives.

If a task you’re working on doesn’t move a core metric, you need to ask yourself if it’s worth doing? Or is there a missing key metric?

So why and how do we pick good metrics, you may ask?!

Well, picking the Right Metric to Incentivize the Behavior You Want matters a lot since it applies to your personal goals as well as your professional ones.

Look for a metric that, when optimized, maximizes impact for the team. The metric should be the one that, when systematically increased over time, leads you and the rest of your team to make the greatest and most sustainable impact.

– — –

Jim Collins, the author of Good to Great, argues that what differentiates great companies from good companies is that they align all employees along a single, core metric that he calls the economic denominator. The economic denominator answers the question: “If you could pick one and only one ratio —profit per x … – to systematically increase over time, what x would have the greatest and most sustainable impact on your economic engine?”

– — –

An actionable metric is one whose movements can be causally explained by the team’s efforts. In contrast, vanity metrics, as Eric Ries explains in The Lean Startup, track gross numbers like page views per month, total registered users, or total paying customers. Increases in vanity metrics may imply forward product progress, but they don’t necessarily reflect the actual quality of the team’s work.

A responsive metric updates quickly enough to give feedback about whether a given change was positive or negative, so that your team can learn where to apply future efforts. It is a leading indicator of how your team is currently doing.

Because the choice of metric can have such a significant impact on behavior, it’s a powerful leverage point. Dedicate the time to pick the right metric, whether it’s just for yourself or for your team

– —-

Conclusion

According to Edmond, the same operating principle – leverage – used throughout The Effective Engineer can help Software Engineers navigate the turbulent technological waters and urges readers to take away from the book, the idea: Time is our most finite asset, and leverage – the value we produce per unit time – allows us to direct our time toward what matters most.

And we should always ask ourselves: Does the work I’m doing provide the highest leverage for my current goal? If not, why am I doing it?

Moreover, when we make the wrong choice – which is bound to happen over the course of our careers – a growth mindset allows us to view each failure as an opportunity to learn and do better next time.