Skip to content

Instantly share code, notes, and snippets.

@rondy
Last active March 16, 2024 15:14
Star You must be signed in to star a gist
Save rondy/af1dee1d28c02e9a225ae55da2674a6f to your computer and use it in GitHub Desktop.

FWIW: I (@Rondy) am not the author of the content presented here, which is an outline from Edmond Lau's book. I've just copy-pasted it from somewhere and saved as a personal gist, before it got popular on newsnews.ycombinator.com. I don't remember where exactly the original source is from and neither could 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.
@rondy
Copy link
Author

rondy commented Jan 3, 2018

Fixed some typos. ✅

@bigbes
Copy link

bigbes commented Jan 10, 2018

@reergymerej
Copy link

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!

@marekpiskorek
Copy link

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
Copy link

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

@pracucci
Copy link

Thanks for the wrap up. Magnificently done.

@supertrens
Copy link

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
Copy link
Author

rondy commented May 12, 2018

@supertrens sure 👍

@bsgreenb
Copy link

Very little in here about communication!

@chonlatee
Copy link

Thank you so much.

@stexuq
Copy link

stexuq commented Mar 21, 2019

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!

Nice!

@johnchangviki
Copy link

Good summary. Could you translate to Chinese?

@Arlington1985
Copy link

@johnchangviki, how if he doesn't know Chinese )

@yayyz
Copy link

yayyz commented Dec 3, 2019

👍 Thank you for the great summary :)

@johnchangviki
Copy link

@johnchangviki, how if he doesn't know Chinese )

sorry, typos.

I want to say Could i translate to Chinese?

@igordonin-pareto
Copy link

igordonin-pareto commented Jan 9, 2020

You wrote about growth mindset but didn't recommend Carol Dweck's great book Mindset on the reading list. I believe it would be a great addition.

BTW: Thanks for this gist, it's awesome. 👍

@aryashashank
Copy link

I got tired just by reading this.

@HyowonHwang
Copy link

HyowonHwang commented Jan 30, 2020

👍 Awesome

@AlphaHot
Copy link

❤️ nice

@burubur
Copy link

burubur commented Jul 3, 2020

Thank You.

@joaoluizn
Copy link

Thank you for this piece of experience!

@geokal
Copy link

geokal commented Nov 21, 2020

I don't know if it's relevant
Teach Yourself Programming in Ten Years

@proplayer99
Copy link

I agree with the majority. the most important thing is being systematic and focused while learning.

@farhanashrafdev
Copy link

Thats awesome

Copy link

ghost commented Jan 5, 2022

🚀

@Faresboui
Copy link

That's awesome!

@abuzafarhaqq
Copy link

Thanks everyone

@franckouam
Copy link

Communicating is too dificult to me. Thank you I will read this as my bible

@sapayev
Copy link

sapayev commented Nov 11, 2022

Thank your for this!

@BinaryKevin
Copy link

NIce, Thank you!

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