How to be a top performer in your first tech job?

I've joined a company I always dreamt of. How can I propel my growth & emerge as a high performer in my first job as a software engineer?

I've been answering this question for many learners at Scaler repeatedly. It's incredibly satisfying that these young developers are mindful of long term growth right at the beginning. Recently, I wrote down some tips from my experience of working as a software engineer for over 12 years and shared in our Scaler Community. I felt this would be useful for a much wider audience as well.

As a young developer in a tech team you will be assigned many smaller tasks, make sure that:

1. You have understood the task precisely. It’s your job to ask the right questions and ensure that you’re doing what actually needs to be done. Even if you do a lot of work and it's not what was required, it's all zero value.
2. Know why you’re building what you’re building.
3. Speed matters. Do not fool yourself with the thought that I’ll make it perfect but I’ll take more time. Most of the time, it's just a self pacifying trick that your brain is playing on you. Done is better than perfect, and perfect often doesn’t exist. Discuss with your lead/teammates, what things you know could be done, but deciding to do later in the interest of shipping faster. 
4. Always know what is going on under the hood. Something that works, but you don’t know how is only a disaster waiting. Read others code as much as you can, including the source code of the libraries you’re using (e.g. If you are working on ReactJS, read the source code of Component class and understand how it works). It's a superpower to know what is going on under the hood. Very few do it, but those who do become best in their space. 
5. ‘It works on my machine’ is not good enough. Think how it will behave when it goes on production, where the code might be on multiple servers, and the environment might be different. 
6. Think about code quality. Unlike the code you write in programming contests - where once the contest is over no one is ever going to read the code again - every single line of code you write at job will be read by 10 or more people, and will need to be understood and modified over time. The code works is not good enough, it’s not even 10% of the job done. It has to follow the internal company coding guidelines, meet efficiency requirements, and needs to be commented well among other things.
7. Simple is better. Never try to impress by showing off how many complicated algorithms you know. It’s good to know stuff, but “Jahan kam aaye sui, kahan chale talwar”. Which is, if something can be done using simplest logic, do not try to use fancy libraries or algorithms.
8. Code reviews and comments/change requests are not punishments, it is a gift from the reviewer to you, to help you learn something new, always thank the reviewer for them instead of building hostility. Try to make sure that you reach a stage as quickly as possible where you get minimum change requests in code reviews.
9. Keep learning more than what you need for the job right now. Once you are out of academics, your learning is your responsibility. Always keep a pet project where you can keep experimenting with the latest technologies, frameworks, understand the pros and cons and new capabilities added. 
10. Always keep an eye out for the newer and upcoming versions of the frameworks you use. Get to know what new things are being added, and what are the implications or benefits of them.
11. Think about the impact. Always know what's the difference being created by the code you’re writing, and keep a watch on whether the expected outcomes were achieved after it went live on production. For eg. - If you’re optimising a service, keep an additional to-do for yourself to check what’s the difference in average service call time before your code changes are implemented and after. 
12. Make it a habit to write weekly snippets (A word coined by Larry Page at Google back in 2002), of what impact you created and what you learned in this week. Make sure you always have something useful to write in snippets.

Now, some important things to be careful about. Mindset is an equally important as skill set to learn (if not more)!

1. The habit of blame displacement: Never ever get into a gang of people who enjoy complaining about everything in this world. In every org there will be two kinds of people, one who are always complaining about managers, their leads, and how everything is f***ked. The others who are always appreciated for the impact being created by them, and when they see something broken they think how to fix it, and bring it up to people in a constructive way. First category never succeeds in life, and just keeps hopping from job to job before deciding “I’ll do MBA” and then get into a mediocre middle management job. Category two comprises change-makers and usually have a high growth career trajectory.
2. Skipping immediate goals and daydreaming. There is no point planning how you will build your billion dollar business when you’re not able to complete simple daily tasks being assigned to you. Win small battles before planning the world domination. 
3. Thinking anything is too simple or beneath you. Only folks who do not know tech well enough think that certain work is too simple work to be assigned to them. CSS might be an example, it's one of the most beautiful and complex tech stack to understand and master, but it's very common that young engineers might say “Hey I’m not a UI developer why are you asking me to fix CSS of the website”. Not being able to finish the task shows your lack of skills, build them instead of avoiding them. Nothing is small, and nothing is trivial when you go in depth. 

These all are my experiences and observations, do not take them as absolute truths. Feel free to disagree and share your opinion in comments. The knowledge of a tribe is always much more powerful than the knowledge of any individual.