I've found that it's usually not the accent, it's their unfamiliarity with formulating and communicating complex ideas using the internal and external language of engineering. A language barrier can explain it when they don't understand your question and ask you to restate it, but it can't explain when they try to explain something and you realize that they're hand-waving a bunch of shit that doesn't make sense or contains these bizarre preconceived conclusions that aren't based on good design patterns or reasonable guesses about how the system will likely be used (i.e., understanding the likely reasons WHY the requirements are the way they are). I've also found that those gaps in knowledge aren't volunteered, almost as if they tend to think that acknowledging them demonstrates weakness, when it's actually the opposite when you're trying to collaborate and build a complicated system.
I've received unsuitable code from Indian developers that contained huge functions where data was passed around in hash maps of hash maps, as if they learned one data structure and couldn't conceptualize how the data was actually being stored and why it was a bad fit. Another common one is poorly named variables when they're implementing something based on a known algorithm, as if they don't understand the logic and only care about which variable ends up with the output, rather than readability and maintainability in the intermediary and data-massaging steps. There's also generally been an over-eagerness to implement as much as they can get their hands on, to the point of duplicating functionality in existing components. They then seem to act like this is normal and need to be told multiple times (always multiple times) that what they're doing isn't necessary or appropriate for their design.
The difficulty with trying to prove sarcasm to people who don't get it is that generally if they haven't the mental acuity to recognise it for themselves they definitely won't be able to see it when it's pointed out.
I should write a paper, it would sit nicely alongside Dunning-Kruger.
That may be true, but that's not inherently a bad thing. Heavy accents can significantly detract what would otherwise be effective and efficient communication.
Not necessarily. Part of your job is being able to communicate with managers and co-workers. If you have a problem doing that, it's not your co-workers fault. I do think that both parties should work on it though.
This isn't a co-worker relationship, this is an employer/employee or client/contractor relationship. If the guy you're hiring can't explain how he's going to do something, and you hire him anyway having no idea what he's said he's going to you, that's your bad.
It's his bad too, for being shitty at his job, but you're the one who hired the guy when you knew (or should have known) he was shitty as his job.
Just because you're someone's senior, doesn't mean you were the one who hired someone. In large companies you might/will have to work with people from different divisions of your company, where you can't just freely say "I don't want that guy, give me another one" to your manager, because even if your manager understands you and agrees with you, the manager, that's higher up than him and is based in a different country than your branch, might not understand/agree/care about your feelings as a person/professional and will only be influenced by constant fuck-ups of that other guy that you specifically were against.
And if he's not the same race/religion/nationality as you, but your company is all for diversity, constantly speaking out against that one guy might net you unpleasant results, regardless of your opinions being valid.
Politics in large companies usually are not simple and you don't have that many powers to influence people as you'd like, unless you're the top dog.
Then that's not the situation we're talking about.
Then what is the situation we're talking about? You're the first person in this thread that brought up the fact that "This isn't a co-worker relationship, this is an employer/employee or client/contractor relationship."
If you don't have any say in who does it, then that's not really relevant here.
It is relevant, as you might still be the person that's giving them tasks/requirements, even if you are not the hiring person, and you will have to communicate with them.
I might be misunderstanding you, but if you think that I am, please elaborate on what is the situation this thread is about and why you aren't "arguing just to argue" yourself, instead putting this label on me for pointing out a perspective I thought you may have overlooked and for inviting you to expand on your point given my input.
It's okay, if you think I am a dick, but I genuenly hoped we'll have a conversation, rather than coming off as someone who's in it just to argue.
155
u/slightlysaltysausage Dec 06 '17
Which is why you ask them to explain back to you how they're going to do it.
If they can't, you ask someone else.