Like many other professions software engineering has its own language, its own vocabulary and its own conventions. However as software engineers in order to do our job well we need to collaborate with people outside of our own profession - which means we have to find a way to communicate efficiently so that we all understand each other.
We can only build the right thing for our users if we know what the right thing actually is. In order for us to know what the right thing is we have to understand the context in which any kind of software is being used. We call this context a domain.
The best way for us as software engineers to learn about any domain would be to experience it ourselves: Doing the job that our users do to feel their pain and to really understand what they would like to and need to have.
Unfortunately that’s not always possible (which shouldn’t stop us in trying). So the next best thing is to have a conversation with a domain expert which is someone intimately familiar with the domain that can be our guide and introduce us to all the wonders of the domain. But by that very definition this person will be an expert in his/her domain and not in our domain. So to have a basis for efficient communication we have to find a way to speak the same language - and that’s where we have to face the hard reality.
As our job is not all about coding (surprise!), we will have to get out of our comfort zone and learn something new: Not the latest framework or the most recent technology but real domain knowledge. And acquiring that knowledge starts by understanding the language of the domain you’re familiarizing yourself with.
And once you start to become proficient in that language you will start to see a change in how your users perceive you as a software engineer. They will no longer see you as “that tech guy that never delivers what I really need” but as a trusted partner that they know understands their problems and ideas.
So be open about learning that foreign language!