Suggestions To College Freshers Joining The Engineering Team

As students take the plunge into Software Engineer career after completing their academics, everything is new - team, product, company culture, career, etc. Usually they would be feeling anxious, curious or proud to have started working in the team. They usually have this thought/worry of how to improve in this new world. College freshers join our team regularly either as a returning intern (converted to full time engineer) or directly hired from the college. During my initial conversations with new joiners, I usually give these suggestions. These suggestions are based on my experiences as a fresher and the learning I got from that experience.

• Ask Questions - You learn when you ask. Ask question when you do not understand. Asking questions helps you think on the topic. There are no stupid questions. Do not assume that this was supposed to be known before you join the team. Do not assume that everyone in the team knows about this and you are the only one who do not know. Keep asking the question until you understand. One of my senior engineer whom I used to shadow during technical interviews, used to tell this to the candidates once he has given them problem - Questions are free, you can ask as many as you like. When you ask the question, it will help others who do not know about that topic. It will also help the person who is going to answer as they need to clearly articulate their thoughts to answer your question. (Just because I wrote this, does not mean I excel in asking questions. I struggled a lot and I keep improving on this - probably a future post on how to ask better questions)
• Read Code - Code is the source of truth. Understand your team’s product by reading the source code of the product. If the repository or package is too big, no worries just pick a random function or random class and start from there. Code reading will help you to learn things in depth, it not only teaches you about the product, its dependencies but as well teach you about coding in general. As you read, more questions will arise; go and ask them to your team. You will also find places in code which can be refactored. If you are lucky, you can execute your products code in your local environment. Do it; learn from the logs it generates, output it generates. If you can put breakpoints and debug it via an IDE then it is even better. Put breakpoints and verify the variables and learn how your product behaves.
• Get early feedback - You will be asked to implement stuff or design something or fix some issue. DO NOT WAIT FOR PERFECTION i.e. do not wait for the implementation to be perfect in every sense or design to have covered every aspect. Rather RUSH FOR THE FIRST DRAFT AND GET IT REVIEWED. Collect feedback on that first draft and then iterate over. If something is wrong in that implementation/design then it needs to be fixed as early as possible. More time that wrong gets hidden, it will become as much more difficult to fix it (time to discover the bug is directly proportional to the time it takes to fix the bug). Keep remembering that review is not judging you as an engineer rather it is critique the code or design to make it better. As you review your code and design, collective knowledge of the team is going into that work. (This also I struggled a lot initially, probably due to imposter syndrome or want to shield my work.)
• Think before you do - When a task is given, do not start implementation right away. Rather write in your own language what needs to be done for that task. This helps you to think of the task as well as do the necessary research on the task before you venture into the implementation. This will also help unearth any blockers for these tasks before hand. So, it might look like - “I need to modify SpeicalWorkflow package. In that, I need to touch utilities.py file at this location. I need to add these 2 functions which will give these outputs. These will be called by my_unique_workflow.py from here. Its input will be validated by these conditions”. This may feel like you are doing double work or too much of hassle. But this initial investment will give you better returns in the future. This is developing a practice of thinking about the problem before venturing out into solution.
• Maintain your Work Journal - Some people call it work journal and some call it work diary. It is important we capture our thoughts, finds and summaries in a work journal. You can keep different cadence of writing that journal. Some like to write weekly summary of what you did, what you learnt and what needs improvement. It is not only important to write the summary but you also need to do periodic reviews of that summary to understand how things are going from a high level. The reviews help you to unearth any patterns. I generally write daily summary and has weekly, monthly and yearly review. I use Obsidian as my work journal tool. There are many tools for writing journals, whichever is more comfortable to you use it.