How do I fix a really difficult bug in programming?

Here was the question:

"How do I fix a really difficult bug in programming?"

Here was my first answer:

There is no such thing as a “difficult bug.”

I suspect my answer requires further explanation. First of all, I doubt that you have experienced actual bugs in your computer, the kind with 8 legs that bite and swarm. I have, a couple of times, but they are rare, and usually not difficult to eradicate.

Perhaps you are talking about errors, but using inaccurate language. In that case, I will assert “there is no such thing as a difficult error.” The same error might be handled easily by a different person. I have seen that circumstance often. For instance, I once spent a month trying to pinpoint a coding error. When I finally asked the help of a colleague, she found it in less than two minutes.

No, there are no difficult errors, but there are people who have difficulty with an error. We have all been there, and we tend to want to blame the error rather than ourselves.

So, the first thing you need to do to handle a “difficult bug” is to ask yourself,

“What is it about me that is making this error so difficult to handle?”

Perhaps you are having difficulty because you are impatient, or think failure to handle the error will make you look bad to your boss or colleagues.

Perhaps pressure to handle the error is throwing you off your center, distorting your thinking.

Perhaps you do not know enough about the system with the error, or the language in which the program is written.

Perhaps your mind is on other things in your life, things distracting you because they are more important to you than this darn “bug.”

Maybe you should discuss this error with a colleague or two, What is it about you that is keeping you from doing that?

Anyway, good luck in your quest for resolution.

Take a look at Errors: Bugs, Boo-Boos, and Blunders

What is Software?

Ir's a new year, so let's start out with something fundamental, cleaning up something that's bothered me for many years.

The other day I was lunching with a computer-naive friend who asked, "What is software?"

Seems like it would be an easy question for those of us who make and break software for a living, but I had to think carefully to come up with an explanation that she could understand:

Software is that part of a computer system that adapts the machinery to various different uses. For instance, with the same computer, but different software, you could play a game, compute your taxes, write a letter or a book, or obtain answers to your questions about dating.

I then explained to her that it’s unfortunate that early in the history of computers this function was given the name “software,” in contrast to “hardware.” What it should have been called was “flexibleware.”

Unfortunately the term “soft” has been interpreted by many to mean “easy,” which is exactly wrong. Don't be fooled. 

What we call “hardware” should have been called “easyware,” and what we call “software” could then have been appropriately called “difficultware.”

How Do I Decide Between appX and appY?

Hardly a day goes by without some developer or tester asking me about some tools or applications. These could be any tools or apps, so let's call them X and Y.

Usually, the question is simple, but asked with heart-stopping urgency:

"Is X better than Y?"

Rather than provide an answer, I tell them they would be better off not asking such "better than?" questions.

Software apps and tools are complex systems. Consequently any X-Y pair will differ on a number of dimensions. X will be better on some; Y will be better on others. Or both will be useless or poor for your needs.

If you're choosing a tool or an app, start with assessing your needs. Then, instead of asking which is better, ask

"Which fits my needs better, X or Y?"

If neither one fits you needs, then look for a third alternative, or a fourth.

In the rare case when both X and Y fit your needs, you might meaningfully ask, "Which is better—for me, at this moment?"

If X and Y still seem equal, then flip a coin. Heads, take X. Tails, take Y.

Then, while the coin is in the air, your mind will usually make the decision, not willing to allow the coin drop to make the decision for you.

But, if your mind doesn't decide, then let the coin drop decide. At that point, it shouldn't matter.

But if you reach this point, wait a moment before you choose X or Y. During that moment, consider the following two questions:

Can I take both X and Y?

What about Z? Is there some third alternative I haven't considered?

Indeed, instead of asking "which is better" questions, ask, "What is the problem I'm trying to solve?"

Are Your Lights On?: How to know what the problem really is?                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          

Why is reading or writing something different from doing something?

First consider reading. Reading is (usually) a solitary activity, with no feedback. Without feedback, there's no check on what you believe you're learning.

Now, writing. Unless you put your writing in the hands of someone (or perhaps some computer analysis app), there's also no feedback, so there's no check on whether you wrote sense or nonsense.

When you do something, you interact with the real world, and the world responds in some way. With the world's feedback, you have the possibility of learning, confirming, or disconfirming something. That's why we strongly favor experiential learning over, say, lecturing or passive reading or writing.

If you want to teach somebody something, don't just send them to a book, or, even worse, tell them what you want them to know. Instead, figure out a way to have them experience the situation in which the learning applies.

After they've had the experience, you then might want to send them to a book where they can read about what they experienced.  Alternatively, you might ask them to write about their learning and have you read what they wrote.

You can try this out:

Step 1. Write a sentence or two about what would happen if you tried to move your desk six inches (15 cm) to the left or right.

Step 2. When you finish writing, get up and move your desk six inches (15 cm) to the left or right.

Step 3. What did you learn in steps one and two?

For a far more thorough answer to this question, see my four-volume series on Experiential Learning 

<https://leanpub.com/b/ExperientialLearning>

Then do some of the experiential exercises you find there.

Why I Stopped Being a Professor

Here's a story from The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully:

A few years back, I thought I had grown wise enough to be a college professor. I treasured that illusion for a few weeks—that is, until I came in contact with the students. From then on, it was all downhill. I did struggle for a long time, even presuming to teach a course in systems thinking—as if I had anything to teach. It was the systems thinking class that delivered the coup de grace to my professorial tenure.

Judy had lingered after class to tell me she was transferring to Oberlin College. Judy's quick, teasing wit marked her as someone exceptional, so I was disappointed to be losing her as a disciple.

"It's not so much the school," she comforted me. "My sister goes to Oberlin, and we're very close."

"Is she an older sister or a younger sister?"

"Neither."

"Neither?"

"We were born on the same day."

"Aha," I triumphed. As co-discoverer of Weinbergs' Law of Twins, I was now on familiar ground. "You're twins!"

"No, we're not twins."

"Born on the same day, but you're not twins? Are you stepsisters?"

"No, we have the same parents."

"Then you're adopted!"

"No, we have the same biological parents."

"Hmmnh. Born to the same parents, on the same day, and not twins? I'll have to think about that. What am I missing?"

"Think about it. Let's see you apply some of the principles you've been teaching us."

I'll spare you the agonies I endured rather than say the dreaded words, "I don't know. Tell me." By the time the next class rolled around, my eyes were almost as baggy as my trousers.

Apparently Judy had seen the symptoms before. As a pre-med, she couldn't stand the sight of human suffering, so she came up and spoke without forcing me to admit defeat.

"Triplets," she said, and my ego bubble burst. My mind raced through a thousand reasons why the riddle wasn't fair. It would just never do to be bested by this little snippet of a girl. She might lose all respect for higher education. She might behave badly at Oberlin. What would they think of us, sending them such an impertinent student?

"Don't you think that's a little farfetched?" It was the best I could concoct, but I needed time to rationalize.

"How can it be farfetched, Jerry, when I actually am one of triplets?" I should have listened to those other professors. They warned me that letting students use my first name would soon lead to other liberties. And even worse, there were other students watching. Perhaps I could play their sympathies to my advantage.

"Naturally it doesn't seem farfetched to you, but how many of the people here have ever met a triplet before?" I held my breath. No, I had guessed right. None of them knew triplets. "See, it is rather farfetched, at least in that sense of the word."

That should have taught her not to get into semantic arguments with professors, but youth is not wise enough to admit defeat. "I can't accept that reasoning," she continued. "It could be that you've never before met any sisters who weren't twins even though they were born on the same day. But it could also be that you've conveniently forgotten, just to prove your point."

"I certainly wouldn't forget sisters like that, if I'd ever known any."

"I think you would. In fact, I think I can prove that you would. How about a little wager? Would you be willing to put five dollars on it?"

Now I know that no honorable professor would take money from a poor student. But Judy needed a lesson she would remember once she got to Oberlin, otherwise she'd get in a lot of trouble with professors who weren't as broad-minded as I am. "Okay, you're on. And these are our witnesses when the bet is finally settled."

"Oh, that won't take long. We can settle it right now."

"Right now? How can you possibly prove I've met sisters born on the same day to the same parents who weren't twins?"

"Because you've got two such sisters living in your own house!"

"What? In my own house? Don't be ridi—. Arrrgh!"

That was the sound of the air escaping from my over-inflated windbag. At that moment, I decided that laughing at myself was a great deal more fun than being a professor. Besides, I couldn't help myself.

Weinberg's Law of Fetch

I told the story about fifty times that day (even a retiring professor has some privileges). When I arrived home, I just couldn't resist telling Dani. I also told the two sisters, born to the same parents, on the same day, who are not twins. Although they probably didn't fully appreciate the story, Rose and Sweetheart love to bark and wag their tails when they hear us laughing, so they joined in the fun. Because they hear better than they see, and because "fetch" is their favorite game, I composed Weinberg's Law of Fetch:

Sometimes farfetched is only shortsighted.

I did want to call it Weinberg's Law of Triplets, but that would have spoiled the riddle. Besides, Rose and Sweetheart aren't triplets. I believe there were seven in their litter.

So, for more memorable stories with morals to learn, get yourself a copy of

The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

Complexity: Why We Need General Systems Thinking

It isn’t what we don’t know that gives us trouble, it’s what we know that ain’t so. - Will Rogers

The first step to knowledge is the confession of ignorance. We know far, far less about our world than most of us care to confess. Yet confess we must, for the evidences of our ignorance are beginning to mount, and their scale is too large to be ignored!

If it had been possible to photograph the earth from a satellite 150 or 200 years ago, one of the conspicuous features of the planet would have been a belt of green extending 10 degrees or more north and south of the Equator. This green zone was the wet evergreen tropical forest, more commonly known as the tropical rain forest. Two centuries ago it stretched almost unbroken over the lowlands of the humid Tropics of Central and South America, Africa, Southeast Asia and the islands of Indonesia.

... the tropical rain forest is one of the most ancient ecosystems ... it has existed continuously since the Cretaceous period, which ended more than 60 million years ago. Today, however, the rain forest, like most other natural ecosystems, is rapidly changing. ... It is likely that, by the end of this century very little will remain. - Karl Deutsch 

This account may be taken as typical of hundreds filling our books, journals, and newspapers. Will the change be for good or evil? Of that, we can say nothing—that is precisely the problem. The problem is not change itself, for change is ubiquitous. Neither is the problem in the man-made origin of the change, for it is in the nature of man to change his environment. Man’s reordering of the face of the globe will cease only when man himself ceases.

The ancient history of our planet is brimful of stories of those who have ceased to exist, and many of these stories carry the same plot: Those who live by the sword, die by the sword. The very source of success, when carried past a reasonable point, carries the poison of death. In man, success comes from the power that knowledge gives to alter the environment. The problem is to bring that power under control.

In ages past, the knowledge came very slowly, and one man in his life was not likely to see much change other than that wrought by nature. The controlled incorporation of arsenic into copper to make bronze took several thousand years to develop; the substitution of tin for the more dangerous arsenic took another thousand or two. In our modern age, laboratories turn out an alloy a day, or more, with properties made to order. The alloying of metals led to the rise and fall of civilizations, but the changes were too slow to be appreciated. A truer blade meant victory over the invaders, but changes were local and slow enough to be absorbed by a million tiny adjustments without destroying the species. With an alloy a day, we can no longer be sure.

Science and engineering have been the catalysts for the unprecedented speed and magnitude of change. The physicist shows us how to harness the power of the nucleus; the chemist shows us how to increase the quantity of our food; the geneticist shows us how to improve the quality of our children. But science and engineering have been unable to keep pace with the second-order effects produced by their first-order victories. The excess heat from the nuclear generator alters the spawning pattern of fish, and, before adjustments can be made, other species have produced irreversible changes in the ecology of the river and its borders. The pesticide eliminates one insect only to the advantage of others that may be worse, or the herbicide clears the rain forest for farming, but the resulting soil changes make the land less productive than it was before. And of what we are doing to our progeny, we still have only ghastly hints.

Some have said the general systems movement was born out of the failures of science, but it would be more accurate to say the general systems approach is needed because science has been such a success. Science and technology have colonized the planet, and nothing in our lives is untouched. In this changing, they have revealed a complexity with which they are not prepared to deal. The general systems movement has taken up the task of helping scientists unravel complexity, technologists to master it, and others to learn to live with it.

In this book, we begin the task of introducing general systems thinking to those audiences. Because general systems is a child of science, we shall start by examining science from a general systems point of view. Thus prepared, we shall try to give an overview of what the general systems approach is, in relation to science. Then we begin the task in earnest by devoting ourselves to many questions of observation and experiment in a much wider context. 

And then, having laboriously purged our minds and hearts of “things we know that ain’t so,” we shall be ready to map out our future general systems tasks, tasks whose elaboration lies beyond the scope of this small book.

[Thus begins the classic, An Introduction to General Systems Thinking]

How do I choose the right career?

The question was, "How do I choose the right career?"

My answer was, "You can’t."

Other responders told you things about how to choose your right JOB, but a job is not a career. Maybe before the 21st century, the world of work was sufficiently stable that one could choose a career, but not longer.

For instance, I’m an old guy so I’ve had sort of a career—in computing. But back in the 1940s, when I asked this question, computers didn’t even exist. At least, none of my career counselors knew of them.

And even for the 20th century, I’ve had a rather stable career. My wife, on the other hand, started out to be a concert pianist, then became a musicologist, then a piano teacher, then an anthropologist, then a management consultant, then a world-class dog trainer, and right now is an animal behavior specialist. She works primarily with canines, but until she was 33 years old, she was deathly afraid of dogs.

In other words, don’t try to choose the right career, but prepare yourself for choosing many careers throughout your working life. Learn the fundamental skills that will serve you well in all your future careers, whatever you choose, whenever you choose them—people skills, problem solving, and systems thinking are what come to my mind as things you'd need in all careers. 

That's why I've studied these things, teach them in workshops, and write books about them.

Psychology of Intelligent Problem Solving

Everyone knows good leaders must be intelligent, but how do we know who is intelligent? One possibility is to ask the psychologists, but I have my doubts about that procedure. Let me explain.

Two Sample Problems

Some time ago, I read a magazine column prepared by Mensa, "an organization of people who score in the top two per cent on standardized IQ tests." Among the test questions they offered were the following two questions, which bent my mind in a direction perhaps not intended by Mensa.

1. All the secretaries in my office are under 21. All the young ladies in my office are very beautiful. My secretary has long blond hair and blue eyes. Which statements below can be justified by the information given?

a) My secretary is under 21.

b) My secretary is a beautiful young lady.

c) Neither of the above.

d) Both of the first two.

4. In a certain field there are both horses and men. There are 26 heads and 82 feet (or hooves) in the field. How many men? How may horses?

Answers

1. The "correct" answer is given by Mensa as (a). What's supposed to trip you up is the assumption that all the secretaries are female, which isn't stated. But what about the assumption that my secretary is in my office? It doesn't say that, but then it doesn't say my secretary is female. Depending on which set of unstated assumptions you choose, all four answers are possible. Although I've never personally had a male secretary, I have worked in many situations where my secretary was in another office—even in another city. Does this make me less intelligent than the psychologist who posed the question?

4. By simple algebra, you get the official answer: 15 horses and 11 men—if you assume that each horse has four feet and each man has two. (You must also assume there are no other beings with heads or feet in that field, and that heads of cabbage, for instance, don't count.) I don't know much about horses, but plenty of men have only one foot, or none. So, for example, one possible solution is 16 horses and 11 men, one of whom is a wounded veteran with no legs. Then, also, a quick Google search of wikipedia yields this quote: "Two-headed people and animals, though rare, have long been known to exist and documented." What does a two-headed horse do to your solution? 

Multiple Solutions

In other words, there are oodles of other solutions—if you're not a psychologist.

Anyone with any intelligence who has been exposed to this genre of testing has experienced the same kind of frustration. You can think of several possible answers, but you know the psychologists want only one—and you're not allowed to ask questions. It's not so bad when the questions are in an entertaining magazine article, or even in the Mensa admission test. (Who wants to be in Mensa anyway?)

But what if you want to be admitted to college? Or win a scholarship? Or put your child on a favored track in second grade? Or get a job? (I sometimes use questions like these when I'm hiring software testers, but I'm looking for people who can think of the most different answers to each question, not the one "right" answer.) The psychologists hold the power to keep you from getting what you want, and their power is rarely questioned.

The Central Dogma

Quite possibly, modern psychology is the most arrogant profession of all time (unless it's programming). In effect, the central dogma of modern psychology says this:

"There is exactly one right answer,

and the psychologist knows it."

This dogma applies equally to test for people at work or rats in mazes. Any rat that displays a modicum of suspicion for the psychologist's setup runs the maze a bit slower than the others—and is labeled "less intelligent." To me, anyone who fails to be suspicious of psychologists should receive quite the opposite label.

This central dogma is damaging enough to the individual person or rat trapped by the psychologist, but its long-range effects on society may be even worse. Schools and employers reward people whose thinking happens to match the narrow thinking of psychologists who produce these tests, so people either learn to think that way or find themselves out in the cold.

After a while, we find  people in problem-solving situations who literally believe that every problem has one and only one solution—a solution so inevitable that they will recognize it when they discover it.

Managers infected by the central dogma act like psychologists. They assign work to their subordinates and expect to have it accomplished in the one right way—their way. Infected designers rarely consider an adequate number of alternative designs—and never consider testing other than by their own intuition. Infected programmers and testers are powerless in the face of a bug that deviates in any way from the "obvious" answer.

Another Problem

In our Problem-Solving Leadership (PSL) workshop, we naturally devote much of the time to problem solving. No matter what problems we use, no matter what we think the "right" answer is, the technical leaders who participate always come up with something better. Try this one, for example, which some of our participants concocted for their classmates:

A man hires a worker to do seven days of work on the condition that the worker will be paid at the end of each day. The man has a 7-inch bar of gold, and the worker must be paid exactly one inch of that gold bar each day. In paying the worker, the man makes only two straight cuts in the bar. How does he do it?

The "right" answer to this problem was supposed to be that the man cuts the bar into lengths of 1, 2, and 4 inches. By "making change," he can pay the man exactly an inch a day—certainly a rather clever solution. Being an old binary machine rat, I found that solution immediately. I felt awfully intelligent as I watched some of the participants struggle to find it.

I no longer felt so intelligent when several participants came up with another solution. The problem says nothing about bending the bar, so they had the man forming the bar into a figure S. Then with two cuts, you can get exactly seven pieces—and make a dollar sign, to boot. I wonder if they did this just to revenge themselves on the psychologists.

My own experience with technical leaders tells me that the best of them operate on a different central dogma:

Any real problem has one more solution

which nobody has found—yet.

They might not be able to find that next solution, or find it right now. It may not be worthwhile finding under the present circumstances. But it's there, waiting to be found. And someone will find it, someday—if they have not been brainwashed by those darn psychologists. That's ultimately the principal reason we want our software developers and testers to work in teams.

WIGGLE Charts—A Sketching Tool for Designers

There's no sense being precise about something when you don't even know what you're talking about. - John von Neumann

For systems designers, it is the best of times and the worst of times. For years we muddled through with a few simple graphic tools for design and documentation—flowcharts, block diagrams, and perhaps decision tables. Then came the diagram explosion, with HIPO, HIPO/DB, Warnier-Orr diagrams, Softech's SADT, Nassi-Shneiderman charts, Petri nets, Constantine structure charts and data flow diagrams, Jackson data structure diagrams, and coding schemes. And for each of these diagrams, you need only bend a line or add a symbol to become known as the inventor of yet another graphic design tool.

Although the choice is large, it is really not very wide. Each of these diagrammatic schemes shares the characteristic of precision—wonderful when you know what you're talking about, but time-consuming and thought-stifling when you don't. And, since most design work is spent thinking roughly, few of these diagrams are of much help through large parts of the design process.

In other design fields, such as architecture, the rough sketch is the most frequently used graphic device, and precise detailed drawings are rarely used at all until the creative part of the design work is finished. The rough sketch has several advantages over the precise drawing:

1. It can be drawn much faster, thus using less time.

2. It represents less investment of time, so we're not afraid to throw it away and try something else.

3. It's very roughness conveys important information about where we are in the design process.

In information processing, rough sketches have always existed, but have never been glorified by a name or by favorable publicity. Schools of architecture offer courses in sketching. The student architect who makes clear quick sketches is much admired by faculty and peers alike. It's time we learned from more mature disciplines and put sketching up on a pedestal.

For many years, I've taught a method of sketching usable with most of the diagrammatic techniques now used in information processing. Although it's been received with enthusiasm, it's never received much publicity, perhaps because:

1. It doesn't require a template.

2. It doesn't have a name.

Although I'll continue to resist the template forces, I've decided to bring the baby to life with a catchy acronym, WIGGLE Charts, for Weinberg's Ideogram for Generating Graphics Lacking Exactitude.

A WIGGLE is merely a box, or block, or line, with one or more rough edges. The rough edges indicate what parts represented by the box or line are imprecisely known. For instance, the following figure is a sketch of a system using a block diagram form

A WIGGLE block diagram

Each box represents input coming from the left, processing inside, and output going to the right. Box 1 has a straight line at its left side, indicating the input to Box 1 is clearly defined somewhere. The right side, however, is rough, indicating we haven't decided what its output will be. As indicated in the diagram, some output will be passed to a second box. but we don't know exactly what. The top and bottom of Box 1 are rough lines, indicating we don't know exactly what this process will be.

Box 2 has undefined input and output, but its process is well known to us, and clearly delimited in scope. Perhaps we have decided to use an off-the-shelf sort, though we don't know which one, so we haven't decided upon a record format.

Box 3 takes the unknown output of Box 2 as its unknown input. By a process that's not yet well defined, it produces two outputs, one well defined and one known only roughly. Perhaps the first report is defined by legal requirements, or by input needs of another system, while the second output is an error report whose format is left open at this stage of the design process. The rough arrows between the boxes indicate we haven't yet decided how control will pass from one box to another. They could be subroutines of the same master routine, or steps in the same job, or separate steps manually coordinated.

Taken together, these three WIGGLE boxes and their arrows give a sketch of the overall design we have in mind. Perhaps more important is what they don't do:

1. They don't give us or any reader an unjustified feeling of precision.

2. They don't intimidate anyone who has an idea about changing something to improve the design.

3. They haven't wasted a lot of time drawing with templates.

Perhaps the nicest feature of WIGGLE charts is the way they can be used with just about anybody's diagrammatic technique. In the second half of this blog post, we'll look at a few more examples of how WIGGLE charts can be used.

(to be continued)

Source

This material on WIGGLE charts is adapted from my book, Rethinking Systems Analysis and Design.

Challenge 9: Organizing The Grand Tour

When you stop learning, stop listening, stop looking and asking questions, always new questions, then it's time to die... - Lillian Smith

One of the most important sources of ideas for change is ideas that have already worked in a similar organization. Moreover, one of the most supportive acts you can perform is to ask someone to teach someone else what they do well. When people teach other people about what they are doing, it forces them to become aware of their own processes.

The Challenge
Your challenge is to organize a tour of your work place for other change artists. Have the people in your workplace teach the change artists "what we do well that others might want to imitate."

Experiences
1. I thought this was a silly assignment—until it paid off with a savings of about $40,000 a year in our printing operation. One of the programmers on the tour had never seen an actual high-volume printer in operation. Once she understood the way things worked, she easily changed one of our major applications so that weekly printing was significantly faster.

2. We found that their performance analyzer did things that we never imagined. We felt a bit foolish using the crude tool we had concocted, but I was proud that we didn't defend it in the face of an obviously superior product (change artist training helped with that). With more than a little help from their team, we switched tools—and, as a side benefit, no longer had to maintain our homemade kludge.

3. The effect on my group was fantastic, and that really surprised me. First they grumbled about all the trouble it would be to prepare for the tour, but then they started cleaning house. It was like when my mother comes to visit—I clean the toilets and put away things that have been laying out for months. The group did the same thing with their code and their supporting documentation. I don't know if the visitors got anything out of their visit, but they sure saw a clean operation. And—this is the best thing—it stayed clean. Actually, I do think they got something out of it, because we've been asked to give four more tours to groups where someone wants to clean house.

4. Well, we didn't learn much, and they didn't learn much, except that we do things pretty much the same way. I guess that's confirming. And I learned that they're nice people. Perhaps in the future we'll be able to help each other, and that feels good even if we don't have any specific current benefits to show.

Reference

This post is part of the series, adapted from the book, Becoming a Change Artist.

Change Artist Challenge #8: Applying The Principle of Addition

The peculiar vanity of man, who wants to believe and who wants other people to believe that he is seeking after truth, when in fact it is love that he is asking this world to give him. - Albert Camus

Satir's Principle of Addition says that people change behavior by adding new behaviors, rather than getting rid of old ones. The reinforced behaviors are done more often, leaving less and less time for behaviors not reinforced.

The Challenge
Your challenge is to practice giving affirmations for behaviors you wish to increase. This can be in the form of an e-mail note, a card, a phone call, a brief office visit, a comment in the corridor. It must be done, however, directly to the person, not through some third party.
Each and every day, give one affirmation to one person.

Experiences
1. This forced me to pay attention to what people were doing.

2. This was really hard! Something deep inside me got caught in my throat when I started to form an affirmation of someone. It's a good thing I had a support group to help me figure out where that came from. I'm still not very good at it, but I can get the words out.

3. I thought I was already doing this, so it would be a really easy assignment. It turned out that nobody recognized when I was giving an affirmation, because I always cut the corners off it by some little joke, or discount.

4. I'm pretty good at this, in person, so I decided to start sending little cards to people who had done something that helped one of my change projects. Boy, was I surprised at how delighted they were! Something about a card made them really sit up and take notice; maybe it showed that I was thinking of them when they weren't present, and I took that little extra time to do this in a way that wasn't the easiest (e-mail). Maybe that made it seem extra important.

5. I made a list of people I ought to affirm, and made five copies, one for each day. I would check each one off the day's list so I would have a measure of how well I was doing. My goal was to be able to do everybody in one day by the end of the week. There were 14 people on the list, and my scores for the five days were 4, 7, 6, 11, 14. I was very proud of myself, and on Saturday I showed the list to my Will (my husband) and explained the assignment. He read over the list and told me I had forgotten someone. I was devastated: What good was a perfect score if it wasn't the whole list? But I couldn't for the life of me figure out who was left off. On Sunday, in church, I was still thinking about it and not really listening to the sermon. Will leaned over and whispered in my ear: "You." At our church, some of us stay after the service for a discussion of the sermon. God must have been watching over me when He sent the sermon that day because the subject was "Love thy neighbor as thyself." I understood that if I didn't love myself very much, loving my neighbor as myself didn't mean very much. I'd say I had a religious experience because of this exercise.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.

Change Artist Challenge #7: Being Fully Absent

 Being Fully AbsentWhoever is in a hurry shows that the thing he is about is too big for him. - Lord Chesterfield

During the Great Plague of 1666, Newton was forced to go home for a holiday when schools closed in London. While idling under a tree, he got the basic idea for his Theory of Universal Gravitation.

During the heyday of telephone exploitation (1877), Alexander Graham Bell got married and took a yearlong honeymoon in Europe! While there, he had his grand vision—not for the telephone, but for the telephone system.

So much for not being able to leave a project for vacation! As your powers as a change artist grow, it's easy to get the grandiose idea that the world can't change without you. This challenge is a challenge to that idea. It's also a way to trick you into taking care of yourself.

The Challenge
Your challenge is to take a week away from work, and when you get back, notice what changed without you being there. You must not do anything about your change artist work for a whole week, but notice what thoughts come into your head, or what apples fall on it.
Do you think you can't do this? Then you have a different assignment, suggested by Wayne Bailey: "If you're going on a week-long vacation and feel the project cannot do without you, then take a two-week vacation."

Experiences
1. We took two weeks and went to Hawaii. It was our first vacation in seven years—really since our honeymoon. I'd always dreamed of a Pacific island paradise, and we found it. The first few days, Shanna and I drove all over the Big Island like tourists. It was interesting, but it wasn't the vacation of my dreams. Then we just starting frolicking on the beach, eating, laying about in the shade, eating, really talking to each other, eating, swimming, and eating. After about seven days of this bliss, I woke up early one morning and realized that though I hadn't consciously thought about work at all, I suddenly had a complete vision of how our process improvement program had to be restructured. Shanna was still asleep (it was real early), so I slipped out for a walk on the beach. When I got back about two hours later, I had the entire thing worked out in my mind. I didn't even have to write it down—it was so clear that I knew I couldn't forget it. Then I put it out of my mind and enjoyed the last three days of our vacation in paradise. When I got back to work, I had a new and revitalized organization. More important, I had a new and revitalized marriage.

2. I decided to spend a week hiking a segment of the Appalachian Trail. I hadn't done any backpacking for a couple of years, so I had to take out all my equipment, replace some of it, and reconsider everything. While doing that, I realized that I needed to do the same thing at work. I was so eager to get started that a little voice inside me said to forget the hike and get back to work. But I resisted. I was able to use the hike—even though it rained most of the time—as a metaphor for the changes I had to make at work. Come to think of it, that was probably because it rained all the time.

3. I stayed home and played solitaire, did jigsaw puzzles, and cleaned the house. I also rearranged my thoughts. Thank you for this assignment.

4. I went to Spain, where I could refresh my school Spanish. I spent a week in Madrid and a week in Barcelona, with a few side trips into the country. Perhaps it was living in another language for two weeks, but I didn't think of work at all. When I came back, I discovered that they had gotten along very well without me, and were eager to show me some of the nifty things they'd accomplished. At first I was depressed, thinking that I wasn't as essential as I had thought. Then I was elated when I realized that I had done a good job of preparing them to keep improving things when I wasn't there. I guess that's really the change artist's job, isn't it.

Source
These challenges are adapted from my ebook, Becoming a Change Artist, which can be obtained from most of the popular ebook vendors. See my website <http://www.geraldmweinberg.com> for links to all of my books at the major vendors.

Persistence in Problem Solving

I write about and teach about problem solving. I also consult on the topic. Sometimes, when one of my clients is stuck on a problem, I tell them I have a sure-fire solution method:

Write it down, seal it in an envelope, put it in a safe place, and open it after 50 years. Then, if it's not solved itself by then, seal it in another envelope for 50 more years. It's sure to be solved by then.

Well, I'd never actually tried the method, but something special happened today that I just have to tell. The story began, if I remember correctly, in 1949, more than 60 years ago. I was taking a bookkeeping class in high school, and on the first day, the teacher started off by saying:

"Bookkeeping is the only word in the English language that has 3 consecutive double letters."

Being a wise-ass young kid, I raised my hand and said, "I know another one."

Startled, she asked, "And what's that?"

"Bookkeeper."

That got a few laughs from the students, and put me on her s-list for two semesters.

Still, after all this time, that's about the only thing I remember from that bookeeping class--mostly because I kept seeking another 3-double-letter word, on and off for all that time.

Well, today I was working on a mystery novel with some prison scenes, and I came up with the kind of word I was seeking. It was prison slang for the warden:

Crookkeeper.

(Dani says it could also be the name of the person who guards shepherds' equipment.)

MORAL: Virtually any problem will be solved if you work on it for 50+ years. So, never give up, but sometimes delay.

Problem Definition

If you like solving problems, and don't always have the patience to wait 50 years, you may shorten your solution time if you start with a better problem definition. You'll be able to do that if you read one or more of the books pictured here. Take a look at http://www.geraldmweinberg.com

Addendum
I guess I should also post a contrasting story about the quickest problem solving effort:

About 5 seconds after I posted this blog, I got a tweet from "@perze" saying:

Hello Mr. Weinberg i don't want to sound like a wise-cracker but "bookkeeping" was misspelled in your last post.

Good for your @perze!

Fixing this post also gave me a few seconds to come up with a couple more 3-double-letter words:

1. When my Aunt Minnie used to visit, my father gave me the task of keeping my cousin Larry out of his sight. In doing that, I was the schnookkeeper.

2. When fishing, I was put in charge of guarding the tackle, so I was the hookkeeper.

3.