I have a list of books for my 2019 resolution, and along with each book is a deadline to finish it by. I set a goal to finish The Effective Engineer: How to Leverage Your Efforts in Software Engineering by the end of February, and I finished it early!

The entire book revolves around one single idea: the effective engineer does work that optimizes leverage, which is defined as the impact produced over time spent on a task. i.e. the ROI for effort that’s put in a certain task. There are many takeaways from the book, but I think I’ll document two particular ones that I have already started practicing in my own time.

Invest in Iteration Speed & Tooling

The author included this interesting quote on this matter.

If you have to do something manually more than twice, write a tool for the third time.

The common argument against this is best explained by this xkcd.

xkcd on automation

My take on this is probably not going to be the most popular, but I do agree with the author on this one. (Automation and tooling is necessary) It is in the blood of an engineer to invent an elegant solution given a particular problem at hand. Automation is no different than the “original task” to be done. “Rethinking” and “ongoing development” is probably indicative of the wrong solution implemented by the engineer, resulting in a downward spiral of productivity. I think the only way to get it right is through experience after several spirals, or to learn from the experience of those who have been through similar situations.

Tooling is as important as the actual product itself, and we should take pride in understanding the tools we use. Personally, before I start any particular project, I’ll optimize my development environment for the fastest iteration possible and do the minimum amount of manual work to validate my implementation. That includes setting up shell scripts, hot reloading, and auto-run test cases. These are simple tricks that I’ve embraced more to boost my development productivity.

Prioritize Regularly

Prioritizing is easy, but doing is regularly is tough. It is deemed as a high leverage task, which means that it yields a high ROI.

Probably one of the mostly used matrices when it comes to the topic of prioritization.

The reason for its high leverage is probably very straightforward, and from the matrix, we should always be focusing on tasks that are in the top right quadrant when the top left quadrant is empty. These are the tasks of highest leverage, and personally I have found writing documentation to be one that belongs in that quadrant.

Writing good documentation reveals many insights on the rationale behind the decisions made during implementation. Memory fails humans almost always as compared to clear, concise technical documentation. For every task that I take on, I have a set of documentation template ready. It’s pretty straightforward:

  1. What’s the goal of this system design?
  2. What are the options for achieving this goal?
  3. What are the pros and cons of each option?
  4. Which option was chosen?
  5. Why?
  6. Concrete implementation details, APIs etc.

There’ll always be push back for #6, because implementation details change all the time, but the rest should be set in stone. I would argue that when the business requirements change, a new set of documentation is needed because the goal of the system would be different from what it was before. The old documentation should be stashed away, but not discarded for “legacy reasons”.

This one is really tough to practice at work because of the very fact that high leverage tasks reside in the top right quadrant. There are almost always tasks that pops in the top left quadrant, leaving little time for important, non-urgent tasks. Which is why I spend time every morning re-prioritizing, trying to squeeze in little burst of time for the more important tasks. I have a neat little system in Todoist that assigns a priority number of each individual quadrant, and priority 2 tasks are what I am always optimizing for, a little counter-intuitive, but it works.

The book was an enlightening read because it helped me understand what it takes, beyond technical abilities, to be a great engineer. I’m lucky to have come across this book early in my career, and I’ll probably revisit this book again in the years to come.