Quirky Engineers - A Follow-up - Embedded.com

Quirky Engineers – A Follow-up

Pardon me while I put my other foot in my mouth.

The embedded community that reads this site pretty overwhelmingly disliked my column about “quirky engineers.” Oddly, many of the comments (not all were posted to the net; some quite amusing speculations about my sex life seem a bit irrelevant) were quite vehement but miss my point.

I wasn't engaging in a polemic against non-conformers per se, but rather offering a true story about a non-conformer who wouldn't fit in. It was a description of quirkiness on two levels: “Tom's” physical presentation, which we were quite willing to overlook (our own sandals-and-bathing-suit dress code itself perhaps 5 sigma out from the mean) as well as his quirky work ethic. We canned him for the latter, a decision that made sense at the time and that I'd repeat today.

We should never have hired the guy. His vast knowledge of the field masked major performance issues. One reader wrote that we succumbed to the “infatuation syndrome.” We were so desperate for an engineer we overlooked serious flaws we knew were there. That was exactly the point of the article. I made a hiring mistake in trying to slot this fellow into a position that had been open too long. My hope is that by sharing the debacle with you, gentle readers, others can benefit from my error. I also collect embedded disaster stories, for the same educational reason. As a sort of embedded gadfly peering into thousands of projects, I've learned that most of us make the same sorts of mistakes; since we're largely unaware of others', though, there's no corrective feedback loop. I hope my sharing of mistakes forms the first tendrils of such a loop.

A number of readers objected to my comments that this field is changing, that projects now use teams rather than solo developers. Sure, a lot of smaller systems are built by one or two people. But a recent study shows the average embedded system has 6.8 firmware engineers (Hardware and Co-Development Tools for Embedded Systems Design , Electronics Market Forecasters). Those 6.8 people have got to find ways to work together. Just like in a marriage, personal habits are an important part of a functioning team. Attendance — virtually or physically, in hours that work for everyone — is critical. Hygiene counts, too.

You don't have to like teams, but it's impossible to ignore this facet of our changing field. A major drive in software engineering is to find ways to build big systems in a reliable manner, and every new approach (eXtreme Programming being the hottest lately) emphasizes people working together. One person — even a guru — can't build a box with a million lines of code in a reasonable time.

Fifty-one percent of the 324 people who voted do feel that the “quirky genius” is a necessary component of firmware engineering. Almost the same number felt otherwise.

We're clearly very divided about this. If you or your colleagues cannot or will not work in teams, plenty of smaller projects still require solo skills. But as the software component of embedded systems grows, as it has by several orders of magnitude in the last 20 years, fewer such opportunities will appear. That's a fact. Whether this is a good or an evil trend is a very different subject.

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at . His website is .

Reader Feedback

Personally, I do two jobs within 2 companies owned by the same company AT THE SAME TIME – which means that when you are doing one job, someone higher up than you in the other company comes along and assumes that because you are doing your other job, you must be short of work and piles more work onto you. I'm not complaining about that though – my point is that so many people in my parent company have 2 job titles, that when people get sacked, their work just gets shifted to the rest of us – as the MDs say 'there's someone to do that' and we end up trying to do 3 or 4 people's jobs in the same time! It's so annoying. Several of the engineers here have jumped ship – I would jump for joy if my parent company hired Freddy Kruger at the moment, as long as he's got a work ethic.

Linton Rapid

I think your points about fitting each member into a team are valid. About a year ago, I was working on a project for another company. The project was moving very slowly, in part because of personality issues. We were extremely fortunate to add a lady to our team who, though not a the top coder, had a genius for getting us all to “play nice”. We made up a large chunk of the time we had lost, though we did not succeed completely.My point is that sometimes a social genius can advance technical project faster than a software genius.

Fred Glauner
NSC Software Engineer
@Track Communications

Well, I read both of your “quirky engineer” articles and I guess Idon't see what the huff'n and puff'n is all about! The fact ofthe matter is that as we progress in technology, more and morefunctionality can be put into smaller and smaller devices. The resultis that one “box” is doing a lot more than it used to do, so that onebox has a lot more code associated with it. Now if you equate thebox to a development project, that means you have more developersassigned to the box; hence, a need for teamwork.For any of us that have been in the industry for more than a yearor two, we know that almost anywhere you go, the definition of the”team” is similar, and the members fall into one of three categories:

  1. The majority of folk are average and carry their weight.
  2. A small percentage of folks just don't put out. Some lack skill and or drive, others have a chip on their shoulder.
  3. The remaining few are the ones that do most of the hard work, and some of that work is at 3AM.

It appears that a major percentage of the readers of the first “quirky”article equated “Tom” with category 3, and felt like you were puttingthose folks down. I suppose your final comments on “teamwork” werewhat put a lot of folks over the edge!I would put Tom in category 2. A bright guy who is at a point in hiscareer where he thinks he can just ride on the “coattails” of hisearlieraccomplishments. These folks are probably the most dangerous to hire.They talk you right into thinking they are the next Einstein (and theyjust might be); but they do very little real work. Yea, I agree thatit's always good to have a “guru” on staff, but when that guru knowsit, that's when the trouble starts! I've worked with some really sharpfolks over the years and I gotta tell you that it can be ultimatepleasureor ultimate pain. In the end, a little humility on their part (to dealwith us “normal” folk) can make a project go a lot smoother!

Good reading your column as always!

Ed Sutter

You're absolutely correct about teamwork being an important consideration inan employee. Some people feel that good programming skills are all thatmatter. That's simply not true, at least not usually.

Back in the mid 80s I was the only engineer supporting the software of aproduct, but I still had to work with the hardware, packaging, EMI andproject teams. I spent more time working with them to try and solve productproblems than just coding software. Of course, that product was later init's life cycle.

Products early in their life cycle don't have 1-man teams. I haven't been ona team with less than 10 engineers in a long time.

A few years ago I worked on a program that had some very good engineers, butseveral of them were clearly “prima donnas”. They refused to do some tasks(it must be unreasonable to expect someone to verify their software in thetarget hardware), refused to let others get involved with softwaredevelopment in “their domain” and would not listen to different ideas on howto implement or verify a design.

Being able to work with people is every bit as important as good programmingskills. I think most people can accept different cultures and some”quirkiness”, but when you're hard to work with or refuse to listen to otherpeople on you're simply not worth the trouble. Not only does it affect yourproduction, it sets a bad example for others. Why should they be teamplayers and take on assignments they don't like when they see tolerance forothers who don't do anything they don't like?

Each job has its own needed skills, but one that's universal is being ableto work with others. I'm sure there's still a place for the isolateddeveloper in some places, but it's very limited. A person who doesn't workwell with a team should expect that he'll be paid less for his skills thanif he did . It's not unfair; it's simply lacking one of the needed skills.

Bob Weber

I personally think that you are right on. I have worked with a few of these. I am now in management because the atmosphere at this company has taken on a more professional feel. In the past is seems that if someone appeared to write code and that code appeared to work, everyone was happy. Unfortunately I have found that those appearances were deceiving. I now have to figure out how to get some of these messes fixed.

Not only did they not write good code they did not document. Some documented some of the assemble code with comments that were a more verbose form of the mnemonics. While there aresome very intelligent people out there it is not possible for them to write code. They are thinkers not code writers. I think that this is a very important fact to realize. Also some of the engineers seem to feel that if someone knows what they are doing somehow they no longer have any job security. What then happens is they get tired of working on the product, which they designed so that no one else could work on it, but they can not be taken off because no one else can figure it out. They then quit.

I call these engineers renegades. They do not want to conform because they feel that they must have total control to maintain job security. I think that they believe this to be true, but I feel that the real reason is if anyone figured out that they were just hacking out code they would get fired. Most of these products work like a major operating system that we use that works most of the time but when stressed or if someone does something a little different it malfunctions. Of course the malfunction is different each time so no one can quite figure out what is wrong.

Some of the engineers claim that designing and reviews stunt their creativity. To those I say take your undisciplined creativity to a product I will not be relying on. The real design engineer, note design, will use his/her creativity in the design stages not wait until it does not work when testing starts. I guess I couldgo on with this for a couple of more pages, but I have found that real design engineers appreciate the team and the input on how their software can be made better. The lone wolf may eat well but they always leave a mess behind.

David Heppner

I read your article quirky engineer.I am very sad that the engineer could not perform.But you are right we are all in business and that needs dedication & hence achievement from every employee.I think your recruitment methods should be able to find technical capabilities and hence right person for the vacant position, rather than blaming on employee.what i mean to say is your technical tests carried out while recruiting the person may not be right.


I thought both your “Quirky Engineers” articles were excellent.

I'm amazed at how people who added feedback missed your point on occasion. How one looks (and other things) is very important to an individualistic person, however I don't think that was what the article was about.

We don't work in a vacuum. We have to work with others, and when you do, offending others makes it harder to get work done. I've felt for a long time that the “Lone cowboy hero” is not a healthy person, because I believe we were made to work together. It is possible to do something in an inneficient way, but that does not make it the best way.

Some times it's better to have the design done inside one head because it is easier to make more efficient use of hardware and software resources, but that person still has to interface with people who simply know things the other cannot. Either because it's not their strength, or not their job function.

I think that one of your points you made in your article is very true:

The world of programming is changing, and like all eventualities,programmers will have to get used to it, or get run over. But what did we expect?, not much in our century is static.

True programmer geniuses however will always be able to program well. Not taking time to fit in where you work is simply a stupid thing to do. If you are a genius, you will realize that doing the actual job is only part of your job, getting along with others and making sure they know what you are doing, and why they pay you the big money is the other.

If you are really good, then your ability to be good will not be fragile, and you will be able to be good in whatever situation you find yourself in, whether in a suit or a bathing suit.

As an individualistic person, I am not worried about losing my identity by making sure I can work with others. I can't help but be different, it's who I am.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.