Programmer or Engineer?

What's the difference?     By: David K. Every For the whole story browse to http://www.igeek.com/  

 

Some people call themselves "Programmers" and others call themselves "Software Engineers". "Engineer" seems to have more prestige in our society, so more people try to call themselves Engineers (even if they aren't). Of course anybody can call themselves whatever they want -- so what people call themselves makes little difference; however, there is a distinct difference between the two.

In order to explain the differences, I have to caricaturize both to the extreme -- to contrast them. Realize that most people are a combination of both attributes -- but you can at least get some ideas on what to look for, if you know the extremes.

There are needs for both (engineers and programmers) - and different tasks require more of one or the other. Most tasks require only a few engineers and quite a few programmers. The problem is that many managers don't understand the difference, or hire the wrong ones for a job.

Programming is not hard - it is tedious. You need to be able to break complex things down, into a long series of simple steps. That is it. How you approach that problem will define whether you are a programmer or an engineer. So the biggest difference between the two is philosophical -- and like most philosophical differences, it can lead to tension. Arrogant types (on either side) can get into these little ego-driven superiority complexes that drive the other side nuts, and some pretend that the "others" are idiots. They aren't idiots -- they just have different goals, different motivations, and different philosophies.

Engineers are more experienced (mature (1)) than programmers (especially in software and design theory ), but that doesn't mean that they are who you need for a task (or that they are always better). Engineers are the "designers", the ones that have been around for years and understand lots of different concepts, or understand some specialties really well. Most of an engineers knowledge is NOT applicable to the task at hand directly, but they draw on their experience and education to solve major projects -- all while avoiding pitfalls. (In complex systems there are many pitfalls, and some can cost projects "years" and millions of dollars).

(1) Don't confuse age with maturity -- many people never grow up. Just because a guy is a 50 year old coder / programmer, doesn't mean he grew past the "hacker" phase - and there are quite a few 20 year old engineers. So look at their personality and philosophy, as well as their experience and education, to figure out which they are likely to be.

Engineers are the ones that want to (or at least understand the need to) design, document, create processes and procedures to avoid future problems. They want take a project from conception to completion (with all the steps in between). They tend to be more "anal" types, who want to focus on the details (in engineering the devil is in the details). Engineers are often more academics (will to do more research before attacking a problems). Engineers will know how to set schedules, and follow them. Inexperienced engineers greatest flaw is that they will sometimes "over-engineer" a solution, and try to solve things that may never be real problems (they will spend time and money solving issues that won't be a real problem for a decade, and then the technology or company goals will have changed enough that it wouldn't have been a problem anyway). Engineers are also the ones that slow a project down in the early phases (spending more time on research, design, analysis, documentation, and debate) in order to avoid potential pitfalls (and save time and money) in the later stages of a project. This is great for long term project costs (and you do get the time/money back) -- but we have a lot of short-term thinkers in society (and business). Engineers are the mature "plodders" who will get a project done and avoid surprises (by thinking them all out before they start) -- and they make sure that its design and documentation is such that a project will be maintainable. Long-term goals (thinkers) -- they do "useless" things like put in automated test code, create "coding standards", or want to do code-reviews (which often turn out to be good ideas in the long run). Most of the surprises (and costs) in software development is because there weren't enough engineers (or they weren't good enough engineers), or people weren't listening to them.

Programmers are more the down and dirty types. They used to be called "hackers", but that now has a new meaning (2). Now days they are more likely to refer to themselves as Coders or Code-Jockeys. Programmers don't have to know everything first, they just enjoy the thrill of solving the problems as they come. They are more the eccentric artists of the computer world. They often spend days without sleep and living on junk food and Mountain Dew, just "doing" -- Go, Go, Go! Of course, they often spend those weeks solving problems that have been solved before (if they had just read a book and researched the issues before hand) -- but sometimes (occasionally) they solve problems in whole new (and ingenuous) ways (and better than the canned solutions), or they solve problems that have never been solved before. They are the impetuous youths of the world -- that used energy and vigor to try compensate for a lack of experience and design (and they succeed). They don't know what they can't do, so they sometimes do the impossible.

(2) Hacking used to mean (in the 70's and early 80's) programmers who would dive into a problem (without documentation or a full understanding of the problem, etc.) and just program their way out. Not much thought went design (because they could think and implement faster than they could design). They didn't need "no stinking manuals", they didn't do documentation (the code was self-explanatory), they just solved problems their own way. However, that name took on a different connotation when many people with this "hacking" personality, started using that persistence to break security, or to figure out how to violate the phone company in 16 different ways. (This brute force thinking is great for breaking security). Now "hackers" refers to that small sub-set of hackers that are often doing criminal acts, like hacking into places (instead of hacking code).

Programmers will dive into something before they fully understand the ramifications, and will often cost companies lots of money because of that lack of experience (understanding), and the "mistakes" or wasted energy. Engineers like to say "Work smart, not hard". Many programmers love programming so much that they will work harder, just because they enjoy programming and don't like the other stuff (designing, documenting, supporting, adding in test code, marketing, corporate politics, most of humanity, etc.). Programmers don't tend to like schedules (those are for bean counters), and they will promise the world (and find out later than they can't deliver, or will kill themselves trying to deliver). The quality of their results is all over the board (from crappy to superb, often with elements of both) -- but usually, their products are usable, but maintainable only by them. When programmers leave a company that is programmer heavy (and they do), or they go on to the next new thing (which is always more exciting than what they are doing), it cost a fortune to ever fix or change that "old" product again (since no one understands what the hell is going on in their code, and there is no documentation or design to help). posted at the geek's blog