The METNAV shop at McGuire AFB was hard to miss, if you could get into the right area, and you know what you were looking for. Out across the flightline, across the old 18 runway, and across a winding series of roads, a small squat building sat — no antennas or other identifying marks. Just plain, white, one story, with a small parking lot and a few trucks, either camouflaged or USAF blue. Driving into the parking lot, you’d find an odd collection of vehicles, but many of us drove 4wd’s of some sort. A good number of the pieces of equipment we worked on were only reachable through off road routes. If you owned a 4wd vehicle, the fateful pager call at 2am didn’t require a trip to the shop, across the flight line, old runways, and in the winter piles of snow pushed up against the sides of the airplane routes, to get a truck usable to reach the failed piece of equipment.
In the line of cars, you would see one that was, well, different. This particular car was, in fact, the subject of a number of discussions in the shop — you’d almost think our little group of Airmen was a collegiate debating society the way we went on about this particular car. No, in case you’re wondering, it wasn’t mine — I switched to a Jeep early in my life, and have been driving them ever since.
What was the discussion about? The point of being different. The young man who owned this car had purchased it not because of the way it looked — it wasn’t particularly attractive. It hadn’t been purchased for its engine, which was nothing spectacular. The vehicle in question had won one award from an out of the way 4wd magazine, a point of pride for the owner, but it still didn’t hold a candle to many of the other 4wd vehicles owned by various folks, or to the Hummer or the 8080 that sat in front of the shop from time to time. The color wasn’t particularly nice, the stereo wasn’t all that great, it couldn’t beat any of the sports cars that various folks drove — in short, there wasn’t anything particularly unique about this particular car.
Except that it was, in fact, unique. The owner of this vehicle, when questioned, answered that he had purchased that particular brand and model for one specific reason: because no-one else on base had one. It’s uniqueness was the point.
This answer occasioned long discussions in the shop, with statements like, “I like being different — in fact, being different is what makes me happy.” Or, “but can’t you see that by defining happiness as being different, you’re actually allowing people to define your happiness the same as if you said being the same is what makes you happy?” Round and round we went — and in the end, I don’t think anyone really “won.”
This long, winding, foray into the world of a METNAV engineer has a purpose, of course. The point is this: being different, or being the same, is no great shakes. The technology world seems to insist on one of the two paradigms — be different, or be like everyone else. Companies, for instance, will often ask me what everyone else is doing in a particular area (well, what is everyone else doing for an overlay in their data center?). As if doing what everyone else is doing somehow reduces your chance of failure. Other people have tested it, so we’re less likely to find a bug, right? Sorry to tell you this, but — wrong. Broad based usage may, or may not, be a sign of clean code. As an example, desktop operating systems are widely used, and yet they still have bugs.
From individual engineers, you often encounter the opposite sentiment — I want to be different for the sake of being different. Like the kid with the car, they’re concerned with doing what other people aren’t. They’re building special snowflakes, well, because they can, or because they somehow think it makes them hard to replace, or some such. In the end, though, there’s nothing quite so uniform as a bunch of people trying to be different — variety carries it’s own sort of boredom after a while.
If focusing on doing what everyone else is doing is wrong, and focusing on doing what everyone else isn’t doesn’t work either, what should we focus on?
What about just getting the job done? What about choosing the right product, the right design, the right idea, the right technology, just because it happens to produce the best results with the least effort, and the least complexity?
As engineers, we need to practice the art of not paying attention to what other people are doing beyond a few basic points. Will the vendor likely be in business in five years? Will the solution be something I can hire someone to work on (if the system requires a unique set of skills or special training, don’t do it)? Do I really need something new, or can I solve this with something I already have? But, most of all, will it work, will allow the company to grow, and will it solve the problem at hand?
We need to stop asking if it’s different, and remember to ask if it will work.