The Effective Engineer

by Edmond Lau

Part 1 : Mindset

Chapter 1: Focus on High-Leverage Activities

Effectiveness = Value per time unit of work

Leverage = Impact produce / time invested

80-20 rule : 80% of impact comes from 20% of work

Increase Leverage in 3 Ways

• Reducing time to complete an activity
• Complete the activity with less time
• Increase output of an activity

Learnings

• Reducing time for others is high leverage
• Focus on improving others' leverage

Chapter 2: Optimise for learning

Optimizing for learning is one of the highest leverage things you can do

Failures are growth opportunities

What to look for/promote

• Fast growth
• Training
• Openness
• Pace
• People
• Autonomy
• Exposure to adjacent disciplines

How to force grow

• Study Code
• Write code
• Go through technical documentation
• Master the programming language
• Send code reviews to harshest critics
• Enroll in classes
• Participate in design discussion - ask to be invited
• Work on a diversity of projects
• Make sure your team has some people for you to learn from
• 20% time to develop new skills
• Be fearless

Chapter 3: Prioritise regularly

Prioritizing is a high leverage task because it determines the leverage of your other tasks

Track to-dos in a singular accessible list

To-do list should be

• Canonical list of work
• Accessible
• Prioritized
• Visited

Focus on what directly produces value and the important non-urgent Examples of important non-urgent

• Planning
• Building relationships
• Personal development

Limit the amount of in progress work

Limit context switching

Say NO to work

Increasing work linearly increases the failure rate exponentially

If-Then Plans = Identify ahead of time a situation where you plan to do the task

Part 2 : Strategies for progress

Chapter 4: Invest in iteration speed

Increasing iteration speed has cascading effects. Completely changes workflow. Less time planning. Less time creating studies. Just ship it.

Building tools. Faster build times. Less time reading code. Now you can just try to build. Repo builds need to be fast.

New tools may speed up others but there is a switching cost. Invest in reducing the switching cost. Julia’s refactor.

Proving your tool saves time buys you leeway in the future to do bigger changes. You need to build trust. Long term impact is hard to quantify but. Short term cost is known.

Chapter 5: Measure what you want to improve

What to measure and what not to measure

Measuring influences employee behavior. Optimizing for speed and cut quality

Measurement should be actionable and responsive

Actionable metrics movements can be casually explained

Vanity metrics are just numbers

Be skeptical of metrics. Try to validate your metrics by arriving at them from a different angle. Back of an envelope

When a number looks off, dig into it early

Chapter 6: Validate your ideas early and often

Ship something small early and get feedback.

Iterate a little. Validate. Course correct. Loop.

A/B tests help you understand what is better and ideally you can quantify how much better. Which helps you decide whether to keep trying to improve. Only 1% better. Probably not. Way betterlet’s do more.

Beware of 1 person teams. You can get bused. No shared knowledge. No oversight project lows are more demoralizing alone. No shares pain. No way to get help

Decisions need feedback loops

Chapter 7: Improve your project estimation skills

Large project slips are most often due to many minor unforeseen issues than 1 major issue

Creating specific goals, you can easily decide what work is not in scope. Creates alignment between stakeholders. Hold people accountable for local traders that impact global goals

Concrete milestones with target dates create accountability

Mitigate risk early by tackling risky problems early

Code complexity grows with interactions between lines of code more than lines of code. Sub systems interacting in complex ways create clean touch points/ contracts between components

Approach rewrite projects with extreme caution

Use a series of incremental behavior preserving transformations

Don’t sprint. An effective engineer is planned ahead

Part 3 : Long term value

Chapter 8: Balance Quality with Pragmatism

Good abstraction should be

• Easy to learn
• Easy to use even without docs
• Hard to misuse
• Satisfy the requirements
• Easy to extend
• Appropriate to the audience

Determining how to balance how much tests to write vs agility is a high leverage task

Tech debt needs to be repaid

Chapter 9: Minimize operational burden

Find simple solutions

Fail fast

Easier to debug

Failing slow removes the error context. Muddies the source of the error

Report errors to engineers while being graceful forusers

Automate team processes

Being able to rerun your scripts more often reduces false alarms and allows more nuanced issues to be raised

Recover quickly

We will break. Learn to mitigate major drawn out failures

Create plans. TSGs before things are broken

Chapter 10: Invest in Teams growth

Interviewing

• Ask questions which have High signal to noise ratio
• Iterate on hiring process
• Reflect on current hiring process
• Rapid fire easy questions to cover a wide surface area to filter out

Create a good onboarding process

Have good docs

Onboarding should

• Ramp up new engineers
• Impart team culture and values
• Expose new engineers to fundamentals/tools needed to succeed -Socially integrate the new employee

Peer programming and code labs are great tools

Assigning a mentor to new employees that help ramp and assign initial starter tasks

Reflect on what docs I would want available for my team if I were the manager

Share ownership of code

Being a sole owner of code doesn’t increase your value. It makes you a liability

Becoming the bottleneck of a project reduces your flexibility to pursue other tasks. In order to scale, you need to be able to release ownership successfully

Hold post mortems

Don’t blame

Increase shared knowledge

Document learnings

Keep docs simple and accessible

Create a good engineering culture

• Optimize for iteration speed
• Push relentlessly for automation
• Build the right abstractions
• High code quality
• Good code review process
• Respectful work environment
• Shared ownership of code
• Automated testing
• Allot time for experimentation
• Foster a culture of learning and improvement
• Hire the best

Create systems early in your career to create a foundation for your career