SloppyThoughts

Implied Odds

One of the things I've learned from playing poker is that players who display sophistication, subtlety, and nuance are frequently viewed as inept by players who lack these qualities.

For instance, if I'm chasing the nut flush, and my only adversary in the hand is someone who rarely protects their hand prior to the river, and never believes when their opponent makes a hand and will always call a big bet after the river, it may be worth my while to call a $500 bet with the expectation that I'll be able to acquire 5 times that amount if I do hit. In poker parlance, the odds you calculate with the expectation that you will make that amount in the end are the "implied odds", and it appears to be a concept well beyond your typical, casual player. If you can put up with being called a "donkey", or worse, it's frequently well worth the risk and effort.

Comparable situations can pop up in business. For instance, suppose you construct a demo to facilitate sales that describes the process you utilize to provide a set of services. The typical, unsophisticated reaction is to make every effort to keep your competitors from getting their hands on that demo.

But let's consider an alternative ... what are your competitors going to do if they get it?

Well, they're going to analyze your business process and poke holes in it when they're competing on a sale. Which you should already have done yourselves, so you can easily innoculate your prospects and make your competitors look foolish in their efforts. Furthermore, your prospects get to wonder why your competitors aren't open about their processes, and what exactly they're hiding, and your competitors now have to fight back against the perception of being untrustworthy. You also encourage your competitors to chase you, so while you're enhancing your own value, they're trying to match you (as I've mentioned before, exceptional companies pursue values; struggling companies pursue competitors.)

So which would you rather be ... obvious, or go for subtlety and the implied odds?

Big Tobacco

I once heard a CEO say, after the most recent in a series of layoffs, that “we’ve got a healthy company, now.”

A little clue for all the other CEOs out there: never, ever say something like that.

True, half the people will blithely nod and say, “Yep, we surely do,” grateful that they were able to keep their jobs, if for only a little while longer. Their families are still supported, they don’t have to deal with the relationship turmoil of less money coming into a marriage, and they don’t have to see what the job market is like. They’ll be pleased that their stock options for which they put in all that past effort are still good and vesting if the real goal of the layoffs was to make an IPO more feasible.

Unfortunately, a portion of the people will actually evaluate the adjective. Do you actually have a healthy company? A more accurate metaphor might possibly be that you have a lung cancer patient, fresh out of surgery, looking forward to a term of chemotherapy, hoping desperately to live long enough to see his daughter married. And they'll figure this out.

There will be two themes in this group of people … those pensively waiting to see if the cancer has metastasized, and those wondering when upper management is going to quit their 3-pack-a-day habit. These are not the mental states you want to cultivate in your "healthy" company.

Don't choose your metaphors frivolously.

Risk and Foresight

The route I take to enter my office building takes me down a hallway dominated by a Montessori pre-school. I mention that it's a Montessori school because those tend to be selected by parents who recognize that the level and quality of thinking provided by the public school system is inadequate.

There's a bulletin board in the hallway. On that board they put notices. One of the notices, not too long ago, was a request that parents not park in the fire lane when dropping off their children (which they do by accompanying their child inside, so it's not an "I'm stopped, run on out, Junior" situation.)

Think about this ... for the sake of a few seconds of convenience, these parents elected to set a precedent of parking in the fire lane. Fire lanes are areas set aside for emergency crews in the case of, for instance, fire. Parking in fire lanes increases the risk that the students in the school will be harmed or die. Their own parents did this.

Be aware of what actions you may be doing carelessly or frivolously that, when done by other people or larger numbers of people, might increase risk to you and those you value. Take particular care in what you teach those who look to you for their example of how to behave.

Analysis and Accomplishment

Scientific American has an article out on the expert mind, which I found on a blog post here. Just a few quick comments on both articles...

Be sure to make a distinction between the mental tools of knowledge and those of analysis. Most people focus on the former, but it's the latter that make you expert, if for no other reason than the fact that the results of analysis themselves become knowledge, usually of a more useful nature (abstractions, relationships, etc.)

The article asserts that "success builds on success, because each accomplishment can strengthen a child's motivation." The phrasing of this statement makes it sound like speculation based on observation, not science. In my experience, it is more likely that the mental and physical tools that have been so well trained to accomplish one task find other tasks requiring similar techniques to be less difficult. If the difficulty reduces while the reward increases, you have motivation. Risk/effort -> reward analysis.

The case of D.H, who improved his chess skill by acquiring the knowledge of chess positions and associated strategies, but who did not exhibit additional analytical skills, is worth noting. This is a useful technique, and can be advantageous to a degree. An analogous situation in the IT world would be the definition of programming patterns ... defined techniques used to solve a particular large-scale problem. It's useful to have programmers on staff who know their patterns. However, don't ever mistake them for analysts. When the problems get particularly difficult, you want someone around who can define new patterns or not be limited in their creativity to what fits into a particular structure.

With regard to the chunking theory, please keep in mind your math theory lessons. A symbol can be viewed as equivalent to a function. Also, a symbol for a function can look exactly like the function. A collection of chess pieces in a particular pattern is not merely the data being stored in your head, but is also the visual, spacial, sequential, whatever pattern being used as the referent. Nifty thing ... a manipulated pattern of the knowledge resulting in a new pattern can then be used as a referent for another pattern.

I Have a Question

I just picked up Mind Performance Hacks. It looks promising, so far, although I’ve just skimmed it. I did see one section, however, that concerned me. It was the section on asking questions.

The author mentions that the construction of conceptual units is the goal of learning. He provides anecdotal evidence (from Surely You're Joking, Mr. Feynman!) about the failure to ask questions in an educational scenario. He properly refers to the data processing limit of retaining 5-11 individual items (sometimes called the Crow Epistemology, referring to the fact that birds can deal with individual numbers up to a certain point, after which individual numbers become “several”) at one time in short-term memory. And then he suggests that the problem is a failure, mostly through fear, of asking questions.

And there is my problem. If you happen to be in second grade, you might still be fortunate enough to be dealing with simple, self-contained concepts that can be constructed merely by moving items from short-term directly into long-term memory. Those of us who have lost our fear of cooties, however, have a little more work to do.

All those concepts you’re building don’t exist in a vacuum. Everyone has a framework in which they are constructed, not just of other concepts, results of evaluation and classification, description of concept relationships and causal effects, but even the fundamental understanding of the relationship between reality and the concepts that represent it. Fitting a new idea into all that takes good technique tailored to individual learning style, practice, persistence, constant effort (so as not to have failed to incorporate new information upon which subsequent information is dependent), a great ability to evaluate the nature of an item (e.g., is it an abstract applicable to a class of items?), foresight (is that the complete set of information?), and a willingness to re-evaluate and correct old knowledge.

Ignoring all the other things that the public school system fails entirely to teach, even in an ideal situation, this process takes time. So if you want a person to be able to reasonably ask questions during a presentation, a presenter of information has to facilitate the process.

For instance, plan on two sessions … three would be better, if at all possible. For each session, first present an outline of what will be discussed. This is not an outline to guide your presentation … this is a structure the audience will use to organize the information, determine if there is no more information coming on a particular item (in which case it’s time to ask questions of perceived deficiencies), understand internal and external relationships, etc. Also, define the scope of the discussion.

The first session should present the basic concept or set of concepts. Be thorough. Point out items that can be considered classifications and properties of classes, abstractions, assumptions, etc. Now stop. Integration takes time, and if you keep going you’ll trample on the stuff they’re trying to process, or they’ll dump it all in an effort to keep listening to new information (those who are well trained may be able to continue this process later from their notes.)

The second session should be a very quick recap of the previous session (to drag it all back into memory … information retrieval takes practice, and you should give them at least one effort to do so before they hit testing time, or whatever the equivalent might be in other situations) and a call for questions. No more questions? Start the second session … relationships to other concepts, implications, causality, etc. Don’t do abstractions here … associate your information as tightly to concretes as possible. This is the time in, for example, physics class, to perform your demonstrations. Now stop. Give them a break. Come back, either later in this session or in a third session and, again, review and ask for questions.

This is what the mind needs.

There are time constraints. There are subject constraints (such as pumping as much information into teenage skulls as possible in 9 months.) There are training and conceptual precedence limitations on the part of students and audience. But the principles still hold. So, evaluate what the constraints will be on a presentation and audience, and figure out how to achieve the same effect with your limitations.

Be sure to think outside the box. For example, I was speaking with a Chinese teacher recently. She told me that the Chinese teachers go to each student’s house in the summer to talk with the student and parents in order to learn and evaluate, among other things, what they’ve done over the summer. She then tailors her lessons accordingly. I don’t know of any American teacher who would do such a thing, even if the government permitted her to alter her lesson plans significantly. An analogous situation … if you have to make a presentation to a bunch of programmers in your office, you might consider setting aside 5 minutes for each developer ahead of time to get an idea of their current understanding of the subject.

What else could you do? How would you apply these techniques to self-directed learning?

Design and Ambiguity

Eide Neurolearnings has an article on “ambiguity” and how developing minds deal with it. I disagree with many of their implications (for instance, that the difficulty children have in dealing with ambiguity is a discrepancy between the development of the reasoning and communicating abilities), not to mention the very … err … ambiguous use of the term, “ambiguity” in each of the associated articles.

So I will limit myself to discussing ambiguity in brainstorming.

There’s no such thing.

Oh, fine, I’ll elaborate.

This referenced article describes the tolerance of ambiguity as “the ability to live in a universe where there are no right or wrong answers, where ideas or thoughts are vague and yet unformed.” These are two very different things. The former phrase is an assertion that, epistemologically, concepts have little or no relation to reality and, therefore, can not be used to determine truth or validity in relation to reality (alternatively, it could just be embracement of the same old tired subjective reality beliefs … yawn.) The latter phrase, on the other hand, is useful ... a statement that concepts can be incomplete. In other words, a statement of “insufficient data”.

What does this mean for us in a design situation … how do we minimize ambiguity, identify it, resolve it, and keep it from causing problems in our projects? (Note that this is not an exhaustive list … I don’t describe, for instance, the things that must be done in the process of mapping abstracts to concretes.)

1. Thoroughly define your context.
2. Identify constraints (typically concretes, so be aware of how these are reflected abstractly.)
3. Take measures to know what you know about every concept (attributes, intrinsic behavior, relationships, classifications, and methods of interaction), both in terms of completeness and confidence.
4. Take measures to know what you don’t know, both in terms of requirements to accomplish the specified goal as well as deficiencies implied by context, interaction, relationship, and      methods of implementation.
5. Figure out if the things you don’t know are relevant to the individual step in the chain of reasoning.
6. Figure out if a later reasoned step mitigates a lack of information in a former step.
7. Describe the efforts necessary to resolve each deficiency.
8. If you choose not to break up the brainstorming session in order to resolve the deficiencies, figure out what you think the conclusion will be, give it a degree of confidence, a      significance with regard to subsequent conclusions, and a description of risk to the entire solution if your conclusion is wrong.
9. Figure out if you can design out the risk (i.e., if a deficiency in knowledge has two ways in which it can resolved, determine if you are able to implement your solution in such a way that either case can be handled).

Omniscience is a fantasy. Beware anyone who never says, "I don't know." Train anyone who acknowledges ignorance, but doesn't yet deal with it in a structured manner. Embrace anyone who can describe for you a solution that compensates for ambiguity. Fire anyone who says, "You can't know."

Programming: Language and Thought

Programming is a difficult art to do well. I don’t mean the high level design or the specification of implementation patterns to use, I mean the actual “let me type up the implementation of this single procedure” effort. The problem lies in the need to have both structured, repeatable, consistent patterns of consideration and thinking, while simultaneously having a set of mental processes that lend themselves to innovation and unconventional insight. There’s the added difficulty caused by the fact that programming is often iterative in nature … you might add the portions of the code here, expect there to be interaction over there, and have to come back here to change things around based on behavior and expectation there.

Setting up a template of things to consider doesn’t work for many reasons, not the least of which is that, for the template to be useful across the board, it would have to be so generic and abstract that the concrete specifics of how to use it in a particular circumstance would allow the programmer so much flexibility that he’d dismiss the template entirely (which he would be inclined to do, since a template of what to think about would be offensive to him and his expensive training). Besides, if you have a template of steps to consider, you allow yourself to be constrained by that template, and innovation suffers.

Frankly, there is no solution. However, there are things that can be done to improve the situation by nudging the programmer’s mind in such a way that he considers certain aspects as part of his normal (and possibly unique) programming manner. The key is language and its use.

Words are referents that point to concepts. When you use a word, you’re indicating to a person that they should consider aspects of the concept. Multiple words might refer to the same concept, but indicate that different aspects of the concept should be considered relevant (this is one of the reasons that accurate use of language is important to unambiguous communication.) The structure of the language can also indicate a particular contextual framework in which the referred concepts should be evaluated.

Similarly, if you force a programmer to consider the language he is to use, or the structure he is to use, you can nudge his thought processes in such a way that he considers a particular necessary aspect of coding that he might otherwise overlook. As such, the person responsible for establishing a company’s (or API) coding style must consider areas in which he can provide this nudge. I’ll provide a few examples (please note that these are _examples_, and I will not enter into a debate about whether my particular example is the right or wrong way to do things.)

Classes, in general, reflect a conceptual entity. Therefore, classes should be named with the noun or noun phrase part of speech. By doing so, the programmer is forced to envision the thing and its intended context. Not only does this cause the programmer to more thoroughly evaluate that context (project business processes) allowing the team to identify deficiencies in specification, and also allows him to identify a meaningful hierarchy of related concepts such that a class hierarchy can be defined, but it also makes it easier for him to keep a mental image of the entity being modeled in mind as the coding proceeds.

Properties and methods have their own requirements and naming styles that can lend themselves to better development style. I’ll address these in the comments if necessary, but otherwise I’ll leave it as an exercise to the reader.

The Microsoft Visual Studio environment allows a developer to construct code “regions”, which are just delimited areas of code identified by a common name (with the ability to collapse everything down to a single node identified by that name.) If the coding standards require regions based on the access type of a particular property or method (e.g., #region Protected Methods), that reminds and encourages the programmer to evaluate what access level is actually appropriate, since recommended practice requires that you use the most restrictive that is reasonable.

There are times when resources must be closed or explicitly released (in the case of interacting with unmanaged code or GDI objects, given a few Microsoft GDI leaks), but programmers will frequently forget to consider this. If your coding style always requires that every code block be put in a Try … Finally structure (given that the Finally block is usually where you want to do that kind of clean-up), then the programmer is reminded in every procedure that he should evaluate whether that kind of clean-up is necessary. You don’t want it to be a Try … Catch or Try … Catch … Finally block, because this would encourage the programmer to unnecessarily handle exceptions, and this is not recommended practice.

Keep these techniques in mind, and consider them when documenting your own coding standards guides. Comments of other suggestions welcome, of course.