Every software engineer has that moment.
You are assigned a feature requirement. It could be a Jira ticket or a sticky note. You first start brainstorming if this is possible, how you would achieve it, and how much time it might take.
But before you start thinking through the technical implementation, you need to step back and ask "why"?
Asking "why" saves you time because it prevents you from building the wrong solution.
Often by nature, there are some technical assumptions built into a requirements ticket.
However, those writing software requirements sometimes don't clearly understand what is and isn't possible. There may be a better solution that is either faster or more user-friendly that has not been thought of or assumed to be impossible. As the software engineer building the feature, understanding why a requirement exists allows you to validate that the best solution (given all the variables) is being selected.
As a software engineer, you are the technical subject matter expert (yes, even if you're new).
Understanding "why" opens up alternative ways to build the feature.
Even if the requirements you're given are correct, there are many assumptions you may make based on what is or isn't listed in the ticket.
It is so important to never make an assumption. Assumptions lead to faulty technical decision-making. This feature may be a stop-gap and will need to change in 6 months. You save yourself and your company time by asking questions and unlocking those things that other stakeholders may not think to volunteer. This complete understanding of the problem and solution allows you to make the right technical trade-offs.
You aren't really doing your whole job as a software engineer if you are just building what people ask rather than what people need.
After asking "why" enough times, you'll build an understanding and intuition about your customers and their needs.
The sweet spot for software engineers is when they understand their customers and their needs deeply.
When that happens, engineers can suggest ideas that product managers or designers might not have considered. This collaboration between engineering, product, and design makes unique software exist. So embrace being a collaborative, product-focused engineer.
Ask "why" and make your product better.
Top comments (0)