Yes, words matter... but I'm also reminded of a phrase (Frank Lutz used it as a book title years ago): "It's not what you say, it's what other people hear." I recall hearing the "job description" Software Engineer back in the 1970s (Margaret Hamilton is said to have been one of the coiners), and I've thought - intermittently over my career - long and hard about it. At this point... Methinks we're all over-thinking this.
I read Leon Martin's article too, and I agree with nearly all of the salient points that he made, and that you've made above. "...if we’re engineering anything, it’s value..." Well, this can be claimed about any of the engineering professions. The carpenter knows that his drill bit is of no intrinsic value to anyone else... what he's doing is using it to make a hole where one is needed. Civil engineers don't "engineer civils", anymore than mechanical engineers "mechanic", or electrical engineers "engineer electrics" - whatever those might be.
Over my decades in this profession, I've come to realize that we deal with a wide spectrum here... a range of experiences (or lack thereof), of perspective, of talents and training, and of focus. In the '70s (again), we were happy to call ourselves "hackers", when everything seemed shiny and new - like tinkerer-inventors in our basements, we were toying with techniques, approaches, methods and practices, trying to find the "best", or at least what seemed to work well. We also were learning that we could not accomplish most (major) tasks and projects alone - that we had to learn to "play well with others"; thus, teams.
With time came a degree more of proficiency, not that my code at that time could be compared to Ms. Hamilton's, whose programs "engineered" Americans to land on the Moon. But we all - those who were practicing seriously, diligently - were getting better, and the rather demeaning term "programmer" didn't fit well to many of us; hence: "software engineer."
We necessarily had to learn that our results - our product, our solutions - were very different in kind. Unlike a structural engineer's girders and rivets, or a chemical engineer's transformed elements and materials, our actual output cannot be touched, or weighed or measured - by its very nature, software is intangible. This brings an inherent difficulty in communicating the readiness (or lack thereof) of the fruits of our labors to the business-weenies and other non-technical folks ("I don' get no respect!" Pax, Mr Dangerfield!). Trying to help my own software teams communicate clearly with others, I use the metaphors "The veneer of photons..." (they'll only believe it when they can see it), and "User mythology..." (they don't have to understand the particulars or details); still, there's a deep gulf between what coders understand and work with daily vs. what non-technical people understand - if anything - about software (explaining why AI can be sold as snake-oil to the b-weenies).
Back to the point: Our profession exists as a continuum, not just expressed as novice-to-expert, but more nuanced. A youngster who's completed a website coding bootcamp has a start in proficiency with one (1) programming language, a few supporting tools, and a worldview that, with his new "hammer" is convinced that all computing challenges are website "nails". Within a few years of employment, that youngster becomes a midster with a few more tools in his kit and experience with a limited/few more problems solved - he's likely earned the full JD/title of "software developer". A different career path has the youngster go to college seeking a degree in "software engineering" - she's got a good foundation in the academics, theory, maths and science of it all - but upon graduation, she's still just an apprentice, with years of sweat-equity to earn a journeyman's or master's viewpoint, wisdom, skills and expertise.
Point is that, regardless of what we call ourselves - hacker, coder, full-stack developer, application developer, system programmer, software engineer - we've all earned a place on the spectrum of training, experience, expertise and worldview. Hopefully, one is self-critically honest about her or his actual spectral wavelength, and can use an appropriately accurate resumé and professional title for self-advertisement to others.
And there's the rub: How others - especially folks in business (who largely provide the opportunities and paychecks), together with their HR gatekeeper lackeys - perceive (see) us. We can quibble all we want to parse and refine our own notions - developer or engineer - of our profession, but is all this effort communicating the right things to our "audience", the folks we seek to hire us, to provide the next problem and project, and who will somehow, clearly or distortedly, judge our "solutions"?
Unhappily, I think not - not entirely or satisfactorily. I'm currently seeing this through the lens of the recently involuntarily unemployed - I was terminated, laid-off last November from a position of director of application development (or dir/SW-engineering, depending on who you asked in the company). Thus, I'm back in the job market ("I'm available to work" is the LinkedIn tag), and my email inbox is stuffed with possible positions entitled Director (or VP, or Senior Lead) of Software Engineering (most commonly, with SW-Development as a close second), with variations and combinations.
Clearly, upon even casual reading of the advertised job descriptions, responsibilities and experiential requirements, there's little to no agreement upon what any of these positions really is or does. Obviously, the key to an actual interview lies with getting past each employer's HR gatekeeper, now equipped with "AI" to further filter applications and resumés. Fortunately, an unemployment counselor recently coached me that it's okay, even recommended, to use ChatGPT to crank out bespoke resumé-variants and cover letters customized to each job description - sort of a "fight fire with fire" approach that I'd not considered by myself.
It's helpful - necessary even - for us to think hard and debate the "are we really engineers?" question. This shapes our personal and aggregate worldviews and philosophies about this brand new (only 50+ years old) profession. It can lead - more importantly, IMHO - to critical thought about our roles and responsibilities in business and enterprise, and about the codes of ethics and morality (so very important to and cherished by other engineering disciplines) necessary to guide our contributions to our fellow citizens and society.
But let's not fret too much over the badge of "software engineer" - it's no more right or wrong than "industrial engineer" or any other engineering discipline - it's whether or not we live up to our professional obligations that really counts.
Sorry for the TL;DR of this, Dave -- It's what happens when you suddenly become (temporarily, I trust) unemployed, "looking for work"! Oh, and my budget- and income-conscious spouse won't let me become a "paid member" of your blog until I get a job again!
Yes, words matter... but I'm also reminded of a phrase (Frank Lutz used it as a book title years ago): "It's not what you say, it's what other people hear." I recall hearing the "job description" Software Engineer back in the 1970s (Margaret Hamilton is said to have been one of the coiners), and I've thought - intermittently over my career - long and hard about it. At this point... Methinks we're all over-thinking this.
I read Leon Martin's article too, and I agree with nearly all of the salient points that he made, and that you've made above. "...if we’re engineering anything, it’s value..." Well, this can be claimed about any of the engineering professions. The carpenter knows that his drill bit is of no intrinsic value to anyone else... what he's doing is using it to make a hole where one is needed. Civil engineers don't "engineer civils", anymore than mechanical engineers "mechanic", or electrical engineers "engineer electrics" - whatever those might be.
Over my decades in this profession, I've come to realize that we deal with a wide spectrum here... a range of experiences (or lack thereof), of perspective, of talents and training, and of focus. In the '70s (again), we were happy to call ourselves "hackers", when everything seemed shiny and new - like tinkerer-inventors in our basements, we were toying with techniques, approaches, methods and practices, trying to find the "best", or at least what seemed to work well. We also were learning that we could not accomplish most (major) tasks and projects alone - that we had to learn to "play well with others"; thus, teams.
With time came a degree more of proficiency, not that my code at that time could be compared to Ms. Hamilton's, whose programs "engineered" Americans to land on the Moon. But we all - those who were practicing seriously, diligently - were getting better, and the rather demeaning term "programmer" didn't fit well to many of us; hence: "software engineer."
We necessarily had to learn that our results - our product, our solutions - were very different in kind. Unlike a structural engineer's girders and rivets, or a chemical engineer's transformed elements and materials, our actual output cannot be touched, or weighed or measured - by its very nature, software is intangible. This brings an inherent difficulty in communicating the readiness (or lack thereof) of the fruits of our labors to the business-weenies and other non-technical folks ("I don' get no respect!" Pax, Mr Dangerfield!). Trying to help my own software teams communicate clearly with others, I use the metaphors "The veneer of photons..." (they'll only believe it when they can see it), and "User mythology..." (they don't have to understand the particulars or details); still, there's a deep gulf between what coders understand and work with daily vs. what non-technical people understand - if anything - about software (explaining why AI can be sold as snake-oil to the b-weenies).
Back to the point: Our profession exists as a continuum, not just expressed as novice-to-expert, but more nuanced. A youngster who's completed a website coding bootcamp has a start in proficiency with one (1) programming language, a few supporting tools, and a worldview that, with his new "hammer" is convinced that all computing challenges are website "nails". Within a few years of employment, that youngster becomes a midster with a few more tools in his kit and experience with a limited/few more problems solved - he's likely earned the full JD/title of "software developer". A different career path has the youngster go to college seeking a degree in "software engineering" - she's got a good foundation in the academics, theory, maths and science of it all - but upon graduation, she's still just an apprentice, with years of sweat-equity to earn a journeyman's or master's viewpoint, wisdom, skills and expertise.
Point is that, regardless of what we call ourselves - hacker, coder, full-stack developer, application developer, system programmer, software engineer - we've all earned a place on the spectrum of training, experience, expertise and worldview. Hopefully, one is self-critically honest about her or his actual spectral wavelength, and can use an appropriately accurate resumé and professional title for self-advertisement to others.
And there's the rub: How others - especially folks in business (who largely provide the opportunities and paychecks), together with their HR gatekeeper lackeys - perceive (see) us. We can quibble all we want to parse and refine our own notions - developer or engineer - of our profession, but is all this effort communicating the right things to our "audience", the folks we seek to hire us, to provide the next problem and project, and who will somehow, clearly or distortedly, judge our "solutions"?
Unhappily, I think not - not entirely or satisfactorily. I'm currently seeing this through the lens of the recently involuntarily unemployed - I was terminated, laid-off last November from a position of director of application development (or dir/SW-engineering, depending on who you asked in the company). Thus, I'm back in the job market ("I'm available to work" is the LinkedIn tag), and my email inbox is stuffed with possible positions entitled Director (or VP, or Senior Lead) of Software Engineering (most commonly, with SW-Development as a close second), with variations and combinations.
Clearly, upon even casual reading of the advertised job descriptions, responsibilities and experiential requirements, there's little to no agreement upon what any of these positions really is or does. Obviously, the key to an actual interview lies with getting past each employer's HR gatekeeper, now equipped with "AI" to further filter applications and resumés. Fortunately, an unemployment counselor recently coached me that it's okay, even recommended, to use ChatGPT to crank out bespoke resumé-variants and cover letters customized to each job description - sort of a "fight fire with fire" approach that I'd not considered by myself.
It's helpful - necessary even - for us to think hard and debate the "are we really engineers?" question. This shapes our personal and aggregate worldviews and philosophies about this brand new (only 50+ years old) profession. It can lead - more importantly, IMHO - to critical thought about our roles and responsibilities in business and enterprise, and about the codes of ethics and morality (so very important to and cherished by other engineering disciplines) necessary to guide our contributions to our fellow citizens and society.
But let's not fret too much over the badge of "software engineer" - it's no more right or wrong than "industrial engineer" or any other engineering discipline - it's whether or not we live up to our professional obligations that really counts.
Sorry for the TL;DR of this, Dave -- It's what happens when you suddenly become (temporarily, I trust) unemployed, "looking for work"! Oh, and my budget- and income-conscious spouse won't let me become a "paid member" of your blog until I get a job again!
Wow: a comment that's longer than the original article.
On the "engineering value" point: I agree. Every professional is producing value, and that my arguments about the "Software" part of software engineering might lack strength. However, I do think there's a difference between the word "mechanical" in Mecanical Engineer and the word "software" in Software Engineer.
If you engage a Mechanical Engineer, it's because you need someone to do something with materials.
If you engage a Software Engineer, it's because you _think_ you need to have someone wrangle some software. But "software" is such a malleable concept, it may turn out the the better solution might just be to change your process.
A long time ago, I was called in to work with a financial services company. They had a problem handling incoming mail. They sold dozens of products, and each product generated many items of mail from each customer. This would come to a mailroom, where people would open each envelope, work out the correct department, and then sort snd deliver the mail accordingly.
A manufacturer of copy machines had just introduced ask OCR capability, and they wanted the insurance company to use it to sort mail automatically.
I was called in to look at how I could integrate the insurance companies systems with the scanner.
During the first meeting, they told me what they wanted me to do, and it sounded interesting. But then I stepped outside of bounds and asked "why are you integrating the OCR system like this?" and they explained about the incoming mail. I asked "have you tried using different return addresses, one for each internal department."
Silence.
Then the meeting was ended. A week later, I heard they'd postponed the OCR solution, and were looking into having the Post Office do the sorting for them for free.
And I guess that's the point I wanted to make. If we call ourselves software engineers, then implicitly the tool we use is software, just as MEs work with mechanical systems.
If that's our scope, we are going to become redundant in the near future: AI can take a spec and create code with increasing accuracy.
If instead we view our scope as understanding the client's needs, not wants, then it will be a long time before a glorified pattern matcher will take our place.
Something more accurate IMO would be ‘optionality maximiser’, but that’s just me the strange hill I’ve chosen to die on :)
I like that. Or perhaps 'reversibility supplier.'
Yes, words matter... but I'm also reminded of a phrase (Frank Lutz used it as a book title years ago): "It's not what you say, it's what other people hear." I recall hearing the "job description" Software Engineer back in the 1970s (Margaret Hamilton is said to have been one of the coiners), and I've thought - intermittently over my career - long and hard about it. At this point... Methinks we're all over-thinking this.
I read Leon Martin's article too, and I agree with nearly all of the salient points that he made, and that you've made above. "...if we’re engineering anything, it’s value..." Well, this can be claimed about any of the engineering professions. The carpenter knows that his drill bit is of no intrinsic value to anyone else... what he's doing is using it to make a hole where one is needed. Civil engineers don't "engineer civils", anymore than mechanical engineers "mechanic", or electrical engineers "engineer electrics" - whatever those might be.
Over my decades in this profession, I've come to realize that we deal with a wide spectrum here... a range of experiences (or lack thereof), of perspective, of talents and training, and of focus. In the '70s (again), we were happy to call ourselves "hackers", when everything seemed shiny and new - like tinkerer-inventors in our basements, we were toying with techniques, approaches, methods and practices, trying to find the "best", or at least what seemed to work well. We also were learning that we could not accomplish most (major) tasks and projects alone - that we had to learn to "play well with others"; thus, teams.
With time came a degree more of proficiency, not that my code at that time could be compared to Ms. Hamilton's, whose programs "engineered" Americans to land on the Moon. But we all - those who were practicing seriously, diligently - were getting better, and the rather demeaning term "programmer" didn't fit well to many of us; hence: "software engineer."
We necessarily had to learn that our results - our product, our solutions - were very different in kind. Unlike a structural engineer's girders and rivets, or a chemical engineer's transformed elements and materials, our actual output cannot be touched, or weighed or measured - by its very nature, software is intangible. This brings an inherent difficulty in communicating the readiness (or lack thereof) of the fruits of our labors to the business-weenies and other non-technical folks ("I don' get no respect!" Pax, Mr Dangerfield!). Trying to help my own software teams communicate clearly with others, I use the metaphors "The veneer of photons..." (they'll only believe it when they can see it), and "User mythology..." (they don't have to understand the particulars or details); still, there's a deep gulf between what coders understand and work with daily vs. what non-technical people understand - if anything - about software (explaining why AI can be sold as snake-oil to the b-weenies).
Back to the point: Our profession exists as a continuum, not just expressed as novice-to-expert, but more nuanced. A youngster who's completed a website coding bootcamp has a start in proficiency with one (1) programming language, a few supporting tools, and a worldview that, with his new "hammer" is convinced that all computing challenges are website "nails". Within a few years of employment, that youngster becomes a midster with a few more tools in his kit and experience with a limited/few more problems solved - he's likely earned the full JD/title of "software developer". A different career path has the youngster go to college seeking a degree in "software engineering" - she's got a good foundation in the academics, theory, maths and science of it all - but upon graduation, she's still just an apprentice, with years of sweat-equity to earn a journeyman's or master's viewpoint, wisdom, skills and expertise.
Point is that, regardless of what we call ourselves - hacker, coder, full-stack developer, application developer, system programmer, software engineer - we've all earned a place on the spectrum of training, experience, expertise and worldview. Hopefully, one is self-critically honest about her or his actual spectral wavelength, and can use an appropriately accurate resumé and professional title for self-advertisement to others.
And there's the rub: How others - especially folks in business (who largely provide the opportunities and paychecks), together with their HR gatekeeper lackeys - perceive (see) us. We can quibble all we want to parse and refine our own notions - developer or engineer - of our profession, but is all this effort communicating the right things to our "audience", the folks we seek to hire us, to provide the next problem and project, and who will somehow, clearly or distortedly, judge our "solutions"?
Unhappily, I think not - not entirely or satisfactorily. I'm currently seeing this through the lens of the recently involuntarily unemployed - I was terminated, laid-off last November from a position of director of application development (or dir/SW-engineering, depending on who you asked in the company). Thus, I'm back in the job market ("I'm available to work" is the LinkedIn tag), and my email inbox is stuffed with possible positions entitled Director (or VP, or Senior Lead) of Software Engineering (most commonly, with SW-Development as a close second), with variations and combinations.
Clearly, upon even casual reading of the advertised job descriptions, responsibilities and experiential requirements, there's little to no agreement upon what any of these positions really is or does. Obviously, the key to an actual interview lies with getting past each employer's HR gatekeeper, now equipped with "AI" to further filter applications and resumés. Fortunately, an unemployment counselor recently coached me that it's okay, even recommended, to use ChatGPT to crank out bespoke resumé-variants and cover letters customized to each job description - sort of a "fight fire with fire" approach that I'd not considered by myself.
It's helpful - necessary even - for us to think hard and debate the "are we really engineers?" question. This shapes our personal and aggregate worldviews and philosophies about this brand new (only 50+ years old) profession. It can lead - more importantly, IMHO - to critical thought about our roles and responsibilities in business and enterprise, and about the codes of ethics and morality (so very important to and cherished by other engineering disciplines) necessary to guide our contributions to our fellow citizens and society.
But let's not fret too much over the badge of "software engineer" - it's no more right or wrong than "industrial engineer" or any other engineering discipline - it's whether or not we live up to our professional obligations that really counts.
Sorry for the TL;DR of this, Dave -- It's what happens when you suddenly become (temporarily, I trust) unemployed, "looking for work"! Oh, and my budget- and income-conscious spouse won't let me become a "paid member" of your blog until I get a job again!
Yes, words matter... but I'm also reminded of a phrase (Frank Lutz used it as a book title years ago): "It's not what you say, it's what other people hear." I recall hearing the "job description" Software Engineer back in the 1970s (Margaret Hamilton is said to have been one of the coiners), and I've thought - intermittently over my career - long and hard about it. At this point... Methinks we're all over-thinking this.
I read Leon Martin's article too, and I agree with nearly all of the salient points that he made, and that you've made above. "...if we’re engineering anything, it’s value..." Well, this can be claimed about any of the engineering professions. The carpenter knows that his drill bit is of no intrinsic value to anyone else... what he's doing is using it to make a hole where one is needed. Civil engineers don't "engineer civils", anymore than mechanical engineers "mechanic", or electrical engineers "engineer electrics" - whatever those might be.
Over my decades in this profession, I've come to realize that we deal with a wide spectrum here... a range of experiences (or lack thereof), of perspective, of talents and training, and of focus. In the '70s (again), we were happy to call ourselves "hackers", when everything seemed shiny and new - like tinkerer-inventors in our basements, we were toying with techniques, approaches, methods and practices, trying to find the "best", or at least what seemed to work well. We also were learning that we could not accomplish most (major) tasks and projects alone - that we had to learn to "play well with others"; thus, teams.
With time came a degree more of proficiency, not that my code at that time could be compared to Ms. Hamilton's, whose programs "engineered" Americans to land on the Moon. But we all - those who were practicing seriously, diligently - were getting better, and the rather demeaning term "programmer" didn't fit well to many of us; hence: "software engineer."
We necessarily had to learn that our results - our product, our solutions - were very different in kind. Unlike a structural engineer's girders and rivets, or a chemical engineer's transformed elements and materials, our actual output cannot be touched, or weighed or measured - by its very nature, software is intangible. This brings an inherent difficulty in communicating the readiness (or lack thereof) of the fruits of our labors to the business-weenies and other non-technical folks ("I don' get no respect!" Pax, Mr Dangerfield!). Trying to help my own software teams communicate clearly with others, I use the metaphors "The veneer of photons..." (they'll only believe it when they can see it), and "User mythology..." (they don't have to understand the particulars or details); still, there's a deep gulf between what coders understand and work with daily vs. what non-technical people understand - if anything - about software (explaining why AI can be sold as snake-oil to the b-weenies).
Back to the point: Our profession exists as a continuum, not just expressed as novice-to-expert, but more nuanced. A youngster who's completed a website coding bootcamp has a start in proficiency with one (1) programming language, a few supporting tools, and a worldview that, with his new "hammer" is convinced that all computing challenges are website "nails". Within a few years of employment, that youngster becomes a midster with a few more tools in his kit and experience with a limited/few more problems solved - he's likely earned the full JD/title of "software developer". A different career path has the youngster go to college seeking a degree in "software engineering" - she's got a good foundation in the academics, theory, maths and science of it all - but upon graduation, she's still just an apprentice, with years of sweat-equity to earn a journeyman's or master's viewpoint, wisdom, skills and expertise.
Point is that, regardless of what we call ourselves - hacker, coder, full-stack developer, application developer, system programmer, software engineer - we've all earned a place on the spectrum of training, experience, expertise and worldview. Hopefully, one is self-critically honest about her or his actual spectral wavelength, and can use an appropriately accurate resumé and professional title for self-advertisement to others.
And there's the rub: How others - especially folks in business (who largely provide the opportunities and paychecks), together with their HR gatekeeper lackeys - perceive (see) us. We can quibble all we want to parse and refine our own notions - developer or engineer - of our profession, but is all this effort communicating the right things to our "audience", the folks we seek to hire us, to provide the next problem and project, and who will somehow, clearly or distortedly, judge our "solutions"?
Unhappily, I think not - not entirely or satisfactorily. I'm currently seeing this through the lens of the recently involuntarily unemployed - I was terminated, laid-off last November from a position of director of application development (or dir/SW-engineering, depending on who you asked in the company). Thus, I'm back in the job market ("I'm available to work" is the LinkedIn tag), and my email inbox is stuffed with possible positions entitled Director (or VP, or Senior Lead) of Software Engineering (most commonly, with SW-Development as a close second), with variations and combinations.
Clearly, upon even casual reading of the advertised job descriptions, responsibilities and experiential requirements, there's little to no agreement upon what any of these positions really is or does. Obviously, the key to an actual interview lies with getting past each employer's HR gatekeeper, now equipped with "AI" to further filter applications and resumés. Fortunately, an unemployment counselor recently coached me that it's okay, even recommended, to use ChatGPT to crank out bespoke resumé-variants and cover letters customized to each job description - sort of a "fight fire with fire" approach that I'd not considered by myself.
It's helpful - necessary even - for us to think hard and debate the "are we really engineers?" question. This shapes our personal and aggregate worldviews and philosophies about this brand new (only 50+ years old) profession. It can lead - more importantly, IMHO - to critical thought about our roles and responsibilities in business and enterprise, and about the codes of ethics and morality (so very important to and cherished by other engineering disciplines) necessary to guide our contributions to our fellow citizens and society.
But let's not fret too much over the badge of "software engineer" - it's no more right or wrong than "industrial engineer" or any other engineering discipline - it's whether or not we live up to our professional obligations that really counts.
Sorry for the TL;DR of this, Dave -- It's what happens when you suddenly become (temporarily, I trust) unemployed, "looking for work"! Oh, and my budget- and income-conscious spouse won't let me become a "paid member" of your blog until I get a job again!
Wow: a comment that's longer than the original article.
On the "engineering value" point: I agree. Every professional is producing value, and that my arguments about the "Software" part of software engineering might lack strength. However, I do think there's a difference between the word "mechanical" in Mecanical Engineer and the word "software" in Software Engineer.
If you engage a Mechanical Engineer, it's because you need someone to do something with materials.
If you engage a Software Engineer, it's because you _think_ you need to have someone wrangle some software. But "software" is such a malleable concept, it may turn out the the better solution might just be to change your process.
A long time ago, I was called in to work with a financial services company. They had a problem handling incoming mail. They sold dozens of products, and each product generated many items of mail from each customer. This would come to a mailroom, where people would open each envelope, work out the correct department, and then sort snd deliver the mail accordingly.
A manufacturer of copy machines had just introduced ask OCR capability, and they wanted the insurance company to use it to sort mail automatically.
I was called in to look at how I could integrate the insurance companies systems with the scanner.
During the first meeting, they told me what they wanted me to do, and it sounded interesting. But then I stepped outside of bounds and asked "why are you integrating the OCR system like this?" and they explained about the incoming mail. I asked "have you tried using different return addresses, one for each internal department."
Silence.
Then the meeting was ended. A week later, I heard they'd postponed the OCR solution, and were looking into having the Post Office do the sorting for them for free.
And I guess that's the point I wanted to make. If we call ourselves software engineers, then implicitly the tool we use is software, just as MEs work with mechanical systems.
If that's our scope, we are going to become redundant in the near future: AI can take a spec and create code with increasing accuracy.
If instead we view our scope as understanding the client's needs, not wants, then it will be a long time before a glorified pattern matcher will take our place.