3 ms·

Critical subject. In engineering * Do not assign writing or communication tasks to hackers, nerds, techies, dorks. Assign to engineers * Periodically retrain

by scrubs 1y ago

Critical subject. In engineering * Do not assign writing or communication tasks to hackers, nerds, techies, dorks. Assign to engineers * Periodically retrain engineers to write * Let sales do sales. Don't confuse sales with marketing. Let's engineers do engineering communication. Details matter, sure. But the big modalities matter too. It's simply NOT a blur between the three * Good communication requires one to know who the audience is, and what they care about and how/where it intersects with what one knows. If you're confused, sit this one out * There's an important extreme of the previous point that needs emphasis. Too many ``communicators" cannot tell the difference between a piece of communication for ``some other", and one's personal diary. I call this diary communication (or diary code). My diary is for me; there is no audience. It can be terse, sweet, staggered, pithy because I know all the players, context, back story. That data is elided from my diary. Hell, maybe it's even right in places. But do not labor under the insane delusion it forms the basis of information for others to build off. You cannot build a team with a bunch of diary nonsense. * Do not communicate everything you know/think. It's called communication not a data dump. Have some game; you gotta have taste. Try this: overload on the first date with a smart, beautiful lady ... see how that goes ... see if she ever wants to waste time on you again * Avoid owl talk, jargon. If I cannot work out a reason why I'm faced with dealing with bunch jargon I assume the speaker is deficient, is hiding something, or is an empty hat passively repeating whatever he read 10 minutes ago. It's never a good look. * Read the room: if you blab on for 10 minutes and nobody has questions ... you blew it. You're another brick in wall, and another reason why people hate meetings * If you publish ``communication" on the web for God's sake do not atomize it by placing each electron of info from the whole in 62 quadrillion places connected by html links. F that. Stay one book/single-volume/whole-unit. The web has almost single-handedly insured we can only learn about electron sized pieces of info without every realizing there's atoms, molecules, matter up to Shakespeare/Newton i.e. the good stuff. I want the good stuff. I resent having to struggle through a maze of BS to get it * Some companies are especially clueless. Some companies suck bad. Have you ever had to deal with Mellanox? Wow! It's a shame

vincent-manis 1y ago
The “atomization” issue is one of my biggest bugbears, which I often comment on here. If your project's documentation is a website with many small documents all linked together in multiple ways, don't expect me to spend time trying to sort it all out. I recognize that some people are hyperlink-happy, but my way of learning was influenced by an obsolete technology called “books”[1], which provide a linear path, so later topics can build on earlier ones. This is very basic pedagogy, which so many documentation practices ignore. [1] “When I was your age, television was called books.” The Princess Bride
- scrubs 1y ago
  Agree! Definitely. Always. All day long, and twice on Sunday. Effective communication is both about the parts (details) ---AND--- composing the parts into an integrated whole. You gotta have both. So don't screw it up by lapsing into atomic incremental update mode where I fix this one ticket, an error, of tell you about some new bit of info then communicate it by writing a new page cross-linking other stuff. Integrate the update.

by scrubs 1y ago

vincent-manis 1y ago

The “atomization” issue is one of my biggest bugbears, which I often comment on here. If your project's documentation is a website with many small documents all linked together in multiple ways, don't expect me to spend time trying to sort it all out. I recognize that some people are hyperlink-happy, but my way of learning was influenced by an obsolete technology called “books”[1], which provide a linear path, so later topics can build on earlier ones. This is very basic pedagogy, which so many documentation practices ignore. [1] “When I was your age, television was called books.” The Princess Bride

scrubs 1y ago
Agree! Definitely. Always. All day long, and twice on Sunday. Effective communication is both about the parts (details) ---AND--- composing the parts into an integrated whole. You gotta have both. So don't screw it up by lapsing into atomic incremental update mode where I fix this one ticket, an error, of tell you about some new bit of info then communicate it by writing a new page cross-linking other stuff. Integrate the update.