Mappers Vs Packers

Mapping is the kind of learning you do when, after you pick up some information, you sit and think about it in an effort to simplify the way you think about it (i.e., simplify your mental map). Mappers are the world's great thinkers: they are the inventors, the scientists, those who think and control.

Packing is like mapping in that you collect information, but differs from mapping in that you don't have any particular desire to simplify your mental map. Packers are the world's great storehouses of memory: they are the storytellers, the historians, those who memorize and repeat.

Circumstances decide whether mappers and packers mesh efficiently or grind each other away. They can work together to produce greater civilization, or they can clash and tear civilization apart.

As an offshoot of ReciprocalityTheory, this may be a point of useful discussion.

See BigPicture. (or not)

I equate MappersVsPackers with MyersBriggs Type Indicator personality theory's iNtuitivesVsSensors. -- JayPetersen

What is a Mapper? What is a Packer?

Explaining here would require summarising in a significant chunk of the ProgrammersStone, so the best answer is "try reading that".

: (A classic piece of Packer thinking :)
: Well I walked into that one, didn't I? But it's true, I haven't finished reading the thing so I suppose what I should really have said is, "I've not yet constructed my map, so go build your own instead of asking for mine."

Basically they are people who use two different ways of learning. This can cause some conflict between them.

Oh good, another BinaryDivision. How does this relate to the HedgehogAndFox idea?

Oh, it's not just another binary division, it's Yet Another one of those divisions where one class is superior to the other. The mappers are of course, the creative thinkers, the real pioneers of thought, while the packers are just rote-thinking drudges. The categories exist, of course, to create a sense of belonging in order to make the book appear to be speaking from shared wisdom that outsiders "just don't get"... pretty standard manipulation, really. At least Meyers-Briggs (which I also think is pure drivel) at least attempts to avoid value judgements.

I get the sense that the author of ProgrammersStone doesn't believe that Packing is really a natural state, rather that it is a result of suppressing the normal Mapping.

Agreed. More to the point, what he calls a packer is someone who prefers following consensus instead of learning, and after learning anything refuses to really analyze it. Many of them are also hostile to non-packers. Unfortunately many of the institutions of modern life encourage this sort of thing.

Hmm. So a Packer is what I call a StampCollector and a Mapper is what I call a ModelMaker. Yes?

Sounds right, assuming that I understand what you mean by StampCollector and ModelMaker.

A packer is someone who doesn't want to risk losing an important piece of information. If you are willing to ReFactor your thoughts, then you're a mapper. Mappers do their refactoring in the background, which is why they sometimes do their best creative work when their conscious mind is distracted. (Driving, doing manual work, etc) -- MikeWarot

At this time, I see that some packing is necessary before you can begin mapping. You need to be a part-time StampCollector, else you will have nothing to map. If you take your map from someone else? Well that doesn't sound much like mapping.

>>If you take your map from someone else?..... then it is packing

If you are willing to ReFactor your thoughts, it would be wise to have packed away some UnitTests first! But your mapper-nature will do this for you, while you (literally) CleanTheKitchen. -- MatthewAstley

Relationship to HedgehogAndFox

Having not read the Hedgehog and Fox book, but based on the description of it here (i.e. I'm on a limb here, folks), here I try to contrast and compare:

Hedgehogs build a single GrandConcept?, and try to use it to explain everything. i.e. "History is a conflict between capital and labor."
Foxes create facts - "Foxes think it's perfectly reasonable to spend one's life lovingly describing new species of beetles."
Mappers consume facts, trying to build a more accurate map of the world in their heads, refactoring out the bits that prove to be incorrect. Coherency of the model is very important to them.
Packers collect facts, and do lots of pattern matching in their application. They value coherency in application.

So, the ideas are similar, but not equivalent, from my initial read of it.

In contrast, Mapper == ModelMaker, Packer == StampCollector, as far as I can tell. -- MikeWarot

There was something called the ProgrammersStone that had this discussion about mappers and packers. I read it and was enlightened. I am definitely a mapper. My wife is definitely a packer. (Please don't take advantage of my ignorance of popular jargon!)

Of course, everyone uses both methods, but they usually rely on one more than the other--like being left or right handed.

I've occasionally talked about this to folks whose general intelligence seem to be greater than mine (a depressing large majority of those I meet) and have discovered that they are really good at both and don't allow one method to become dominant.

-- BobBockholt

@MikeWarot:

> * Mappers consume facts, trying to build a more accurate map of the world in their heads, refactoring out the bits that prove to be incorrect. Coherency of the model is very important to them.

While I agree that removing the parts of the model that are incorrect is important to mappers, refactoring is not "removing". It is changing part or all of the model to achieve at least one of the following goals:

Decrease size of model (represent the same facts with fewer "rules")
Increase coverage of the facts achieved by the model (represent more facts with the the same number of different "rules")

This model maintenance tends to allow a Mapper to anticipate more of the world that has not yet been encountered while not falling into fixed/immutable patterns of "prejudice". I wonder what the distributions of Mappers / Packers is at various ages. I suspect that as one ages, the tendency is to shift along the spectrum from Mapper to Packer...

The text of Programmers' stone does not do very well at defining but there are many references to how Mappers and Packers act and think and some of their techniques.

There is a potential communication barrier between the mappers and packers, as packers often involve themselves in stress economies, they are stressed and try to stress others, getting a kind of fix. They can't stop it just like that, perhaps that could happen in retreats or during meditation therapies. Maping is also a method of acquiring maps, so mappers do not need to pack to gain some maps to start off with. Knowledge acquisition comes naturally and one keeps a child-eye-view or regains it to become a mapper.

Mappers predominantly adopt the cognitive strategy of populating and integrating mental maps, then reading off the solution to any particular problem. They quickly find methods for achieving their objectives by consulting their maps.

Packers ways of memorization by rote would not avail them the even deeper maps gained by mapping. This is 'solved' by packing more people into the group sharing the knowledge packet bucket and engaging in unfettered groupthink. Packers are habit-seekers and tend to solve problems by referring to past decisions. Packers are averse to novelty since that robs them of the usual habit based behaviors and decisions based on habit.

[http://en.wikipedia.org/wiki/Who_Moved_My_Cheese Who moved my cheese?] is another similar division and goes along the lines of many cognitive research studies.

I grok it this way:

Mappers use their experiences to write additional Unit Tests. They use TDD, and adjust their model until their tests pass (possibly adding more detail to the tests in the process). They are happiest when the code needed is small, and will mentally refactor to optimize that. They are willing to "cut", or at least reduce the precision of, scenarios (unit tests) they consider low priority if they are blocking a useful refactoring.
Packers use their experiences to write additional rules in their Prolog program. They therefor excel at exact scenario repetition, and can incorporate information much quicker than a mapper (who needs to find the right place in the model to put it). Conflicting rules are handled by removing the oldest (or some similar strategy), not by attempting to unify or distinguish them.

-- ScottMcMurray

Scott, while you may be correct I actually interpreted the two categories in the opposite way: not in the psychology processes of mappers and packers, but in what technology would be best paired with each type. That is to say, I think you describe well how mappers would do TDD, and how packers would use logic programming, but neither would have chosen those respective techniques had they been given the choice. As an example, when a packer encounters an error, they simply fix that error add another test case to their code to cover it. A mapper on the other hand, will look for patterns in the errors they have encountered and try to eliminate a class of them either at compile time (through types) or at runtime (via a logic-constraint system). Essentially, mappers are looking for the underlying principle behind their defects, but tests (by this I mean black-box testing, which I consider to be the only QA activity which can without contention be called "testing" without possible equivocation with other QA concepts) don't really provide a means for reasoning about how the different errors relate. By this I mean two things, 1) it is impossible to know if any two sets of tests cover the same code behavior unless the two sets are identical, and 2) Any given test suite could be a valid test for a potentially infinite number of distinct functions which have nothing to do with the requirements. The only way to reason is this way reason with universal quantification. Of course, it is much more difficult to make the kinds of generalizations mappers like to make about their system. The only solution is to simplify (re-factor) the code, which requires exposing the actual structure of the code, which types and constraint logic do. --ross anderson

Another comment about Scott's explanation, I think this quote is interesting "[Packers] therefor excel at exact scenario repetition, and can incorporate information much quicker than a mapper (who needs to find the right place in the model to put it)." I think its interesting because I know someone who often comes to much quicker conclusions than I do, especially about where to put physical objects in a space. It could be that she is a packer and I am a mapper, but the correlation with MBTI's (iNtuitive/Sensing) distinction suggests that we are both mappers. If this is the case then I have two alternate suggestions: 1) as a MTBI (Feeling) type, she is much more likely to act upon a conclusion after it is arrived at by her synthetic thought processes (since it is often enough correct anyway) whereas I am an MTBI (Thinking) type, and must analyze any conclusion reached by my synthetic thought processes using my analytic thought processes to be sure I am actually correct; or 2) I simply have focused my mapping on other subjects in which I am more trained and specialized. --ross anderson

Instead of splitting everyone into two camps (almost always an oversimplification), I prefer to think of them as different ends of a spectrum. Everyone falls somewhere on that spectrum. You may tend more toward Mapper or Packer, but no one is a perfect example of either of them.

It's not that one is inherently "better" than the other. It's that one is inherently better suited to certain career choices than the other. Mappers tend to do better in technical fields. Packers tend to do better in business management and law. IMHO, technical stuff is more frequently governed by physics and mathematics while business and law are man-made. When a programmer (typically a Mapper) tries to automate part of a business process, they are frequently frustrated by the the fact that corner cases abound, frequently because of how different people (usually Packers) do things or because of how rules/laws (largely created by Packers) are structured. Trying to distill all of these things down to one or two unified processes drives the business people nuts. I've seen that in my own, professional life.

As you may have guessed, I tend toward the Mapper end of the scale. This is consistent with working in a technical career. Mappers tend to excel at grokking large, inter-related complex systems. They tend to expect that everything correlates, interrelates and interacts and they try to create "grand, unified theories of <whatever>" from the correlations. They see nothing wrong with spending boatloads of money on fundamental research, trying to fill in part of the overall map of how things work. Will that research result in something which benefits us (mankind, or themselves)? Maybe, maybe not. But the exploration and the resulting understanding is worth it. If you don't know how it works, how can you ever know what can and cannot be accomplished? I gotta know HOW it works. Part of the map is unexplored, and I just gotta know what's there. Research is exploration. And Mappers are all about exploration, seeing how this connects to and influences that.

Packers prefer to hold onto small "packets" of information, which they can apply to larger scenarios, but they have no expectation that these packets interconnect or interact. They tend not to try to interconnect them. They tend to prefer "good and evil," "black and white," "do and don't." They can't understand why anyone would want to plunk outrageous sums of money sending probes to other planets or smashing atoms together when people are having a hard time finding a job or putting food on the table. If it doesn't directly result in something which benefits us (mankind, or themselves), why are we spending money on it?

They are not without reasoning skills, but they tend to prefer to keep things simple. Spending money on development = new products. New products = profits. Profits = good. Therefore, spending money on development = good. Spending money on research = low probability that we'll get a new product out of it in the foreseeable future. Therefore, spending money on research = bad.

Mappers tend to look at it differently. Spending money on development = new products in the near term. Spending money on research = new knowledge and potentially new products in the longer term. Money in the near term is desirable, but knowledge and money in the long term is also desirable. Let's make some money in the near term and spend some significant fraction of it on research. We make less money this quarter, but we, potentially, have more quarters of growth.

In my experience, Packers tend to think shorter term and Mappers tend to think longer term, both for business and in politics. Feel free to correct me if you've seen otherwise.

Most people start off as Packers, but only some of them take those packets of information and try to correlate them, becoming Mappers to some degree or another. Most kids go through a "why?" stage in their life. A Mapper parent will likely help them develop into Mappers as well. A Packer parent, who can't give them answers to "why?" is more likely to result in them never seeing interactions between the packets, with a high probability that they will become Packers as well. If some of the political news in Texas is any indication, they tend to get upset when their kids are exposed to Mappers at school and trend toward becoming Mappers, themselves.

Benjamin Franklin was a Mapper who could also speak Packer. "A stitch in time saves nine" and "an ounce of prevention is worth a pound of cure" were both penned by him, intended for a predominately Packer audience. Statements like those are PRECISELY what Packers seek. Simple, easy to remember, resulting in useful decisions and behaviors. This, from the same man who flew a kite in a thunderstorm, got shocked, and theorized that the force that did that was the same force that allowed him to electrocute a turkey with a couple Leyden Jars (early capacitor-type devices). Mapper, in the extreme. But capable of rephrasing his understanding in ways that Packers could comprehend.

In my experience, the majority of people tend more toward Packer than Mapper. I don't know if that was true in the past, but that appears to be the case today. --Meower68

CategoryComparisons