Over a million developers have joined DZone.

Putting People in Boxes

DZone's Guide to

Putting People in Boxes

· Big Data Zone ·
Free Resource

Hortonworks Sandbox for HDP and HDF is your chance to get started on learning, developing, testing and trying out new features. Each download comes preconfigured with interactive tutorials, sample data and developments from the Apache community.

When I was in high school I had a conversation with a singer, a man with an incredible range. I was sitting at a piano, and he demonstrated that he could sing notes well below the bass clef. Then he said “Not bad for a tenor, huh?”

That struck me as bizarre. He was obviously a bass, but he called himself a tenor. Or rather, he was capable of singing bass. He was capable of singing tenor as well. But you don’t usually call someone a tenor and a bass. Singers fit into four boxes: soprano, alto, tenor, and bass. Maybe you subdivide the boxes, such as first and second tenor, but you only get to pick one box.

We all tend to put people in boxes, but the urge is particularly strong with children and bureaucrats: children because they have a limited view of the world, and bureaucrats because, well, pretty much the same reason.

Imagine this singer trying out for a choir. Suppose he’s given a form to check which part he sings and he checks both bass and tenor. A director might ask what he means, and respond “Great, we can put you on different parts depending on what we need.” But an audition coordinator might say “Look, Mack. Don’t try to be funny or imagine that you’re some unique snowflake. Which part do you sing?”

It’s not that hard to explain that you can sing two voice parts. Other combinations of abilities are harder to explain. Here’s an example from an earlier post:

Take an expert programmer back in time 100 years. What are his skills? Maybe he’s pretty good at math. He has good general problem solving skills, especially logic. He has dabbled a little in linguistics, physics, psychology, business, and art. He has an interesting assortment of knowledge, but he’s not a master of any recognized trade.

If you’re a programmer but there isn’t a box for programmer, you have to pick another box, but you might not fare well by the evaluation criteria of that box.

Not fitting into traditional categories makes you stand out, for better or for worse. It can make you highly valued. It can also make you a thorn in an administrator’s side, or simply someone to be ignored.

James Scott uses the term illegible for people who don’t fit into boxes. Venkat Rao summarizes the idea in the glossary of his blog. His summary is a bit dense, but it’s worth reading carefully.

A system is legible if it is comprehensible to a calculative-rational observer looking to optimize the system from the point of view of narrow utilitarian concerns and eliminate other phenomenology. It is illegible if it serves many functions and purposes in complex ways, such that no single participant can easily comprehend the whole. The terms were coined by James Scott in Seeing Like a State. Illegible systems are generally more robust than legible ones, and Scott’s model is mainly about the failures caused by imposing legibility on an initially illegible reality.

I’d like to hear the terms legible and illegible more widely used. I’ve had conversations withDaniel Lemire, for example, where he would use one of these terms and immediately clarify a discussion.

Hortonworks Community Connection (HCC) is an online collaboration destination for developers, DevOps, customers and partners to get answers to questions, collaborate on technical articles and share code examples from GitHub.  Join the discussion.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}