How should we decide what actually to work on in order to more effectively achieve our goals? Assess the activities' leverage:
Leverage = (Impact Produce) / (Time Invested)
Another way of thinking about leverage is the commonly-mentioned Pare- to principle, or 80–20 rule—the notion that for many activities, 80% of the im- pact comes from 20% of the work.
Your overall leverage—the amount of value that you produce per unit time—can only be increased in three ways:
- By reducing the time it takes to complete a certain activity
- By increasing the output of a particular activity
- By shifting to higher-leverage activities
To increase the leverage of each activity, ask yourself these three questions:
- How can I complete this activity in a shorter amount of time?
- How can I increase the value produced by this activity?
- Is there something else that I could spend my time on that would produce more value?
- Adopt a Growth Mindset: Mindset influences whether people take advantage of opportunities to improve their skills.
Compounding leads to an exponential growth and learning, like interest, also compounds.
Improve yourself 1%, it is a high-leverage investment to devlop the skills and knowledge to make use of future opportunities.
Factors to consider when choosing a new job:
- Fast growth
- Training
- Openness: Look for a culture of curiosity.
- Pace: Do push yourself, but also find a pace that's sustainable for you in the long run.
- People: Surround yourself with people who are smarter, more talented and more creative than you.
- Automony: The freedom of choose what to work on.
- Study code for core written by the best engineers at your company.
- Write more code.
- Go through any technical, educational material available internally
- Master the programming languages that you use.
- Send your code reviews to the harshest critics.
- Enroll in classes on areas where you want to improve.
- Participate in design discussion of projects you're interested in.
- Work on a diversity of projects.
- Make sure you're on a team with at least a few senior engineers whom you can learn from.
- Jump fearlessly into code you don't know.
Learning opportunities aren't limited to the workplace. Here are ten starting points to help inspire a habit of learning outside:
- Learn new programming languages and frameworks
- Invest in skills that are in high demand.
- Read books
- Join a discussion group
- Attend talks, conferences, and meetups.
- Build and maintain a strong network of relationships.
- Follow bloggers who teach
- Write to teach
- Tinker on side projects
- Pursue what you love
In any engineering discipline (and in life), there will always be more tasks to do than you have time for. Wroking on one task means not working on another.
- Track To-Dos in a Single, Easily Accessible List
So how do you determine if something else has higher leverage than what you’re currently doing?
- Important and urgent: Crises, Pressing Issues, Deadlines
- Important and Not Urgent: Planning and prevention, Building relationships, New opportunities, Personal deveopment.
- Not Important and urgent: Interruptions, Most meetings, Most emails and calls
- Not important and not urgent: Surfing the web, busy work, time wasters.
Increasing work linearly increases the likelihood of failure exponentially
We identify ahead of time a situation where we plan to do a certain task.
The planning creates a link between the situation or cure (the if) and the behavior that should follow (the then). When cure triggers, the then behavior follows automatically without any conscious intent.
- Continuous deployment
Because learning compounds, the sooner you accelerate your iteration speed, the faster your learning rate will be.
Time saving tools pay off large dividends.
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.
So start small. Find an area where a tool could save time, build it, and demonstrate its value.
- Get proficient with your favorite text editor or IDE
- Learn at least one productive, high-level programming language
- Get familiar with UNIX (or Windows) shell commands
- Prefer the keyboard over the mouse
- Automate your manual workflows
- Test out ideas on an interactive interpreter
- Make it fast and easy to run just the unit tests associated with your current changes
Good metrics accomplish a number of goals:
- Help you focus on the right things
- When visualized over time, they help guard against future regressions
- Can drive forward progress
- Lets you measure your effectiveness over time and compare the leverage of what you're doing against other activities you could be doing instead.
when deciding which metrics to use, choose ones that:
- maximize impact
- Are actionable
- Are responsive yet robust
- Hours worked per week vs productivity per week
- Bugs fixed vs bugs outstanding
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.
We need to be careful about how we use data. Sometimes, we pick easy-to-measure or slightly irrelevant metrics, and use them to tell a false narrative about what's happening.
Make sure your data is reliable. The only thing worse than having no data is the illusion of having the right data.
Optimize for feedback as soon as possible--in other words, understanding what customers actually want and then iterating on feedback.
Invest a small amount of work to gather data to validate your project assumptions and goals.
Project estimation is one of the hardest skills that an effective engineer needs to learn.
A goo estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project and hit its targets.
Project schedules often slip because we allow the target to alter estimate. A more productive approach is to use the estimates to inform project planning, rather than the other way around.
How do we produce accurate estimates?
- Decompose the project into granular tasks
- Estimate based on how long tasks will take, not on how long you or someone else wants them to take.
- Be aware of anchoring bias
- Use multiple approaches to estimate the same task
- Don't assume that adding more people will shorten a project timeline
- Allow others to challenge estimates
As engineers, our jobs typically require us to fix outstanding bugs, conduct interviews, attend team meetings, hold one-on-ones with our managers, partic- ipate in pager duty rotations, train new engineers who join the team, respond to email, and tackle many other recurring duties. Once you factor in these de- tails, an 8-hour workday doesn’t actually provide 8 hours of working time on a project
Define specific goals to reduce risk and efficiently allocate time, and outline milestones to track progress. This allows us to build alignment around what tasks can be deferred and decreases the chance that a project inadvertently grows in scope.
Tackling the riskiest areas first helps us identify any estimation errors associated with them
There are a number of reasons why working more hours doesn’t necessarily mean hitting the launch date:
- Hourly productivity decreases with additional hours worked
- You're probably more behind schedule than you think
- Additional hours can bourn out team members
- The sprint toward the deadline Incentivize technical debt
Increase the prob- ability that overtime will actually accomplish your goals by:
- Making sure everyone understands the primary causes for why the timeline has slipped thus far. Are you sure those same problems will not persist going forward?
- 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.
High software quality enables organizations to scale and increases the rate at which engineers can produce value, and underinvesting in quality can ham- per your ability to move quickly.
On the other hand, it’s also possible to be overly dogmatic about code reviews, standardization, and test coverage—to the point where the processes provide diminishing returns on quality and actually reduce your effectiveness.
Benefits of Code review:
- Catching bugs or design shortcomings early
- Increasing accountability for code changes
- Positive modeling on how to write good code
- Sharing working knowledge of codebase
- Increasing long-term agility
Fundamentally, there’s a tradeoff between the additional quality that code reviews can provide and the short-term productivity win from spending that time to add value in other ways.
Technical debt refers to all the deferred work that’s necessary to improve the health and quality of the codebase and that would slow us down if left un- addressed.
Technical debt doesn’t just accumulate when we make quick and dirty workarounds. Whenever we write software without fully understanding the problem space, our first version will likely end up being less cleanly designed than we’d like.
The key to being a more effective engineer is to incur technical debt when it’s necessary to get things done for a deadline, but to pay off that debt peri- odically.
When engineering teams don’t focus on doing the simple thing first, they either end up being less effective over time because their energy is spent on a high upkeep cost, or they reach a point where the operational burden gets so high that they’re forced to simplify their architecture
Having too complex of an architecture imposes a maintenance cost in a few ways:
- Engineering expertise gets splintered across multiple systems.
- Increased complexity introduces more potential single points of failure.
- New engineers face a steeper learning curve when learning and under- standing the new systems.
- Effort towards improving abstractions, libraries, and tools gets diluted across the different systems
It’s fine to experiment with a new programming language for a prototype or a toy project, but think hard before using it in a new production system
Slowly failing systems muddy the sources of code errors, making it difficult for us to discover what went wrong.
Inevitably, bugs will arise and soft- ware will be misconfigured, and we will need to spend time reproducing the issues and pinpointing the sources of errors. The more directly we can link the feedback to a source, the more quickly that we can reproduce the problem and address the issue.
By failing fast, we can more quickly and effectively surface and address issues.
- Crashing at startup time when encountering configuration errors
- Validating software inputs, particularly if they won’t be consumed until much later
- Bubbling up an error from an external service that you don’t know how to handle, rather than swallowing it
- Throwing an exception as soon as possible when certain modifications to a data structure, like a collection, would render dependent data structures, like an iterator, unusable
- Alerting engineers about any invalid or inconsistent program state as early as possible
When deciding whether to automate, the judgment call that an engineer must make is: Will I save more time overall by manually doing a particular task or by paying the upfront cost of automating the process?
Engineers automate less frequently than they should, for a few reasons:
- They don’t have the time right now.
- They suffer from the tragedy of the commons.
- 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.
Activities where automation can help include:
- Validating that a piece of code, an interaction, or a system behaves as ex- pected
- Periodically running batch computations
- Restarting a web service
An idempotent process produces the same results regardless of whether it’s run once or multiple times
When idempotence isn’t possible, structuring a batch process so that it’s at least retryable or reentrant can still help. A retryable or reentrant process is able to complete successfully after a previous interrupted call.
Building confidence in your ability to recover lets you proceed more boldly.
Investing in onboarding is just one way to invest in your team’s growth. Investing in other people’s success is important for another reason: you can get swept up the ladder with them.
- Ramp up new engineers as quickly as possible.
- Impart the team’s culture and values.
- Expose new engineers to the breadth of fundamentals needed to succeed.
- Socially integrate new engineers onto the team.
There’s a common misconception that being the sole engineer responsible for a project increases your value. While that can feel good and may even increase your job security, it also comes with a cost.
Identifying others on your team who can relieve some of those demands gives you more freedom to focus on other high-leverage activities.
- 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.
The more you learn from each experience, the more you’ll take with you into your next project, and the more you’ll succeed.
This will help you be more productive, streamline decisions, and recruit other strong en- gineers. You build a great culture by fostering the same habits you need to effectively deliver impact.
- Optimize for iteration speed.
- Push relentlessly towards automation.
- Build the right software abstractions.
- Focus on high code quality by using code reviews.
- Maintain a respectful work environment.
- Build shared ownership of code.
- Invest in automated testing.
- Allot experimentation time, either through 20% time or hackathons.
- Foster a culture of learning and continuous improvement.
- Hire the best.