When it comes to starting on a new team as a software engineer, there are a few things that come to my mind as important advice. Here’s eight of one (in no particular order):

  1. Find your interests. A new team and product means new and foreign ideas are introduced to you for the first time. Explore everything, but gravitate towards where you find yourself interested in. The passion, combined with hardwork, often makes up for lack of knowledge, skill, or experiences.

  2. Learn things that seem “scary” to others. When a fellow engineer brings up parts of the codebase that are less understood, or “scary”, those are places worth exploring. A successful person is one that stands out among the most, and thus it is crucial to be able to solve unique challenges that befell most.

  3. Read code. Make sense of it. At each layer. This means thinking and criticizing the decision of each and every line of code, function, class, package/module, and finally the entire application. When things don’t make sense, find out by asking someone else or thinking about it.

  4. Write down what you learn, or things that seem interesting. While these observations may not make sense at first, your collection of thoughts will grow over time and patterns will emerge. This may be in the form of a complete journal, or it could be loose as just a collection of notes (most common). It doesn’t matter how neat and tidy your notes are, simply writing them down is good enough. As you look read through your old notes, take time to reflect, compare, or combine thoughts into bigger ones.

  5. Take advantage of being new. Your innocence grants you immunity. Be willing to explore, ask around, or even suggest mild ideas. Ensure that you phrase it in terms of learning, and if you are suggesting ideas, make sure they are incremental and don’t exceed your own current repertoire.

  6. Don’t over explore. The first priority is always to make sure your daily responsibilities are met, your tasks are well communicated, and progress is being made towards the goals to meet the deadlines. It may be advantageous to be deliver tasks under the recommended deadlines to build up good faith. Often times, it’s best if your learning and exploration aligns with your priorities. This is not always in your control, but you should strive to be flexible or to be involved in choosing the tasks you work on.

  7. Form genuine relationships with everyone around you. Once you are able to build up relationships with others, they will be more inclined to help when you need their support to achieve your goals. It also improves your team atmosphere and sets your team up for success. The best teams are often the ones that can work well together, which requires building trust and connection.

  8. Deliver incrementally. This is important always, but also even more crucial at the start. While you’re trying to figure out how to mesh your coding styles, standards, and ideas with the rest of the team, it is extremely important that you deliver things incrementally that are well-scoped. This allows for peer feedback at each step of the way, and can help save a lot of time. It also helps to give others a good impression of how you work. I often find that large units-of-work generally corresponds to code sloppiness.

This post was inspired by a fellow reader and friend of mine who recently furthered his career at a new company. I wish him and everyone who is in a new place all the best.