[Effective Engineer] Mindset (Part 1)

Jul 15, 2022 books tech-career productivity

The Effective Engineer, written by Edmond Lau, is the Bible for software engineer. I summarize key points of this book (with minimal insights from me) and break it down into three major steps of practicing to become an effective engineer: adopting the right mindset, execute religiously, and build long-term value. This article is about part 1: the mindset.

Disclaimer: although a summary like this can help, I highly recommend reading it for more insights, as some examples in this book can inspire you to reflect your scenario at work.

“The best thing that you can do is not pretend that you know everything, but go into it with the mindset that your job is to learn as much as you can, as quickly as you can.” - Mark Zuckerberg

[Chapter 1] Focus on high-leverage activities

Maximize the “leverage”.
A simple math equation: impact produced / time invested.

How to measure impact?

For software engineers: getting things done (GTD).
Measured by metrics: product launch, bug fixes, important features, performance optimization, seek approval/alignment.

3 ways to increase leverage

Increase output/impact within a period of time.
Reduce invested time to do the same thing.
Focus on leverage points/high-leverage activities.

Questions to ask for any activity

How to get more things done per time unit?
How to get things done faster?
Is there a more high-leverage activity to do instead?

[Chapter 2] Optimize for learning

Adopt growth mindset

Stretching outside the comfort zone

Networking for introverts: practice how to tell a good story.
Dialogue with strangers is a learnable skills.

“own your story”

Build your own story instead of telling other’s story.
Excited to solve the next problem, even though you don’t have any background before.

Invest in learning rate

Learning increases in an exponential rate, like compound interests.
Optimize for learning early on: a good first job -> a rapidly growing career.
Small delta increments: the point is about staying consistent and committed.

Work in the environment conducive for learning

I am being extremely exhaustive on this section because it can be a checklist when I want to switch job. :)

Fast growth

Growth on core metrics: DAU, CTR, user engagement/retention rate, etc.
Are you going to work on initiatives that are core to the company growth?
Are they aggressively hiring over recent years?
How quickly for superstars grow to leadership positions?

Training

Is there onboarding/bootcamp period for new hire?
Is there formal/informal mentorship?
Willing to make long-term learning investment?

Openness

Cross-team transparency: what are other teams working on?
Culture of curiosity: proactively ask questions, open knowledge sharing, value feedback, etc.
Reflect and document past mistakes.

Pace

Moving fast and break things: “fast” defined by iteration speed.
Lightweight approval process.
Where to spend the majority of time: maintenance versus building new product/features?

People

Is the interviewer smarter than you?
Are interviews rigorous and comprehensive?
Meet with potential teammates beforehand: are they impressive?

Autonomy

Freedom to choose what to work on/how to do it?
Diversity of projects?
Engineer’s influence on product design & direction?

Leverage work opportunities to develop your technical depth

20% time at Google: take one-or-two hour per day instead of a full day.
Study codebase for classic software abstractions.
Internal educational materials.
Master your PL: at least one scripting language for quick prototyping.
Take courses of your weak points: professional degree, management science, MBA, etc.
Participate in design reviews that you are interested in.
At least a few senior members on the team.

Locate learning opportunities outside work

Follow technical trends and learn skills with high demand.
Read books; attend talks/conferences; and write to teach.
Build a strong network of relationships: force yourself to meet people you don’t know.
Work on side projects.

[Chapter 3] Prioritize regularly

Making prioritization as a routine means regularly identify/reidentify high-leverage activities.

Never trust your brain to remember everything. Use checklist in whatever form, but the point is that you must write them down and constantly reassess/reorganize them based on shifting priorities.

What should be prio’ed?

Work that directly produce value

Tasks that directly increases acquired users, sales, or impacts your team’s core business metrics.
Coding necessary features, seek PM approval for product launch, regular sync with teammates to avoid duplicate efforts, etc.
Only focus on what matters: say No to unnecessary meetings, coffee chat, small bugs.

Important but non-urgent tasks (identity capital)

Investment that make you more effective but without urgent deadlines: build relationships, learn programming tools/environments, personal development, practicing prioritization, etc.
Investment in identity capital can help you with important-and-urgent tasks with being more productive.

How to execute on them?

Protect maker’s schedule

Block your calendar with long, continuous time slots for critical tasks, which enables you to enter the state of flow (the effortless concentration).
Make your meetings back-to-back instead of fragmenting your schedule, which can reduce the context switch cost.
Set routines like “No meeting Wednesday”, “Focus Friday”, etc.

Limit work-in-progress items

Constant context switch between tasks hinder deep engagement of each one.
Human brain’s working memory can only load 5-9 tasks on stage.
Use trial and error to find your optimal number of WIPs.

Make it a habit by establishing your workflow

Use if-then to fight procrastination

Subconscious followup: If {conditions}, I will do {tasks}. This can prevent the moments that “I don’t feel like doing it” because the if condition subconsciously forces you to think the then-tasks are something that you need to do anyway.
To fill up small gaps: if I have 20 minutes, I will do {tasks}. So you won’t spend 10 minutes wondering what to do next and end up not finishing it.

Build your own routine workflow to track and execute.

Edmond provides an example that beginners can start off with.

Divide your checklist to Doing, Today, and This week sections.
Each item should have an ETA (estimated time to complete): use 25 minutes as a unit and mark each item with the estimated number of units.
Every morning, spend a few minutes planning: moving some items from This week to Today.
When you are free during the day or right before your “concentrated time block” starts, moving items from Today to Doing. Keep them short!
Monday morning/Sunday night, do a 30-minute review session to scope out This week section for this week and retrospect on items that were not executed well in the last week.

Continue reading the next section: [Effective Engineer] Execution (Part 2)