One mistake I've seen junior software engineers repeat again and again is their lack of understanding of why they work on tasks they work on. This confusion can be somewhat justified by the relatively small scope junior engineers typically have but it's a slippery slope. Doing something only "because my manager (or a senior engineer) asked me to do it" has a few drawbacks:
- Inability to execute independently: making even the smallest decision without involving your manager or the tech lead will be hard if you don't understand the bigger picture. You will get stuck if you can't get hold of them. It will also be difficult for you to demonstrate you know how to solve problems at your level and are ready for bigger challenges.
- Communication gap: your manager or senior engineer may unintentionally give you incomplete or incorrect information. If you don't have enough context, you may not notice this. You may struggle to complete the task, but once you finally do, it may turn out that what you built is not what they hoped for and needs redone.
- Hindered innovation: unawareness of where your work fits limits your ability to propose solutions beyond what you're asked to do. Sometimes, the approach you're instructed to follow may not be the best solution to the problem, but exploring alternatives is impossible if you don't understand the broader context.
- Incorrect prioritization: working on a task without knowing its purpose may lead to neglecting this task and unknowingly delaying work that depends on it.
How to understand the bigger picture?
The easiest way to understand where your work fits is to ask your manager or the tech lead. They are responsible for what the team needs to deliver, so they should be able to explain this instantly.
Your question may even come to them as a surprise. They probably assume everyone on the team already understands the purpose of their work. In my experience, this is not always the case. The bigger and more complex the project, the harder it is to connect the dots.
You can start small, but it is important to go deep. Start asking about your task. You may hear that it contributes to a project the team is working on. An answer like this is not very helpful but could be a great starting point. It allows you to drive the discussion further and ask more interesting questions like:
- Why are we working on this project? Why is it important?
- What metrics is this work expected to move, and how?
- How does it support the company's goals and priorities?
- What projects did we decide not to pursue to fund this work (a.k.a. opportunity cost)?
A different way to understand where your work fits might be by talking to your product manager or people from the UX (User Experience) or marketing team. Because of their different perspective, they can teach you things you would never learn from fellow engineers. The challenge with this approach is that you need to be able to explain your role in the project to them.
💙 If you liked this article...
I publish a weekly newsletter for software engineers who want to grow their careers. I share mistakes I’ve made and lessons I’ve learned over the past 20 years as a software engineer.
Sign up here to get articles like this delivered to your inbox:
https://www.growingdev.net/
Top comments (0)