Effective == Results
So what makes an effective engineer? Intuitively, we have some notion of which engineers we consider to be effective. They’re the people who get things done. They’re the ones who ship products that users love, launch features that customers pay for, build tools that boost team productivity, and deploy systems that help companies scale. Effective engineers produce results.
What is leverage?
The key to answering these questions and prioritizing these different activities is assessing their leverage. Leverage is defined by a simple equation. It’s the value, or impact, produced per time invested.
Increasing value produced per unit time in 3 ways:
Output of an engineer is measured in a variety of ways:
Growth mindset
On the other hand, those with a growth mindset believe that they can cultivate and grow their intelligence and skills through effort. They may initially lack aptitude in certain areas, but they view challenges and failures as opportunities to learn. As a result, they’re much less likely to give up on their paths to success.
Learning and compounding
The earlier compounding starts, the sooner you hit the region of rapid growth and the faster you can reap its benefits… Even small deltas in the interest rate can make massive differences in the long run.
Small changes
This last point about the compounding returns of intelligence is the least intuitive: we tend to drastically underestimate the impact of small changes on our growth rate. But when we spend our work hours on unchallenging tasks, we’re not just boring ourselves and missing out on chances to learn—we’re also paying a huge opportunity cost in terms of our future growth and learning.
6 major factors to consider when choosing a new job or team and the questions you should be asking for each of them:
Culture
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.
Learning 1 hour per day
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.
Diverse projects
Work on a diversity of projects. If you find yourself always doing similar tasks using similar methods, it’s going to be hard to pick up new skills.
Senior engineers
Make sure you’re on a team with at least a few senior engineers whom you can learn from. If you’re not, consider changing projects or teams.
Jump into the unknown
Jump fearlessly into code you don’t know. After years of observation, Bobby Johnson, a former engineering director at Facebook, concluded that engineering success was highly correlated with having no fear in jumping into code they didn’t know.
Here are ten starting points to help inspire a habit of learning outside of the workplace:
Having checklists
In The Checklist Manifesto, Dr. Atul Gawande shows how the adoption of checklists has drastically reduced errors in field after field, even for the most seasoned experts working on routine tasks. Pilots who follow pre-flight checklists, surgeons who follow operation checklists, and construction managers who follow safety checklists all eliminate large classes of avoidable errors simply by writing steps down and tracking what needs to be done.
Prioritization is a high leverage activity
Huddled around a conference room table, 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).
Saying NO
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.
Quadrant 2 activities:
Todo list
Working on larger features
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. The same configuration flag often allows teams to selectively enable a feature for internal team members, beta users, or some fraction of production traffic until the feature is ready.
Shortening feedback loop
We’ll then show why it’s critical to invest in time-saving tools and how to increase both their adoption and your leeway. Since much of our engineering time is spent debugging and testing, we’ll walk through the benefits of shortening our debugging and validation loops.
Faster iteration
Facebook’s growth illustrates why investing in iteration speed is such a high-leverage decision. The faster that you can iterate, the more that you can learn about what works and what doesn’t work.
Writing tools
When I ask engineering leaders which investments yield the highest returns, tools is the most common answer. Bobby Johnson, a former Facebook Director of Infrastructure Engineering, told me, I’ve found that almost all successful people write a lot of tools … [A] very good indicator of future success [was] if the first thing someone did on a problem was to write a tool.
Code compilation time
When code takes that long to compile, engineers make a conscious decision not to compile very often—usually no more than a few times a day. They batch together large chunks of code for the compiler and try to fix multiple errors per development
Tool adoption
Therefore, it’s not sufficient to find or build a time-saving tool. To maximize its benefits, you also need to increase its adoption across your team. The best way to accomplish that is by proving that the tool actually saves time.
Minimal reproducible test case
A minimal, reproducible test case removes all unnecessary distractions so that more time and energy can be spent on the core issue, and it creates a tight feedback loop so that we can iterate quickly.
Common tasks to automate:
Mindful of common tasks
Mastery is a process, not an event, and as you get more comfortable, the time savings will start to build. The key is to be mindful of which of your common, everyday actions slow you down, and then figure out how to perform those actions more efficiently.
Common shell commands
Get familiar with UNIX (or Windows) shell commands. Being able to manipulate and process data with basic UNIX tools instead of writing a Python or Java program can reduce the time to complete a task from minutes down to seconds. Learn basic commands like grep, sort, uniq, wc, awk, sed, xargs, and find, all of which can be piped together to execute arbitrarily powerful transformations.
Misalignment of priorities
This misalignment of priorities makes it difficult for you to succeed. The sooner you acknowledge that you need to personally address this bottleneck, the more likely you’ll be able to either adapt your goals or establish consensus on the functionality’s priority.
What to prioritize
Don’t wait until after you’ve invested massive amounts of engineering time to seek final project approval. Instead, prioritize building prototypes, collecting early data, conducting user studies, or whatever else is necessary to get preliminary project approval. Explicitly ask the decision makers what they care about the most, so that you can make sure to get those details right.
Google long click
In the Plex, Steven Levy finally shed some light on the subject: he revealed that Google’s best indication of user happiness is the long click. This occurs when someone clicks a search result and doesn’t return to the search page, or stays on the result page for a long time. A long click means that Google has successfully displayed a result that the user has been searching for. On the other hand, a short click—occurring when someone follows a link only to return immediately to the results page to try another one—indicates unhappiness with the result.
Only after Twitter engineers started monitoring and instrumenting their systems were they able to identify problems and build the much more reliable service that over 240 million people now use every month. When we don’t have visibility into our software, all we can do is guess at what’s wrong.
Etsy
Many other engineering and product teams design and fully build out a product or feature before launching them to users. They might then discover, after months of work, that what they built didn’t actually move core metrics as much as they had hoped. The Etsy listing page team approached their redesign much more incrementally. They would articulate a hypothesis, construct an A/B test to validate the hypothesis, and then iterate based on what they learned.
Randomly killing services at Netflix
At Netflix, engineers did something counterintuitive: they built a system called Chaos Monkey that randomly kills services in its own infrastructure. 18 Rather than spending energy keeping services alive, they actively wreak havoc on their own system.
Learning from APIs
Study the interfaces of popular APIs developed by Parse, Stripe, Dropbox, Facebook, and Amazon Web Services, and figure out what makes it so easy for developers to build on top of their platforms. Also reflect on APIs that you or the rest of community don’t like, and understand what you don’t like about them.
Choosing a good metric
The only way to be consistently confident when answering questions like these is to define a metric associated with your goal—whether that metric is weekly active rate, response time, click-through rate, or something else—and then measure the change’s impact. Without those measurements, we’re only able to proceed based on intuition; and we have few avenues for understanding whether our intuition is correct.
Choosing better metrics:
Choosing metrics:
1) maximize impact 2) are actionable 3) are responsive yet robust
Alignment
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.
Analyzing the system
Successful technology companies build the equivalent of a pilot’s flight instruments, making it easy for engineers to measure, monitor, and visualize system behavior. The more quickly that teams can identify the root cause of certain behaviors, the more rapidly they can address issues and make progress. At Google, site reliability engineers use a monitoring system called Borgmon to collect, aggregate, and graph metrics and to send alerts when it detects anomalies.
Other numbers that might be useful to internalize or at least have readily at hand include:
Increase confidence in your data integrity:
Work in a team with more eyeballs
There are other risks of one-person projects as well. The lows of a project are more demoralizing when you’re working alone. Sand traps that you struggle to get out of, monotonous work that you need to grind through, and bugs that seem to defy all understanding become less draining and more bearable when there’s someone there to share your pain
Estimates vs targets
Engineers create estimates, and managers and business leaders specify targets. How to effectively handle gaps between the estimates and targets
How to estimate?
Use multiple approaches to estimate the same task. This can help increase confidence that your approach is sound. For example, suppose you’re building a new feature. You can 1) decompose the project into granular tasks, estimate each individual task, and create a bottom-up estimate; 2) gather historical data on how long it took to build something similar; and 3) count the number of subsystems you have to
Fallacy of people and time
Beware the mythical man-month. In engineering, project durations typically get measured in terms of person-hours, person-days, person-weeks, or person-months—i.e. the number of hours, days, weeks, or months of work that it takes an average engineer to complete a project. Unfortunately, this type of accounting leads to the myth that people and time are interchangeable.
Effective learning
The goal from the beginning should be to maximize learning and minimize risk, so that we can adjust our project plan if necessary.
Code complexity
Code complexity grows as a function of the number of interactions between lines of code more than the actual number of lines, so we get surprised when subsystems interact in complex ways.
Why rewriting projects are troublesome
Better re-writing…
Benefits of code reviews:
Good abstractions should be:
Reducing complexity
Cleanup work
Asana, a startup that builds an online productivity tool, schedules a Polish and Grease Week at the end of every quarter to pay off any UI and internal tools debt that they might have accumulated. Quora devotes a day after every week-long hackathon to do cleanup work.
Adding more new technology?
Failing fast include
Activities where automation can help include:
Automating mechanics » Automating decision making
Automation can produce diminishing returns as you move from automating mechanics to automating decision-making.
Idempotent
One technique to make batch processes easier to maintain and more resilient to failure is to make them idempotent. An idempotent process produces the same results regardless of whether it’s run once or multiple times. It therefore can be retried as often as necessary without unintended side effects.
What if questions
Various levels of engineers
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.
Great engineering cultures:
Hacks