Programmer or Engineer?

Programmer or Engineer?

What's the difference?

By: David K. Every adapted from 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)

 

Which do you need?

So which one (programmers or engineers) you need depends on the task. Ideally, you have a balance in a project; with a few engineers doing the architectural design of a project and giving some guidance and avoiding problems (and demanding documentation) -- and a few programmers, that are sent off in directions (under the control of engineers) to implement like crazy, and tenaciously solve the problems as they arise. Programmers are often spirited horses than need an experienced rider (Engineer) to control and guide them -- but once they are pointed in the right direction, man can they run. Engineers are often not the biggest code producers (quantity), or best debuggers -- they prefer to design out problems (and code) in the first place. The Engineers will be screaming "design, document, implement". The programmers will be screaming, "Stop talking about it! Lets CODE! CODE! CODE!".

You can imagine that it is hard to find individuals of one type that can tolerate the other type (or rarer to find people that are a good balance of both) -- it's sorta like congress. But if you do balance them, the results can be the best of both worlds. Sadly most companies don't have a balance. They get a leader of one type (or the other), who sees no value in the opposing style -- and so they drive all those that don't think like them out. Or more common, the company has no clue about the the differences and doesn't care -- so politics allows the same thing to happen. The results of either extreme can be ugly; however, too many engineers are just slow(er), too many programmers can kill a company or a product.

Startups and small companies often favor the hackers/programmers. These guys slap something together (quickly), and try to sell it. It often works (barely) so it sells in the first incarnation. Then they slap a few more features on, and it still sells. Then the lead-programmer leaves (they get bored doing the same thing for more than 2 years), and the project spirals into code-hell. No one can maintain the project, and the company won't invest the money to "redesign it". So they flounder around, trying to squash bugs, and every feature they add (or bug they fix) creates new bugs. They spend ten times the money (and time) trying to fix things as they did developing it in the first place, and they wont spend the time or money to do it right. If these companies are a sinking ship; they will hire bodies to bail water, yet they won't fix the leaks. Most companies are in this programmer-heavy mode -- and most will not engineer their way out (because they don't understand engineering). Instead, companies try to buy their way out of problems (with bodies) and hide the symptom, instead of allowing the product (and problems) to be fixed, which is usually getting some engineers and creating some process (and curing the disease).

The opposite of that extreme is companies that favor all engineers -- like Aerospace, Govt., some big Corporations. Of course part of that is because of the risks (and that many lives often hand in the balance of their designs). These guys design, document, argue, refine, go back to the start, over-engineer the heck out of something, and create something that would be a great product -- but will take 10 years to create. They process things to death, and require 27 forms to be filled out to use the restroom. That product will have wonderful architecture, that can last into the next century -- and they'll generate enough documentation to kill a forest, and the product will be so over-done that it will take 5 extra years before the computing-horsepower will catch up (or the price of computers comes down enough) so that the product will actually be viable. But these products often have a far longer life span, and can grow for a long time. Unless they were designed by a committee -- and then they will be as functional as a 2-legged table. Not to mention the fact that all the engineers in the world can not compensate for bad (stupid) requirements -- which causes a lot of friction between engineers and marketing (since both think they have all the answers, and neither do).

The Industry

Apple and Microsoft were "hacker" heavy in the 70's and 80's (though they got better over time). IBM was more the "over-engineering" strategy. It used to be joked that IBM's process consisted of "Ready.. Aim...Aim... Aim... Aim...", where as Apples' process was "Fire, Aim, Ready?" Microsoft would do neither, preferring to watch other marksmen shoot first - then they would just shoot the marksman with the best score, and then take credit for their work.

Some companies use a strategy that I call it "design by acquisition". Since they can't do it "right" themselves (because they don't understand engineering), they just buy-up whoever is beating them at the time, and then market the heck out of those products. They make half-hearted attempts to "fix things" on products that they have acquired, but often they only make subsequent versions worse and worse (more features and more bugs). Symantec and Novell have done this a few times. Many "market leaders" use this strategy as a way to compensate for the fact that they forgot what made them the leader in the first place -- so they just try to hang-on to their positions (so that Sr. Management can get their performance bonuses) without really gaining or losing market share -- but they seldom succeed for long. Usually, someone more adept comes along and "eats their lunch".
In general, I find most game companies (and most startups) are too hacker heavy (but that is changing). Aerospace is way too engineering heavy (compounded by bureaucracy). Big Business (Fortune500) is all over the place, but is usually mired in process, with politics (and who is doing what to whom) dictating one extreme or the other. Commercial Software is a little programmer heavy (but varies by company). BioMed was the best balance I've seen (but it may have just been the companies I dealt with). Companies all vary, and they vary over time (first making mistakes in one extreme and then the next) -- and it is rare to find a good balance, but it can exist in any industry.

The Conclusion

Remember, in the world, you often get what you pay for (and what you ask for).

If you want a hot-shot kid that can slap a together code for you in no time -- and they will do exactly that. You will pay for that decision for years (in maintenance) -- but you get a product in a fraction of the time.

If you put in the money and the time (and engineers), to design a product right, then you get something that will carry you far into the future -- but you have to hope that your competitors don't beat you to the punch (with hot-shot kids), and you need to make sure that you aren't trying to OVER-solve problems (and waste time/money).

The best of both worlds is to mix and match well. Put hot-shots on the short term stuff -- and then use that time advantage to do things right. (Parallel development). Or you can put both on the same projects (if they work well together) -- and have the engineers controlling the programmers (if they can do so without squashing them). Balance the two on projects so that the hot-shots are driving the engineers to implement faster, and the Engineers are slowing the programmers down (so that they realize what the long-term costs are for many of their decisions, minimize the risks, and so they can document as they go). Maturity and drive. Sometimes you can find individuals that are a good balance of both -- most people have their strengths and weaknesses and lean to one side or the other. Either way, understanding the differences and drives are the first step to making the right decisions. Hopefully this article gave you a better understanding of those things better.