3 ms·

I used to be a huge proponent of learning to write well as the most important skill an engineer can learn. Now, I think it's the second most important skill.

by beat 7y ago

I used to be a huge proponent of learning to write well as the most important skill an engineer can learn. Now, I think it's the second most important skill. The most important skill is sales. The key value of writing well, in a workplace environment (or other environments, really) is to convince others to agree with what you're proposing. Convincing people that something they don't initially understand or trust is going to be a win for them is a sales problem. Clear writing is only a means to that end.

beat 7y ago
And as a follow-on comment rather than an edit... There's nothing smarmy or dishonest about sales. Misleading sales is bad sales. The best salespeople are focused on fulfilling the customer's needs, not selling the product. The product sells itself once the customer understands that it fulfills their needs and offers them real benefits relative to the expense. And expense isn't just money. It's time. It's risk. It's learning curves. Customers often don't understand their own needs very well, so a big part of sales is helping the customer understand their own problems, in order to provide valuable solutions. The engineer who can really dig into requirements, really get to understand the customer and help the customer understand their own needs, and then offers a working solution, with clearly stated benefits and clearly stated costs, will do far better.
- hyeomans 7y ago
  Do you have any good resources on sales?
  - beat 7y ago
    Start with How to Win Friends and Influence People, by Dale Carnegie. Ignore the cheesy-sounding title; this book was written in the 1930s and has been in print continuously ever since, which speaks to its effectiveness. I also recommend To Sell Is Human, by Daniel Pink (and all of Daniel Pink's other books, as well).
    - hyeomans 7y ago
      Thank you. I try to re-read How to win friends every year, there's always a nugget of information that I remember. I bought To Sell is Human, thank you for that one.
  - kovacs 7y ago
    If you can only read one book on the topic I'd make it this one - https://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X https://www.amazon.com/Influence-Psychology-Persuasion-Rober... It's not about sales it's about how people think, act, and make decisions. I would bet that most any book on sales will invariably touch on at least some of the topics covered in this book. It's a fun read and I promise you will start to see these patterns being used in everyday life in verbal and non-verbal communication.
- tonyedgecombe 7y ago
  >Misleading sales is bad sales. True, unfortunately it’s also the majority of sales.
la_barba 7y ago
That sounds like a contrived scenario to me personally. Most programmers simply do the task that their supervisor or manager has assigned to them. Its not like they can refuse to do a task simply because it was worded poorly. They would just ask for further clarification.
- beat 7y ago
  Most programmers simply do the tasks assigned to them, because most programmers don't know how to sell! If you can sell, then you get to decide what you should be working on, convince your manager (and team leads, and other managers, and business teams, and anyone else who might be a stakeholder or shot caller) that it is in their best interest to have you work on the thing you have recommended. Note that this can't be BS... what you're recommending has to be an actual win for them. So, when you've completed the task you sold them on, they see you as a visionary and successful technical leader. The trust that creates will allow you to pick bigger, more ambitious things to work on. Of course, this assumes that you want to take control over your own work. If you're content just doing what you're told to do, then keep on doing that.
  - la_barba 7y ago
    Its not that I didn't understand your point. I just don't think this applies to most software engineers.
    - funkymike 7y ago
      Understanding the problem domain, i.e. what the customers really want and need rather than just what they specifically ask for, will help any software engineer do their job better. Only then can you suggest alternative solutions that solve the real needs vs. patching one requested item after another that are all half measures to solving the real problems.
      - la_barba 7y ago
        I don't know what scenario you're envisioning, but I'm envisioning a scenario where the task a programmer works on is assigned to them by a supervisor, a project manager, a lead, a project planner or whatever other similar designation companies have. The idea that non-trivial projects get built by engineers "selling" their ideas to each other doesn't align with my experience or even expectations. As a manager, I want my best developer to work on certain tasks, and not a junior developer. I don't want someone not familiar with the domain or technology to pick tasks which they have a high likelihood of failing at, etc, etc. Nothing controversial. Simple basic common sense. Companies have ways to escalate concerns programmers have about the tasks themselves. And it could also be that programmers are invited to comment on the road map/big picture. But that is something different.
munificent 7y ago
I disagree that this separate from writing as a skill. I don't think you can characterize any writing as "good" if it fails to persuade the reader to care about the author's message. The audience for writing is humans and the author has to get their message to stick in that human's head. A piece of text that is precise, terse, grammatically correct, and completely uninteresting or persuasive is not writing, it's merely a catalog of facts. But I agree totally that the "get the person to care" aspect is a fundamental part of writing well that is very often overlooked in technical writing.
- beat 7y ago
  They're both important. The question is, which is more important? Well, what are we measuring? Success in goals. And which is more likely to achieve goals... good writing with poor sales, or good sales with poor writing? I'd argue the latter, for a variety of reasons.

by beat 7y ago

beat 7y ago

And as a follow-on comment rather than an edit... There's nothing smarmy or dishonest about sales. Misleading sales is bad sales. The best salespeople are focused on fulfilling the customer's needs, not selling the product. The product sells itself once the customer understands that it fulfills their needs and offers them real benefits relative to the expense. And expense isn't just money. It's time. It's risk. It's learning curves. Customers often don't understand their own needs very well, so a big part of sales is helping the customer understand their own problems, in order to provide valuable solutions. The engineer who can really dig into requirements, really get to understand the customer and help the customer understand their own needs, and then offers a working solution, with clearly stated benefits and clearly stated costs, will do far better.

hyeomans 7y ago
Do you have any good resources on sales?
- beat 7y ago
  Start with How to Win Friends and Influence People, by Dale Carnegie. Ignore the cheesy-sounding title; this book was written in the 1930s and has been in print continuously ever since, which speaks to its effectiveness. I also recommend To Sell Is Human, by Daniel Pink (and all of Daniel Pink's other books, as well).
  - hyeomans 7y ago
    Thank you. I try to re-read How to win friends every year, there's always a nugget of information that I remember. I bought To Sell is Human, thank you for that one.
- kovacs 7y ago
  If you can only read one book on the topic I'd make it this one - https://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/006124189X https://www.amazon.com/Influence-Psychology-Persuasion-Rober... It's not about sales it's about how people think, act, and make decisions. I would bet that most any book on sales will invariably touch on at least some of the topics covered in this book. It's a fun read and I promise you will start to see these patterns being used in everyday life in verbal and non-verbal communication.
tonyedgecombe 7y ago
>Misleading sales is bad sales. True, unfortunately it’s also the majority of sales.

la_barba 7y ago

That sounds like a contrived scenario to me personally. Most programmers simply do the task that their supervisor or manager has assigned to them. Its not like they can refuse to do a task simply because it was worded poorly. They would just ask for further clarification.

beat 7y ago
Most programmers simply do the tasks assigned to them, because most programmers don't know how to sell! If you can sell, then you get to decide what you should be working on, convince your manager (and team leads, and other managers, and business teams, and anyone else who might be a stakeholder or shot caller) that it is in their best interest to have you work on the thing you have recommended. Note that this can't be BS... what you're recommending has to be an actual win for them. So, when you've completed the task you sold them on, they see you as a visionary and successful technical leader. The trust that creates will allow you to pick bigger, more ambitious things to work on. Of course, this assumes that you want to take control over your own work. If you're content just doing what you're told to do, then keep on doing that.
- la_barba 7y ago
  Its not that I didn't understand your point. I just don't think this applies to most software engineers.
  - funkymike 7y ago
    Understanding the problem domain, i.e. what the customers really want and need rather than just what they specifically ask for, will help any software engineer do their job better. Only then can you suggest alternative solutions that solve the real needs vs. patching one requested item after another that are all half measures to solving the real problems.
    - la_barba 7y ago
      I don't know what scenario you're envisioning, but I'm envisioning a scenario where the task a programmer works on is assigned to them by a supervisor, a project manager, a lead, a project planner or whatever other similar designation companies have. The idea that non-trivial projects get built by engineers "selling" their ideas to each other doesn't align with my experience or even expectations. As a manager, I want my best developer to work on certain tasks, and not a junior developer. I don't want someone not familiar with the domain or technology to pick tasks which they have a high likelihood of failing at, etc, etc. Nothing controversial. Simple basic common sense. Companies have ways to escalate concerns programmers have about the tasks themselves. And it could also be that programmers are invited to comment on the road map/big picture. But that is something different.

munificent 7y ago

I disagree that this separate from writing as a skill. I don't think you can characterize any writing as "good" if it fails to persuade the reader to care about the author's message. The audience for writing is humans and the author has to get their message to stick in that human's head. A piece of text that is precise, terse, grammatically correct, and completely uninteresting or persuasive is not writing, it's merely a catalog of facts. But I agree totally that the "get the person to care" aspect is a fundamental part of writing well that is very often overlooked in technical writing.

beat 7y ago
They're both important. The question is, which is more important? Well, what are we measuring? Success in goals. And which is more likely to achieve goals... good writing with poor sales, or good sales with poor writing? I'd argue the latter, for a variety of reasons.