The effective engineer Notes

Published in

Just thoughts

7 min readOct 11, 2016

I just finished reading The effective Engineer by Edmond Lau. This is a great book to read and wanted to share my notes about it.

Thanks a lot, Edmond to allow me to share them even if I find they go really in details 😋

Adopt the right mindset

Focus on high Leverage activities

The book is all about leverage. What it just means is having the more impact on what you do. 80–20 rule.

Leverage = Impact Produced / Time Invested

How to make more impact with what you are doing right now?

Complete in less time
Increase the impact of the task through changes
Drop the task if not impactful and move on to a better one.

Keep learning

You need to keep a growth mindset in order to continue evolving. If you don’t you’ll reach a plateau. If you do you keep more control. Investing in your rate of learning, keep learning everyday even just 1%, get a job that allow you to learn through people, on boarding or autonomy. Increased learning means more happiness

How to dedicate time for new skills
20% of time, makers day
Via side skills useful for main skill
Read best engineers code
Write more code
Ask for code review
Enroll in class to improve
Participate in other projects discussions
What to do?
Read books
Learn a new languages
Learn high demand skills
Join discussion group or conferences

Prioritize Regularly

Prioritization is a skill that requires a lot of practice Track all your todos in a single list, always write stuff down to not have to worry. Your estimations will often be wrong and on the road to a goal, you probably will add more items to do. Focus on the goal, on what will produce real value. Keep time to focus on the important and non urgent. Do not let daily interruptions drive our priorities otherwise the non urgent will be lost even if it might produce more value. Protect your schedule by learning to say no and limit what you have in progress. Fragmentation here helps boost productivity. Switching contexts a lot will reduce productivity. Fight procrastination with planning to avoid falling into a moment where you need effort to start something.

Execute, Execute, Execute

Invest in iteration speed

Moving fast through continuous deployment and fast learning. Invest into time saving tools for your workflow and shorten debugging and validation loops maybe through automation. Master your programming environment by making small improvements and making it yours. Prefer keyboard over mouse, automate workflows through script languages or knowing UNIX commands.

Master is a process not an event

To keep the speed high, don’t ignore your non engineering bottlenecks. Value communication and acknowledge that getting approval is slow. Find what the leaders care about and create a safe review and approval process through good coordination. Depending on other people add overhead and friction but it is necessary.

Measure what you want to improve

Drive progress via metrics. They help focus on the right thing, confirm objectives, guard against regression and measure effectiveness over time.

Picking the right metrics will help maximize impact. They need to be responsive but robust. They will serve as your north star.

Instrument all the things, even stuff you don’t need yet. This will add flexibility when trying to define the north star. What does not guide you will be helpful in day to day operation and forensics. Log more just in case.

Have some numbers internalized. Stuff that are generic and useful to compare to what you get and see if you are totally out of the right order of value.

Be skeptical about data integrity, it is easy to abuse numbers and make them lie. Never confuse correlation with causality. Have tooling to iterate on the data and expose them soon in the process to detect anomalies. If possible, cross validate.

Validate early and often

Don’t delay get feedback figure out what’s working. By iterating with small steps, it lowers the effort to validate. Start with the scariest part to demystify the project. This will allow to get valuable feedback early.

Start by a small prototype to validate and you can even fake parts of it just to provide the feel of what you do.

Building feedback loops for your decisions will allow you to stop guessing what you are doing and have more confidence.

AB test your changes for validation, you can then quantify the impact you are making more easily.

Never have a one person team, this will reduce the feedback and validation. Avoid gigantic reviews and commit early and often. Requesting reviews and accepting the feedback. Test your ideas through discussions with colleagues, Write the API first, a design doc and share the context.

Do not work in isolation

Have better estimation skills

Business needs the estimations for long term vision. Adapt and review them often. Do not take estimations for targets. And especially don’t let target change your estimations.

Provide accurate estimations by decomposing into granular tasks, long estimations hides high risks. Do not let someone else estimate your job. Treat them as probabilities and estimates a task through different angles. If the task is open ended, time box it.

Even with all this, budget for the unknown, most disasters are due to termites not tornadoes. Keep in mind that a month of work does not mean that it will be done in a month.

Define clear goals and milestones to avoid feature creep. With business and your team this will bring alignment.

Reduce the risk by tackling the hard part firsts. Maximize your learning and revisit the estimations.

Approach rewrite project really carefully, people tend to underestimate due to familiarity with the old project. Also this is where a lot of new features creep in. If you need to add features, it will go in both projects and add time. Keep it incremental.

Even if you are late, don’t sprint in the middle of a marathon. Productivity decrease with additional hours and you are probably already too late and behind schedule already. Sprinting will lead to burn out, will hurt team dynamics and increase tech debt and communication If you still decide to sprint, make sure people understand why the project slipped so far, develop a realistic plan and timeline and prepare to abandon the sprint if it is useless.

Build long term value

Balance quality with pragmatism

It happens often that we over invest in quality and lower the value we provide.

Keep a sustainable code review process that catch bugs early. Increase accountability and build a positive model on how to write good code. Share the knowledge of the codebase.

Have clear and simple primitives to reduce future maintenance and allow higher productivity in future improvements. Solves the hard problem once and build for reusability around it. Avoid early abstractions that might lead to complexity adding more features.

How to know about good abstractions? — Find popular abstractions read through them — Look through open source in big companies — Study interfaces of popular API

Automate testing all your projects to decrease the repetitive work and shortening the path to notice errors. See your tests as some kind of executable documentation of what you wrote. (Still maintain clear documentation)

Repay technical debt to avoid increased rates on repaying it later. Do not let the debt be out of control and payback the part with the highest leverage.

Minimize operational burden

Choose boring stacks, embrace operational simplicity. This lower taintenance costs of complexity. If you use too many technologies, paradigms and so on, your team expertise gets split into the different systems. This will increase the learning curve for new comers and lower your ability to switch context. You will have your efforts diluted across systems.

Do the simple thing

Build systems to fail fast it will help surface issues and allow fixing them faster, slow failing brings troubles debugging and hides causes.

Automate mechanical tasks over decision making, tackle smart decision automation later, prefer low hanging fruits. We often forget to automate due to lack of time, self interest in the pager rotation about fixing for us not the others, underestimating the frequency and missing the time saving opportunity. Make your batch processes idempotent or at least retryable. Run them more often than expected to surface errors.

Increase your ability to respond and recover quickly via playbook and operations. Reduce situations where emotions cloud our judgement and simulate failures to be prepared. Plan for the unexpected.

Invest in your team’s growth

Have a positive and smooth on boarding that will allow to be aligned with your team members, you will achieve more.

Hiring is everyone’s responsibility, screen for the type of candidates likely to do well on the team and get them excited about the team, missions and culture. Use high signal to noise ration questions and do some kind of starter project. Scan for red flags and match on team culture and code. Do not be afraid of unconventional approaches.

Design good onboarding process to increase team success. Ramp up engineers as quickly as possible, share the team values and culture and expose engineers to the team’s fundamentals. Integrate the new hires socially in the team to through code labs, talks, mentorship and starter tasks.

Share ownership of code increase the bus factor and avoid SPOF and bottlenecks. This is achieved by keeping the code readable, rotate type of tasks and projects, documenting all the things and talking about the projects.

Build collective wisdom through post mortems, pause To reflect on past project and think about what could have been done better Retrospectives will help you detect lack of playbooks and remediation. Ask the five whys and have honest conversations, do not blame and debrief.

Build a great engineering culture it will pay off, base it on what you just read and be positive.

Conclusion

Time is our most finite asset and leverage allows us to direct or time towards what matter most

Books recommended

Cross-posted from https://blog.yannick.io