3 ms·

I always have trouble parsing the Seemingly Wrong Thing That I’m Redefining writing style, so I’m not sure my comment is germane. It seems like OP is saying to

I always have trouble parsing the Seemingly Wrong Thing That I’m Redefining writing style, so I’m not sure my comment is germane. It seems like OP is saying to communicate about technical matters in a way that is not obscured by jargon and distracting minutia. That is generally good advice, and has an ancillary benefit that explaining deeply technical matters in plain language usually deepens the explainer’s understanding. There is a less charitable interpretation where this is just “I talk to the customers so the engineers don’t have to!” dreck, in which case, Be Less Click Thirsty.

yakshaving_jgt 5y ago
My interpretation was that it was more of an encouragement to think about things at a higher level of abstraction rather thinking of implementation details, as is a common reflex for so many programmers. Being able to communicate at that higher level of abstraction is a consequence of first having trained yourself to think at that level.
- Enginerrrd 5y ago
  Yeah it's an important skill. I knew an engineer that was about as smart as me in school. If there was a real stumper of a question on the exam, we'd be the only two to get it right. He was a hard worker. But that guy was incapable of discussing things at the 64,000 ft view, let alone the 30,000 ft or 10,000 ft. As a result, he had a really tough time working with anyone else, and the entire program was deeply focused on teams. You became like family with the other students by the end of the 2nd year. Your reputation in groups was incredibly important. This guy, he could be completely correct, and yet somehow get other smart engineering students to turn against him, including myself. No one could work with him. One instance of that still haunts me... It's really unusual that I don't listen to someone else and consider what they had to say, and yet I did exactly that on a really important project with that guy. He was completely correct about a very important and fundamental thing, and yet I just couldn't see it until it was too late. 10 years later, that still bothers me. That lack of skill haunted him in his later career. The last I'd heard, he had gotten fired from a job with a company that didn't fire anybody. It was bizarre to watch someone that could think about such technical and difficult things effortlessly, yet be unable to reason about them (or at least communicate) with nearly any level of higher abstraction.
7237139812 5y ago
OP here - I think your interpretation (the former) is pretty spot on. I also think the less charitable interpretation is not _exactly_ wrong. The title and repetition of "Be Less Technical" are definitely not devoid of "click thirst" - but the content is intended to be more in line with "we need to find ways to talk to each other, irrespective of whether we talk to customers or compilers".
- benreesman 5y ago
  I'm flattered that the OP took an interest in my comment, and when I said "less" click-thirsty I hope I didn't come off too judgemental: whether we admit it or not we're all pretty well wired-up for the engagement dopamine hit at this point, including me and my comment. Given that you've clarified the point you were making was the one I hoped: I am interested in hearing more from you and I would gently discourage that particular writing style. Your post could have been called, just for the sake of argument, "Work Technical, Speak in Plain Language" or something to that effect. There is this, I'll say it, dysfunction, where certain folks in the software business are trying to create a (high-paying) career track that is adjacent to deeply technical stuff but not really touching it. That needs to be drowned in a bathtub. Anyone smart enough to write an optimizing compiler is smart enough to explain how one works, at least in outline, to a layperson. There is no need for a middle-man layer of blubber between the people who need to know why to buy or not buy one, and the person who knows how to write one.
  - MauranKilom 5y ago
    > Anyone smart enough to write an optimizing compiler is smart enough to explain how one works, at least in outline, to a layperson. There is no need for a middle-man layer of blubber between the people who need to know why to buy or not buy one, and the person who knows how to write one. I don't think that conclusion follows from the premise. I could also mop the floor and clean the windows at work, but that doesn't mean that it would benefit the company overall. Similarly, just that engineers could in theory explain the thing they do to e.g. a customer does not mean that they should spend their time doing this. * There's further nuance in that (in my experience) engineers tend to be, by default, not great at communicating at the right level with a lay-person (which is more or less the point of the article), and that hiring people to interface between e.g. customers and engineers comes with pitfalls and can go wrong (your point, I believe). I personally think it's best if someone who presents products to customers has a deep engineering background and has transitioned into their customer-facing role from there. But if you need to visit more customers to make more sales, hiring more sales people instead of drawing from your engineering department is probably a wise choice. I say these things as an engineer in the trenches. * To be clear, I have no intention of disparaging either job.

yakshaving_jgt 5y ago

My interpretation was that it was more of an encouragement to think about things at a higher level of abstraction rather thinking of implementation details, as is a common reflex for so many programmers. Being able to communicate at that higher level of abstraction is a consequence of first having trained yourself to think at that level.

Enginerrrd 5y ago
Yeah it's an important skill. I knew an engineer that was about as smart as me in school. If there was a real stumper of a question on the exam, we'd be the only two to get it right. He was a hard worker. But that guy was incapable of discussing things at the 64,000 ft view, let alone the 30,000 ft or 10,000 ft. As a result, he had a really tough time working with anyone else, and the entire program was deeply focused on teams. You became like family with the other students by the end of the 2nd year. Your reputation in groups was incredibly important. This guy, he could be completely correct, and yet somehow get other smart engineering students to turn against him, including myself. No one could work with him. One instance of that still haunts me... It's really unusual that I don't listen to someone else and consider what they had to say, and yet I did exactly that on a really important project with that guy. He was completely correct about a very important and fundamental thing, and yet I just couldn't see it until it was too late. 10 years later, that still bothers me. That lack of skill haunted him in his later career. The last I'd heard, he had gotten fired from a job with a company that didn't fire anybody. It was bizarre to watch someone that could think about such technical and difficult things effortlessly, yet be unable to reason about them (or at least communicate) with nearly any level of higher abstraction.

7237139812 5y ago

OP here - I think your interpretation (the former) is pretty spot on. I also think the less charitable interpretation is not _exactly_ wrong. The title and repetition of "Be Less Technical" are definitely not devoid of "click thirst" - but the content is intended to be more in line with "we need to find ways to talk to each other, irrespective of whether we talk to customers or compilers".

benreesman 5y ago
I'm flattered that the OP took an interest in my comment, and when I said "less" click-thirsty I hope I didn't come off too judgemental: whether we admit it or not we're all pretty well wired-up for the engagement dopamine hit at this point, including me and my comment. Given that you've clarified the point you were making was the one I hoped: I am interested in hearing more from you and I would gently discourage that particular writing style. Your post could have been called, just for the sake of argument, "Work Technical, Speak in Plain Language" or something to that effect. There is this, I'll say it, dysfunction, where certain folks in the software business are trying to create a (high-paying) career track that is adjacent to deeply technical stuff but not really touching it. That needs to be drowned in a bathtub. Anyone smart enough to write an optimizing compiler is smart enough to explain how one works, at least in outline, to a layperson. There is no need for a middle-man layer of blubber between the people who need to know why to buy or not buy one, and the person who knows how to write one.
- MauranKilom 5y ago
  > Anyone smart enough to write an optimizing compiler is smart enough to explain how one works, at least in outline, to a layperson. There is no need for a middle-man layer of blubber between the people who need to know why to buy or not buy one, and the person who knows how to write one. I don't think that conclusion follows from the premise. I could also mop the floor and clean the windows at work, but that doesn't mean that it would benefit the company overall. Similarly, just that engineers could in theory explain the thing they do to e.g. a customer does not mean that they should spend their time doing this. * There's further nuance in that (in my experience) engineers tend to be, by default, not great at communicating at the right level with a lay-person (which is more or less the point of the article), and that hiring people to interface between e.g. customers and engineers comes with pitfalls and can go wrong (your point, I believe). I personally think it's best if someone who presents products to customers has a deep engineering background and has transitioned into their customer-facing role from there. But if you need to visit more customers to make more sales, hiring more sales people instead of drawing from your engineering department is probably a wise choice. I say these things as an engineer in the trenches. * To be clear, I have no intention of disparaging either job.