Almost two years ago now, I graduated with my computer science degree from the University of Pittsburgh and joined Stavvy as a Software Engineer I. Since that time I’ve worked on a number of challenging and rewarding projects, earned a promotion, and grown significantly as an engineer and a person. I started on a team of 15 people, now our headcount is over 150! This aggressive growth has given me the chance to mentor a number of new engineers joining the team. Oftentimes it’s their first job after graduating and they ask some permutation of “How can I hit the ground running as a new member of the team? How did you succeed as a Software Engineer I?”
My answer is that it goes a long way if your company has a strong culture of growth, mentorship, and learning, but there are a number of ideas that will help you succeed:
Be a Sponge! 🧽
The first three months at your job are a window of opportunity. You’re not expected to be productive yet - your first job is just to learn how to do your job. Read documentation, research your stack, experiment, and absorb as much information as you can. Think of yourself as a sponge and try to be enthusiastic even when you’re a bit overwhelmed with new ideas.
One thing that helped me here was building stuff from scratch. In my first month at Stavvy I was tasked with adding a new endpoint to our API server, which lived in a large repository. I found it difficult to comprehend our server framework when there was already so much code on top of it! This led to me pattern matching existing code without a deeper understanding of what was truly going on. Then I encountered a problem that hadn’t been seen before at Stavvy, and pattern matching was no longer good enough. To erase that blind spot, I read the framework documentation, followed some tutorials, and built my own toy server. This gave me a better grasp of the abstractions I was working with, and I was able to think of better solutions when encountering new problems.
Help Me Help You! 🙏
A great engineer is resourceful and independent, but also knows when to ask questions. My rule of thumb is if you’re stuck for more than thirty minutes, reach out to someone. Avoid the mental pitfall of “any minute now I’ll have it figured out” - that’s a good way to kill a few hours you don’t have.
When you do reach out, make it easy for others to help you. Ask good questions. Try to respect their time and experiment to find the communication style that works for your particular team. Avoid asking basic things that you can Google or find in an internal wiki page, for example. For more on this, read 4 Ways to Ask Better Questions as a Software Engineer, it’s a fantastic guide that I return to time and time again.
We’re Looking for a Few Good Men(tors)… 🤝
Find at least one person who is a level above you, has been in your shoes recently, and is able to advise on what you can do to be more effective and progress up the internal ladder. Create opportunities for these conversations to happen. Schedule a one on one every few weeks.
If you’re in-person, grab lunch together or go for a beer. As a mentor I find it rewarding to give back, and in a more self interested sense it helps develop my skills as an aspiring lead and manager.
Do Demos. 🎤
Take credit for your work! Talk about what you have built. Make yourself visible to the rest of the organization. It’s a fantastic way to spread awareness of what you have accomplished, get feedback on projects, and mark development milestones. Make sure to call out and thank those who have helped you and contributed to the project.
I personally prefer to give live demos, but if you’re nervous about public speaking, I recommend recording your demo beforehand and playing it back. It’s all the same information, you have it for later, and you don’t have to worry about something breaking in the middle of your demo.
Build Your Onramp. 🚧
Between three to six months is the time where the expectations transition from learning to consistenly delivering working code. Make sure you’re on track to get to that point. Keep notes on what distractions or blockers are slowing you down. Tell your manager about these things early and often - they’re here to help you, they want to see you succeed, and have a priceless depth of experience to draw from.
If your team uses sprints and you have tickets that are carrying over multiple times, talk to your manager about expectations, estimating projects, breaking down tickets into smaller units of work, and how you can finish things more predictably.
Pay It Forward! 💸
Once you’re established, give back. Spread knowledge. Pay it forward to the next wave of new hires. This creates a culture of learning and helps your team grow. Someone once told me “the greatest senior engineers are those who create more senior engineers”. As you learn, write documentation. You have an advantage in that the information is fresh in your mind and you have yet to fall under the curse of knowledge.
For example, I had a heck of a time configuring AWS Management Console properly. Through a combination of aggressive Googling, asking my teammates about their setup, and good coffee I unstuck myself. Once I had things working, I wrote a step-by-step guide with some screenshots so that other new engineers could benefit from my struggle, and I would remember how to do this next time. It was low effort to put that page together, but now that’s part of our onboarding guide and every engineer who has joined since has used that reference to get from zero to productive more quickly.
Parting Thoughts.
This advice is based on my particular career - everyone’s situation is unique - but this is the guide I wish I had when I started. It’s especially relevant if you’re a junior engineer.
I learned a lot from writing this and I hope it can help others on their journey!
If you’re looking for more, I would specifically recommend reading The Manager’s Path by Camille Fournier. It doesn’t sound like it would be useful to an engineer, but don’t let the title fool you. It covers navigating teams at every level in your career and helped me to understand how to make the most out of those relationships.