Ask First, Code Later: The single, most important question
Ask First, Code Later: The single, most important question
Question project requirements rather than blindly implementing them. By asking "why" and engaging in early discussions, developers can find the true reasons behind requests
You just received the following requirements:
Update the product titles on our online marketplace. Instead of displaying the titles on two lines, show them in one. If the title is too long, use an ellipsis (…) at the end
You can go ahead and implement this, or you can first try to understand the reasoning behind this change.
🔑 The key question
Who defines requirements?
Often, you’ll find that these requirements come from a single person and haven’t been peer-reviewed.
When you receive the requirement, ask “so that?”
PM: We want to get the title into a single line
Me: So that?
PM: So that we can reduce the height of each product on the page, optimize screen real estate, and show more products within the client device’s viewport.
💬 Start the discussion
The earlier you identify a potential problem, the cheaper it is to fix it.
Having conversations during the requirement phase helps you address corner cases.
Someone: Instead of changing the title, why don’t we use a 2-column layout instead of a single column? This would nearly double the number of products shown, and we could keep the title as it is.
Someone else: The most important part of the title is in the middle. Switching to a single line might lead to a suboptimal experience. What if we generate a shorter title with a length limit in the backend and then switch to a single line? That way, we can avoid using ellipses.
🎯 Conclusion
Don’t just accept requirements at face value because someone said so.
Ask why they want it done.
People often struggle to connect problems with the right solutions on their own. It's through collaboration that good solutions are found.
Two brains are better than one.
🗞️ Other articles people like
👏 Weekly applause
Personal Finance for Engineers 🏦 by
. The most important decision I took was reading about personal finances in the gap of 2 months I had between finishing university and starting at Amazon. Start with this article if you don’t have a plan for your money.How to propose an impactful improvement to the codebase and own the implementation. This one highlights the importance of asking “why“ and having initiative. Don’t be someone just completing what’s assigned to you.
10 Tips to Identify and Fix Your Writing as a Software Engineer by
. Writing is leverage. You’ll have much more impact through others than by yourself.
I always like it when people have some entrepreneurial ambitions and think like customers or business owners for a second rather than just code head down whatever task they were given.
Caring about the whys will only make your product better.
Excellent advice, Fran, and thanks for the mention!
Love this article Fran! This was a super helpful feedback I've received at the start of my career. Clarifying requirements on something assigned to you or a ticket that comes your way does the following:
1. Helps you simplify a requirement or evaluate if its even needed
2. Build product sense
3. (If you need to write code), helps you write a good PR description since a good description should also contain context behind why the code change is needed as well as link design docs, figma mockup, project requirement doc, etc. We want to make sure all info is in writing
4. Helps you communicate impact to others sincw you want others to see you for being a good team player as well as delivering positive impact