In online parlance, IANAL stands for “I Am Not A Lawyer” and usually precedes some free and probably erroneous legal advice. Recently, I've had the phrase IANABS in my mind. That is, I Am Not A Brain Surgeon.

 Well, for one thing, I'm not a brain surgeon—or any kind of surgeon, for that matter. I'm not known for my manual dexterity so letting me cut on you would probably be a bad idea. But its more than just that. Suppose you were a hospital administrator and you needed to hire a brain surgeon. I don't know (because I'm also not a hospital administrator) but I suspect you'd try to locate candidates who call themselves brain surgeons and not spend time interviewing – much less hiring – podiatrists, thoracic surgeons, and orthopedic specialists.

As engineers, I'm not sure we classify ourselves far enough. Sure, the distinctions are obvious to us. But maybe they aren't as clear to the people who sign our paychecks. I'm an electrical engineer, for example. But so are the guy at the power company. If I learned something about delta and wye transformers, I've forgotten it. If you want to design a substation, I'm probably not your guy.

What would a reasonable ontology of software developers look like? It seems like what divisions we do have are pretty arbitrary. He's a C++ guy or she knows Linux. Those are only a little better than nothing. You can write a lot of different things in C++, Linux, Java, or Windows. I also hear a lot about “embedded developers.” But the truth is, I see people who specialize in big multi-blade x86 vehicle controls systems being lumped in with people who cram functions into 8 bit chips so the whole system costs less than a buck. Is that really the same skill?

The impact a mistake in hiring makes can be considerable. I spent many years as a consultant so I've seen the gamut of companies from those that I thought were on the ball to those who... well, let's just say those who had room for improvement.

I've noticed that one basic distinction among developers is that some people are better tool builders and some are better tool users. I am much more productive building tools and I don't do well building systems for their own sake (which might explain why I've written a bunch of compilers and more than one operating system). For some people, all that is “overhead” and they get excited about what the system will “do.” They just want to consume tools. That's great – we need each other. But my point is, it is a different mind set.

Does one title “embedded developer” really mean anything? Should we invent new categories? For example, microcontroller developer, embedded PC developer, and physical computing developer all come to mind. Yes, many of us are versatile enough to do more than one of these things (and if you aren't, a few years of consulting will cure that). But I can't help but think that better specificity in titles would lead to happier employees and employers.