Must Read - The Effective Engineer

I have been keenly waiting to find some time to write this article outlining some of the great points mentioned by Edmond Lau in his book “The Effective Engineer”, a book that I think everyone in this field should know.

I call it a must read book for folks who are soon entering the professional world or recently entered, because the earlier you board the ship the more you can apply and learn. I found out a bit late in my career but still it was worth the read. Most of the things outlined in the book I learned the hard way while some are completely new to me and the others needed some refreshers on the importance.

Edmond invested a lot of time in writing this book. The stories/references from top companies like DropBox, Box, Google are amazing and relevant. Most of today's tech teams have adopted the best techniques from top companies that are mentioned by Edmond, but some important ones are still left behind, no one really cares especially in the world of Startups.

Sharing my top learnings in detail, all the quotes are bits from the book that I shared in my own words with added flavour (no sugar, lol) on Linkedin:

Focusing on high leverage activities is the way to go! A simple formula leverage is value/time. Learn to say no to low leverage activities, a simple meeting that you think you shouldn't be a part of.

This is common, sometimes we forget about the most important task and start investing time that might not be beneficial to the project/team/company, we should always be reprioritising our work depending on the leverage. It is also very challenging for entry level engineers to say no to certain things, it might be okay initially. Even I wasted time in meetings that I was just sitting and had nothing to learn from or contribute to.

Technical debt is like financial debt, it compounds over time like the interest and becomes harder to pay off. Having a periodic cycle focusing on technical debt is a worthy investment, like a monthly payment to avoid future problems.

One of my favourites, we usually treat tech debt as just a word which means something we would not consider to revisit, that's why a good practice of revisiting periodically is followed in big tech companies. As mentioned above, assume what happens when you miss your monthly credit card dues, it accumulates!

Focusing on the non urgent but important tasks is very difficult to do if your company doesn't have a healthy engineering culture.

First let me explain what are the non urgent but important tasks, tasks that do not contribute directly to the product that makes an impact for the customers, etc.

A simple example would be having robust documentation, refactoring a module, POCing a new technology, improving the infrastructure for the longer run, all these types of tasks are put behind because of the urgent tasks needed to meet some deadline. These types of problems are everywhere but more specifically in Startups where one Engineer can be wearing multiple hats which makes these a lot more challenging.

Finding the right balance between code quality and productivity is very challenging especially if you are working in a faced paced startup.

This is particularly or Startups, since I have worked for a few years in a startup environment where productivity is more important than quality, it becomes very challenging to have a scalable and maintainable codebase. While focusing on quality only would make it hard to move things, like merging a Pull Request could be a pain for an Engineer because of too strict standards or code reviews. In simple words, it's hard to follow Google Standards in a Startup environment. Find the right balance!

To be a more effective engineer for a team/company, work on things that accelerate your team growth, like an onboarding experience for new engineers.

As an individual contributor, one of the important aspects we miss is how to help the team to grow and scale quickly with things that are usually not part of daily day to day work, onboarding experience is one while interview experience is another, making impact on such areas gives a big boost for the team.

Software related failures are inevitable, engineers' must overcome those by improving their ability to recover and react quickly.

As mentioned, we cannot avoid the Software failures, they will happen if not today maybe tomorrow. You cannot write perfect software, actually no one can! The only way is to overcome by having good practices of logging, debugging, reverting, resolving and escalating.

In the end, I would add that this book has alot more to offer, these were just my favourite bits, the reference and recommendation section has its own worth. You can buy the book from here, you can also learn more about Edmond here.