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
- Why invest?
- CI /CD – automated tests and delivery
- Tools to evaluate metrics – to improve quality, process and speed
- Small chunks delivered faster
- Config flag for larger features
- Elective deployment
- Move fast learn fast
- Faster you iterate faster you learn what works and what not
- Remove bottlenecks
- Invest in time saving tools
- Write a tool if you need to do a thing more than 2 times
- Reduction in compile time
- Incremental change adoption
- Use 20% of time on optimising
- Switch to efficient tools even if switching takes time – compounds later
- Start small, build it, showcase and improve
- Shorten your debugging and validation loop
- Minimal workflow – start small
- Master your programming environment
- Fine tune simple actions even if saves a second here or there
- Get proficient with your text editor
- Learn at least one productive high level programming language
- Get familiar with commands
- Prefer keyboard over mouse
- Automate your manual workflows
- Test out ideas on a interactive interpreter
- Make it fast and easy to run unit test cases for only the changes
- Don’t ignore the non-engineering bottlenecks
- Personally address the bottlenecks
- Communication is important for people related bottlenecks
- Prioritize build prototypes get feedback from decision makers
- Get the ball rolling in your launch checklist
- 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:
- Maximize impact
- Are actionable
- Are responsive yet robust
Instrument everything what’s going on – helps in diagnosing the problems
- Monitor your software
- Determine how its used
- Measure anything and everything
- Analytics
- Project all instrumented values on a Dashboard
Internalize useful numbers – Knowing useful numbers like these enables you:
- With a few back-of-the-envelope calculations
- To quickly estimate the performance properties of a design without actually having to build it
- help you spot anomalies in data measurements
- clarifies both the areas and scope for improvement
Be skeptical about Data Integrity
- Using data to support your arguments is powerful
- The right metric can slice through philosophical biases, and product arguments
- Quickly resolving discussions
- Unfortunately, the wrong metric can do the same thing—with disastrous results. We have to be careful how we use data.
- Strategies to increase confidence in your data integrity:
- Log data liberally, in case it turns out to be useful later on.
- Build tools to iterate on data accuracy sooner. Real-time analytics is useful
- Write end-to-end integration tests to validate your entire analytics pipeline
- Examine collected data sooner
- Cross-validate data accuracy by computing the same metric in multiple ways
- When a number does look off, dig in to it early
Validate your ideas early and often
- Optimising for feedback as soon as possible
- Understanding what customers actually want and then iterating on that feedback
- Get the right things done
- Build MVP and get beta out for feedback
- 10% effort to be spent on small informative prototype
- Fake the full implementation of an idea to validate whether it will work is extremely powerful
- Validate product changes with A/B testing
- Use available tools instead of writing it yourself
- Results in understandable and actionable knowledge
- Reduce risk of large implementations with small validations
- Beware of one person team
- No feedback & validation
- Code reviews
- Monotonous work
- Dependency on the person
- Achievement celebration will not be there
- Strategies for feedback channel
- Be open and receptive to feedback
- Commit code early and often
- Request code reviews from thorough critics\
- Ask to bounce ideas off your teammates
- Design the interface or API of a new system first
- Send out a design document before devoting your energy to your code
- If possible, structure ongoing projects so that there is some shared context with your teammates
- Solicit buy-in for controversial features before investing too much time
- Build feedback loops for your decisions
Improve your project estimation skills
Use accurate estimates to drive projects
- Decompose the project into granular task
- Estimate based on how long the task takes, not a person takes to finish
- Person who takes up the task must give an estimate
- Avoid casual guesses
- Use multiple approach to estimate – granular to full project, historical data of previous work
- Avoid mythical man-month / person-days – nine women can’t give birth to a baby in one month
- Use time boxing to avoid growing scope of the tasks
- 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
- Must haves and nice to haves differentiation
- 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
Top comments (0)