4 ms·

This actually seems like solid advice for communicating, generally -- I don't get the feeling that this is overly-sensitive to not offending people. > Avoid us

This actually seems like solid advice for communicating, generally -- I don't get the feeling that this is overly-sensitive to not offending people. > Avoid using specialized or technical terms without defining them. I try to do this even when speaking to technical individuals. It may make things more verbose but I appreciate it when others simplify as much as possible. > Including humor [risks confusing, irritating or insulting people] I have definitely seen jokes by myself or others completely fall flat, get misinterpreted or derail conversations. I could see how the Human Interface Guidelines[1] do feel a bit overboard in trying to be politically correct when you realize these are just suggestions for creating apps. But if app developers used most of the advice more frequently I feel like apps generally would be higher quality. Like, why not try to keep things simple and language as kind as possible? [1] https://developer.apple.com/design/human-interface-guidelines/foundations/inclusion https://developer.apple.com/design/human-interface-guideline...

carlmr 4y ago
>> Avoid using specialized or technical terms without defining them. >I try to do this even when speaking to technical individuals. It may make things more verbose but I appreciate it when others simplify as much as possible. It's immensely helpful to do this, especially in technical settings. The problem is that a lot of engineers won't ask out of shame of not knowing the jargon. By using plain language they don't need to be embarrassed and your communication is much more effective.
wyager 4y ago
> This actually seems like solid advice for communicating, generally If and only if your job is to write tedious corporate pablum.
- heywoodlh 4y ago
  > If and only if your job is to write tedious corporate pablum I disagree. Some background: I am a cloud security engineer (been in a senior security role for approximately six years). In my experience in the security field I have found that the best security engineers specialize in one or a few specific topics (e.g. systems administration, networking, reverse engineering, etc.) and are really valuable at those few things and then have a broad enough understanding of other security concepts that they can be generally useful in other topics they do not specialize in. Some of the most interesting presentations, documentation and conversations I have encountered has been when someone covers a topic I think I know well and breaks it down to such a fundamental level that "an idiot" could understand it. Typically, the intended audience for security content like this are highly technical individuals. Those who can "dumb down" a highly technical concept to any technical skill level are usually experts about that topic in my experience. But perhaps for genius-level individuals (a group to which I do not belong), maybe it is not useful to break things down. But for me, I know I find it useful when people don't make any assumptions about my knowledge.

carlmr 4y ago

>> Avoid using specialized or technical terms without defining them. >I try to do this even when speaking to technical individuals. It may make things more verbose but I appreciate it when others simplify as much as possible. It's immensely helpful to do this, especially in technical settings. The problem is that a lot of engineers won't ask out of shame of not knowing the jargon. By using plain language they don't need to be embarrassed and your communication is much more effective.

wyager 4y ago

> This actually seems like solid advice for communicating, generally If and only if your job is to write tedious corporate pablum.

heywoodlh 4y ago
> If and only if your job is to write tedious corporate pablum I disagree. Some background: I am a cloud security engineer (been in a senior security role for approximately six years). In my experience in the security field I have found that the best security engineers specialize in one or a few specific topics (e.g. systems administration, networking, reverse engineering, etc.) and are really valuable at those few things and then have a broad enough understanding of other security concepts that they can be generally useful in other topics they do not specialize in. Some of the most interesting presentations, documentation and conversations I have encountered has been when someone covers a topic I think I know well and breaks it down to such a fundamental level that "an idiot" could understand it. Typically, the intended audience for security content like this are highly technical individuals. Those who can "dumb down" a highly technical concept to any technical skill level are usually experts about that topic in my experience. But perhaps for genius-level individuals (a group to which I do not belong), maybe it is not useful to break things down. But for me, I know I find it useful when people don't make any assumptions about my knowledge.