Congratulations, you are hired!
You worked hard. You crushed your interview and whiteboarded like a pro. Today, you start your Software Engineer position. You probably have high expectations and ambitions for your new role. I sure did my first day at Achievers. That is, until I met with the HUGE codebase. At that moment, happy thoughts turned into fear and left me looking for an answer to only one question: how do I start? Over time, I overcame this feeling and learned lessons along the way that can help other developers going through a similar experience.
First, some background. Before I joined Achievers as a Software Engineer, my only previous work experience was at a tech start-up. My main reason for changing jobs and starting new was my desire to learn from other developers in a collaborative environment and take part in a larger project. I did not know much about the business or any of the features on the Achievers platform. I had no experience working on a large project with many developers. I didn’t even have much experience in web development. It felt like I was inside a maze and did not know which path should I take first.
Eventually, through hard work, perseverance, and some help from my peers, I did figure things out! Along the way, I learned six valuable lessons that helped me work my way through the large codebase and find my way in a larger company.
1. Do not be afraid to ask questions
Set aside your ego and start asking questions, even if you think your questions are dumb. Chances are other developers have gone through the same set of problems and have the solution. Many people fear looking incompetent amongst peers and prefer to isolate themselves in the hope that their lack of knowledge will not be discovered. Some people even feel like a fraud, a psychological phenomenon known as Imposter Syndrome. If you have Imposter Syndrome, don’t worry! I haven’t met a developer that doesn’t suffer from feelings like this to some extent. If you are like me you might also worry how frequently you should ask questions, which leads me to my second lesson.
2. Only ask after doing your own research
Other developers also have goals and tasks to complete so it is important to respect their time. My manager suggested that I should only ask questions if I have first researched the task. I personally observed that asking questions with zero knowledge and asking questions with some knowledge makes a big difference in the eyes of your peers. When you explain that you have tried to work out your problem, but got stuck at a certain part, the response you get tends to be more precise and takes less time away from your peers. In addition to this advice, my team lead also suggested that we should strive to not ask the same question more than once, which brings me to my next lesson.
3. Take notes. Lots of them. And then take some more.
There will be times you will ask the same question more than once and that is okay; however, as a rule of thumb you should aim to reduce the number of questions you ask, especially repeat questions. While I am no elephant, I bet even an elephant would forget some of the finer details of a large codebase. For every task you complete, every process you are unfamiliar with, every bit of information you receive that you have a chance of forgetting, you should take notes. Most developers have their own personalized notes because no one can remember everything. While taking notes helps you retain the process, the next lesson will help you inside the codebase.
4. Start using the debugger
I did not opt to use the debugger much in my previous development experience. I don’t know why. Maybe because the projects were smaller in scale and I knew them inside and out. Oh, what a fool I was! I am not sure how I got so far without it before, but I am sure I would not be able to find my way around the Achievers codebase without being able to hit a breakpoint and trace line by line. As my team lead always says, “Nothing is magic”, meaning the answer is in the code and code is there for you to explore. All you have to do is set a breakpoint, hit it, and unveil the mystery!
5. Accomplish one task at a time
Besides the help and the tools that smoothed my transition, it was still a hard process to leave a workplace where I was in my comfort zone and had good friendships built and adapt in a new workplace. To deal with the overwhelming experience, I often reminded myself to take one step at a time. For example, sometimes I would set a small task and achieve it to gain confidence and sometimes I would identify the biggest obstacle in my way and conquer it. Personally, my biggest obstacle was learning how to properly use Git, a tool I avoided for years. I made it my top priority to become better at it within my first two weeks. Accomplishing that goal was a great gain and gave me the assurance to approach my work fearlessly.
6. Be open to new processes
During my time at Achievers I’ve been exposed to new processes that I hadn’t experienced before. One particular practice I enjoy is code reviews. Having my code evaluated by my peers and observing other developers’ code allowed me to learn at a much faster pace. It also ensures that our large codebase is more consistent, aligns with best practices, and prevents bugs. Similarly, I have learned the importance of writing unit tests and have become an advocate of writing clean, maintainable, and testable code. Over time, I learned that understanding and following the best practices of your workplace can speed up your orientation. Most methods are there for a reason and are most suitable for that workplace environment.
Overall, I went through a challenging but rewarding period where I discovered a lot about how to approach learning in a new environment. Following these guidelines will help you adapt in your new role and start out with a bang! If you have any other ideas on how to master the onboarding experience, please let us know in the comments below.
A Survival Guide: how to make it as a newly hired Software Engineer was originally published in Achievers Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.