• How we view our own effectiveness impacts how much effort we invest in improving it
• Two mindsets
  1. Fixed mindset (human qualities are carved in stone)
  2. Growth mindset (human can cultivate and grieve their intelligence and skills through effort)
     • Those with growth mindsets are willing to take steps to better themselves

• Own your story
  • It's not about apologizing for where your resume doesn't line up
  • But rather telling your story
    • Who you are
    • What skills you've built
    • What you're excited about doing next and why

• Accepting responsibility for each aspect of a situation that you can change
• Rather than blaming failures and shortcomings on things outside your control
• Taking control of your own story
• Optimizing for experience where you effortlessly succeed
• Investing in your rate of learning

1. Compounding leads to an exponential growth curve
2. The earlier compounding starts, the sooner you hit the region of rapid growth and the faster you can reap its benefits
3. Even small deltas in the interest rate can make massive difference in the long run

1. Learning follows an exponential growth curve
   • Knowledge gives you a foundation, enabling you to gain more knowledge even faster
2. The earlier that you optimize for learning, the more time your learning has to compound
3. Due to compounding, even small deltas in your own learning rate make a big difference over the long run

• Treat yourself like a startup The Startup of You
  • Startups initially prioritize learning over profitability to increase their chances of success
  • Setting yourself up for long-term success requires thinking of yourself as a startup or product in beta, a work-in-progress that needs to be invested-in and iterated in every single day
• Continuous iteration Delivering Happiness
  • "Think about what it means to improve just 1% per day and build upon that every single day. (37x at the end of the year, not 365%/3.65x better)

• 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
• What should you do?
  1. Develop a deeper understanding of areas you're already working on and tools that you already use
  2. Gain experience in "adjacent disciplines"
     • Disciplines related to your core role and where increased familiarity can make you more self-sufficient and effective
     • Product Management
       • User Research
       • Product Management
       • Backend Engineering
     • Infrastructure engineer
       • Maxine learning
       • Database internals
       • Web Development
     • Growth engineer
       • Data Science
       • Marketing
       • Behavioral psychology
     • Adjacent Disciplines will not only be useful
     • But you'll also be more likely to retain the information because you'll be actively practicing ot

1. Study code for core abstractions written by the best engineers at your company.
2. Write more code.
3. Go through any technical, educational material available internally.
4. Master the programming languages that you use.
   • Make sure that at least one of your languages is a scripting language (e.g., Python or Ruby) that you can use as your Swiss army knife for quick tasks.
5. Send your code reviews to the harshest critics.
   • Optimize for getting good, thoughtful feedback rather than for lowering the barrier to getting your work checked in.
   • Discuss software designs with your company’s best designers in order to avoid writing great code for a design that doesn’t work well.
6. Enroll in classes on areas where you want to improve.
7. Participate in design discussions of projects you’re interested in.
   • Don’t wait for an invitation.
   • Ask project leads if they’d mind you being a silent observer or even a participant in a design meeting.
   • If mailing lists are open internally, add yourself or read through key conversations in the archives.
8. Work on a diversity of projects.
   • Interleaving different projects can teach you what problems are common across projects and what might just be artifacts of your current one.
   • The interleaved practice of different skills is more effective than repeated, massed practice of a single skill at preparing people to tackle unfamiliar problems
9. Make sure you’re on a team with at least a few senior engineers whom you can learn from.
10. Jump fearlessly into code you don’t know.
    • engineering success was highly correlated with “having no fear in jumping into code they didn’t know.”
    • Fear of failure often holds us back, causing us to give up before we even try.
    • “in the practice of digging into things you don’t know, you get better at coding.”

• How can I improve?
• How could I have done this better?
• What should I learn next to best prepare me for the future?

• 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.
• research in positive psychology shows that continual learning is inextricably linked with increased happiness

1. Learn new programming languages and frameworks.
2. Invest in skills that are in high demand
3. Read books
   • Using books to discover how the world works
   • Books offer a way for you to learn from the lessons and mistakes of others (you can re-apply that knowledge without having to start from scratch.)
4. Join a discussion group
5. Attend talks, conferences, and meetups
6. Build and maintain a strong network of relationships
   • the more people you meet, the more you’ll find serendipitous opportunities
   • “Lucky people dramatically increase the possibility of a lucky chance encounter by meeting a large number of people in their daily lives. The more people they meet, the greater opportunity they have of running into someone who could have a positive effect on their lives.” - The Luck Factor
7. Follow bloggers who teach
8. Write to teach
   • When you write to teach other people, you gain a deeper understanding of ideas you’re already familiar with and pinpoint the details that you didn’t fully understand.
   • The Feynman Technique: The Best Way to Learn Anything
   • Writing also provides an opportunity for mindful reflection on what you’ve learned.
   • Presenting at conferences can have similar benefits.
9. Tinker on side projects
   • Creativity stems from combining existing and often disparate ideas in new ways.
   • Projects in seemingly orthogonal areas like drawing and writing can have benefits that flow over to help you be a better engineer.
10. Pursue what you love
    • Spend time on what you’re passionate about instead,
    • Let that passion fuel your motivation to learn and to grow.

• The Checklist Manifesto

• Getting Things Done: The Art of Stress-Free Productivity: David Allen: 9780142000281: Amazon.com: Books
• Because the human brain is optimized for processing and not for storage.
  • The Magical Number Seven, Plus or Minus Two - Wikipedia
    • The average brain can actively hold only 7 +/- 2 items in its working memory.
    • Once there are more than 7 items, people fail to repeat digits and words back in the correct order over half the time.
  • Research shows that expending effort on remembering things
    1. reduces our attention
    2. impairs our decision-making abilities
    3. hurts our physical performance

1. a canonical representation of our work
2. easily accessible
   • allows you to quickly identify a task you can complete if you unexpectedly have a block of free time.
   • if you think up a new task, you can add it directly to your list even when you're out and about, rather than investing mental energy in trying to remember it.

• Notebook
• Task management software
• Mobile app
• Dropbox text file

1. you reduce the number of tasks you need to remember down to just one: to check your single, master list
2. you free your mind to focus on a higher-leverage activity: actually prioritizing your work.

1. we had limited data
2. every task we tackled inspired new tasks that we'd then insert into our to-do list -> we never got to most of the backlogged items on our ranked list

• 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.

• Activity is not necessarily production
• Many work activities do not directly contribute towards useful output

1. directly bring a product closer to launch
2. directly increase the number of users, customers or sales
3. directly impact the core business metric your team is responsible for.

• Once you do this a few times, it becomes easier to recognize which tasks are the most valuable.

• 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.

• Focus on what matters
• And what matters is what produces value.

Partitioning of activities based on urgency and importance

• Their productivity might slow down at first,
• but with time, the new tools and workflows that they learn will increase their effectiveness and easily compensate for the initial loss.

• Examples
  • Frequent pager duty alerts might indicate a need for automated recovery procedures.
  • High-priority bugs might be a symptom of low test coverage.
  • Constant deadlines might be caused by poor project estimation and planning.
• Investing in Quadrant 2 solutions can reduce urgent tasks and their associated stress.

1. Schedule necessary meetings back-to-back or at the beginning or end of your work day, rather than scattering them throughout the day.
2. If people ask you for help while you're in the middle of a focused activity, tell them that you'd be happy to do it before or after your breaks or during smaller chunks of your free time.
3. Block off hours on your calendar (maybe even with a fake meeting) or schedule days like "No Meeting Wednesdays" to help consolidate chunks of time.
4. Learn to say no to unimportant activities, such as meetings that don't require your attendance and other low-priority commitments that might fragment your schedule.

• the brain's working memory is like a stage and its thoughts are like the actors.
• The stage has a limited amount of space (for 7 ± 2 actors), but in order to make decisions, the prefrontal cortex needs to bring all the relevant actors onto the stage at once
• When we work on too many things simultaneously, we spend most of our brain's mental energy moving actors on and off the stage rather than paying attention to their performance.

• there is a limit to how many things we can work on at once.
• Constant context switching hinders deep engagement in any one activity and reduces our overall chance of success.

• When a small group of people fragment their efforts across too many tasks, they stop sharing the same context for design discussions or code reviews.
• Competing priorities divide the team, and momentum on any one activity slows down.

• Use trial and error to figure out how many projects you can work on before quality and momentum drop
• resist the urge to work on too many projects at once.

• in which we identify ahead of time a situation where we plan to do a certain task.
• Examples
  1. "if it's after my 3pm meeting, then I'll investigate this long-standing bug,"
  2. "if it's right after dinner, then I'll watch a lecture on Android development."
• "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." (subconscious followup)
  • Procrastination primarily stems from a reluctance to expend the initial activation energy on a task.
  • This reluctance leads us to rationalize why it might be better to do something easier or more enjoyable, even if it has lower leverage.
  • When we're in the moment, the short-term value that we get from procrastinating can often dominate our decision-making process.
  • But when we make if-then plans and decide what to do ahead of time, we're more likely to consider the long-term benefits associated with a task.
• The concept of if-then planning also can help fill in the small gaps in our maker’s schedule.
  • 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.
    • finishing a code review,
    • writing interview feedback,
    • responding to emails,
    • investigating a small bug,
    • writing an isolated unit test.

• The suggestions are endless
• Take general principles
• Iteratively adapt your own system until you find something that works well for you
• If you don’t have a system, then reading productivity books or using another engineer’s system can help provide a starting point.
• The actual mechanics of how you review your priorities matter less than adopting the habit of doing it.

1. Have sections for
   1. This Week
   2. Today
   3. Doing
2. Estimate and annotate each task with the number of 25-minute pomodoros
3. Do morning prioritization
   • Identify a small number of important tasks that I wanted to accomplish during the rest of the day.
   • Whenever I didn’t get something done that I had previously prioritized, the routine gave me an opportunity to review why: had I worked on something else more important, misprioritized, or simply procrastinated?
4. If it’s in the morning, then I’ll pick tasks requiring more mental effort and creativity.
5. Timing what I’m doing might seem like overkill, but I’ve found that it increases my awareness of how much time I spend on a given task and makes me more accountable when distractions arise.
6. Track how many 25-minute sessions I spend on a task, mainly to validate and learn about whether my initial estimates were accurate.
7. On a Sunday afternoon or Monday morning, I review the priorities I’ve accomplished, examine the ones I had planned to finish but didn’t so I can understand why, and scope out what I hope to accomplish in the following week

• With each iteration, you get a better sense of which changes you will point you in the right direction, making your future efforts much more effective.
• If you never break anything, you're probably not moving fast enough

1. CD
2. investing in time-saving tools
3. Improving your debugging loops
4. Mastering your programming workflows
5. Removing any bottlenecks that you identify

• So increasing your effort as a way to increase your impact fails to scale
• Tools ate the multipliers that allow you to scale your impact beyond the confines of the work day
  1. Time-saving Tools pay off large dividends
  2. Faster tools get used more often
  3. Faster tools can enable new development workflows that previously weren't possible
     • CD
     • Compilation Speed
     • REPL
     • CI

• 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
• Sometimes, the time-saving tool that you built might be objectively superior to the existing one, but the switching costs discourage other engineers from actually changing their workflow and learning your tool
  • In these situations, it's worth investing the additional effort to lower the switching cost and to find a smoother way to integrate the tool into existing workflows
• One side benefit of proving to people that your tool saves time is that it also earns you leeway with your manager and your peers to explore more ideas in the future
  • It can be difficult to convince others that an idea that you believe in is actually worth doing
  • So start small

• When you're fully engaged with a bug you're testing or a new feature you're building, the last thing you want to do is to add more work
• When you're already using a workflow that works, albeit with a few extra steps, it's easy to get complacent and not expend the mental cycles on devising a shorter one

1. Get proficient with your favorite text editor or IDE
2. Learn at least one productive, high-level programming language
   • Each Minute spent writing boilerplate code for a less productive language is a minute not spent tackling the meatier aspects of a program
3. Get familiar with shell commands
4. Prefer the keyboard over the mouse
5. Automate your manual workflows
6. Test our ideas on an interactive interpreter
7. Make it fast and easy to run just the unit tests associated with your current changes

1. Identify the biggest bottlenecks
2. Figure out how to eliminate them

• Oftentimes the cause is a misalignment if priorities rather than negative intention
• 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
• Communication is critical for making progress on people-related bottlenecks
  • projects fail from under-communicating, not over- communicating

• 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, do that you can make sure to get those details right
• Don't defer approvals until the end

• whether they be
  • Verification by the quality assurance team
  • A scalability or reliability review by the performance team
  • An audit by the security team

1. They help you focus on the right thins
2. When visualized over time, good metrics help guard against future regressions
3. Good metrics can drive forward progress
   • A technique called performance ratcheting used in Box
     • Use metrics to set a threshold (performance ratchet)
     • Any new change that would push latency or other key indicators past the ratchet can't get deployed until it's optimized, or until some other feature is improved by a counterbalancing amount.
     • Moreover, every time the performance team makes a system-level improvement, they lower the ratchet further.
4. 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

• Just because it's hard to measure a goal doesn't mean that it's not worthwhile to do so

1. Is there some way to measure the progress of what I'm doing?
2. If a task I'm working on doesn't move a core metric, is it worth doing? Or is there a missing key metric?

• The choice of which metric to measure dramatically impacts and influences the type of work that we do
• There can be more than one way to measure progress toward any given goal
• The magnitude of the goal for a metric also matters
• What you don't measure is important as well
  • "average handle time" for customer service

1. maximize impact

   • economic denominator from Good to Great

     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?

     • In the context of engineering, the core 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.
     • Why having a single, unifying metric?
       1. it enables you to compare the output of disparate projects
       2. it helps your team decide how to handle externalities
2. are actionable
   • One whose movements can be causally explained by the team's efforts
   • In contrast, vanity metrics (from The Lean Startup)
     • track gross numbers
     • Increases in vanity metrics may imply forward product progress
     • But they don't necessarily reflect the actual quality of the team's work
     • Examples
       • page views per month
       • total registered users
       • total paying customers
   • actionable metrics
     • Examples
       • signup conversion rate
       • the percentage of registered users that are active weekly over time
     • Through A/B testing, we can trace the movement of actionable metrics directly back to product changes or to feature launches
3. are responsive yet robust

   responsive

   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

   robust

   external factors outside of the team's control don't lead to significant noise

   (no term)

   Responsiveness needs to be balanced with robustness.

Core metrics

a high-level, big-picture activity

Day-to-day operation metrics

Gaining insight into what's going on with systems that we've built

• 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.
  • That's a main reason why the 2013 HealthCare.gov launch was such an abysmal failure.

• Since we often don't know everything that we want to measure ahead of time
• Therefore, we need to build flexible tools and abstractions that make it easy to track additional metrics

• The numbers that matter to you will vary based on your focus area and your product.
  • Latency numbers every programmer should know

1. Knowing useful numbers like these enables you, with a few back-of-the-envelope calculations, to quickly estimate the performance properties of a design without actually having to build it.
2. Internalizing useful numbers can also help you spot anomalies in data measurements.
3. Knowledge of useful numbers can clarify both the areas and scope for improvement.

• To obtain performance-related numbers, you can write small benchmarks to gather data you need.
• Other numbers may require more research, like talking with teams (possibly at other companies) that have worked in similar focus areas, digging through your own historical data, or measuring parts of the data yourself.

• 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.

• Our best defense is skepticism

  Bad math students

  they get to the end of the problem, and they’re just done.

  Good math students

  get to the end of the problem, look at their answer, and say, 'Does that roughly make sense?'

• When it comes to metrics,
  1. compare the numbers with your intuition to see if they align.
  2. Try to arrive at the same data from a different direction and see if the metrics still make sense.
  3. If a metric implies some other property, try to measure the other property to make sure the conclusions are consistent.

• Unfortunately, it’s all too common for engineers to underinvest in data integrity, for a few reasons:
  1. Since engineers often work against tight deadlines, metrics—whose importance only shows up after launch—can get deprioritized.
  2. When building a new product or feature, it’s much easier to test and validate their interactions than to verify whether some seemingly plausible metric (like page views) is actually accurate.
  3. Engineers reason that because their metrics-related code was well unit-tested, the metrics themselves also should be accurate, even though there could be system-level errors or incorrect assumptions.
• The net result is that metrics-related code tends to be less robust than code for other features.

1. Log data liberally, in case it turns out to be useful later on.
2. Build tools to iterate on data accuracy sooner.
3. Write end-to-end integration tests to validate your entire analytics pipeline.
4. Examine collected data sooner.
5. Cross-validate data accuracy by computing the same metric in multiple ways.
6. When a number does look off, dig in to it early.

1. lead to fewer costly errors
   • The shorter each iteration cycle, the more quickly we can learn from our mistakes.
   • The longer the iteration cycle, the more likely it is that incorrect assumptions and errors will compound.
2. give us opportunities between each iteration to collect data and correct our course.
   • Oftentimes when we build products and set goals, we embark on paths that aren’t clear-cut.

   • Demystifying the riskiest areas first lets you proactively update your plan and avoid nasty surprises that might invalidate your efforts later.

     What’s the scariest part of this project? That’s the part with the most unknowns and the most risk. Do that part first.

Minimum Viable Product

that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort - The Lean Startup

• that definition resembles our definition of leverage
• building an MVP requires being creative
  • Dropbox's MVP is a short 4-minute video
• the principle of validating our work with small efforts holds true for many engineering projects.
  • The cost of building a quick prototype doesn’t amount to much in the scheme of the larger project, but the data that it produces can save you a significant amount of pain and effort if it surfaces problems early, or convinces you that the larger migration wouldn’t be worthwhile.
  • The strategy of faking the full implementation of an idea to validate whether it will work is extremely powerful.

1. Help you decide which variation to launch.
2. Tell you how much better that variation actually is.
3. Encourage an iterative approach to product development, in which teams validate their theories and iterate toward changes that work

• When deciding what to A/B test, time is your limiting resource
• Hone into differences that are high-leverage and practically significant, the ones that actually matter for your particular scale.
• Initially, it’s tricky to determine what’s practically significant, but as you run more experiments, you’ll be able to prioritize better and determine which tests might give large payoffs.

The one-person team

An iconic Silicon Valley story features the engineer who designs and builds an ambitious system all on his own. Expecting to launch his project soon, he sends a large code review to a teammate—only to learn about a major design flaw he’d missed, and to be informed that he should have built his system in a completely different way.

1. it adds friction to the process of getting feedback
2. The lows of a project are more demoralizing when you're working alone.
   • A single stall can grind the project to a halt, causing deadlines to slip
3. The highs can be less motivating when you’re working alone.
   • Knowing that your teammates are depending on you increases your sense of accountability
   • The desire to help your team succeed can override the dips in motivation that everyone occasionally feels.

1. Be open and receptive to feedback
2. Commit code early and often
3. Request code reviews from thorough critics
4. Ask to bounce ideas off your teammates
5. Design the interface or API of a new system first
6. Send out a design document before devoting your energy to your code
7. If possible, structure ongoing projects so that there is some shared context with your teammates
8. Solicit buy-in for controversial features before investing too much time

• There might not be many data points, or there may only be qualitative data available.
• The more senior of an engineer you become (and particularly if you enter into management), the tougher and the more nebulous your decisions become.

1. formulating a hypothesis about what might work,
2. designing an experiment to test it,
3. understanding what good and bad outcomes look like,
4. running the experiment, and learning from the results.

1. hold the date constant and deliver what is possible
2. hold the feature set constant and push back the date until all the features can be delivered

• Decompose the project into granular tasks.
  • If a task will take more than two days, decompose it further.
  • A long estimate is a hiding place for nasty surprises.
    • Treat it (a long estimate) as a warning that you haven't thought through the task thoroughly enough to understand what's involved
  • The more granular a task's breakdown, the less likely that an unconsidered subtask will sneak up later.
• Estimate based on how long tasks will take, not on how long you or someone else wants them to take.
• Think of estimates as probability distributions, not best-case scenarios.
• Let the person doing the actual task make the estimate
• Beware of anchoring bias
  • Avoid committing to an initial number before actually outlining the tasks involved, as a low estimate can set an initial anchor that makes it hard to establish a more accurate estimate later on.
• Use multiple approaches to estimate the same task
• Beware the mythical man-month
• Validate estimates against historical data
• Use timeboxing to constrain tasks that can grow in scope
• Allow others to challenge estimates

• a simple spreadsheet for team members to track how many hours they estimated a task would take and how long it actually took.

1. A well-defined goal provides an important filter for separating the must-haves from the nice-to-haves in the task list.
   • The more specific the goal, the more it can help us discriminate between features.
2. It builds clarity and alignment across key stakeholders.
   • Building alignment also helps team members be more accountable for local tradeoffs that might hurt global goals.
   • Building alignment helps ensure that team members internalize those costs and make consistent tradeoffs.

• Each milestone was a very clear point where we had introduced some value that we didn't have before
  • The measurable quality enabled her team to scrutinize every single task and ask, "Is this task a prerequisite for this milestone?"
• Milestones act as checkpoints for evaluating the progress of a project and as channels for communicating the team’s progress to the rest of the organization.

• 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.
• Moreover, it’s extremely hard to decompose integration into granular tasks during the early estimation phases of a project, when you’re not sure what the end state will look like.
• How can we reduce integration risk?
  1. Build end-to-end scaffolding and do system testing earlier.
     1. it forces you to think more about the necessary glue between different pieces and how they interact, which can help refine the integration estimates and reduce project risk.
     2. if something breaks the end-to-end system during development, you can identify and fix it along the way, while dealing with much less code complexity, rather than scrambling to tackle it at the end.
     3. it amortizes the cost of integration throughout the development process, which helps build a stronger awareness of how much integration work is actually left.

• They share the same project planning and estimation difficulties as other software projects.
• Because we tend to be familiar with the original version, we typically underestimate rewrite projects more drastically than we would an undertaking in a new area.
• It is easy and tempting to bundle additional improvements into a rewrite.
• When a rewrite is ongoing, any new features or improvements must either be added to the rewritten version or they must be duplicated across the existing version and the new version. The cost of either option grows with the timeline of the project.

1. additional flexibility at each step to shift to other work that might be higher-leverage
2. Dramatically reduce risk (worth to increase the overall amount of work)
3. Significantly reduce the time pressure of the project

1. Hourly productivity decreases with additional hours worked
2. You're probably more behind the schedule than you think
3. Additional hours can burn out team members
4. Working extra hours can hurt team dynamics
5. Communication overhead increases as the deadline looms
6. The sprint toward the deadline incentivizes technical debt

• Making sure everyone understands the primary causes for why the timeline has slipped thus far.
• Developing a realistic and revised version of the project plan and timeline.
• Being ready to abandon the sprint if you slip even further from the revised timeline

• Catching bugs or design shortcomings early.
• Increasing accountability for code changes.
• Positive modeling of how to write good code.
• Sharing working knowledge of the codebase.
• Increasing long-term agility.

• Rather, think of code reviews as being on a continuum.
• They can be structured in different ways to reduce their overhead while still maintaining their benefits.
• Experiment to find the right balance of code reviews that works for you and your team.

1. It reduces the complexity of the original problem into easier-to-understand primitives.
2. It reduces future application maintenance and makes it easier to apply future improvements.
3. It solves the hard problems once and enables the solutions to be used multiple times.

1. takes more time than building one specific to a given problem.
   • That’s more likely to happen with software the team relies heavily on than with peripheral parts of the codebase
   • so focus more energy on making the core abstractions great.
2. it’s possible to overinvest in them up front
3. poor abstraction
   • When we’re looking for the right tool for the job and we find it easier to build something from scratch rather than incorporate an existing abstraction intended for our use case, that’s a signal that the abstraction might be ill-designed.
   • Create an abstraction too early, before you have a firm handle on the general problem you’re solving, and the resulting design can be overfitted to the available use cases.
   • Bad abstractions aren’t just wasted effort; they’re also liabilities that slow down future development.

• easy to learn
• easy to use even without documentation
• hard to misuse
• sufficiently powerful to satisfy requirements
• easy to extend
• appropriate to the audience

1. Find popular abstractions in your codebase at work or from repositories on GitHub.
2. Look through the open source projects at technology companies like Google, Facebook, LinkedIn, and Twitter.
3. 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.

• Decreases repetitive work that we'd otherwise need to do by hand.
• Leads engineers to be much more accountable for the quality of their own work.
• Allows engineers to make changes with significantly higher confidence
  • Automated tests mitigate against a culture in which people are fearful of modifying and improving a piece of code just because it might break.
• Helps to efficiently identify who's accountable for the broken change
• Executable documentation of what cases the original author considered and how to invoke the code
  • Average familiarity with a codebase decreases as both the code and the team grow

• The inflection point came when a simple unit test visibly started to save time.
• When the time savings became obvious, people looked for other strategic tests to help them iterate faster.

• Focus on high-leverage tests
• Once you have a few good tests, testing patterns, and libraries in place, the effort required to write future tests drops

• Start small and approach the problem incrementally

• Repay the debt with the highest leverage
• Code in highly-trafficked parts of the codebase that takes the least time to fix up.

1. Engineering expertise gets splintered across multiple systems
2. Increased complexity introduces more potential single points of failure.
3. New engineers face a steeper learning curve when learning and understanding the new systems
4. Effort towards improving abstractions, libraries, and tools gets diluted across the different systems

• Always ask, "What's the simplest solution that can get the job done while also reducing our future operational burden?"
• Revisit sources of complexity, and find opportunities to trim them away.

• These techniques cause software to fail slowly.
• The software may continue to run after an error, but this is often in exchange for less decipherable bugs further down the road.
• The more directly we can link the feedback to a source, the more quickly that we can reproduce the problem and address the issue.

1. use fail-fast techniques to surface issues immediately and as close to the actual source of error as possible;
2. complement them with a global exception handler that reports the error to engineers while failing gracefully to the end user

• They don't have the time right now.
• They suffer from the tragedy of the commons, in which individuals act rationally according to their own self-interest but contrary to the group's best long-term interests.
• They lack familiarity with automation tools
• They underestimate the future frequency of the task
• They don't internalize the time savings over a long time horizon

1. Automating mechanics
   • Straightforward
   • Testable
2. Automating decision-making
   • Much more challenging
   • They rarely get tested well
   • By definition they run in unusual circumstances

• Given your finite time, focus first on automating mechanics.
• Only after you've picked all the low-hanging fruit should you try to address the much harder problem of automating smart decisions.

• Convert infrequent workflows into more common ones by scheduling dry runs every day or week;

• From The Score Takes Care of Itself

• They practice their failure scenarios to strengthen their ability to recover quickly.
• They believe that it’s better to proactively plan and script for those scenarios when things are calm, rather than scramble for solutions during circumstances outside of their control.

• The smaller the company—and the more likely that the person you interview will be an immediate co-worker—the greater the leverage of those interviews.
• If those 40 hours resulted in even just one additional hire, the 2,000+ hours of output that he or she would contribute per year would more than justify the cost.

• A good interview process achieves two goals
  1. It screens for the type of people likely to do well on the team
  2. It gets candidates excited about the team, the mission, and the culture
     • Ideally, even if a candidate goes home without an offer, they still leave with a good impression of the team and refer their friends to interview with the company
     • One of your primary levers as an interviewer is therefore making the interview experience both fun and rigorous
• As an interviewer, your goal is to optimize for questions with high signal-to-noise ratios
  • Questions that reveal a large amount of useful information (signal) about the candidate per minute spent, with little irrelevant or useless data (noise)
    • Good, well-executed questions let you confidently differentiate among candidates of varying abilities;
    • Bad, poorly managed questions leave you unsure whether to hire the candidate.
  • The types of questions that generate the most signal depend on the qualities most correlated with success on your team.
    • An increasing number of companies have shifted toward interviews that include a hands-on programming component.
  • Ample literature exists to help you get started on designing questions.
    • Cracking the Code Interview

• Take time with your team to identify which qualities in a potential teammate you care about the most
• Periodically meet to discuss how effective the current recruiting and interview processes are at finding new hires who succeed on the team.
• Design interview problems with multiple layers of difficulty that you can tailor to the candidate's ability by adding or removing variables and constraints
• Control the interview pace to maintain a high signal-to-noise ratio.
  • Don't let interviewees ramble, get stumped, or get sidetracked for too long.
  • Either guide the interviewee along with hints, or wrap up and move on to a different question.
• Scan for red flags by rapidly firing short-answer questions to probe a wide surface area.
• Periodically shadow or pair with another team member during interviews
• Don't be afraid to use unconventional interview approaches if they help you identify the signals that your team cares about.

1. First impressions matter
2. Training a new engineer for an hour or two a day during her first month generates much more organizational impact than spending those same hours working on the product.
3. The initial time investment to create onboarding resources continues to pay dividends with each additional team member.

• Investing in your team's success means that you are more likely to succeed as well.
• Effectively ramping up new team members ultimately gives you more flexibility to choose higher-leverage activities.
  • A stronger and larger team means
    1. easier code reviews
    2. more people available to fix bugs
    3. increased resources for on-call rotations and support
    4. greater opportunities to tackle more ambitious projects.
• Onboarding is a win-win situation;
  1. the new hires receive valuable training,
  2. the mentors get more things done.
• A poor onboarding experience reduces a team's effectiveness.
  1. Productive output gets lost when a recent hire takes longer to ramp up.
  2. Code quality suffers if new team members use abstractions or tools incorrectly, or if they aren't familiar with team conventions or expectations.
  3. Insufficient training means it's harder to accurately identify low performers
  4. Good engineers undergo unnecessary stress and may even get weeded out because of weak guidance.

1. Identify the goals that your team wants to achieve

   • Goals for Quora's onboarding program

     1. Ramp up new engineers as quickly as possible
     2. Impart the team's culture and values
     3. Expose new engineers to the breadth of fundamentals needed to succeed
        • A key part of a good onboarding program is ensuring that everyone starts on a consistent, solid foundation.
     4. Socially integrate new engineers onto the team

   • Your own goals may vary
   • What's important is understanding what you want to achieve so that you can focus your efforts appropriately
2. Construct a set of mechanisms to accomplish these goals
   • Four main pillars for Quora's onboarding program
     1. Codelabs
        • A codelab is a document that explains why a core abstraction was designed and how it's used, walks through relevant parts of its code internals, and supplies programming exercises to validate understanding.
        • The codelabs clarified what abstractions were important to master early on and recommended a particular order for learning them.
        • They enabled new engineers to ramp up more quickly and make product changes sooner.
     2. Onboarding talks
        • Cover the things we believed were the most important for new hires to learn.
        • Together, the onboarding talks and codelabs helped ensure that new hires learned the fundamentals.
     3. Mentorship
        • Mentors checked in daily with their mentees during the first week, and then met for weekly 1:1s.
        • All of this helped establish the shared goal of ramping up new hires as quickly as possible, and set the expectation that they shouldn’t hesitate to seek guidance.
     4. Starter tasks
        • Complete a starter task by the end of the first week
        • This aggressive target conveyed the value of getting things done and moving fast.
        • It also meant that the team needed to remove enough onboarding friction for new hires to build momentum quickly.
        • Mentors were responsible for identifying starter tasks of increasing complexity for their mentees.
   • Building a good onboarding program is an iterative process.
   • To get a sense of what worked well and what could use some improvement.
     • Think about your own experience
     • Survey others on the team

• There’s a common misconception that being the sole engineer responsible for a project increases your value.
  • When you’re the bottleneck for a project, you lose your flexibility to work on other things.
• From a company’s perspective, sharing ownership increases the bus factor to more than one.
  • Shared ownership also means that everyone participates in maintenance duties and one person doesn’t carry the entire burden.
  • Shared ownership eliminates isolated silos of information and enables an engineer to step in for another teammate, so that everyone can focus on whatever produces the most impact.
• This gives senior engineers more free time to work on other projects and junior engineers an opportunity to ramp up on the infrastructure and the codebase.

• To increase shared ownership, reduce the friction that other team members might encounter while browsing, understanding, and modifying code that you write or tools that you build.
• Some strategies
  • Avoid one-person teams.
  • Review each other’s code and software designs.
  • Rotate different types of tasks and responsibilities across the team.
  • Keep code readable and code quality high.
  • Present tech talks on software decisions and architecture.
  • Document your software, either through high-level design documents or in code-level comments.
  • Document the complex workflows or non-obvious workarounds necessary for you to get things done.
  • Invest time in teaching and mentoring other team members.

1. What happened
2. How it happened
3. Why it happened
4. What we can do to prevent it from happening in the future

1. How effectively did your feature actually accomplish your team’s goals?
2. Was that actually the best use of your team’s time?

1. If your team hasn’t defined a clear goal or metric for a launch, it’s difficult to assess its success.
2. If your team doesn’t want to publicly declare months of work to be a failure, it’s tempting to close discussions.
3. If your team is overwhelmed with new projects, it’s hard to make time for reflection.

1. It requires acknowledging that months of effort may have resulted in failure, and viewing the failure as an opportunity for growth.
2. It requires aligning behind a common goal of improving the product or team, and not focusing on where to assign blame.
3. It requires being open and receptive to feedback, with the goal of building collective wisdom around what went wrong and what could’ve been done better

1. Optimize for iteration speed.
2. Push relentlessly towards automation.
3. Build the right software abstractions.
4. Focus on high code quality by using code reviews.
5. Maintain a respectful work environment.
6. Build shared ownership of code.
7. Invest in automated testing.
8. Allot experimentation time, either through 20% time or hackathons.
9. Foster a culture of learning and continuous improvement.
10. Hire the best.