That's true, I found myself asking so many questions even explaining how we are going to solve a problem, But I found myself bit low because of so many questions I ask, it's like in every standup meeting I keep asking many questions and counter client in demand in many ways, It kinda "make me feel like if i have problem for every solution". Thinking about all scenarios before starting is time consuming & stressing as well.
That's a good point Muhammad. The other part of knowing that dev is not only about the technical details is using the same terminology as the customer/user/stakeholder. Early in my career I insisted the user learn my language about fields and strings and technical things. But I found the most success learning to speak the user's terms. So they can correct me when I use them wrongly, and then I learn to see from their perspective. Even practice what they do if I can. Then when I code something I'm thinking of solving their problem more than the technical. Even if it is a little off target it's close enough that it can be fixed without large refactors. And it doesn't accrue as much tech debt in general.
For further actions, you may consider blocking this person and/or reporting abuse
Where hackers, sticks, weekend warriors, pros, architects and wannabes come together
That's true, I found myself asking so many questions even explaining how we are going to solve a problem, But I found myself bit low because of so many questions I ask, it's like in every standup meeting I keep asking many questions and counter client in demand in many ways, It kinda "make me feel like if i have problem for every solution". Thinking about all scenarios before starting is time consuming & stressing as well.
That's a good point Muhammad. The other part of knowing that dev is not only about the technical details is using the same terminology as the customer/user/stakeholder. Early in my career I insisted the user learn my language about fields and strings and technical things. But I found the most success learning to speak the user's terms. So they can correct me when I use them wrongly, and then I learn to see from their perspective. Even practice what they do if I can. Then when I code something I'm thinking of solving their problem more than the technical. Even if it is a little off target it's close enough that it can be fixed without large refactors. And it doesn't accrue as much tech debt in general.