Instantly share code, notes, and snippets.

Embed
What would you like to do?

FWIW: I didn't produce the content presented here (the outline from Edmond Lau's book). I've just copy-pasted it from somewhere over the Internet, but I cannot remember what exactly the original source is. I was also not able to find the author's name, so I cannot give him/her the proper credits.


Effective Engineer - Notes

What's an Effective Engineer?

  • They are the people who get things done. Effective Engineers produce results.

Adopt the Right Mindsets

Focus on High Leverage Activities

  • Leverage = Impact Produced / Time Invested
  • Use Leverage as Your Yardstick for Effectiveness
  • 80% of the impact comes from 20% of the work.
  • Focus on high leverage and not just easy wins.

Optimize for Learning

  • Change jobs if you have to.
  • Optimizing for learning is high leverage.
  • Adopt a growth mindset.
    • Talk to people. Become good at telling stories. It gets better with time.
    • Those with a growth mindset believe that they can cultivate and grow their intelligence and skills through effort.
    • Own your story.
  • Invest in the rate of learning
    • Learning compounds. Compounding leads to exponential growth. Earlier the compounding starts, the better.
    • Working on unchallenging tasks is a huge opportunity cost. You missed out on compounded learning.
    • Prioritize learning over profitability.
    • Invest your time in activities with the highest learning rate.
  • Seek Work Environments Conducive to Learning
    • Fast Growth: Companies where #problems >> #resources. Opportunity to choose high impact work.
    • Make sure you are working on high priority projects.
    • Openness: Look for culture with curiosity, where everyone is encouraged to ask questions.
    • Fast Paced.
    • People smarter than you.
    • Autonomy: Freedom to choose what to work on. Smaller companies => More autonomy.
  • While on Job
    • Make a daily habit of acquiring new skills.
    • Read code written by brilliant engineers.
    • Jump fearlessly into code you don't know.
    • Always be learning. Invest in skills that are in high demand.
    • Read Books. Attend Conferences.
    • Build and maintain strong relationships.

Prioritize Regularly

  • Opportunity cost of working on wrong ideas can set back growth by years.
  • Prioritize tasks based on ROI.
  • Regular prioritization is high leverage activity.
  • On TODO Lists:
    • Maintain a 'single' todo lists where all tasks are listed.
    • Don't try to remember stuff. Brain is bad at remembering. It's rather good at processing.
  • Ask yourself regularly: Is this the most important thing I should be working on?
  • Focus on what directly produces value.
  • Learn to say no.
  • Focus on the important and non-urgent.
  • Find ways to get into flow. “A state of effortless concentration so deep that they lose their sense of time, of themselves, of their problems.”
  • When possible, preserve larger blocks of focused time in your schedule.
  • Limit the amount of Work in Progress.
    • Cost of context switching is high.
  • Prioritizing is difficult.
  • Prioritization is high leverage. It has huge impact on your ability to get right things done.

Invest in Iteration Speed

  • Continuous Deployment is high leverage.
    • Will save a lot of time in manual deployment of code. They are the people who get things done. Effective Engineers produce results.
  • Move fast to learn fast.
    • Move fast and break things.
    • Moving fast enables us to build more things and learn at faster rate.
  • Invest in time saving tools.
    • If you have to do something more than twice, write a tool the third time.
    • Tools are multipliers that allow your to scale your impact beyond the confines of a day.
    • Faster tools get used more often.
    • Faster tools can enable new workflows that previously weren't possible.
    • Productivity skyrockets with tools.
    • Time saving property of tools also scale with team adoption.
  • Shorten your debugging and validation Loops.
    • Extra time spent in optimizing debugging workflow can help you fix annoying bugs with less headache.
    • Debugging is hard. It's time consuming. Upfront investments to shorten debugging loops are worth it.
  • High test coverage to reduce build and site breakages.
  • Fast unit tests to encourage people to run them.
  • Fast and incremental compiles and reloads to reduce development time.
  • Master you programming environment.
    • One editor. One high level language. Shell. Keyboard > Mouse. Automate manual workflows. Use interactive shell. Make running specific tests easy.
  • Faster you can iterate, faster you can learn.

Measure what you want to Improve

  • Use metric to drive progress.
    • If you can't measure it, you can't improve it.
    • Good metric.
      • Helps you focus on right things.
      • Drives forward progress.
      • Helps you guard against future regressions.
      • Performance ratcheting: Any change should strictly improve the metric.
      • Bad metric can lead to unwanted behavior.
      • Examples:
        • #hours worked < productivity.
        • click through rates < long click through rates.
    • Metric you choose influences your decisions and behavior.
    • Look for metric that, when optimized, maximizes impact for the team.
    • Actionable metric - Whose movement can be casually explained by team's effort.
    • Responsive metric - Updates quickly to give back feedback whether a given change was =ve or -ive.
    • Choosing a metric is high leverage.
    • Dedicate time to pick right metric.
  • Instrument everything to understand what's going on.
    • Measure anything, measure everything.
    • Graphite, statsd. A single line of code lets you define a new counter or timer on the fly.
    • Measuring goals you want to achieve is high leverage.
  • Internalize useful numbers.
    • Knowledge of useful numbers provide a valuable shortcut for knowing where to invest efforts to maximize gains.
    • Need upfront work. Need not be accurate, ballpark idea suffices.
    • Knowing useful numbers enables you to do back of the envelope calculations to quickly estimate the performance properties of a design without actually building it.
    • Internalizing useful number help you spot anomalies. Be skeptical about data integrity.
  • Log data liberally.
  • Build tools to iterate on data accuracy sooner.
  • Examine data sooner.
  • When numbers look off, dig in to it sooner.

✔️ Measure your progress. Carefully choose your top-level metric. Instrument your system. Know your numbers. Prioritize data integrity.

Validate your ideas early and often.

  • Not validating early leads to wasted efforts.
  • Don't delay get feedback.
  • Find low effort ways to validate work.
  • Power of small batches. Helps you avoid making a big mistake by stopping the flow.
  • Approach problem iteratively.
  • No large implementations.
  • Working solo? Be wary. Be extra vocal and get feedback.

Improve project estimation skills.

  • Beware of mythical man month. Communication overhead is significant.
  • Reduce risk early.
  • Rewrite projects - almost always fail.
  • Additional hours hurt productivity. Causes burnout.
  • Do the riskiest task first.
  • Allow buffer room for the unknown.

Balance Quality with Pragmatism

  • High code quality. Code readability.
  • Establish sustainable code review process.
  • Code reviews help:
    • Catch bugs and design problems early.
    • Sharing working knowledge of the codebase.
    • Increases long term agility. Easier to understand, quicker to modify.

Manage complexity through Abstraction

  • Example: MapReduce.
  • Right abstractions make huge difference.
  • “Pick the right ones, and programming will flow naturally from design; modules will have small and simple interfaces; and new functionality will more likely fit in without extensive reorganization,”
  • “Pick the wrong ones, and programming will be a series of nasty surprises: interfaces will become baroque and clumsy as they are forced to accommodate unanticipated interactions, and even the simplest of changes will be hard to make.”
  • The right abstraction can increase engineering productivity by an order of magnitude.
  • Simple abstractions avoid interweaving multiple concepts, so that you can reason about them independently rather than being forced to consider them together.
  • Designing good abstractions take work.
  • An abstraction's usage and popularity provides a reasonable proxy for its quality.

Automate Testing

  • Unit test cases and some integration testing provide a scalable way of managing growing codebase.
  • A suite of extensive and automated tests can reduce overall error rates by validating the quality and by safeguarding against regressions.
  • Tests also allow engineers to make changes, especially large refactorings, with significantly higher confidence.
  • Despite its benefits, it can be difficult to foster a culture of automated testing.
  • Focus on high leverage tests.
  • Writing more tests, creating a virtuous feedback cycle and saving more development time.

Repay Technical Debt

  • 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 unaddressed.
  • Accumulating technical debt is fine as far as it is repaid within time.
  • Refactor often.

Reduce Operational Complexity

  • Keep no. of technologies low. Don’t sway towards shiny new technologies.
  • Every additional technology you add is is guaranteed to go wrong eventually. Will need your time.
  • Do the simple thing first.
  • Embrace operational simplicity.
  • The first solution that comes to mind is generally complex. Don't stop. Keep peeling off the layers of onion.
  • Simplify the architecture to reduce their operational burden.
  • “What’s the simplest solution that can get the job done while also reducing our future operational burden?”
  • Discipline to focus on simplicity is high leverage.

Fail Fast

  • Fail immediately and visibly.
  • Doesn’t necessarily mean crashing your programs for users.
  • fail-fast to surface issues immediately.
  • Failing fast is high leverage as it saves debugging time.

Relentlessly Automate

  • Automating mechanics is good.
  • Automating decision making - no.
  • Hone your ability to respond and recover quickly.
    • Leverage recovering quickly > Leverage preventing failures.
  • “script for success,” practice failure scenarios, and work on our ability to recover quickly.
  • Make batch process idempotent
  • Make processes retryable, i.e., not leaving any global state.

Invest in your team's Growth

  • Invest in onboarding.
  • The higher you climb up the engineering ladder, the more your effectiveness will be measured not by your individual contributions but by your impact on the people around you.
  • "You’re a staff engineer if you’re making a whole team better than it would be otherwise. You’re a principal engineer if you’re making the whole company better than it would be otherwise. And you’re distinguished if you’re improving the industry.” - Focus primarily on making everyone around you succeed.
  • Your career depends on your team's success.
  • Make hiring everyone's responsibility.
  • Shared ownership of code.
    • Keep bus factor more than one.
    • Shared ownership removes isolated silos of information.
  • Build collective wisdom through post mortems.
  • Invest in automated testing.
    • Automated test cases lead to higher confidence when refactoring.
    • Write test cases when the code is fresh in mind.
    • Don’t be dogmatic about 100% code coverage.
    • Value of tests increases over time and cost to write goes down.
  • Hire the best.
  • Surround yourself with great advisors

☀️ “Leverage is the lens through which effective engineers view their activities. ” ☀️

10 Books to read:

  • Peopleware Productive projects and Teams. Amazon. My Summary.
  • Team Geek: A Software Developer’s Guide to Working Well with Others. (Debugging Teams) Amazon. My Summary.
  • High Output Management
  • Getting Things Done: The Art of Stress-Free Productivity
  • The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich
  • The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change
  • Conscious Business: How to Build Value Through Values
  • Your Brain at Work
  • Flow: The Psychology of Optimal Experience
  • Succeed: How We Can Reach Our Goals

Blogs:

Recommended Blogs To Follow:

  • http://www.theeffectiveengineer.com/ - The Effective Engineer is my personal blog, where I write about engineering habits, productivity tips, leadership, and culture.
  • http://www.kalzumeus.com/ - Patrick McKenzie runs his own software business and has written many excellent long-form articles on career advice, consulting, SEO, and software sales.
  • http://katemats.com/ - Kate Matsudaira, who has worked at large companies like Microsoft and Amazon as well as at startups, shares advice about tech, leadership, and life on her blog.
  • http://randsinrepose.com/ - Michael Lopp has worked for many years in leadership positions at Netscape, Apple, Palantir, and Pinterest, and writes about tech life and engineering management.
  • http://softwareleadweekly.com/ - Oren Ellenbogen curates a high-quality weekly newsletter on engineering leadership and culture.
  • http://calnewport.com/ - Cal Newport, an assistant professor of computer science at Georgetown, focuses on evidence-based advice for building a successful and fulfilling life.
  • http://www.joelonsoftware.com/ - Joel Spolsky, the co-founder of Stack Exchange, provides all sorts of programming pearls of wisdom on his blog.
  • http://martinfowler.com/ - Martin Fowler, author of the book Refactoring, writes about how to maximize the productivity of software teams and provides detailed write-ups of common programming patterns.
  • http://pgbovine.net/ - Philip Guo, a computer science professor, has written extensively and openly about his graduate school and work experiences.
@Aghassi

This comment has been minimized.

Show comment
Hide comment
@Aghassi

Aghassi Dec 28, 2017

Every additional technology you add is is guaranteed to go worong eventually. Will need your time.

I believe you have a typo 😄

Aghassi commented Dec 28, 2017

Every additional technology you add is is guaranteed to go worong eventually. Will need your time.

I believe you have a typo 😄

@jayceekay

This comment has been minimized.

Show comment
Hide comment
@jayceekay

jayceekay Dec 28, 2017

If you have to do something more than twwise, write a tool the third time.

another typo

jayceekay commented Dec 28, 2017

If you have to do something more than twwise, write a tool the third time.

another typo

@anowlcalledjosh

This comment has been minimized.

Show comment
Hide comment
@anowlcalledjosh

anowlcalledjosh Dec 28, 2017

A couple more typos:

Master you Programming Environment

change was =ve or -ive.

Instrument everythong

Dont delay get feedback

Make processes retrable

🙂

anowlcalledjosh commented Dec 28, 2017

A couple more typos:

Master you Programming Environment

change was =ve or -ive.

Instrument everythong

Dont delay get feedback

Make processes retrable

🙂

@jbellars

This comment has been minimized.

Show comment
Hide comment
@jbellars

jbellars Dec 28, 2017

Learning compunds.

Presumably "compounds"

jbellars commented Dec 28, 2017

Learning compunds.

Presumably "compounds"

@nalekberov

This comment has been minimized.

Show comment
Hide comment
@nalekberov

nalekberov Dec 28, 2017

smaller comanies
Another typo

nalekberov commented Dec 28, 2017

smaller comanies
Another typo

@jumarmartin

This comment has been minimized.

Show comment
Hide comment
@jumarmartin

jumarmartin Dec 28, 2017

Great writeup, but there is another typo.

Failing fast is high leverage as it saves devugging time.
devugging

great writeup nonetheless!

jumarmartin commented Dec 28, 2017

Great writeup, but there is another typo.

Failing fast is high leverage as it saves devugging time.
devugging

great writeup nonetheless!

@gbxl

This comment has been minimized.

Show comment
Hide comment
@gbxl

gbxl Dec 29, 2017

Will save a lot of time in manual deployment of code.They are the people who get things done. Effective Engineers produce results. Contains the text relevant to What's an Effective Engineer? and doesn't make sense here

gbxl commented Dec 29, 2017

Will save a lot of time in manual deployment of code.They are the people who get things done. Effective Engineers produce results. Contains the text relevant to What's an Effective Engineer? and doesn't make sense here

@megamindbrian

This comment has been minimized.

Show comment
Hide comment
@leolas95

This comment has been minimized.

Show comment
Hide comment
@leolas95

leolas95 Dec 29, 2017

Excellent write up :) I think there is a typo:

Instrument everythong to understand what's going on.

leolas95 commented Dec 29, 2017

Excellent write up :) I think there is a typo:

Instrument everythong to understand what's going on.

@rondy

This comment has been minimized.

Show comment
Hide comment
@rondy

rondy Dec 29, 2017

FWIW: I didn't produce the content present here.

I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.

Tks guys anyway for pointing out all the typos and stuff.

Owner

rondy commented Dec 29, 2017

FWIW: I didn't produce the content present here.

I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.

Tks guys anyway for pointing out all the typos and stuff.

@eindiran

This comment has been minimized.

Show comment
Hide comment
@eindiran

eindiran Dec 29, 2017

Another typo: "Shared ownershop"

eindiran commented Dec 29, 2017

Another typo: "Shared ownershop"

@de11

This comment has been minimized.

Show comment
Hide comment
@de11

de11 Dec 29, 2017

Stop setting such (High) standards for an engineer. Reading it feels good, implementing some of it feels awesome...but making it a standard to qualify for a title, leads to human optimization that leads to burnout and depression. So, thanks but no thanks.

de11 commented Dec 29, 2017

Stop setting such (High) standards for an engineer. Reading it feels good, implementing some of it feels awesome...but making it a standard to qualify for a title, leads to human optimization that leads to burnout and depression. So, thanks but no thanks.

@gihadchbib

This comment has been minimized.

Show comment
Hide comment
@gihadchbib

gihadchbib Dec 29, 2017

@de11 the only way to grow is to set standards that are higher than what you can actually achieve.

gihadchbib commented Dec 29, 2017

@de11 the only way to grow is to set standards that are higher than what you can actually achieve.

@zmmille2

This comment has been minimized.

Show comment
Hide comment
@zmmille2

zmmille2 Dec 30, 2017

@gihadchibb I disagree. I think that failing to meet your goals leads to burnout. I would instead argue that you should redefine your goals as you accomplish them. You shouldn’t get all of them, but you shouldn’t miss them all, either.

zmmille2 commented Dec 30, 2017

@gihadchibb I disagree. I think that failing to meet your goals leads to burnout. I would instead argue that you should redefine your goals as you accomplish them. You shouldn’t get all of them, but you shouldn’t miss them all, either.

@gihadchbib

This comment has been minimized.

Show comment
Hide comment
@gihadchbib

gihadchbib Dec 30, 2017

@zmmille2 There is a difference between setting high standards for yourself and defining short term goals - which in turn are driven by your high standards. I agree that these goals should be achievable, but I find it a bit far-fetched to say that having high standards ultimately leads to burnout and depression. I would argue that it actually even makes your life easier and more manageable in the long run.

gihadchbib commented Dec 30, 2017

@zmmille2 There is a difference between setting high standards for yourself and defining short term goals - which in turn are driven by your high standards. I agree that these goals should be achievable, but I find it a bit far-fetched to say that having high standards ultimately leads to burnout and depression. I would argue that it actually even makes your life easier and more manageable in the long run.

@hrithikguy

This comment has been minimized.

Show comment
Hide comment
@hrithikguy

hrithikguy Dec 30, 2017

I think it depends on the person and people shouldn't tell others what goals to set for themselves. For some people, it wouldn't lead to burnout and depression, and for others, it would. People should use self-awareness.

hrithikguy commented Dec 30, 2017

I think it depends on the person and people shouldn't tell others what goals to set for themselves. For some people, it wouldn't lead to burnout and depression, and for others, it would. People should use self-awareness.

@PabloCastellano

This comment has been minimized.

Show comment
Hide comment
@PabloCastellano

PabloCastellano Dec 30, 2017

Thanks for sharing. I find it very useful and will make sure I have this list nearby from now on.

PabloCastellano commented Dec 30, 2017

Thanks for sharing. I find it very useful and will make sure I have this list nearby from now on.

@pierrenel

This comment has been minimized.

Show comment
Hide comment
@pierrenel

pierrenel Dec 31, 2017

prooductivity -> productivity

pierrenel commented Dec 31, 2017

prooductivity -> productivity

@toanant

This comment has been minimized.

Show comment
Hide comment
@sammcj

This comment has been minimized.

Show comment
Hide comment
@sammcj

sammcj Jan 2, 2018

I also forked and cleaned up.

https://gist.github.com/sammcj/22135c9200ab1df6518faa1bb87d0d12/revisions

https://gist.github.com/22135c9200ab1df6518faa1bb87d0d12.git

sammcj commented Jan 2, 2018

I also forked and cleaned up.

https://gist.github.com/sammcj/22135c9200ab1df6518faa1bb87d0d12/revisions

https://gist.github.com/22135c9200ab1df6518faa1bb87d0d12.git

@rondy

This comment has been minimized.

Show comment
Hide comment
@rondy

rondy Jan 3, 2018

Fixed some typos.

Owner

rondy commented Jan 3, 2018

Fixed some typos.

@bigbes

This comment has been minimized.

Show comment
Hide comment
@reergymerej

This comment has been minimized.

Show comment
Hide comment
@reergymerej

reergymerej Jan 11, 2018

I'm not sure how I feel about this. On the one hand, it's a bunch of devs reviewing something on Github, so you expect a bunch of comments about syntax. On the other hand, the content is basically a blog, so you'd expect comments about the ideas. I just don't know how to respond!

reergymerej commented Jan 11, 2018

I'm not sure how I feel about this. On the one hand, it's a bunch of devs reviewing something on Github, so you expect a bunch of comments about syntax. On the other hand, the content is basically a blog, so you'd expect comments about the ideas. I just don't know how to respond!

@mpiskore

This comment has been minimized.

Show comment
Hide comment
@mpiskore

mpiskore Jan 12, 2018

FWIW: I didn't produce the content present here. I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.

By Edmond Lau

Or maybe I'm not getting something?

mpiskore commented Jan 12, 2018

FWIW: I didn't produce the content present here. I've just copy-pasted it from somewhere over the Internet, but I cannot remember exactly the original source. I was also not able to find the author's name, so I cannot give him/her the proper credit.

By Edmond Lau

Or maybe I'm not getting something?

@AJCastroChandri

This comment has been minimized.

Show comment
Hide comment
@AJCastroChandri

AJCastroChandri Feb 16, 2018

@mpiskore Edmond Lau is the author of The Effective Engineer.

AJCastroChandri commented Feb 16, 2018

@mpiskore Edmond Lau is the author of The Effective Engineer.

@pracucci

This comment has been minimized.

Show comment
Hide comment
@pracucci

pracucci Feb 27, 2018

Thanks for the wrap up. Magnificently done.

pracucci commented Feb 27, 2018

Thanks for the wrap up. Magnificently done.

@supertrens

This comment has been minimized.

Show comment
Hide comment
@supertrens

supertrens Apr 12, 2018

Thank for producing that high-quality post...
Can I get permission to translate it to my mother tongue ( Haitian Creole)
Of course, you will get the credit

supertrens commented Apr 12, 2018

Thank for producing that high-quality post...
Can I get permission to translate it to my mother tongue ( Haitian Creole)
Of course, you will get the credit

@rondy

This comment has been minimized.

Show comment
Hide comment
@rondy
Owner

rondy commented May 12, 2018

@supertrens sure 👍

@bsgreenb

This comment has been minimized.

Show comment
Hide comment
@bsgreenb

bsgreenb May 18, 2018

Very little in here about communication!

bsgreenb commented May 18, 2018

Very little in here about communication!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment