How to be a Newb Software Engineer
What to do when you land your first software job or when you are starting a new software job.
According to Urban Dictionary, newb is, “A term used to describe a inexperienced gamer/person/etc. Unlike a noob, a newb is someone who actually wants to get better.” Being the new software engineer in a company can be daunting. This guide will give you information on how to be less of a noob and more of a newb.
Setup Your Loop
The most important thing to figure out as soon as you start a new software project is how to run the project and test your changes. If the loop seems long, look for ways to tighten the time between your change and seeing your change exercised.
RTFM — Read The Fine Manual :-)
Learn about the system you are working on. It is easy to get lost in doing task after task. It is worth blocking out some hours to understand the system as a whole instead of just your small piece.
Meet the Team
When you meet the team, figure what they do and what system they know best. Knowing the roles individuals play allows you to know later who to talk to when you have a problem.
Round Robin Your Question
Try not to burden one coworker with all of your questions. Try to spread them out throughout the team. Spreading your questions achieves two things: 1. It shows everyone you are asking questions 2. It avoids the risk of overburdening one person with questions.
Batch Your Questions
Instead of asking your questions the moment it pops in your head, create a list of questions to ask later. Batching your questions reduces the interruptions your coworkers will experience. If someone explicitly tells you not to batch your questions and gives you the green light to ask any question at any time, please do not follow this advice of batching. By the way, this person is probably willing to take you under their wing.
Be Coach-able
Follow the advice from people on the team. This does not mean you should blindly follow what people say. If you disagree with someone, don’t say, “Uh huh, okay” and then do the opposite to the advice they told you. Be willing to tell them you are not going to follow the advice because of X(whatever reason).
Become an Investigator
As a programmer, investigation skills are good to have. Sometimes the subject matter expert on your team will not have the answer to your question or you may feel you have used up your “question quota.” For example, if you are reading a design doc and you want to read the code developed with the design doc and the author did not give a code location. By looking at the date of the design doc, you can then look at the code check-ins of the author around the creation of the design doc. Being creative in getting your answers is a skill that will serve you well.
Read Commits of Other Software Engineers
If you are working at a company which has a large code base, the code base itself can be a great resource. Learn how to use the code search system your company provides. The code base can answer questions on how to do things. Need to learn how to log? Find a code commit where someone did logging. Need to learn how to query the database? Find a commit where someone queried the database. Looking at examples in the code base will save you hours.
Understand Code
When reading code, it helps to draw a diagram to aid in understanding the system. For sparsely commented code, look at the descriptions of the commits that created the code.
Understand Error Messages
Above all else, read the error message. Sometimes it is easy to fall into the trap of not wanting to read the cryptic messages the computer provides. Communicating with the computer is a two-way street, to communicate effectively with the computer, you should also listen to what the computer is trying to tell you. If you don’t understand the error message, remove the specific details related to your specific problem and search for the error message either on the Internet or your company’s local intranet.
Use Binary Search
There will come a time where you encounter a bug and you don’t know what line of code is causing the problem. Example: You have added 20 features and they all seemed to work fine when you added them. You later notice your program crashes after a certain sequence of steps. What do you do? First, you remove the last feature you added and see if it still crashes. If that does not work, remove the second to last change. If that still does not work, now is the time to employ binary search. Remove all the features up to feature 10 and check if it now works. If the software works, move to feature 15. If the software does not work, move to feature 5. Repeat this until you find what feature is causing the problem. Doing it this way, allows you to find the error in O(logn) time. You can use this same idea when solving other software related problems.
Including internships and full-time positions, I have started as a new software engineer many times. Hopefully, the things I have learned will help you become an effective new software engineer on a team. If I missed any tips you use, please comment below. If you found this helpful, please heart this blog.
