4 ms·
I know that there are semantic differences between "Software Engineer" and "Computer Programmer", but they seem really insignificant to me. I'm curious how they
by viggity 15y ago
I know that there are semantic differences between "Software Engineer" and "Computer Programmer", but they seem really insignificant to me. I'm curious how they differentiate the two. How does HN differentiate them?
I've always just thought of "Software Engineer" as someone who takes their profession more seriously, but it is more of a self-applied label than anything else.
- viggity 15y agosome googling came up with these links: http://stackoverflow.com/questions/27516/whats-the-difference-between-programmer-and-software-engineer http://stackoverflow.com/questions/27516/whats-the-differenc... http://en.wikipedia.org/wiki/Programmer http://en.wikipedia.org/wiki/Programmer
- bostonpete 15y agoI think the long and short of it is that in some countries, there's a significant difference, in the US there's not -- at least not a significant difference that's well-known/understood. The fact that they appear as different professions in a time magazine poll is a bit absurd.
- ashchristopher 15y agoIn Canada, part of the distinction is that Software Engineers are real (with a ring) engineers. A lot of their education is in engineering principles - same classes as Electrical, Mechanical and Computer engineers. I know in the states Software Engineer describes most developers. How many Twitter engineers are actual engineers? Exactly.
- prodigal_erik 15y agoDoes that mean Canadian software engineers are required to study stuff like statics and dynamics and metallurgy, wasting time on mechanical failure modes that are utterly irrelevant in software?
- ashchristopher 15y agoYes to statics and dynamics.
- HeyLaughingBoy 15y agoFor the most part, the general public doesn't differentiate. Within the industry, the common expectation is that "Engineering" means that some sort of repeatable process is being applied to control the quality of the output. In real life what that should mean is that at every step of the life cycle, you know what has to be done next, or you know where to look it up. Customer reports a bug on release 12.4.1 of the software? There's a procedure that says what you do to record it, how to decide if it's a bug; how to decide if/when it's fixed, etc. Boss asks why the customer saw the bug if he's spending so much money on extra testers? You have output documents that show the Test Plan for that release, the results of all Test Cases that were run. You can show that the reason no test cases found the bug is that the customer was working in an area that had no real requirements, so was never properly designed, so the designs weren't reviewed and the code was just the programmer's best guess and since there was no requirement, the testers didn't think to test that area. How do you keep it from happening again? Your process has some kind of Continuous Improvement baked in so you can capture mistakes made and fix the procedures that caused them. Lather, rinse, repeat, automate. That's Engineering in a very small nutshell. Most shops can't be bothered, but for an increasing percentage, it makes sense.