10 Things to Do if You Were Just Hired as a Junior Engineer

In my time working in software engineering, I have been a newbie to teams myself and had the opportunity to mentor newbies that have joined my teams. This advice is based mostly on what I wish I had done myself with a dash of experience observing mistakes devs make when starting out. TLDR; It's not just about the code.

1. Be a Zero

In the wonderful Astronoaut's Guide to Life on Earth, Chris Hadfield introduces the idea that a person's actions in a situation can have three outcomes:

• -1 they make the situation worse
• 0 they do not affect the situation positively or negatively
• +1 they improve the situation

When you enter a new environment, it can be your desire to be a +1 that actually does the opposite. Of course you want to be a +1, but I can't tell you how often I've seen new developers start out of the gate pointing out everything that is being done wrong, how we need to change our entire process and that what they learned in the past is the true path. This kind of behavior starts your relationship with your new teammates off on the wrong foot and turns you... into a -1. You can make things better but first, understand how this team operates, ask great questions and keep your eyes and ears open. Being a zero at this stage will set you up to share those great ideas when you understand how all the pieces fit together.

2. Learn the Product

To borrow a truism, as a developer, you are not paid to write code. Code is the tool you use to build product. Understand what you're working on, why it's important and what is most important to the product at this stage of the company's life. Early on, getting features out the door as quickly as possible matters more than full test coverage. Later in the game quality, stability and performance are going to become more important. Where is the product right now?

Go through all the scenarios an end user would encounter and take notes, see if you can get some time from more experienced developers or product managers to explain what everything does. Write down areas that can be improved so that you can make suggestions later. If you're dropped into a busy team, they might appreciate that you have some ideas for your first project ready if there is not a plan for you already in place. Understanding of how your company's product works won't take any additional technical experience but will make you immediately valuable as an expert.

3. Learn About the Company

How old is it, who founded it, why? Who are the customers? Who are the competitors? What is the company's business model? What are their values? How do they market and sell their services? How do they organize? Where do you fit in?
Having a clear understanding of the character of the company you're working in will help you realize how your work fits into the bigger picture and make sure your ideas help move it toward its goals.

4. Leave a Trail

You have an advantage that people working at the company do not - experiencing everything for the first time. You are going to have to set up a dev environment. If the documentation is not there already, create some docs that you will piece together from asking people questions. If there are instructions, follow them and update any differences or sticking points that you encounter. Document everything that does not exist that you wish you had right now. The team, and future devs joining the team, will thank you.

5. Ask For Help

You will have to rely on the rest of the team to get up-to-speed on how things are done and getting to a certain level of technical ability. Most people are very helpful and understanding; you should still do your best to respect their time. A great way to do that is by persevering when you get stuck. It's tempting and easy to tap another developer on the shoulder to help you get through a tough bit of code, but don't do it yet. First, read the commit history, look for clues in the codebase, google around. If you're still stuck after trying at least two ways to solve the problem, ask for help as specifically as possible. Get in the habit of solving problems on your own while making the most of your team's expertise.

6. Understand Your Team

Every group that has been working together for any period of time will have its own reasons for being as they are. Maybe you're coming into a team of two or three engineers and notice lack of project management processes or documentation, it's likely because this team has been busy shipping and their informal back-and-forth has been more efficient than a perfectly organized Kanban board at this stage. Pay attention to where people's strengths lie so that you know the right people to ask questions and where there are gaps you can help fill.

7. Understand Other Teams

While you are focused mainly on building the product, many people are affected by the work you are doing. Salespeople will need to sell those awesome features, customer success will need to support them and product people will need your help to know what tradeoffs exist with any given solution. Make it a point to get to know people throughout the company. Almost no one will turn down a coffee invitation and give you a chance to get to know them better. Knowing what's top-of-mind for people in different parts of the company will give you more ideas for ways to be helpful than you will know what to do with.

8. Find Problems

If you've patiently done all of the above, you will have learned a lot about the product, the team and the rest of the company. Keep a list of all the problems you encounter and who is impacted by them. Things like - team has no documentation, dev setup is taking days, product managers don't include wireframes. Take some time to think about which problems, if solved, would produce the biggest impact.

9. Solve Problems

With your list in hand, you can start coming up with ideas for how to make things better. Some, you will be able to tackle on your own without too much additional input like putting together a repeatable dev environment setup and adding some documentation for the next hires. Early on, try to focus just on those problems that stand between you and flawless execution.

Wrong

"The engineering process is broken, there are no written tests, no code reviews, product is giving us soundbytes instead of clear specs and the CEO drops by every five minutes with requests that derail our work. We have to fix everything starting with implementing Agile/Scrum this exact way and requiring 100% test coverage."

Right

You: Hey team lead, could I get some advice? It's not really clear to me what I need to build based on these specs.
Team Lead: Hmm... I'm not sure what product meant either, let's walk over and talk to them.
Product Manager: Oh, here's everything we are trying to do here.
You: Great, I took notes based on our conversation and came up with this spec, does that capture what we're trying to build?
Product Manager: Yeah, that's great. Really helpful.
You: Ok, I will add this to our product documentation and we can update it if > requirements change, cool?
Product Manager: Can we clone you?

Product people might be more technical and rigorous about writing great specs than you, this is just an example.

10. Keep growing

While your number one priority at work should be to do everything you can to add value to your team, keep your long-term goals in mind. That way, as opportunities open up, you can steer toward those that will bring you closer while continuing to drive the company forward. Make sure your manager knows what you want so that they can help you get to the next step. That full stack monolith might get split up so you get more exposure to back end development, new team members will join and you will be able to get more leadership experience, someone will eventually have to build that test framework using the tool you always wanted to learn. Be patient and execute in your current role while thinking strategically about your own growth and development.