Before I was a programmer, I was a software trainer for Manpower in Chicago. In fact, I started teaching myself programming to pass the time during long stretches when the trainees were busy working away on their tutorials. I was stuck at a desk with a PC, reading books or magazines in front of the paying customers was a no-no, so why not make use of the time?
The training consisted of step-by-step instructions that walked the trainee through the basics of working with, say, Microsoft Word or Excel. I soon noticed that the trainees fell into one of two categories: those who viewed the instructions as gospel that must be followed to the letter, and those who viewed the instructions as a means for learning the software. I thought of them as process-oriented vs. goal-oriented.
The process-oriented people would drive me a little nuts sometimes. We’d have conversations something like this:
“Excuse me, I did something wrong here. The next step shows that I should have a table with six columns, but mine only has five. Should I start over?”
“No, you’ve already typed all that data into the table and I’m sure you don’t want to type it again. Do you understand how to create a table?”
“Yes, I think so.”
“Then just move on.”
“But the picture in the sample shows a table with six columns.”
“That’s okay. You probably just typed the wrong number of columns in the dialog box when you created it. If you understand how to make a table, you can move on.”
“But mine doesn’t look like the instructions say it should. Can I do this exercise again?”
“If you really want to, sure, go ahead.”
These people had learned what they needed to learn. But they hadn’t followed the process to the letter and seemed to think they’d get a black mark on their permanent records if they didn’t go back and successfully complete every instruction.
By contrast, the goal-oriented trainees usually skipped past some of the instructions once they knew they’d grasped the concept. They understood that the point of the training was to learn the software, not to be a slave to training process.
I witnessed a laughable example of the follow-the-instructions mentality when I was working as a contract programmer at Disney. This was 1999, and most of us were busy rewriting database systems to make sure they were Y2K compliant. We had regular meetings to ensure that we met conversion deadlines set by upper management, and some dim-bulb administrative assistant was put in charge of running the meetings and writing progress reports.
At one of those meetings, she announced that we were supposed to certify seven systems that day. I had created one of those systems using Access 2000, which was Y2K compliant. I demonstrated the system’s functions, showed that it would handle four-year dates, and figured that was that. My boss (who unfortunately wasn’t also the dim bulb’s boss) nodded his approval.
Then the dim bulb explained that her Y2K process manual said we should have a document from Microsoft stating that Access 2000 is Y2K compliant. I told her I’d already gone online and checked Microsoft’s technical specs, which stated specifically that Access 2000 is Y2K compliant.
“But we’re supposed to have a document.”
At that point, my boss jumped in.
“Tom just demonstrated that it’s Y2K compliant, and Microsoft has stated that it’s Y2K compliant. It’s Access 2000. They wouldn’t release software called Access 2000 that can’t handle dates starting in the year 2000. Let’s move on.”
“But we don’t have a compliance document from Microsoft. The manual says we should have a compliance document for the files.”
My boss sighed.
“Okay then, Tom will find out how to get a compliance document. Let’s move on and certify the other systems.”
“We can’t do that. We’ll have to reschedule.”
“Reschedule? Why would we reschedule? Everyone’s here and we have the meeting room for another hour.”
The dim bulb referred to her printed meeting agenda.
“It says here we’re going to certify the following seven systems at this meeting. But we can’t, because we don’t have the document for Tom’s system.”
“Yes,” my boss said slowly, as if speaking to a toddler. “So let’s certify the other six and we’ll come back to Tom’s system next time.”
The dim bulb checked her agenda again.
“But it says here we’re going to certify these seven systems. We can’t certify one of them today, so we’ll have to cancel this meeting and reschedule when we’re ready to certify all seven of them.”
For a minute, I’d thought I’d actually see my boss (a very affable man) blow a gasket. Instead, he pointed to her printed agenda and spoke through gritted teeth.
“Well, you see, what you have in front of you there is just some ink on a piece of paper. The goal here is to get systems certified. There’s no reason we can’t certify the other six systems on the list and then come back to Tom’s system next time.”
“But it says here we’re supposed to certify seven systems today.”
“There are seven systems on the list because that’s how many we thought we could demonstrate in the time allotted for this meeting. These systems have nothing to do with each other. They just happen to be on today’s list. So let’s certify the other six.”
The dim bulb looked confused for a moment, then sought clarification in her printed agenda.
“No, it says here we’re supposed to certify seven systems. We can’t do that today. We’ll have to reschedule.”
So the meeting ended with eight of us rolling our eyes and the dim-bulb satisfied she hadn’t violated the dictates of some ink on a piece of paper.
It took me about 10 minutes to find and download the document the dim bulb needed. I forwarded it to my boss and told him I would have found it sooner, but Chareva had called me from the grocery store. She’d gone there with a list of 12 items to purchase but discovered the store was out of one of them. So she had no choice but to put the other 11 items back on the shelves and reschedule the shopping trip. My boss liked that one.
So what does all this have to do with health and nutrition?
Well, I thought about the slave-to-instructions mentality when several readers sent me a link to an article about a mom in Canada who (eek!) violated government nutrition guidelines:
A Manitoba mom was slapped with a $10 fine because the lunches she packed for her kids’ lunches didn’t have any Ritz crackers.
Kristen Bartkiw sent her children Natalie and Logan to daycare with lunches of leftover roast beef, potatoes, carrots, milk, and oranges.
That sounds like a pretty decent lunch for a kid. What could possibly be the problem?
The daycare providers evidently didn’t think the wholesome lunch fit the nutritional bill because Bartkiw was subsequently charged for the Ritz crackers that the lunches had to be ‘supplemented’ with.
According to Metro News, Manitoba laws require that daycares provide children with a nutritious meal as prescribed by the Canadian Food Guide. That means one milk, one meat, one grain, two fruits.
Oh, dear. Mrs. Bartkiw didn’t include a grain product in those lunches. The Canadian Food Guide says each lunch must include a grain product, so by gosh, the rule-followers had to jump and give those kids a Ritz — because we must always obey the process, and because everything (including stupidity) sits better on a Ritz.
Let’s look at the ingredients for Ritz crackers:
Oh, yes, definitely … those are the ingredients that turn a nutritionally deficient meal into a nutrition powerhouse.
This is what I mean by confusing the goal with the process. The goal is for kids to be healthy. Anyone with a brain should recognize that there’s nothing about the meal Mrs. Bartkiw packed – beef, vegetables, fruit and a potato – that’s going to harm her children’s health. And anyone with a brain should recognize that adding Ritz crackers to that meal isn’t going to make her kids any healthier.
That’s why I want governments to get out of the nutrition-advice business. The “advice” becomes a set of rules, and then the rules must be followed. Everyone involved becomes a slave to the process. The original goal that the process was intended to support – helping people become healthier – ends up having nothing to do with any of it.