(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Sunday, January 14, 2007
What I've Learned From Sales, Part I: Don't Feed the Trolls
This is the first part of “What I’ve Learned From Sales.” In this part, “Don’t Feed the Trolls,” I present my explanation for why people act like “trolls,” raising objection after objection to new ideas, and I suggest how to side-step this behaviour and deal directly with their concerns.
(Part II, Wanna Bet?, describes how to handle one very common form of objection. Part III, How to use a blunt instrument to sharpen your saw, describes the mind-set that there are opportunities for improvement to be found everywhere.)
“Oh no,” you must be thinking, “another Guy Kawasaki wanna-be trying to tell me how to sell things.” Well, yes to the wanna-be accusation, but no to the proposition that this is a general-purpose article about sales. I am not going to pretend to tell you how to promote your business, turn your product idea into a money-maker, or even how to sell yourself to an employer.
What I am going to share with you is some experience I have had with sales that strongly parallels my experience discussing new ideas with people. (I know, reasoning by analogy is often faulty. But it’s what we humans do, we’re pattern-matching machines.) If you find that people seem unreasonably resistant to good ideas like more powerful programming languages, putting people before process, or valuing working code above documents, you may find this helpful.
Guy Kawasaki’s The Macintosh Way explains how to create and evangelize great ideas, whether they are products for sale or world-changing movements.
Our model here is that the mental process of considering a new idea is the same as the mental process behind buying something. If you are discussing a new idea with someone—even if you aren’t actively trying to “sell” it to them—they are still going through the buying process. And if they have trouble accepting the idea, they will resist, or in sales jargon, they will “raise objections.”
Do you think this is specific to sales? No, when we see new ideas like the Ruby programming language, we encounter objection after objection. Some are ironic: Some Java enthusiast objects to Ruby on performance grounds: perhaps they are too young to remember when the C/C++ folks objected to Java on performance grounds? Or perhaps it will be the IDE support objection, or the Not Invented By Microsoft (a/k/a Not a Corporate Standard) objection, or any of a million others that are not completely unreasonable, but are also usually irrelevant.
What is an objection?
On the face of it, an objection is an expression of a discrepancy between your idea and what someone wants. So if they say “Lisp has too many parentheses,” you might think that they are saying “I would use Lisp if it didn’t have so many parentheses.”
The great secret we can learn from sales is that this is not true. As we will see below, people say what they think other people want them to say. So someone might be thinking “Lisp is too hard for me, all this talk of
We need to understand this, because the absolute worst thing you can do with an objection is answer it directly. If someone is really thinking “Lisp is too hard,” what good does it do to try to persuade them that parentheses are their friends? They don’t really care. Worse, if you trot out the benefits of homiconicity and its applications to macros and introspection and meta-circularity, you’re actually making Lisp sound harder, not easier.
Let me give you an example from my own experience in sales. At one time I was a Macintosh salesperson. I used to sell Mac SEs and Mac IIs in “The Dark Times” after Steve Jobs was expelled from Apple by the vile and treacherous Prince John… but I digress. I was a Macintosh salesperson at a time much like this time: nineteen out of twenty computer sales were PCs.
Revolution in the Valley tells the incredible story of the creation of the Macintosh—from the perspectives of the people who were actually there. It’s packed with behind-the-scenes anecdotes and little-known secrets. Much of the material is available on line for free.
You would think that selling Macintoshes would be a lonely existence. But no, the phone would ring regularly and customers would visit the office on a daily basis, always with the same question, Why should I buy a Macintosh instead of a PC? And at first, I would answer this question. Macintoshes were superior to PCs in every way. (Actually, this was technically very true at that time. Why, you could run as many as six monitors on a Macintosh II! But I am digressing from my digression.)
I learned a funny thing about answering people’s questions. I would answer their questions, and they would argue with me. I would say that you could run multiple monitors on a Macintosh II, making yourself more productive. And they would say “but I don’t need to be that productive, so that doesn’t count.” Or I would say that the mouse and windowing interface is easier to use, you can learn to use more programs. And they would say “but all I need is a word processor and a spreadsheet, so I don’t need to learn new programs.”
(Why would they do that? It was so that if someone asked them, “did you shop around and make an intelligent decision?,” they could reply, “why yes, I shopped around, I checked out Macs and PCs, I did a lot of research, and surprise surprise, I ended up with the exact same thing that my neighbour Bob has, except mine is running at 12Mhz and poor Bob is stuck with 10Mhz.” It may sound to you like they are doing an awful lot of work just to be able to say that one thing with a straight face, but I can tell you that there is this multi-billion dollar automobile industry that works on this principle: people want to be a little better than their neighbour, but not so much better that they are different than their neighbour.)
I can give you many more examples, but the interesting thing is not whether people wanted this stuff or not, but no matter how convincingly I answered their question, they would just ask another one. Their questions had nothing to do with how they were making up their mind.
I learned very quickly that what people think often bears no relationship to how they behave. People usually say the things that they think other people expect them to say, but they go ahead and do whatever it is they always wanted to do. In the case of buying computers, my observation is that most people want to buy whatever it is that most people are buying. They want to belong, to fit in. So they are going to buy a PC. Or an iPod.
So what was really on their mind was fitting in, even though they argued about the Macintosh’s technical merits.
The lesson I learned is that before we can introduce a new idea to someone, we first need to understand what is really on their mind.
Salespeople call this “uncovering the hidden objection”. They have all these elaborate techniques for figuring out what’s really on a prospect’s mind when they encounter resistance to the sales pitch. I’m not going to suggest we do that. Instead, I’m going to suggest we avoid the objections in the first place by “qualifying.”
What is “qualifying” and why is it the most important step in the sales process?
Many people say the most important step is “closing,” the art of getting the prospect to hand over the money, the end of the sale. If you judge by the behaviour of people selling time shares, fitness club memberships, and automobiles, this is the only thing salespeople work on: haranguing prospects and ‘overcoming objections’ by arguing.
Experienced and successful salespeople follow a different path. Experienced salespeople believe that the most important step is qualifying, the art of discovering whether a prospect has an actual need for the product, the beginning of the sale. Salespeople who are strong qualifiers spend almost no effort on closing because they are always working with prospects who want to buy.
On the other hand, if you do not discover their real problem, you extol virtues that have no attraction for them and neglect to address any perceived issues in their mind. The principle at work is that if you know what someone really needs, you address their needs from the very beginning. When you arrive at the conclusion, you have already addressed any questions they may have.
This is true for sales. It is also true for new ideas. If someone fears that an idea like learning Lisp (or meta-programming, or designing a program in the technical interview) would be too difficult for them, you will only be successful if you first explain how easily they will learn the new idea, and only then explain how wonderful the idea is.
Although there are various models for understanding people’s motivations—such as Maslow’s Hierarchy of Needs, or the Greed-Belonging-Exclusivity-Fear Quartet—for development tools and methodologies my experience is that the simplest model fits best: people are motivated to solve their problems: if you can identify a problem they think they have, you can show them how to solve it.
In On Intelligence, Jeff Hawkins explains how the human neocortex matches visual, audible, and kinaesthetic patterns—and replays them to form the basis of prediction. He makes a convincing case that the neocortex is the single most important distinction between humans and other species… and therein explains what makes humans human.
People without problems are not good prospects for lightweight development methodologies, new development tools, programming languages, or any other “change for the better.” Just the other day I was lunching with Dmitri from Opalis. We were talking about a development tool I am trying to build, and Dmitri was suggesting that it was a “vitamin” and not an “aspirin”.
I was taken aback. Isn’t improving software development important for everyone? Then I remembered my sales training and asked him about how things were going at Opalis. Dmitri admitted that his team was performing well and that he had built a lot of trust with his organization. So he didn’t have a problem. Quite simply, if someone doesn’t have a headache, you cannot establish the value of an aspirin for them.
Now, even Dmitri’s team has room for improvement, so it is not correct to say that there is no value in improved methodologies, tools, languages, or anything else for him. However, such things may not be a priority right now. This is exactly the same case as trying to sell a Macintosh to Bob’s neighbour: I believed that absolutely everyone could have benefited from owning a Macintosh. However, Bob’s neighbour didn’t think he had a usability problem, he thought he had an urgent “keeping up with Bob” problem.
And there’s the key: Don’t focus on how you think your new idea can help them be better. Instead, focus on whether they have an urgent problem that your new idea can fix.
Discovering their priorities shouldn’t difficult. Why don’t we simply ask them? Well, there’s a trick to asking someone about their priorities. Remember, they will tell you what they think other people want to hear, not what they are thinking. Here’s an example concerning agile development:
Agilist: “What’re your priorities for the development team in the next 60-90 days?”
Manager Says: “I have a total commitment to process improvement and faster response to business initiatives,” …but thinks… CMM Level Four—or, God willing, Level Five—will get me a higher profile and a shot at the CIO position. I need some consultants in here to start imposing some bondage and discipline over our development processes.
The trick is to get specific and objective. Never take objections as evidence of their real needs, and never accept vague feel-good values at face value. Top salespeople don’t. Try calling a busy estate agent and saying you’d like to buy a house. I guarantee that the agent will ask you, “when do you need to buy a new house?” And so it is with new ideas:
You cannot position lightweight development, tools, languages, or any other type of change without being able to fit them into the specific and objective problems someone is trying to solve. You need to relentlessly pursue the immediate, urgent priority:
Startup Founder: “I’ve heard that Agile stuff is crap—it only works for star programmers who would be good no matter how you manage them.”
Agilist: “Well, there’re a lot of opinions out there. Tell me, what would you say is the most pressing issue facing your development team right now?”
Startup Founder: “Well, we have hacked together some great stuff, but we need to scale, and to scale without imploding we’ll need some discipline, some real management of the development team. That’s why we need a real methodology.”
Agilist: “I can understand the importance of scaling up. So, have you set some specific objectives for scaling up over the next month or two?”
Startup Founder: “For the next couple of months? Oh, it’s all about recruiting, definitely recruiting. I need another two or three top people to work on a new project that could be worth millions. We’ve identified some good candidates, but it’s very difficult to get them to accept an offer from a start up.”
Agilist: “You know, we really ought to consider whether using Agile might help you recruit—have you considered the possibility that some star candidates might be looking for an environment that is more Agile than the one they are leaving?”
Startup Founder: “Hmmm…”
As you can tell, once you have a specific problem with specific dates attached to when the problem needs to be resolved, you can discuss a specific solution. You’ve side-stepped the useless “objections.” One more time: do not accept vague objectives, get specific objectives with near-term dates attached to them.
If someone really doesn’t have any applicable near-term objective, you will not be able to introduce a new idea to them. So don’t be surprised if they express very little interest. But when you have an immediate, specific objective in hand, you can position the idea as a solution to their problem.
And that works for almost any idea. Say you had a new programming language designed for set-top boxes. But it turns out nobody has a “programming set top boxes” problem. So they raise objections about the speed of your virtual machine, or the fact that programmers cannot manage memory in your language, so they cannot squeeze programs into very small spaces.
Should you keep pounding away at that? Or go looking for an immediate problem people have, like building web applications?
If you side-step their objections—like memory management—and get to the root of their immediate needs, you might be able to introduce a new popular programming language. Good luck!
Part II, Wanna Bet?, describes how to handle one very common form of objection. If you liked this post, you might also like a related post, The false dichotomy of choosing between your values and expediency.
This is the first part of “What I’ve Learned From Sales.” In this part, “Don’t Feed the Trolls,” I present my explanation for why people act like “trolls,” raising objection after objection to new ideas, and I suggest how to side-step this behaviour and deal directly with their concerns.
(Part II, Wanna Bet?, describes how to handle one very common form of objection. Part III, How to use a blunt instrument to sharpen your saw, describes the mind-set that there are opportunities for improvement to be found everywhere.)
“Oh no,” you must be thinking, “another Guy Kawasaki wanna-be trying to tell me how to sell things.” Well, yes to the wanna-be accusation, but no to the proposition that this is a general-purpose article about sales. I am not going to pretend to tell you how to promote your business, turn your product idea into a money-maker, or even how to sell yourself to an employer.
What I am going to share with you is some experience I have had with sales that strongly parallels my experience discussing new ideas with people. (I know, reasoning by analogy is often faulty. But it’s what we humans do, we’re pattern-matching machines.) If you find that people seem unreasonably resistant to good ideas like more powerful programming languages, putting people before process, or valuing working code above documents, you may find this helpful.
Guy Kawasaki’s The Macintosh Way explains how to create and evangelize great ideas, whether they are products for sale or world-changing movements.
Do you think this is specific to sales? No, when we see new ideas like the Ruby programming language, we encounter objection after objection. Some are ironic: Some Java enthusiast objects to Ruby on performance grounds: perhaps they are too young to remember when the C/C++ folks objected to Java on performance grounds? Or perhaps it will be the IDE support objection, or the Not Invented By Microsoft (a/k/a Not a Corporate Standard) objection, or any of a million others that are not completely unreasonable, but are also usually irrelevant.
What is an objection?
On the face of it, an objection is an expression of a discrepancy between your idea and what someone wants. So if they say “Lisp has too many parentheses,” you might think that they are saying “I would use Lisp if it didn’t have so many parentheses.”
The great secret we can learn from sales is that this is not true. As we will see below, people say what they think other people want them to say. So someone might be thinking “Lisp is too hard for me, all this talk of
let and lambda and closures and tail recursion is confusing.” But they are embarrassed to admit this, so they seize on something that sounds more reasonable, like “the syntax is weird.”We need to understand this, because the absolute worst thing you can do with an objection is answer it directly. If someone is really thinking “Lisp is too hard,” what good does it do to try to persuade them that parentheses are their friends? They don’t really care. Worse, if you trot out the benefits of homiconicity and its applications to macros and introspection and meta-circularity, you’re actually making Lisp sound harder, not easier.
At one time I was a Macintosh salesperson. I used to sell Mac SEs and Mac IIs in “The Dark Times” after Steve Jobs was expelled from Apple by the vile and treacherous Prince John…
Let me give you an example from my own experience in sales. At one time I was a Macintosh salesperson. I used to sell Mac SEs and Mac IIs in “The Dark Times” after Steve Jobs was expelled from Apple by the vile and treacherous Prince John… but I digress. I was a Macintosh salesperson at a time much like this time: nineteen out of twenty computer sales were PCs.
Revolution in the Valley tells the incredible story of the creation of the Macintosh—from the perspectives of the people who were actually there. It’s packed with behind-the-scenes anecdotes and little-known secrets. Much of the material is available on line for free.
I learned a funny thing about answering people’s questions. I would answer their questions, and they would argue with me. I would say that you could run multiple monitors on a Macintosh II, making yourself more productive. And they would say “but I don’t need to be that productive, so that doesn’t count.” Or I would say that the mouse and windowing interface is easier to use, you can learn to use more programs. And they would say “but all I need is a word processor and a spreadsheet, so I don’t need to learn new programs.”
(Why would they do that? It was so that if someone asked them, “did you shop around and make an intelligent decision?,” they could reply, “why yes, I shopped around, I checked out Macs and PCs, I did a lot of research, and surprise surprise, I ended up with the exact same thing that my neighbour Bob has, except mine is running at 12Mhz and poor Bob is stuck with 10Mhz.” It may sound to you like they are doing an awful lot of work just to be able to say that one thing with a straight face, but I can tell you that there is this multi-billion dollar automobile industry that works on this principle: people want to be a little better than their neighbour, but not so much better that they are different than their neighbour.)
I can give you many more examples, but the interesting thing is not whether people wanted this stuff or not, but no matter how convincingly I answered their question, they would just ask another one. Their questions had nothing to do with how they were making up their mind.
What people think often bears no relationship to how they behave
I learned very quickly that what people think often bears no relationship to how they behave. People usually say the things that they think other people expect them to say, but they go ahead and do whatever it is they always wanted to do. In the case of buying computers, my observation is that most people want to buy whatever it is that most people are buying. They want to belong, to fit in. So they are going to buy a PC. Or an iPod.
So what was really on their mind was fitting in, even though they argued about the Macintosh’s technical merits.
The lesson I learned is that before we can introduce a new idea to someone, we first need to understand what is really on their mind.
Salespeople call this “uncovering the hidden objection”. They have all these elaborate techniques for figuring out what’s really on a prospect’s mind when they encounter resistance to the sales pitch. I’m not going to suggest we do that. Instead, I’m going to suggest we avoid the objections in the first place by “qualifying.”
The most important principle of effective selling is that qualifying the customer is more important than overcoming objections.
What is “qualifying” and why is it the most important step in the sales process?
Many people say the most important step is “closing,” the art of getting the prospect to hand over the money, the end of the sale. If you judge by the behaviour of people selling time shares, fitness club memberships, and automobiles, this is the only thing salespeople work on: haranguing prospects and ‘overcoming objections’ by arguing.
Experienced and successful salespeople follow a different path. Experienced salespeople believe that the most important step is qualifying, the art of discovering whether a prospect has an actual need for the product, the beginning of the sale. Salespeople who are strong qualifiers spend almost no effort on closing because they are always working with prospects who want to buy.
On the other hand, if you do not discover their real problem, you extol virtues that have no attraction for them and neglect to address any perceived issues in their mind. The principle at work is that if you know what someone really needs, you address their needs from the very beginning. When you arrive at the conclusion, you have already addressed any questions they may have.
This is true for sales. It is also true for new ideas. If someone fears that an idea like learning Lisp (or meta-programming, or designing a program in the technical interview) would be too difficult for them, you will only be successful if you first explain how easily they will learn the new idea, and only then explain how wonderful the idea is.
If someone doesn’t have a headache, you cannot establish the value of an aspirin for them… Don’t focus on how you think your new idea can help them be better. Instead, focus on whether they have an urgent problem that your new idea can fix.
Although there are various models for understanding people’s motivations—such as Maslow’s Hierarchy of Needs, or the Greed-Belonging-Exclusivity-Fear Quartet—for development tools and methodologies my experience is that the simplest model fits best: people are motivated to solve their problems: if you can identify a problem they think they have, you can show them how to solve it.
In On Intelligence, Jeff Hawkins explains how the human neocortex matches visual, audible, and kinaesthetic patterns—and replays them to form the basis of prediction. He makes a convincing case that the neocortex is the single most important distinction between humans and other species… and therein explains what makes humans human.
I was taken aback. Isn’t improving software development important for everyone? Then I remembered my sales training and asked him about how things were going at Opalis. Dmitri admitted that his team was performing well and that he had built a lot of trust with his organization. So he didn’t have a problem. Quite simply, if someone doesn’t have a headache, you cannot establish the value of an aspirin for them.
Now, even Dmitri’s team has room for improvement, so it is not correct to say that there is no value in improved methodologies, tools, languages, or anything else for him. However, such things may not be a priority right now. This is exactly the same case as trying to sell a Macintosh to Bob’s neighbour: I believed that absolutely everyone could have benefited from owning a Macintosh. However, Bob’s neighbour didn’t think he had a usability problem, he thought he had an urgent “keeping up with Bob” problem.
And there’s the key: Don’t focus on how you think your new idea can help them be better. Instead, focus on whether they have an urgent problem that your new idea can fix.
Discovering their priorities shouldn’t difficult. Why don’t we simply ask them? Well, there’s a trick to asking someone about their priorities. Remember, they will tell you what they think other people want to hear, not what they are thinking. Here’s an example concerning agile development:
Agilist: “What’re your priorities for the development team in the next 60-90 days?”
Manager Says: “I have a total commitment to process improvement and faster response to business initiatives,” …but thinks… CMM Level Four—or, God willing, Level Five—will get me a higher profile and a shot at the CIO position. I need some consultants in here to start imposing some bondage and discipline over our development processes.
The trick is to get specific and objective. Never take objections as evidence of their real needs, and never accept vague feel-good values at face value. Top salespeople don’t. Try calling a busy estate agent and saying you’d like to buy a house. I guarantee that the agent will ask you, “when do you need to buy a new house?” And so it is with new ideas:
You cannot position lightweight development, tools, languages, or any other type of change without being able to fit them into the specific and objective problems someone is trying to solve. You need to relentlessly pursue the immediate, urgent priority:
Startup Founder: “I’ve heard that Agile stuff is crap—it only works for star programmers who would be good no matter how you manage them.”
Agilist: “Well, there’re a lot of opinions out there. Tell me, what would you say is the most pressing issue facing your development team right now?”
Startup Founder: “Well, we have hacked together some great stuff, but we need to scale, and to scale without imploding we’ll need some discipline, some real management of the development team. That’s why we need a real methodology.”
Agilist: “I can understand the importance of scaling up. So, have you set some specific objectives for scaling up over the next month or two?”
Startup Founder: “For the next couple of months? Oh, it’s all about recruiting, definitely recruiting. I need another two or three top people to work on a new project that could be worth millions. We’ve identified some good candidates, but it’s very difficult to get them to accept an offer from a start up.”
Agilist: “You know, we really ought to consider whether using Agile might help you recruit—have you considered the possibility that some star candidates might be looking for an environment that is more Agile than the one they are leaving?”
Startup Founder: “Hmmm…”
As you can tell, once you have a specific problem with specific dates attached to when the problem needs to be resolved, you can discuss a specific solution. You’ve side-stepped the useless “objections.” One more time: do not accept vague objectives, get specific objectives with near-term dates attached to them.
If someone really doesn’t have any applicable near-term objective, you will not be able to introduce a new idea to them. So don’t be surprised if they express very little interest. But when you have an immediate, specific objective in hand, you can position the idea as a solution to their problem.
And that works for almost any idea. Say you had a new programming language designed for set-top boxes. But it turns out nobody has a “programming set top boxes” problem. So they raise objections about the speed of your virtual machine, or the fact that programmers cannot manage memory in your language, so they cannot squeeze programs into very small spaces.
Should you keep pounding away at that? Or go looking for an immediate problem people have, like building web applications?
If you side-step their objections—like memory management—and get to the root of their immediate needs, you might be able to introduce a new popular programming language. Good luck!
Part II, Wanna Bet?, describes how to handle one very common form of objection. If you liked this post, you might also like a related post, The false dichotomy of choosing between your values and expediency.
Comments on “What I've Learned From Sales, Part I: Don't Feed the Trolls”:
<< Home
Great post, thanks.
Any suggestions for when you're selling to people who you can't have a detailed conversation with? (E.g. selling a product over the web).
Any suggestions for when you're selling to people who you can't have a detailed conversation with? (E.g. selling a product over the web).
# posted by 
: 2:27 AM
: 2:27 AM
Absolutely brilliant post. I've always had problems introducing new ideas to colleagues. Explaining why Erlang could have some benefits over Java is not an easy sell.
# posted by : 6:42 PM
: 6:42 PM
Rather than just echoing the "another great post" comment. Let me tell you why I think this is really good writing:
1) You have a solid idea that has merit and is not commonly bandied about.
2) You tell it as a story that makes it interesting regardless of the content.
3) It is just the right length for the content. Neither presuming too much insider knowledge from the reader nor endlessly echoing the refrain.
Bravo!
1) You have a solid idea that has merit and is not commonly bandied about.
2) You tell it as a story that makes it interesting regardless of the content.
3) It is just the right length for the content. Neither presuming too much insider knowledge from the reader nor endlessly echoing the refrain.
Bravo!
Your post was filled with excellent insights from a mental fitness perspective. People have emptiness in their personal and professional lives. When people are empty, they will have many different signals revealing their emptiness. Signals of emptiness include asking questions, wanting to fit in with others, and resisting change. When people are empty, they don't have what they want, need or aren't doing what needs to be done to be successful.
Very nice! Reminds me of my sales days and processes like SPIN selling. You REALLY need to identify problems and solve them.
As for Anonymous, brainstorm the problems your solution really solves (try doing this BEFORE you build your solution - many companies could have saved 2 years development by realizing that they didn't actually solve any problems :->). Speak to representative sample of audience in person or online (in person is better - if you can see them drooling and their eyes going dreamy as you explain the potential, then you've got a winner). Then write pages based on each of those solutions which users can access via your home page and via Google searches and each of which ends with a tailored offer and call to action.
As for Anonymous, brainstorm the problems your solution really solves (try doing this BEFORE you build your solution - many companies could have saved 2 years development by realizing that they didn't actually solve any problems :->). Speak to representative sample of audience in person or online (in person is better - if you can see them drooling and their eyes going dreamy as you explain the potential, then you've got a winner). Then write pages based on each of those solutions which users can access via your home page and via Google searches and each of which ends with a tailored offer and call to action.
Vorlath says:
You may be right on some parts of your blog entry, but not in the case of Lisp and brackets. I understand closures, recursion and everything else about Lisp. I had to use it on several occasions. I actually use closures every day in Borland's C++ which supports them. They are more limited, but useful for event callbacks. The reason I don't use Lisp is definitely the syntax. It's ugly as sin. But it's only one reason. Even if the syntax were modified, I would probably still not use it because the syntax clearly indicates the flow or thought process that must be taken. And I don't like it. Changing the syntax won't change the recursive nature of it. In my world, recursion = bad every time. Fixing runtime problems just gets too nasty. But the syntax is still the first roadblock to my using it.
Pointing to the syntax more easily describes the problems because the syntax directly affects how you must structure your programs.
In short, you're also saying that programmers who say they don't like C style syntax just don't understand imperative programming. What they're really saying is that if they understood it, they'd use it but are afraid to admit that they don't get it. Sorry, but that's just ridiculous.
You may be right on some parts of your blog entry, but not in the case of Lisp and brackets. I understand closures, recursion and everything else about Lisp. I had to use it on several occasions. I actually use closures every day in Borland's C++ which supports them. They are more limited, but useful for event callbacks. The reason I don't use Lisp is definitely the syntax. It's ugly as sin. But it's only one reason. Even if the syntax were modified, I would probably still not use it because the syntax clearly indicates the flow or thought process that must be taken. And I don't like it. Changing the syntax won't change the recursive nature of it. In my world, recursion = bad every time. Fixing runtime problems just gets too nasty. But the syntax is still the first roadblock to my using it.
Pointing to the syntax more easily describes the problems because the syntax directly affects how you must structure your programs.
In short, you're also saying that programmers who say they don't like C style syntax just don't understand imperative programming. What they're really saying is that if they understood it, they'd use it but are afraid to admit that they don't get it. Sorry, but that's just ridiculous.
# posted by : 10:00 PM
: 10:00 PM
Vorlath:
You may be right on some parts of your blog entry
Thank you, I'm flattered you say that.
but not in the case of Lisp and brackets.
I wonder if in your haste you skimmed over the sentence where I said someone might be thinking...?
That was meant as an example, not an over-arching Super-Theory of Lisp Marginalization.
I hope this clears up the obvious misunderstanding. Please re-read the post and comment again or email if you feel that it really seems to be suggesting that everyone who rejects Lisp's syntax have a hidden motive.
That's not my intention, and I'll gladly change the text if you think it fails to make the proper point.
You may be right on some parts of your blog entry
Thank you, I'm flattered you say that.
but not in the case of Lisp and brackets.
I wonder if in your haste you skimmed over the sentence where I said someone might be thinking...?
That was meant as an example, not an over-arching Super-Theory of Lisp Marginalization.
I hope this clears up the obvious misunderstanding. Please re-read the post and comment again or email if you feel that it really seems to be suggesting that everyone who rejects Lisp's syntax have a hidden motive.
That's not my intention, and I'll gladly change the text if you think it fails to make the proper point.
When i was a life insurance seller (as a student), a good way to handle this problem was to tell the prospect: "Ok, i see your point, but if we can solve this particular problem, would you be happy with...". So we can find the real objections.
Later it may be neccesary to handle the first objection but most of the time it is not neccesary.
Later it may be neccesary to handle the first objection but most of the time it is not neccesary.
I see where you are coming from and it makes sense to draw the parallel from selling something to persuading people of the benefits of new ideas, but the world of sales and selling techniques is dangerously rich in bullshit and I think we need to be cautious.
The truth is that there is no real trick to sales. It is about understanding the true needs of your customers to know what their problem is - and knowing them well enough to be able to help explain both the problem and why your offering will solve it. It's not about closing techniques, or clever ways of asking questions or any of that other "Secrets of the Top Salesmen" stuff.
The truth is that there is no real trick to sales. It is about understanding the true needs of your customers to know what their problem is - and knowing them well enough to be able to help explain both the problem and why your offering will solve it. It's not about closing techniques, or clever ways of asking questions or any of that other "Secrets of the Top Salesmen" stuff.
# posted by : 5:26 PM
: 5:26 PM
Thanks for putting my recent observations into easy to understand words! I've been trying to explain this concept to some clients and while they haven't been resistant, I can feel some reluctance. These particular clients happen to be in IT so this article is an excellent guide to show them the light.
# posted by : 4:16 PM
: 4:16 PM<< Home
