Advice from My Mentors

Becoming better engineer

• Don’t be in a corner and think that things will get done by themselves, because they will not.
• Be proactive. Learn more and make sure you are always ahead of everyone in the meetings.
• Always take one meeting more for every confusion you have.
• Read things that have passed test-of-time (i.e Refactoring by Martin Fowler, Uncle Bob etc.) and don’t read random articles on Medium or other forums.
• Always take the first step! Never be the one sitting and waiting for others to do stuff for you.
• Ask questions for clarification. Do not do anything unless you are crystal clear about it.
• Never switch off your critical thinking! Do not think that something is concrete and cannot be changed. Nobody is God, anyone can make mistakes.
• Be simple as possible in your documentation. There’s a difference between ‘being simple’ and ‘being simple as possible’. Make sure your knowledge is transferred exactly as you wanted it to be.
• While developing products, don’t code for yourself, but for the team. Make sure every perspective is thought-through.
• Never assume things. Assumptions are very dangerous! Always make sure what you’re doing makes sense and do it by asking lots and lots of questions.
• Learn to praise. Praising and appreciating your mentor or juniors makes them more confident. No one hates praising.
• Show off what you build. There’s nothing wrong with bragging about your skills. Keep yourself in the limelight.
• Don’t get scared of error logs. Software programs are written for facilitation of the programmers so take the information from error logs to solve your problem.
• Don’t try to do everything you’re assigned to. Complete the tasks you are currently working on and let the assigner know priority of your tasks. InProgress tasks have higher priority than the tasks that you haven’t started.
• Feedback is important while communication. “Okay”, “Got it” etc. is not enough. Make proper feedback sentences like “I understand, so it should be…”. This shows your attention.
• Improve communication skills. Make sure you don’t mumble and your words are loudly and clearly pronounced.
• Be precise in what you write. Repetition is bad but making sure what you write covers all scenarios is important. Don’t become a storyteller too.
• Always be suspicious about yourself. If something works and you’re 100% sure it will work on all cases, you’re wrong.
• Code that you did not run has errors!
• A bug is an assumption that is wrong.
• Robustness Principle: “be conservative in what you do, be liberal in what you accept from others”.