(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Wednesday, January 23, 2008
Are you an Engineer?
Provocative.
I’m not sure that is an unassailable definition of Engineering, however it seems close enough that quibbling over the definitions of modeling and mathematics wouldn’t add a lot of value. The discussion of appropriate job titles for enterprise software development didn’t really resonate with me (although I quoted them for shock value). Instead, I was moved by the question of which parts of software development are Engineering? Which parts are Science?
In my own career, I have actually been most interested in Industrial Design. Programming Languages have scope for Engineering: look at formal languages like Haskell and Coq for examples of languages designed by people making day to day use of Science. Programming languages also have huge scope for Design: designing a notation for programs is an exercise in applied psychology, an exercise in influencing the thoughts and behaviour of the programmer.
A recent article accused the MapReduce algorithm of lacking novelty, of using forty year-old ideas. For a Scientist, this is a problem: Scientists wake up in the morning trying to move the world forward. But for a software developer, using a forty year-old idea ought to be the normal case. Is it Engineering? Is it Science? Maybe it is Damn Useful, and maybe the non-Engineer, non-Scientist measures themselves against that yardstick.
I don’t have a tidy conclusion for you: just a suggestion that you read the linked post and ask yourself what you really want to do with your talent and your life, be it Engineering, Science, Design, or making software that enriches people’s lives.
Then go out and do it.
Update: Are you a Doctor?
If you don’t use mathematics in your day to day work, you aren’t an engineer. All engineers (say those who build bridges, or space craft, or cars) make heavy use of mathematics and/or hard sciences like Physics on a regular basis…
The title “Software Engineer” is (most of the time) a particularly deceptive one. To be accurate it should [be] something like “Software Maintenance Worker” or “Software Handyman,” but I guess it is easier to hire someone if his job title is “Rodent Officer” instead of "Ratcatcher.”
—Ravi Mohan, Ratcatchers and Engineers
Provocative.
I’m not sure that is an unassailable definition of Engineering, however it seems close enough that quibbling over the definitions of modeling and mathematics wouldn’t add a lot of value. The discussion of appropriate job titles for enterprise software development didn’t really resonate with me (although I quoted them for shock value). Instead, I was moved by the question of which parts of software development are Engineering? Which parts are Science?
In my own career, I have actually been most interested in Industrial Design. Programming Languages have scope for Engineering: look at formal languages like Haskell and Coq for examples of languages designed by people making day to day use of Science. Programming languages also have huge scope for Design: designing a notation for programs is an exercise in applied psychology, an exercise in influencing the thoughts and behaviour of the programmer.
A recent article accused the MapReduce algorithm of lacking novelty, of using forty year-old ideas. For a Scientist, this is a problem: Scientists wake up in the morning trying to move the world forward. But for a software developer, using a forty year-old idea ought to be the normal case. Is it Engineering? Is it Science? Maybe it is Damn Useful, and maybe the non-Engineer, non-Scientist measures themselves against that yardstick.
I don’t have a tidy conclusion for you: just a suggestion that you read the linked post and ask yourself what you really want to do with your talent and your life, be it Engineering, Science, Design, or making software that enriches people’s lives.
Then go out and do it.
Update: Are you a Doctor?
To come up with a proper treatment, doctors need to have an exact diagnosis. To have an exact diagnosis, doctors need to know exactly what is going on in the body. And the only way they can do that is to have a total and complete understanding of how the body works. They can’t just skimp out and decide “Oh, the circulatory system’s not that important.” They can’t just say “Heart trouble? Here, have some aspirin.” Sure, the aspirin might stop the pain temporarily, but in the long run, the patient will suffer even more, and probably die.
Comments on “Are you an Engineer?”:
<< Home
Certainly "logic" is a form of math and is a central aspect of software development.
Algorithms.
Processes.
Cost / benefit tradeoffs, i.e. kinds of "accounting".
These are all mathematical, and significant aspects of software development.
Algorithms.
Processes.
Cost / benefit tradeoffs, i.e. kinds of "accounting".
These are all mathematical, and significant aspects of software development.
Algorithms.
I would stop well short of saying that most software development is done with any kind of rigorous consideration of algorithms.
I would stop well short of saying that most software development is done with any kind of rigorous consideration of algorithms.
Being back in the job market has caused me to realize yet again that the industry is terribly confused. On the one hand, you've got a bunch of people in a small company all with same the job title of "Programmer" who work out their own designs for what they code, have to constantly apply creative and logical thinking, sniff out odd, unforeseen problems, push a platform to its limits to do innovative things, because nobody ever told the guys in sales "we can't do that" -- the assumption is, if they can dream it up, we can find a way to build it. Across town you have people who pretty much take some thick spec handed down from on high and semi-mechanically translate it into code, or just nail big chunks of enterprise framework together, and they make $20k more a year each than the first bunch of guys, and have titles like "Software Engineer III." And to recruiters and HR people, the latter group's resumes have more big-ticket buzzwords on them, so by the only metric they can work with, they appear more employable.
I have a strong opinion , and here's my standard analogy:
You hold out a wooden board to a Engineer and a Scientist. You ask them: "is this strong enough?"
The scientist would immediately talk of using some sort of laminate he had read about, or set to the task of building braces which would attach to the board to make it stronger. Then he would attach sensors to detect breaks in it, devise a monitoring unit, etc.
The engineer would simply say: "Strong enough for what?"
This is why benchmarks make very little difference and why dynamic language frameworks can compete. Your building blocks only have to fit within some allowable parameters which are always determined by the task at hand.
You hold out a wooden board to a Engineer and a Scientist. You ask them: "is this strong enough?"
The scientist would immediately talk of using some sort of laminate he had read about, or set to the task of building braces which would attach to the board to make it stronger. Then he would attach sensors to detect breaks in it, devise a monitoring unit, etc.
The engineer would simply say: "Strong enough for what?"
This is why benchmarks make very little difference and why dynamic language frameworks can compete. Your building blocks only have to fit within some allowable parameters which are always determined by the task at hand.
"If you don’t use mathematics in your day to day work, you aren’t an engineer."
Head scratch...
Nurses, cooks and baseball players all 'use math' on a day to day basis. What does that say about science and/or engineering?? Absotively, posilutely nothing.
Scientists understand. Engineers apply. Engineers ought to have the mathematical tools to test their applications but they could eschew that with real world tests without any loss of functionality (e.g. instead of deriving catenary strengths and load values via mathematics, when designing a bridge, they could just drive heavier and heavier loads over the bridge until collapse. Silly and time consuming and decidedly dangerous, but still engineering...) Engineers solve problems by creating solutions (as opposed to merely implementing solutions others have created) That's the only definition of engineer that makes sense to me
A recent article accused the MapReduce algorithm of lacking novelty, of using forty year-old ideas.
To stay with the bridge analogy: most bridges use some variant of 'algorithms' that are well in excess of 100 years old. Some of these are merely refinements of technologies that were used in the construction of the very first bridges, however many hundreds, if not thousands of years ago.
Head scratch...
Nurses, cooks and baseball players all 'use math' on a day to day basis. What does that say about science and/or engineering?? Absotively, posilutely nothing.
Scientists understand. Engineers apply. Engineers ought to have the mathematical tools to test their applications but they could eschew that with real world tests without any loss of functionality (e.g. instead of deriving catenary strengths and load values via mathematics, when designing a bridge, they could just drive heavier and heavier loads over the bridge until collapse. Silly and time consuming and decidedly dangerous, but still engineering...) Engineers solve problems by creating solutions (as opposed to merely implementing solutions others have created) That's the only definition of engineer that makes sense to me
A recent article accused the MapReduce algorithm of lacking novelty, of using forty year-old ideas.
To stay with the bridge analogy: most bridges use some variant of 'algorithms' that are well in excess of 100 years old. Some of these are merely refinements of technologies that were used in the construction of the very first bridges, however many hundreds, if not thousands of years ago.
Genetic engineers don't use any math at all, and yet they still design and build useful tools using logical rules with as much rigor as the science can muster.
"To come up with a proper treatment, doctors need to have an exact diagnosis. To have an exact diagnosis, doctors need to know exactly what is going on in the body."
This is patently false.
I refer you to Atul Gawande's "Complications: A Surgeon's Notes on an Imperfect Science". It's all about how doctors operate (no pun intended) on hunches, especially in the ER, where there often isn't enough time for a totally-conclusive diagnosis.
This is patently false.
I refer you to Atul Gawande's "Complications: A Surgeon's Notes on an Imperfect Science". It's all about how doctors operate (no pun intended) on hunches, especially in the ER, where there often isn't enough time for a totally-conclusive diagnosis.
Joe:
It is not patently false. Surgeons operating in an ER do work with imperfect information about the patient's condition.
This does not mean that ER surgeons are allowed to skip their studies. The point of the quote is that Doctors need to know a great deal about how the human body works to do their job, including making decisions in an imperfect environment.
Compare and contrast this to the typical "Mort" who clicks a fw buttons on a Visual Blub++ wizard and then copies and pastes code from a web page into their application.
Mort is also working to a deadline and has imperfect information. But he does not strive to understand programs or programming beyond the bare minimum to get the extremely short-term result he seeks.
It is not patently false. Surgeons operating in an ER do work with imperfect information about the patient's condition.
This does not mean that ER surgeons are allowed to skip their studies. The point of the quote is that Doctors need to know a great deal about how the human body works to do their job, including making decisions in an imperfect environment.
Compare and contrast this to the typical "Mort" who clicks a fw buttons on a Visual Blub++ wizard and then copies and pastes code from a web page into their application.
Mort is also working to a deadline and has imperfect information. But he does not strive to understand programs or programming beyond the bare minimum to get the extremely short-term result he seeks.
Reminds me of this novel idea some man publishing in 1865, of sending a projectile out of orbit to land people on the moon.
Brilliant idea for its, as were other Joule Verne inventions, but I guess it lost most of its luster when in 1969 some engineers managed to pull it off.
Brilliant idea for its, as were other Joule Verne inventions, but I guess it lost most of its luster when in 1969 some engineers managed to pull it off.
I think the defining characteristic of engineering is balancing tradeoffs. Better engineers have at the ready the understanding of the tradeoffs of more things at more levels.
I'd also say science is the use of the scientific method. I don't mean that tritely: I believe that's the essence of science.
Math is the relationships that exist, the language of the Creator.
True story: I was lamenting to my dad on the phone one day as I realised the following: "My whole life is going to be balancing tradeoffs, isn't it?" Not that that's a bad thing; it was just a weighty realisation.
I'd also say science is the use of the scientific method. I don't mean that tritely: I believe that's the essence of science.
Math is the relationships that exist, the language of the Creator.
True story: I was lamenting to my dad on the phone one day as I realised the following: "My whole life is going to be balancing tradeoffs, isn't it?" Not that that's a bad thing; it was just a weighty realisation.
Most of the mathematics used by software engineers is embodied in the tools they use. A type system is a mathematical object and type-checking is a mathematical procedure. Whenever you compile and run a typed program you are using mathematics.
Most of the mathematics used by software engineers is embodied in the tools they use. A type system is a mathematical object and type-checking is a mathematical procedure. Whenever you compile and run a typed program you are using mathematics.
By that argument, every computer user is a Computer Scientist. There is more to engineering than using tools.
By that argument, every computer user is a Computer Scientist. There is more to engineering than using tools.
By that argument, every computer user is a Computer Scientist.
No, computer scientists are the people who invent the mathematics that the software engineers use. And software engineers differ from computer users in that the latter don't write programs. (Maybe I shouldn't have said "run" in my previous comment. I was trying to include run-time type-checking.)
No, computer scientists are the people who invent the mathematics that the software engineers use. And software engineers differ from computer users in that the latter don't write programs. (Maybe I shouldn't have said "run" in my previous comment. I was trying to include run-time type-checking.)
I don't believe that writing a program in and of itself makes you an engineer, regardless of how much Computer Science and Mathematics went into the language and tools you use, for the same reason that using a spreadsheet tool does not make you a mathematician, scientist, or engineer even though you are "using" mathematics in a trivial sense and also writing a program in a non-trivial sense.
Further to my statement that "~p implies ~q" does not imply that "p implies q," I remind everyone that "exists x such that x ~member of E does not imply that for all x, x ~member of E."
In other words, the fact that not using math means you aren't an Engineer does not imply that using math makes you an Engineer, for whatever definition of math we agree on.
And furthermore, the statement that some people writing programs are not engaged in Engineering is not a statement that all people writing programs are not engaged in Engineering.
In other words, the fact that not using math means you aren't an Engineer does not imply that using math makes you an Engineer, for whatever definition of math we agree on.
And furthermore, the statement that some people writing programs are not engaged in Engineering is not a statement that all people writing programs are not engaged in Engineering.
I don't know who came up with this misconception that engineering implies the use of mathematics, but it is a prevalent one. In Spanish it's easier to equate the word Ingeniero to Ingenio, Engineer, like "engine"… derives from the Latin ingenium, meaning "innate quality, especially mental power, hence a clever invention" hence, an engineer, essentially, is someone who makes useful or practical inventions. [Wikipedia]. I don't know about you, but to me Software engineer is a perfectly apt title.
Who's being negative?
So there's a statement on the table: "This class of persons engaged in writing programs are not engineers."
That can only be construed as a negative if you have it in your mind that Engineering is some lofty profession above Programming.
I think this statement is interesting because it strikes at the heart of the same issue I raised when I asked a certain class of undergraduate—the kind that want easy and practical University courses—whether they want to be clerks.
What's wrong with being a clerk? Nothing. It's only a problem if deep in your heart you despise clerks and you spend your life in denial about the career you have chosen. I wouldn't wish that on anyone, so I asked my readers to think about that carefully.
Likewise, we can argue about what activities from programming can or cannot be considered Engineering. But really, even if you don't do any Engineering, what's wrong with that? As I said in the post, my own interest is in Industrial Design.
Sure, Woz is a hero of mine. But so is Gerrit Reitveld.
So there's a statement on the table: "This class of persons engaged in writing programs are not engineers."
That can only be construed as a negative if you have it in your mind that Engineering is some lofty profession above Programming.
I think this statement is interesting because it strikes at the heart of the same issue I raised when I asked a certain class of undergraduate—the kind that want easy and practical University courses—whether they want to be clerks.
What's wrong with being a clerk? Nothing. It's only a problem if deep in your heart you despise clerks and you spend your life in denial about the career you have chosen. I wouldn't wish that on anyone, so I asked my readers to think about that carefully.
Likewise, we can argue about what activities from programming can or cannot be considered Engineering. But really, even if you don't do any Engineering, what's wrong with that? As I said in the post, my own interest is in Industrial Design.
Sure, Woz is a hero of mine. But so is Gerrit Reitveld.
an engineer, essentially, is someone who makes useful or practical inventions
That waters the word down. In Ontario, at least, a Professional Engineer is much more than someone who makes useful things.
But let's say we use your definition. Then everyone is an engineer, and there's really no need for calling someone a Software Engineer. What else would they do with software? Install it?
That waters the word down. In Ontario, at least, a Professional Engineer is much more than someone who makes useful things.
But let's say we use your definition. Then everyone is an engineer, and there's really no need for calling someone a Software Engineer. What else would they do with software? Install it?
Mort is also working to a deadline and has imperfect information. But he does not strive to understand programs or programming beyond the bare minimum to get the extremely short-term result he seeks.
I don't think Mort is that different from a (quack) doctor in this case. His patient (the program) will suffer and likely die.
Actually, given the mortality rate of software projects, I wonder if we couldn't compare programming with 19th-century medicine. I recall reading that some doctors circa the American Civil War actually wrote of the beneficent effects of a "good, healthy pus".
Hey, remember when we thought Design Patterns were brilliant?
I wonder if my child will one day ask me, "Daddy, did you really use leeches to cure software?" And I will have to laugh and say yes.
I don't think Mort is that different from a (quack) doctor in this case. His patient (the program) will suffer and likely die.
Actually, given the mortality rate of software projects, I wonder if we couldn't compare programming with 19th-century medicine. I recall reading that some doctors circa the American Civil War actually wrote of the beneficent effects of a "good, healthy pus".
Hey, remember when we thought Design Patterns were brilliant?
I wonder if my child will one day ask me, "Daddy, did you really use leeches to cure software?" And I will have to laugh and say yes.
I think the term "software developer" fits better. A "software craftsman" is not an engineer IMO. Not even at Ericsson do they use the term "software engineer", just "designer".
A scientist is someone who attempts to discover new principles through experimentation.
An engineer is someone who applies proven techniques to build a product.
Outside of research institutions, few of us plow new ground by developing new algorithms or constructs (think Knuth). Most of us take a well-established toolkit and use our creativity to make something useful, fast, and attractive.
An engineer is someone who applies proven techniques to build a product.
Outside of research institutions, few of us plow new ground by developing new algorithms or constructs (think Knuth). Most of us take a well-established toolkit and use our creativity to make something useful, fast, and attractive.
We were chatting about the fact that my job title was 'software developer' whilst my fiancé's was 'software engineer' over dinner recently in the company of an engineer of the more traditional variety. We decided that the difference was that if I could make a mistake that could cause a website can break and inconvenience a few people a fair amount, if my fiancé could make a mistake that would make the internet can go down in most of the country, and the traditional engineer could make a mistake that would cause somebody could die. Obviously that doesn't extrapolate to other domains though.
Oh, and my mathematical ability is currently being wasted :-)
Oh, and my mathematical ability is currently being wasted :-)
pfft. semantics.
If you are trying to solve a problem you do not have a canned solution for then you are engineering a solution. At that moment you may as well be an engineer.
I haven't built a webapp yet that didn't include real and challenging engineering problems.
If you are trying to solve a problem you do not have a canned solution for then you are engineering a solution. At that moment you may as well be an engineer.
I haven't built a webapp yet that didn't include real and challenging engineering problems.
Don't real engineers all belong to societies and assume liability for their work? I know the term is co-opted for other uses, but underneath there is some implicit promise by an engineer to only used professional approved methods.
To me, engineering was the boring discipline full of structure and rules. Programming was the wild west, and even better, we can't be sued if our software screws up big time.
There has been a lot of talk about what programmer's do, and what they don't do, but that type of generalizing is unfair. Programming covers a huge territory. There is light weight programming such as HTML. There are many different forms of medium weight programming, including COBOL and most straight-forward Java systems. And there is heavy weight, seriously hard, math intensive programming like writing language compilers, symbolic calculators, operating systems or databases. Covering that range with sweeping statements is difficult.
Paul.
http://theprogrammersparadox.blogspot.com
To me, engineering was the boring discipline full of structure and rules. Programming was the wild west, and even better, we can't be sued if our software screws up big time.
There has been a lot of talk about what programmer's do, and what they don't do, but that type of generalizing is unfair. Programming covers a huge territory. There is light weight programming such as HTML. There are many different forms of medium weight programming, including COBOL and most straight-forward Java systems. And there is heavy weight, seriously hard, math intensive programming like writing language compilers, symbolic calculators, operating systems or databases. Covering that range with sweeping statements is difficult.
Paul.
http://theprogrammersparadox.blogspot.com
"The statement “~p implies ~q” says nothing about whether q implies p."
I think you meant "p implies q"?
"~p => ~q" and "q=>p" are logically equivalent (as Arne pointed out when I quoted this part)
I think you meant "p implies q"?
"~p => ~q" and "q=>p" are logically equivalent (as Arne pointed out when I quoted this part)
Yes, Ravi, thanks, I was in a hurry when I wrote that.
The statement "~p implies ~q" does not imply that "p implies q."
And the statement that "there exists x such that x is a member of Y and x is not a member of Z" does not imply that "for any x where x is a member of Y, x is not a member of Z."
The statement "~p implies ~q" does not imply that "p implies q."
And the statement that "there exists x such that x is a member of Y and x is not a member of Z" does not imply that "for any x where x is a member of Y, x is not a member of Z."
<< Home
