The Effective Engineer¶
Metadata¶
- Author: [[Edmond Lau]]
Highlights¶
More engaged users drive more revenue, more venture capital, and higher startup valuations, and in recent years, teams dedicated to the art and science of user growth have proliferated. These teams focus on optimizing how users flow into and out of a product. — location: 599 ^ref-64921
To help us identify what’s high-leverage, we’ll discuss two simple heuristics: focusing on what directly produces value, and focusing on the important and non-urgent. — location: 630 ^ref-35677
It’s far easier and more efficient to compile a small number of goals that are important to complete, pick initial tasks toward those goals, and then make a pairwise comparison between what you’re currently doing and what else is on your to-do list. — location: 670 ^ref-54767
The goal isn’t to establish a total ordering of all your priorities, since any ordering you make will be based on imperfect information; instead, it’s to continuously shift your top priorities toward the ones with the highest leverage, given the information you have — location: 673 ^ref-20145
we systematically went through every idea and estimated its percentage impact (0.1%, 1%, 10%, or 100%) on our growth metrics as well as the time it would take to implement (hours, days, weeks, or months). Not only were many of these estimates quite off because we had limited data, but every task we tackled inspired new tasks — location: 666 ^ref-39518
This didnt work
The next two sections present two heuristics that can help: focusing on what directly produces value, and focusing on the important and non-urgent. — location: 676 ^ref-1557
But make sure that the effort you invest is proportional to its expected impact. — location: 695 ^ref-38922
Prioritize the ones that produce the most value with the least amount of effort. Once you do this a few times, it becomes easier to recognize which tasks are the most valuable — location: 696 ^ref-47482
Don’t try to get everything done. Focus on what matters—and what matters is what produces value. — location: 703 ^ref-25888
Therefore, 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. Stated simply, the second heuristic is to focus on important and non-urgent activities — location: 707 ^ref-37625
He would label everything on his to-do list from 1 through 4, based on which quadrant the activity fell under — location: 725 ^ref-8328
Halvorson describes the if-then plan, in which we identify ahead of time a situation where we plan to do a certain task. Possible scenarios could be “if it’s after my 3pm meeting, then I’ll investigate this long-standing bug,” or “if it’s right after dinner, then I’ll watch a lecture on Android development.” Halvorson explains that the “planning creates a link between the situation or cue (the if) and the behavior that you should follow (the then).” When the cue triggers, the then behavior “follows automatically without any conscious intent.” 21 — location: 786 ^ref-32515
I save a list of short tasks that I need to get done and that don’t require a big chunk of uninterrupted time, and I use them to fill in the blank. Tasks that have worked well for me include finishing a code review, writing interview feedback, responding to emails, investigating a small bug, or writing an isolated unit test. — location: 802 ^ref-56296
David Allen, in Getting Things Done, suggests grouping to-do items by location-based contexts and then handling tasks based on your current context. — location: 817 ^ref-21290
in Personal Kanban, recommend creating a backlog of your work, transitioning tasks through various columns on a board (e.g., “backlog,” “ready,” “in progress,” and “done”), and limiting the amount of work-in-progress according to your own bandwidth as determined by trial and error — location: 819 ^ref-47834
author of Todoodlist, is an advocate of the old-fashioned pencil and paper to track what you need to get done. — location: 824 ^ref-51943
Francesco Cirillo uses a timer to track 25-minute focused sessions, called pomodoros; he works on a single task during each session. — location: 822 ^ref-62082
Key Takeaways Write down and review to-dos. Spend your mental energy on prioritizing and processing your tasks rather than on trying to remember them. Treat your brain as a processor, not as a memory bank. Work on what directly leads to value. Don’t try to do everything. Regularly ask yourself if there’s something higher-leverage that you could be doing. Work on the important and non-urgent. Prioritize long-term investments that increase your effectiveness, even if they don’t have a deadline. Reduce context switches. Protect large blocks of time for your creative output, and limit the number of ongoing projects so that you don’t spend your cognitive energy actively juggling tasks. Make if-then plans to combat procrastination. Binding an intention to do something to a trigger significantly increases the likelihood that you’ll get it done. Make prioritization a habit. Experiment to figure out a good workflow. Prioritize regularly, and it’ll get easier to focus on and complete your highest-leverage activities. — location: 880 ^ref-28804
We built tools to automatically version and package our code. We developed a testing framework that parallelized thousands of unit and integration tests across a tier of worker machines — location: 905 ^ref-11948
Or suppose you need to migrate an in-production database table from one schema to another. The standard process to change a live schema is: 1) create the new schema, 2) deploy code to write to both the old and new schemas, 3) copy existing data over from the old schema to the new schema, 4) deploy code to start reading from the new schema, and 5) remove the code that writes to the old schema. — location: 916 ^ref-64502
Just because changes are deployed incrementally, however, doesn’t mean that larger features aren’t possible or that users see half-finished features. A large feature gets gated behind a configuration flag, which is disabled until the feature is ready. — location: 924 ^ref-16696
The next time you find yourself repeatedly going through the same motions when you’re fixing a bug or iterating on a feature, pause. Take a moment to think through whether you might be able to tighten that testing loop. It could save you time in the long run. — location: 1096 ^ref-24240
Use testing tools that run only the subset of tests affected by your code. Even better, integrate the tool with your text editor or IDE so that you can invoke them with a few keystrokes — location: 1149 ^ref-35943
Find out where the biggest bottlenecks in your iteration cycle are, whether they’re in the engineering tools, cross-team dependencies, approvals from decision-makers, or organizational processes. Then, work to optimize them. — location: 1202 ^ref-14230
Key Takeaways The faster you can iterate, the more you can learn. Conversely, when you move too slowly trying to avoid mistakes, you lose opportunities. Invest in tooling. Faster compile times, faster deployment cycles, and faster turnaround times for development all provide time-saving benefits that compound the more you use them. Optimize your debugging workflow. Don’t underestimate how much time gets spent validating that your code works. Invest enough time to shorten those workflows. Master the fundamentals of your craft. Get comfortable and efficient with the development environment that you use on a daily basis. This will pay off dividends throughout your career. Take a holistic view of your iteration loop. Don’t ignore any organizational and team-related bottlenecks that may be within your circle of influence. — location: 1203 ^ref-9808
Good metrics accomplish a number of goals. First, they help you focus on the right things. They confirm that your product changes—and all the effort you’ve put into them—actually achieve your objectives — location: 1270 ^ref-26471
Second, when visualized over time, good metrics help guard against future regressions. Engineers know the value of writing a regression test while fixing bugs: it confirms that a patch actually fixes a bug and detects if the bug re-surfaces in the future. — location: 1276 ^ref-2875
Third, good metrics can drive forward progress — location: 1281 ^ref-18542
Fourth, a good metric lets you measure your effectiveness over time and compare the leverage of what you’re doing against other activities you could be doing instead. — location: 1290 ^ref-26507
Hours worked per week vs. productivity per week — location: 1306 ^ref-37925
Consider a few examples of how tracking different metrics can affect team behavior — location: 1306 ^ref-41389
Click-through rates vs. long click-through rates — location: 1314 ^ref-61282
Average response times vs. 95th or 99th percentile response times. — location: 1320 ^ref-3937
Bugs fixed vs. bugs outstanding. — location: 1330 ^ref-23094
Registered users vs. weekly growth rate of registered users. — location: 1334 ^ref-26124
Weekly active users vs. weekly active rate by age of cohort. — location: 1338 ^ref-20290
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, — location: 1378 ^ref-20770
The company Percona provides MySQL-related consulting services. 36 If you want to optimize the performance of your MySQL database, Percona consultants can audit everything from your configuration, operating system, and hardware to your architecture and table design, and, within a day or two, assess how well your database is performing. — location: 1467 ^ref-26649
Writes tend to be the bottleneck for many systems, and if that’s the case for your system, then designing the system to scale the writes might mean parallelizing them across more machines or batching multiple writes to disk. — location: 1512 ^ref-26834
the number of registered users, weekly active users, and monthly users the number of requests per second the amount and total capacity of data stored the amount of data written and accessed daily the number of servers needed to support a given service the throughput of different services or endpoints the growth rate of traffic the average page load time the distribution of traffic across different parts of a product the distribution of traffic across web browsers, mobile devices, and operating system versions — location: 1530 ^ref-46343
“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. Other times, we confuse correlation with causality — location: 1544 ^ref-49472
and Engineering at Netflix, explained that Netflix throws reams of semi-structured logs into a scalable data store called Cassandra, and decides later on whether that data might be useful for analysis. — location: 1576 ^ref-17027
Key Takeaways Measure your progress. It’s hard to improve what you don’t measure. How would you know what types of effort are well spent? Carefully choose your top-level metric. Different metrics incentivize different behaviors. Figure out which behaviors you want. Instrument your system. 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. Know your numbers. Memorize or have easy access to numbers that can benchmark your progress or help with back-of-the-envelope calculations. Prioritize data integrity. Having bad data is worse than having no data, because you’ll make the wrong decisions thinking that you’re right. 6. — location: 1590 ^ref-44818
In Chapter 4, we learned that investing in iteration speed helps us get more things done. In this chapter, we’ll learn how validating our ideas both early and often helps us get the right things done. — location: 1643 ^ref-24931
Brock, an engineering manager at Square, frequently advises his team, “What’s the scariest part of this project? That’s the part with the most unknowns and the most risk. Do that part first.” 14 Demystifying the riskiest areas first lets you proactively update your plan and avoid nasty surprises that might invalidate your efforts later — location: 1664 ^ref-26457
An A/B test doesn’t just help you decide which variation to launch. Even if you were absolutely convinced that a certain change would improve metrics, an A/B test tells you how much better that variation actually is. — location: 1755 ^ref-35602
Building your own A/B testing framework might seem daunting. Fortunately, there are many existing tools that you can use to test your product hypotheses. Free or open source A/B testing frameworks include Etsy’s feature-flagging API, 31 Vanity, 32 Genetify, 33 and Google Content Experiments. 34 If you want more tooling and support, you can pay a monthly fee for software like Optimizely, 35 Apptimize, 36 Unbounce, 37 and Visual Website Optimizer. 38 Given how much you can learn through A/B testing, it’s well worth the investment — location: 1788 ^ref-30247
Be open and receptive to feedback. If you adopt a defensive mindset about your work, it will be difficult for you to listen to feedback—and people will be less willing to offer it in the future. Instead, optimize for learning. View feedback and criticism not as personal attacks but as opportunities for improvement. — location: 1852 ^ref-61202
Key Takeaways Approach a problem iteratively to reduce wasted effort. Each iteration provides opportunities to validate new ideas. Iterate quickly to learn quickly. Reduce the risk of large implementations by using small validations. Invest a little extra effort to figure out if the rest of your plan is worth doing. Use A/B testing to continuously validate your product hypotheses. By incrementally developing a product and identifying what does and doesn’t work, you increase the probability that your efforts are aligned with what users actually want. When working on a solo project, find ways of soliciting regular feedback. It may be easy and comfortable to keep working in a silo, but you run the huge risk of overlooking something that, if spotted early, could save you lots of wasted effort. Adopt a willingness to validate your decisions. Rather than making an important decision and moving on, set up feedback loops that enable you to collect data and assess your work’s value and effectiveness. — location: 1920 ^ref-64833
Project estimation is one of the hardest skills that an effective engineer needs to learn. But it’s crucial to master: businesses need accurate estimates to make long-term plans for their products. They need to know when resources might free up to work on upcoming features or when they can promise feature requests to customers. And even when we don’t have pressure to ship against a deadline, how long we think a project will take affects our decisions of what to work on. — location: 1974 ^ref-42837
Engineers create estimates, and managers and business leaders specify targets. How to effectively handle gaps between the estimates and targets is the focus of this chapter. — location: 1993 ^ref-8334