Dillon Rose

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


Learnings


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


How to force grow


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


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


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


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


Create a good onboarding process

Have good docs


Onboarding should


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


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