That it's all about the technical details. They are important, but getting the details perfect won't matter if the business problem is misunderstood. You'll build a solution to a problem they don't have and create new problems. I did that more than once in my career.
I good indicator that there is a misunderstanding is when you get into a coding conundrum. Meaning you had to solve a technical problem that doesn't make sense to you. It kinda gives you a weird feeling like something is missing. Learn to listen to that and ask questions until you figure out what's missing.
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.
I like how you said "It kinda gives you a weird feeling like something is missing." When I get that feeling I have step back and ask about the context because my big picture is partial.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That it's all about the technical details. They are important, but getting the details perfect won't matter if the business problem is misunderstood. You'll build a solution to a problem they don't have and create new problems. I did that more than once in my career.
I good indicator that there is a misunderstanding is when you get into a coding conundrum. Meaning you had to solve a technical problem that doesn't make sense to you. It kinda gives you a weird feeling like something is missing. Learn to listen to that and ask questions until you figure out what's missing.
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.
I like how you said "It kinda gives you a weird feeling like something is missing." When I get that feeling I have step back and ask about the context because my big picture is partial.