I'm a curious Engineering Manager with 19+ years of experience in developing software and leading engineering teams. Having lived in 5 countries, I've learned to collaborate effectively with multi-disciplinary and geo-distributed teams. Having worked across industries such as Retail, Telco, Manufacturing and Energy, enables me to drive engineering excellence, business value, and customer success.

• Learn multiple ways of solving the same problem and know the pros and cons.
• The term best practices is relative. Best practices constantly evolve over time.
• Never settle in learning in-depth how something works. Embrace unlearning and re-learning.
• Instead of only doing your part, help out in dependent workstreams too to fully understand the E2E. Aim to solve the "whole problem".
• The most dangerous phrase: "we've always done it this way".
• Never be too busy to improve. Don't get stuck in a hamster wheel of inefficiency.
• Avoid unearned complexity by practicing YAGNI.
• Beware of the sunk cost fallacy.
• Out of all the agile practices commonly used, estimating work items and trying to measure project velocity is the least productive.

• Put people over processes.
• Assume best intentions.
• Judge people on their contributions, not on how confident they seem.
• Don't let your own desire to get things done quickly, turn into undue pressure on peers.
• Success is not a zero-sum game, so be happy and content with others' success.
• New systems are best designed by a small number of minds, not committees.
• As a Manager/Lead, if things go well, give your team the credit. If things go sideways, take the blame yourself.

• Code is a liability, not an asset. Each meaningful piece of code has to be version controled, tested, secured, deployed, monitored and documented.
• Code is just one of the many ways of achieving a solution.
• Your team is only as good as the weakest code reviewer.
• Don't get sucked into hyped/fashionable tech. Internalize that CS fundamentals don’t change much over time.
• Knowledge of specific frameworks, libraries or tools is not that important in the long run.
• Keep the docs as close to the actual source code as possible.
• All code in the critical path should have good tests, regardless if the tests were written first, last, or in the middle.
• Have the same high standards for all the code, from tests, little scripts to the inner loop of a critical system.
• Deploy from a main branch to an environment from the very beginning of a project.
• Don't implement in the app code, what can be configured in the infra.
• Automate all the things that are worth automating.
• Ensure the system is observable so that you can enquire at any time what is happening.