Engineering, like many human activities, requires as much team work as it does knowledge, skill, and experience. The following is a list of destructive stereotypes which people fall into when engineering. Each of them is primarily identified with a "down side" which categorizes its detrimental effects. However, each one is lasted with an "up side" which often includes a justification or a potential pitfall which would occur if no one ever displayed this characteristic.

In reality, most people have a little bit of each of these stereotypes within them, and it is a constant exercise to suppress the negative effects and amplify the positives. Frequently, people see these characteristics in their co-workers yet fail to see it in themselves. I find that it is useful to give each characteristic a name so that they can be talked about and referenced when they arise in yourself or in others.

Following the list of personal stereotypes is a list of engineering syndromes. These are ailments which afflict a good design yet are notoriously difficult to diagnose, for which I offer no solution!

Down Side: Discredits ideas before they’ve been fully explained. Has a complete fear of the unknown or is so religious about previous design experience that they won't try anything new. Their favorite phrase is: "That’ll never work."

Up Side: Many ideas, in fact, won’t ever work. People with great experience often know that a particular solution won’t work, but can't explain why – they "just know it". The less experienced team members become frustrated by the apparent lack of rationality and resent being shut-up, but they may be thankful later.

Down Side: This person has a lower threshold for speaking. While one person is articulating an idea that they've been thinking about for a day, the interrupter yells "Wait! I've got an idea!" and then they proceed to pull a piece of crap out of their ass and sculpt it into something hideous while everyone waits.

Up Side: These people often have good ideas and occasionally do a big favor by bringing focus to a rambling brainstorm.

Down Side: This person fails to see the fundamental limiting factor of the design. When they see a difficult constraint they attempt to circumvent it by changing the problem. Their favorite phrase starts: "If only...":; "If only this portable stereo didn't have to run on batteries."; "If only we didn't have to go so fast to get into orbit."

Up Side: In some situations, the very best solution is to change the problem. If one person thinks that the problem should be changed but others don't then there is probably a lack of clarity in the design assumptions which needs to be rectified.

Down Side: Continually breaks everyone’s concentration by cracking jokes or making fun of the situation, especially the users of the product.

Up Side: Comic relief is always welcome in small doses. And of course, making fun of sales, marketing, accounting, and lawyers is always welcome!

Down Side: Fails to help when they are clearly needed. After walking a mile, they fail to go the extra inch to finish the job. Their favorite phrases are: "That’s not my problem." and "That's not a bug, its a feature!"

Up Side: At least they don’t fight back when you knock them over.

Down Side: Prevents the rest of the team to contributing. During design, they fail to share any expertise. During implementation they insist on specifying the details of everything.

Up Side: There is a correlation between good engineers and "hogs". The best engineers often recognize their own superiority and do their best to get the optimal solution, and end up looking like hogs. (Things go very bad when someone thinks they are better than they really are yet acts like a hog.) In some situations, the hog actually trains everyone else how to do the job.

Down Side: Their favorite phrase is: "If we'd just done it my way, we wouldn't be having this problem." They remember who made the early design decisions that went wrong and "forget" the warnings that others posted about things that ultimately went wrong in their own system. They can quote someone’s exact words when it’s in their favor and "forget" the instructions that they didn’t agree with.

Up Side: A whole team of selective memorizers never lets anyone weasel out. But even then, they will probably drive each other crazy.

Down Side: Once their part of the problem is solved, they abandon everyone else. This is very common during testing when they have no bugs left and they could at least be acting as QA but instead start playing games or leaving early.

Up Side: Being exhausted is understandable. "Meditating" by playing a game or doing something else that isn’t thinking about the problem improves their ability to fix their own bugs and improves endurance.

Down Side: These people love to point out facts which just don't help things such as the observation that time is passing. For example: "Oh my god! We’ve already worked on this for 20 minutes!"

Up Side: Sometimes everyone has lost track of progress and needs to be reminded that any solution is better than no solution.

Down Side: These people try to reengineer things after tons of testing has been completed. Their favorite phrase is: "This is so ugly its going to break." despite the fact that all testing shows that it isn't. They inevitably introduce more problems than they fix.

Up Side: They may be right, they see a failure that hasn’t been tested. (The right response to this is to have it tested as opposed to preemptively fixing it). They may be saving time in the long run if the product is going to be reused for many generations and fixing it now saves "backward compatibility" hacks in the future.

Down Side: These engineers hobble a system together quickly that barely solves the problem. Often the entire problem is not yet fully understood and yet they act like their overly specific solution is actually a general one. Time expense is shifted to later in the project when the early solution has to be ripped out and replaced. These early solutions often create a false sense of progress, especially to those outside of the project (sales & marketing for example) which can have extremely high collateral costs.

Up Side: Quick prototypes are invaluable for analysis, but shouldn’t be confused with the final product.

Down Side: Creates incredibly complex solutions to simple problems. This is often due to a lack of experience or a resistance to research.

Up Side: Some problems only have complex solutions. Often a simple solution appears possible but turns out to be a mirage only after significant work has been done. Some complex-looking systems are in fact simple due to extra systems that are glued on such as user interface.

Down Side: Loves to apply polish to unfinished projects. They spend time making something look pretty (i.e. putting on the pinstripes) before the product is working. The polish inevitably "rubs off" and must be reapplied several times before the project is complete.

Up Side: Keeping a project looking good keeps everyone excited about it. This is especially valuable for maintaining the excitement of sales, marketing, and investors types.

Down Side: The opposite of The Prototype Pinstriper, these people are only interested in the overall feel of the solution and lose interest when the details have to get done.

Up Side: Experience often creates Rough Cutters because the "details" are frequently the same on every project and the seasoned engineers lose interest in the solved wheel. The experienced engineer’s time can be more efficiently used on the next project instead of the details of the last.

Down Side: These people believe that there is one way, the way, that every problem must be solved. As far as the Holy Warrior is concerned, there are no unsolved problems there are only engineers that don’t know the solutions.

Up Side: Is often justified by experience. May prevent "reinvent the wheel syndrome" and expensive escapades by less experienced team members.

a.k.a: In Software Engineering: "It’s in the libraries"

Thanks to: Scott Cronce

Down Side: These people believe that all which can not be seen is magic. When queried about the operating principle of a critical component they respond: "It’s magic." Another favorite phrase is "I don’t know how it works, and I don’t want to know." The most destructive aspect of the Magician’s Apprentice is that they refuse to diagnose any problem which might reveal the inner workings less they find out that it isn’t magic after all.

Up Side: At least they aren’t reinventing the wheel.

Down Side: A solution is constructed (perhaps at great cost) and it just doesn’t work, yet no one will admit it. In the worst case, the team spends more time modifying the solution than they would have if they had just admitted it was flawed and started over again.

Up Side: Occasionally one last little hack will indeed fix it. At least a lot can be learned from the failures.

Down Side: A perfectly functional but "ugly" solution has been built. The team can’t stand the looks of it and wants to change it for fuzzy reasons which boil down to "its ugly and I hate it."

Up Side: The team intuitively knows that the solution is a dead end. They know that they are in "stuck in a rut syndrome" but can’t explain why.

a.k.a: More than one way to skin a cat.

Down Side: A hundred different tools are available to help solve a problem, but the team becomes focused on only a few. After a while, they forget that the others even exist. They will attempt to modify one tool when another already exists which does a better job.

Up Side: A solution which requires fewer tools is often more desirable and easier to maintain in the long run if it is possible.

a.k.a: Not Invented Here Syndrome

Down Side: The team refuses to reuse an existing solution. They waste time and may create an even worse solution.

Up Side: Unless you build something from scratch, you don’t really know how it works. The team may be much more productive at problem diagnosis later because they spent the time to really learn the problem early by reinventing the wheel.

a.k.a. In software engineering "syntaxophilia".

Thanks to: Jim Mischel for his original contribution of "syntaxophilia".

Down Side: Engineers love tools. They often rationalize their work as a way to get to play with the newest coolest tools. Often, new tools are solutions without problems and suffers of this syndrome go looking for problems to justify their cool new tools.

Up Side: Practice makes perfect and one can’t know how to apply a new technique without trying it first. Also, this syndrome is associated with self-education which may far outweigh the cost of the syndrome.