Tips for New Software Developers: Navigating Your First Year in Engineering

Chris Castle, Software Engineer, gets candid about what helped him the most in his first year as a full-stack developer.‍

{{divider}}
‍
Just over a year ago, I began my Engineering journey — you can even check out my career switch to tech in an earlier blog.

Now that I'm twelve months in, I've reflected on the first year and distilled my insights — some learned and some shared with me — that could be useful for those embarking on the same path. So whether you've just graduated from boot camp or perhaps are looking for ways to take your engineering career to the next level, I hope this helps:  

1. Find a great mentor‍

A mentor can be a game-changer for someone early in their career by offering a steady, reassuring hand to guide you along paths they've already trodden. Great mentor-matching relies on knowing where you need the most help beforehand — it could be technical areas, professional development topics, or simply onboarding effectively.

I've always found the most value in pairing with people outside my daily orbit so you don't get sidetracked talking operational topics. Remember that it's a two-way relationship — mentors benefit from sharpening their coaching skills too!

2. Learn intentionally and consistently

‍As a junior engineer, I was encouraged to view learning as an investment — to go deeper on each topic instead of shipping and moving onto the next one. Fortunately, personal growth is a core value at GetYourGuide. Still, senior colleagues speak nostalgically of similar times in their careers when the expectation to deliver was lower.

Savor this time, and treat learning as a pillar of your job — a project with defined goals, milestones, and tasks. Block dedicated learning time accordingly. And don't discount softer topics like talking to customers, getting hands-on with the product, and understanding stakeholders.

3. Prepare to fail — because you will (temporarily!)

Benjamin Franklin once said, "By failing to prepare, you are preparing to fail," which holds true in Engineering. Every engineer has broken something important in their time. If they haven't — they're likely not moving fast enough or innovating. Breaking things is inevitable; being prepared is a choice.

Learn your company's internal processes for managing incidents inside out — that might be how to conduct rollbacks, how to declare an incident, which stakeholders need looping in, and so on. If you get the chance, put them into practice before they're needed — a senior engineer should be able to help you execute a practice rollback allowing your team to do a dry run together.

Practicing these procedures before an actual crisis can save a lot of stress and confusion. Managing an incident efficiently and effectively showcases your skills and leadership capabilities.

4. Don't neglect the work-about-work

For an engineer, there can be a nagging feeling that if you're not writing code, you're not working. Instead, your mindset should be that of a problem-solver contributing to the entire product development cycle. Part of being that Swiss Army knife is knowing what to work on, when, and having the skills to do it.

Regularly reflect on where you're at, review your individual goals, ask for feedback, ideate on projects, set goals, and resource against them. Failing to do so leads to short-term, scrappy thinking that doesn't benefit anybody. Aim to be productive and impactful, not busy. There's a difference. 

Disclaimer: This point does not endorse setting 'meetings that should have been an email that themselves should have been a slack message'.

5. Work through the Imposter Syndrome

‍Feeling like an imposter, especially in the first few months, is a common experience. What helped me was establishing ownership of small projects with my manager. At first they'll be more straightforward like 'improve our onboarding docs', or 'deprecate XYZ set of components' that's fine. Getting these small wins and sharing each success built my confidence and helped me feel more competent before stepping into heftier challenges.

6. Know how to ask for help

‍Asking for help can be intimidating, and that pesky imposter syndrome might rear its ugly head again. Being self-sufficient is the aim, but there will be times when you do everything right - you've read the docs, plunged the depths of Stack Overflow, tried everything you can think of that might work - and still be stuck. Knowing when and how to ask for help is crucial.

With my manager, I set a rule for myself: if I'm stuck on a problem for more than an hour, it's time to ask for help. But it's not just about when to ask; it's about how you ask. Being specific about the problem and showing what I've tried makes it easier for others to provide guidance effectively. For example:

"Hey, can I get some help with X?"

Vs:

"I'm encountering X while trying to solve Y. I've consulted Z resource and tried solution A, but encountered B. Here's the relevant code snippet. I think the issue might be related to C, but I'm not sure. Any advice or resources on the next steps?

Which one makes it easier for a colleague to respond to?

7. Don't wait for permission to make things happen 

You have good ideas. You have unique viewpoints and experiences that can contribute to the product or the tech that runs it.

It's a disservice if you don't share or deliver on them. Make it a habit to think about problems, generate ideas, share for feedback, and follow through on them. Make it a goal to champion a single idea, usher it through the product development process, and ship it — you'll learn a lot doing that end-to-end, and deliver impact in the process.

8. Over time, create a vision for the kind of engineer you want to be

There is an almost unlimited combination of paths within engineering — management vs. individual contributor, general vs. specialist, start-up vs. scale-up, front-end vs. back-end, single monitor vs. dual monitor. Okay, that last one is less important.

What is important is creating a vision for where you want to be and finding ways to move  towards it over time. Your first years are a fantastic opportunity to dabble in a few areas and figure out 'who' you are. Over time, you'll develop a sense of what you want to achieve and be known for. Then, you can create a plan to work towards it.

9. Develop engineering-adjacent skills to create more opportunities

The best engineers are more than engineers. They tend to have one or two adjacent skills that, when combined with their engineering capabilities, make them unique in what they can offer. They tend to be 'good enough' at these areas rather than experts.

The adjacent skill could be Design — can they whip up Figma prototypes for an upcoming feature? Product Management — could they lead a team roadmap meeting? Data — can they wrangle events to gather insights from recent experiments? People — can they articulate how to help people reach their potential and make that happen?

Intentionally pushing yourself out of your comfort zone and bridging domains together will make you versatile and suitable for a wider range of projects and opportunities.

The adventure continues

I've learned a lot in the last twelve months while appreciating that this is only the beginning. I was promoted to mid-level in late summer, which refreshed my levels of imposter syndrome and raised my self-set expectations. Who knows, maybe I'll be back to share further updates on my story.

All this is to say that the learning and growth never stops. Maintaining a growth mindset is the most critical attribute a dev can bring to the table.

‍