The Effective Engineer & Code Complete : Learnings

Simple notes from the things I find are important while reading the books. Most of it will be direct quotes from the books. Will keep updating as I read them.

The Effective Engineer

Effective engineers aren’t the ones trying to get more things done by working more hours. They’re the ones who get things done efficiently — and who focus their limited time on the tasks that produce the most value. To be effective engineers, we need to be able to identify which activities produce more impact with smaller time investments. Not all work is created equal. Not all efforts, however well-intentioned, translate into impact.

Always keeps these things in mind
Leverage, Optimize for Learning, and Prioritization

Leverage is the value, or impact, produced per time invested.

To be effective always ask these questions:
1. Ways to complete this activity in a shorter amount of time?
2. Ways to increase the impact/value produced by this activity?
3. Is there anything else that that would produce more value from your time?

Always plan high leverage activities, and emphasize on the necessity to not only list the activities, but also to pre-slot activities that can fit into 20 minute blocks of time. This forgoes the inefficiency of figuring out what to do when a free block opens up

Always prioritize and have a growth mindset. Manage your todos and keep prioritizing high leverage activities.

Invest in iteration Speed. If you are doing a thing more than once write a tool for it. Keep writing tools to increase effectiveness. Learn the editor shortcuts, your developer env.

Feedback loop. Validate your ideas early. Discuss the API design or interface or design document before coding it. Reduce the risk of large implementations by using small validations. The best engineers seek feedback constantly. They push each other to improve, and they learn quickly. This generally applies to all facets of the workday, from code reviews to site outages to foosball. Use A/B testing to validate your product hypotheses.

Improve project estimation. Don’t let a desired target dictate the estimates. Instead, these estimates should be used as an input to decide whether delivering a set of features by a certain date is feasible. If it is not, they should lead to a conversation about whether to change the feature set or the delivery date. Allow buffer room for the unknown in the schedule.

Balancing quality with pragmatism is little bit like an art. On one hand, we want our work to be a master piece. On the other hand, we are limited on time and other resources to finish our work.

Ultimately, software quality boils down to a matter of tradeoffs, and there’s no one universal rule for how to do things. High software quality enables organizations to scale and increases the rate at which engineers can produce value, and underinvesting in quality can hamper your ability to move quickly. On the other hand, it’s also possible to be overly dogmatic about code reviews, standardization, and test coverage — to the point where the processes provide diminishing returns on quality and actually reduce your effectiveness.

Manage Technical Debt. Focus on debt that cripple our work the most.

Be Careful of the “Shiny New Things” Syndrome.
Plan and practice failure modes.

Stop keeping difficult things for the end. Just start with it and it will be done. Dont shy away from them.

Invest in growth. Keep a percentage of your time to learn new things.

Time is our most finite asset, and leverage — the value we produce per unit time — allows us to direct our time toward what matters most.

Code Complete

Comments might actually imply bad code. Heavily commented code actually implies that the underlying codebase is abstruse and not self-documenting. Ideally code should be simple, straightforward and not need heavily commented.

.. to be continued ..