The effective engineer (Part-II)

Again I started reading this book “The Effective Engineer” by Edmond Lau. I noted down these points while reading so that it can be kind of cheat-sheet for myself and others too. I strongly recommend buying the book and reading it at-least once.

The book is divided into 3 parts and my idea here is to write 3 blog posts one for each. So here is the second part of the series. You can read the Part-I here.

Execute, Execute, Execute

Invest in Iterate Speed

1. Why invest?
   1. CI /CD – automated tests and delivery
   2. Tools to evaluate metrics – to improve quality, process and speed
   3. Small chunks delivered faster
   4. Config flag for larger features
   5. Elective deployment
2. Move fast learn fast
   1. Faster you iterate faster you learn what works and what not
   2. Remove bottlenecks
3. Invest in time saving tools
   1. Write a tool if you need to do a thing more than 2 times
   2. Reduction in compile time
   3. Incremental change adoption
   4. Use 20% of time on optimising
   5. Switch to efficient tools even if switching takes time – compounds later
   6. Start small, build it, showcase and improve
4. Shorten your debugging and validation loop
   1. Minimal workflow – start small
5. Master your programming environment
   1. Fine tune simple actions even if saves a second here or there
   2. Get proficient with your text editor
   3. Learn at least one productive high level programming language
   4. Get familiar with commands
   5. Prefer keyboard over mouse
   6. Automate your manual workflows
   7. Test out ideas on a interactive interpreter
   8. Make it fast and easy to run unit test cases for only the changes
6. Don’t ignore the non-engineering bottlenecks
   1. Personally address the bottlenecks
   2. Communication is important for people related bottlenecks
   3. Prioritize build prototypes get feedback from decision makers
   4. Get the ball rolling in your launch checklist
7. Take a holistic view of your iteration loop

“Premature optimization is the root of all evil”

Measure what you want to improve

When deciding which metrics to use, choose ones that:

1. Maximize impact
2. Are actionable
3. Are responsive yet robust

Instrument everything what’s going on – helps in diagnosing the problems

1. Monitor your software
2. Determine how its used
3. Measure anything and everything
4. Analytics
5. Project all instrumented values on a Dashboard

Internalize useful numbers – Knowing useful numbers like these enables you:

1. With a few back-of-the-envelope calculations
2. To quickly estimate the performance properties of a design without actually having to build it
3. help you spot anomalies in data measurements
4. clarifies both the areas and scope for improvement

Be skeptical about Data Integrity

1. Using data to support your arguments is powerful
2. The right metric can slice through philosophical biases, and product arguments
3. Quickly resolving discussions
4. Unfortunately, the wrong metric can do the same thing—with disastrous results. We have to be careful how we use data.
5. Strategies to increase confidence in your data integrity:
   1. Log data liberally, in case it turns out to be useful later on.
   2. Build tools to iterate on data accuracy sooner. Real-time analytics is useful
   3. Write end-to-end integration tests to validate your entire analytics pipeline
   4. Examine collected data sooner
   5. Cross-validate data accuracy by computing the same metric in multiple ways
   6. When a number does look off, dig in to it early

Validate your ideas early and often

1. Optimising for feedback as soon as possible
2. Understanding what customers actually want and then iterating on that feedback
3. Get the right things done
4. Build MVP and get beta out for feedback
5. 10% effort to be spent on small informative prototype
6. Fake the full implementation of an idea to validate whether it will work is extremely powerful
7. Validate product changes with A/B testing
   1. Use available tools instead of writing it yourself
   2. Results in understandable and actionable knowledge
   3. Reduce risk of large implementations with small validations
8. Beware of one person team
   1. No feedback & validation
   2. Code reviews
   3. Monotonous work
   4. Dependency on the person
   5. Achievement celebration will not be there
   6. Strategies for feedback channel
   7. Be open and receptive to feedback
   8. Commit code early and often
   9. Request code reviews from thorough critics\
   10. Ask to bounce ideas off your teammates
   11. Design the interface or API of a new system first
   12. Send out a design document before devoting your energy to your code
   13. If possible, structure ongoing projects so that there is some shared context with your teammates
   14. Solicit buy-in for controversial features before investing too much time
9. Build feedback loops for your decisions

Improve your project estimation skills

Use accurate estimates to drive projects

1. Decompose the project into granular task
2. Estimate based on how long the task takes, not a person takes to finish
3. Person who takes up the task must give an estimate
4. Avoid casual guesses
5. Use multiple approach to estimate – granular to full project, historical data of previous work
6. Avoid mythical man-month / person-days – nine women can’t give birth to a baby in one month
7. Use time boxing to avoid growing scope of the tasks
8. Allow others to challenge the estimates

Budget for unknown – build buffer time and have room for possible calamities

Define specific project goals and measurable milestones

1. Must haves and nice to haves differentiation
2. Clarity and alignment across key stakeholders

Reduce risk early – Tackle risky areas first, build e2e scaffold and do system test early.

Approach rewrite projects with almost caution – incremental rewrites are effective or phases.

Don’t sprint in the middle of a marathon – avoid burnout by working extra hours, be realistic and keep informed.

If you are a Gumroad user then here’s your link

–Some points or sections are collected from internet to make more sense to the context–