Elicit the deeper needs
Learn how to listen to the client better. Hold silence open for them to reveal what they need from you. Instead of doing what the client wants, you must think about the quality without a name and the process of removing ego from the task of discovering requirements.
Every project will start with a vision of a final product. The vision is a finished form, but the form as guessed by someone who has yet to take the first steps to discover the root of their problem. If the most crucial part of software development is understanding the problem, then make that the reality of your processes.
Your client is an expert in knowing when you have not satisfied them, but they are not the architect or the builder. They don’t know what they don’t know, and they don’t know what you don’t know, either. They will not ask for things they need that are obvious to them. They will also not ask for anything that seems juvenile or unofficial.
Remember the Eishin Campus project—the need for rain on faces and a contemplative walk by the water. In software, the need can be as simple as not requiring a login to first use the application, or the need may be elements of UX, such as seeing the effects of your actions before you take them. Options for theming, such as offering a light mode and a dark mode, may seem frivolous or optional to many, but for some, they can make the difference between a readable application and one that is barely usable.
And always remember the XY problem. Remember the ‘faster horse’ quote and the person stuck trying to figure out how to make their database transactions faster rather than reducing the number of pointless transactions. We can resolve many of these problems by asking ‘why’ a few more times. Other times, even an interviewer can get a little stuck on a solution and will need to step back. In each case, one round of questions is never enough.
You can only learn answers to the questions you can ask. You can only ask questions when you know you don’t know the answer. You can only know there is a question when you can detect ambiguity or gaps. It’s learning to see these gaps that makes you a software engineer, not your ability to write code to solve an already well-defined problem.
So, go now and spend more time reading about bugs than successfully deployed features. Bugs are unexpected behaviour, so figure out why it was not expected. Gorge yourself on failures and grow on a diet of mistakes.