Are Programmers Engineers?(ericsink.com)
ericsink.com
Are Programmers Engineers?
http://www.ericsink.com/Are_Programmers_Engineers.html
23 comments
This is the worst article I have ever read regarding programmers vs engineers
Almost all of that is a load of horse shit.
> Engineers are required. Programmers are optional. > To be an engineer, you have to be licensed.
No, if you want to work for the 'public good' (doing city works, verifying things that people will be using inside their body or their failure could kill someone) then you need to be licensed. An Electrical engineer does not have to be licensed.
> Engineers work for a living. Programmers do what they love to do.
No.
> Engineers generally don't do that. Teenagers don't design bridges in their spare time and then decide to pursue civil engineering as a career. Engineers always think of their job as their profession, because that's all it has ever been.
Hell yes they do [1]
> Engineering is well-understood. Programmers have no idea what they're doing.
What in the hell? Why do you think businesses have massive R&D budgets? It's because engineering is uncertain, you never know something is going to work until you try it. If you aren't failing, you aren't trying. With both professions (or hobbies).
> Engineering is real. Programming is abstract.
To an extent. This is actually kind of a complicated one, when I sit down and do the PCB layout for something, it's nothing more than programming. It's laying out logical structures in a certain order that allow me to dump part of my brain out onto a computer screen.
Programming is real in that there is interaction with humans, you can have a theory, verify or nullify it, optimize it. The same abstract structures of engineering are there, but more often then not the target stays imaginary.
If I program something in OpenSCAD, then I print it, I was programming something real. The question is not in where it comes from, it's where it goes. The final state of the problem is where it lies, sometimes engineering is abstract, and sometimes programming is real.
[1] http://www.pisymphony.com/toothpick/toothpick12.jpg
EDIT: Just so I don't come off as a (huge) jerk, and so I have something nice to say (offset the bad with a good), I encourage the author (if present) to go out and try engineering. Break out of the programming shell and test your conceptions about the world, see if they turn into misconceptions or stay true.
> Engineers are required. Programmers are optional. > To be an engineer, you have to be licensed.
No, if you want to work for the 'public good' (doing city works, verifying things that people will be using inside their body or their failure could kill someone) then you need to be licensed. An Electrical engineer does not have to be licensed.
> Engineers work for a living. Programmers do what they love to do.
No.
> Engineers generally don't do that. Teenagers don't design bridges in their spare time and then decide to pursue civil engineering as a career. Engineers always think of their job as their profession, because that's all it has ever been.
Hell yes they do [1]
> Engineering is well-understood. Programmers have no idea what they're doing.
What in the hell? Why do you think businesses have massive R&D budgets? It's because engineering is uncertain, you never know something is going to work until you try it. If you aren't failing, you aren't trying. With both professions (or hobbies).
> Engineering is real. Programming is abstract.
To an extent. This is actually kind of a complicated one, when I sit down and do the PCB layout for something, it's nothing more than programming. It's laying out logical structures in a certain order that allow me to dump part of my brain out onto a computer screen.
Programming is real in that there is interaction with humans, you can have a theory, verify or nullify it, optimize it. The same abstract structures of engineering are there, but more often then not the target stays imaginary.
If I program something in OpenSCAD, then I print it, I was programming something real. The question is not in where it comes from, it's where it goes. The final state of the problem is where it lies, sometimes engineering is abstract, and sometimes programming is real.
[1] http://www.pisymphony.com/toothpick/toothpick12.jpg
EDIT: Just so I don't come off as a (huge) jerk, and so I have something nice to say (offset the bad with a good), I encourage the author (if present) to go out and try engineering. Break out of the programming shell and test your conceptions about the world, see if they turn into misconceptions or stay true.
My brother, a successful (good pay, high responsibility, prevents things from blowing up) mechanical engineer, doesn't really understand programming beyond html basics.
Talking about how we both go about doing time estimates once, he said, "you know, I never really thought about it, but you're paid to do things that haven't been done before"
Talking about how we both go about doing time estimates once, he said, "you know, I never really thought about it, but you're paid to do things that haven't been done before"
I was going to say pretty much the same thing, as it turns out there is a 'professional' Data Processing exam as well but few programmers take it, just like few of the engineers designing tech have a PE certification. Out of all the engineers at Intel when I joined in the way back time, the only ones who had PE after their names were the ones doing certifications (UL, FCC, EMI, etc).
That said, programming shares a lot of characteristics with 'art.' I expect that a large number of programmers have no 'process' to go from requirements to running code, rather they sit down and start coding until it works.
Interestingly enough this bit me when getting my first performance review at Intel, I was charged with writing a driver for a new graphics chip and since the chip had a little RISC engine on it for doing things like bitblt I wrote a mini-assembler, compiler, and linker to compile graphics operations. My manager marked me down for 'sand bagging' and when I inquired what he meant he explained that he had observed me sitting around, reading usenet, and basically goofing off for three months and then I sat down and wrote all the software less than a month. He complained that rather than bullshit about how long it was going to take to write I should have just written it and used the other three months to do work. Of course what ensued was me trying to explain that for 3 months I was trying to figure out how it needed to be written and then once that was all known actually writing it was trivial.
What I took away from that was that HW engineering had great milestones for things like circuit design, PCB layout, first films, first boards, design verification, manufacturing verification, production. But software only had, uuhhhhh, blam here it is.
I related that story to a friend who introduced me to a sculpture artist. She had the same 'process' except she would look at a rock for a month and then one weekend chip off all the parts of the rock that weren't part of the sculpture, but she had to 'see' it first before she could start chipping. Art. Not engineering.
That said, programming shares a lot of characteristics with 'art.' I expect that a large number of programmers have no 'process' to go from requirements to running code, rather they sit down and start coding until it works.
Interestingly enough this bit me when getting my first performance review at Intel, I was charged with writing a driver for a new graphics chip and since the chip had a little RISC engine on it for doing things like bitblt I wrote a mini-assembler, compiler, and linker to compile graphics operations. My manager marked me down for 'sand bagging' and when I inquired what he meant he explained that he had observed me sitting around, reading usenet, and basically goofing off for three months and then I sat down and wrote all the software less than a month. He complained that rather than bullshit about how long it was going to take to write I should have just written it and used the other three months to do work. Of course what ensued was me trying to explain that for 3 months I was trying to figure out how it needed to be written and then once that was all known actually writing it was trivial.
What I took away from that was that HW engineering had great milestones for things like circuit design, PCB layout, first films, first boards, design verification, manufacturing verification, production. But software only had, uuhhhhh, blam here it is.
I related that story to a friend who introduced me to a sculpture artist. She had the same 'process' except she would look at a rock for a month and then one weekend chip off all the parts of the rock that weren't part of the sculpture, but she had to 'see' it first before she could start chipping. Art. Not engineering.
Still though, you are comparing your experience to the whole of all programmers. Engineering itself has the characteristics of 'art'. There is still an unknown aspect to designing and developing a product even if you use a schematic or have a sane workflow.
What you and the author are speaking of is some of the unconventional aspects of programming, which come along with the drastic growth the field is going through.
What you and the author are speaking of is some of the unconventional aspects of programming, which come along with the drastic growth the field is going through.
The article is complete baloney. I worked for 3 years as a mechanical engineer for Boeing, so I know about the field. Heck, he's spectacularly wrong, especially about one point - engineers do love what they're doing. Yes, I fiddled about designing and building mechanical things as a kid (gas gokart, hot rods, electronics projects, chemistry things, etc.) and I'm hardly alone among engineers I went to college with. The main thing limiting me was lack of money and lack of fabrication skills. The first time I had access to a machine shop I tried to build a steam engine. I would have designed and built my own airplane if I had more than a few dollars to my name.
The real difference between an engineer and a technician (or programmer) is the engineer knows calculus. They'll often be doing the same work, but the engineer knows calculus and uses it, the technician applies rules of thumb.
The real difference between an engineer and a technician (or programmer) is the engineer knows calculus. They'll often be doing the same work, but the engineer knows calculus and uses it, the technician applies rules of thumb.
[deleted]
I don't know how else to put it: this is wrong. Engineering is the practical application of science to create something with utility. Building a bridge is to physics as programming is to computer science. Programmers don't typically invent new algorithms and data structures to solve a problem. They apply a novel combination of known techniques to achieve a balance of quality and cost-effectiveness. My favourite quotation:
'Anyone can build a bridge that stands, it takes and engineer to build a bridge that barely stands'
You can write code in your basement for fun. You can also build your own house. Because you can do something doesn't mean you can do it well, nor that you can do it efficiently. Engineers are particularly concerned with the latter.
Computer science is the exploratory, scientific component of the equation. CS designs and quantifies new algorithms and data structures. With the rigorous understanding computer scientists develop, an engineer can evaluate the cost-effectiveness of a given solution. A basement coder may be applying known techniques, or they may be experimenting. Whether they're trying to gain knowledge or solve a problem seems to largely define whether the task is science or engineering.
Almost every point here addresses barriers to entry, which are a modern, and certainly not integral, component of engineering. Yes, becoming a licensed engineer is hard. But engineering isn't the act of 'doing things while being a professional engineer'. It is the systematic application of engineering principles, which anyone can use. While they are using them they are, to my mind, an engineer.
'Anyone can build a bridge that stands, it takes and engineer to build a bridge that barely stands'
You can write code in your basement for fun. You can also build your own house. Because you can do something doesn't mean you can do it well, nor that you can do it efficiently. Engineers are particularly concerned with the latter.
Computer science is the exploratory, scientific component of the equation. CS designs and quantifies new algorithms and data structures. With the rigorous understanding computer scientists develop, an engineer can evaluate the cost-effectiveness of a given solution. A basement coder may be applying known techniques, or they may be experimenting. Whether they're trying to gain knowledge or solve a problem seems to largely define whether the task is science or engineering.
Almost every point here addresses barriers to entry, which are a modern, and certainly not integral, component of engineering. Yes, becoming a licensed engineer is hard. But engineering isn't the act of 'doing things while being a professional engineer'. It is the systematic application of engineering principles, which anyone can use. While they are using them they are, to my mind, an engineer.
[deleted]
This question comes up a lot. My latest formulation is that programming has elements of a all sorts of disciplines: science (debugging is often about making and then testing hypotheses), engineering, mathematics, design, art, but can't entirely be encapsulated by any of these. I usually call it a craft: "an activity involving skill in making things by hand" but like everything, this definition only partially applies (eg, the "by hand" bit).
I also like the Hunt/Thomas formulation of programming as gardening: http://www.artima.com/intv/garden.html
That nicely captures the often improvisational nature of things.
I also like the Hunt/Thomas formulation of programming as gardening: http://www.artima.com/intv/garden.html
That nicely captures the often improvisational nature of things.
Most of the arguments are BS, but so far I found the following the stupidiest thing I've ever heard about this topic:
> When our finally product is built, it requires no manufacturing. It is merely a string of bytes. Theoretically, a monkey sitting at the keyboard might accidentally of typed the same string. The product we build cannot be touched or held. It will be worthless in just a few years.
A phone can be touched and held and yet it's also worthless in a few years. More worthless than f.ex. fly by wire software which will still work on aircrafts in those few years. Or ECU. Or gearboxes. Or microwaves. Most applications of various device firmware and machine operations software is legacy and guess what - it works. And contrary to material and moving parts, which must be replaced even if they work flawlessly, software can theoretically outlive it without any updates because it doesn't wear out.
Also, applying the infinite monkey theorem won't get you anywhere, ever.
> When our finally product is built, it requires no manufacturing. It is merely a string of bytes. Theoretically, a monkey sitting at the keyboard might accidentally of typed the same string. The product we build cannot be touched or held. It will be worthless in just a few years.
A phone can be touched and held and yet it's also worthless in a few years. More worthless than f.ex. fly by wire software which will still work on aircrafts in those few years. Or ECU. Or gearboxes. Or microwaves. Most applications of various device firmware and machine operations software is legacy and guess what - it works. And contrary to material and moving parts, which must be replaced even if they work flawlessly, software can theoretically outlive it without any updates because it doesn't wear out.
Also, applying the infinite monkey theorem won't get you anywhere, ever.
Ugh... This article was hard to read.
I'd say software architecture is closer to engineering than programming (aka coding).
But ya...not too much difference given the complexity of the SDKs these days.
But ya...not too much difference given the complexity of the SDKs these days.
Programmers are self employed engineers (but not limited too...)
Engineers at job tend to use Java, C++ in their projects.
Engineers at home tend to use anything they like.... From Haskell to Brainfuck. Even all the interesting softwares were born from the minds of The-engineers-at-home, ie the programmers. Example is Linux, Git.....
Engineers at home tend to use anything they like.... From Haskell to Brainfuck. Even all the interesting softwares were born from the minds of The-engineers-at-home, ie the programmers. Example is Linux, Git.....
Some of those titles really come across as an engineer taking potshots at programmers. Seems very passive-aggressive to me.
Wow. That was a load of crap. Engineering looks dull. Please check out whats going on in the technology/art community. I would say that compared to that, version control looks a bit dull.
There is something called 'hacker' culture... Any comments?
My father is a software engineer. I am proud of him. The problem is.... His boss is not an engineer.
One chapter from “Professional Software Development” by Steve McConnell is directly related to this question.
And there is no answer, moreother, I think Software Engineering is still somewhere near the “handcrafting” (if compare with Real Engineering).
And there is no answer, moreother, I think Software Engineering is still somewhere near the “handcrafting” (if compare with Real Engineering).
I'm pretty sure a lot of engineers have "designed bridges" in their free time as a teenager before they realized they wanted to be an engineer. Hell I did a huge amount of hardware tinkering for both legal and illegal reasons when I was in highschool. Build various phreaking boxes, tesla coils, radio frequency overiding devices, and all sorts of other crap. I could have either became an electrical engineer or a programmer, but I chose the latter cause it's really what I love to do.