Wednesday, June 21, 2017

Goals for Beginning Programmers

The question was, "What are some goals a beginning programmer should have?"

I’d have to disagree with those who answered, “Pick a language.” Instead, I’d say, “Pick at least two languages.”

I agree that you should avoid the “holy war” about which language is “better,” but the way to do this is to train yourself to be multi-lingual, or at least bilingual.

Pick two languages that are as different as possible, and do all your practice programs in both languages. Then take some time to figure out how each language has influenced your thinking about the program.

We’ve used this method for several generations of beginning programmers with remarkable results. One of our goals was to train programmers who could move into a new job where they used a language the programmer had never seen before.

Within two weeks, the programmer would be able to match the shop’s average.

Within four weeks, the programmer would be the best in the shop.

And within six weeks, the programmer would be teaching the others how to be better programmers.


Quite simply, our students achieved these ambitious goals, thus giving themselves a terrific advantage in the job market, with prosperous future careers.

Monday, June 19, 2017

Feedback to Yourself

Over the years, I've written a lot and taught a lot about feedback. See, for example, our book, What Did You Say?: The Art of Giving and Receiving Feedback. The book has been put to good use by thousands of readers, through two editions, and especially to teams. Recently our handyman, Abel, taught me that we'd missed something 

In the book, we wrote about giving and receiving feedback with one other person and with groups such as teams and projects. What we missed was feedback to yourself.

Abel had been fixing a variety of problems in the kitchen of our old house: broken tiles, a stuck drawer, a slow sink, a jammed ice-cube maker. It was a long list, and Abel worked until he had to leave to pick up his kids from school.

"Did you finish everything?" I asked.

"Yes, and I did a good job."

"You always do a good job, Abel."

Abel smiled. "Thanks. There's a few things I could have done better if I had more time and a few things that weren't in your tool room. Do you want me to come back and touch things up?"

Abel explained what he could improve, and we agreed to another visit two days later, after he made a trip to Ace Hardware. That evening, I showed Dani all he had done.

"That's wonderful," she said. "Some of those things were beginning to annoy me. He did a good job."

"That's interesting," I said. "Abel said the same thing."

"What thing?"

"He said, 'I did a good job.'"

"Of course he did. He always does a good job.Just like you."

"Thanks," I said. "Maybe I always do a good job, but I don't always say so. I  think I was taught not to 'blow my own horn.'"

Dani nodded. "You know, I think I was taught the same thing. Like when you ask me about one of my consulting jobs. I say, 'Yeah, I did okay, but I could have done better.'"

"I do the same. I think it's the 'but' that makes us different from Abel."

"How so?"

"Abel said 'I did a good job," yet he left off the 'but I could have done a better job."

"I thought that's what he said?"

"No, what he said, in effect, was, 'I did a good job, and I could have done a better job.' In other words, he didn't fall to either side—good or bad—but he said both. He provided feedback to himself that was much better than the self-deprecating way that we do it."

In short, what Abel knew how to do was give complete and accurate feedback, something both Dani and I have taught for decades. But what Abel did was give himself that kind of useful feedback. He corrected himself, sure, but at the same time, he affirmed himself for what he did well without discounting it with a big "but."

Do you have a big but? If so, it's time to trim down.


Sunday, June 11, 2017

Programmers, Testers, & Dogs

Danny Faught wrote to Dani Weinberg:

Of course, I believe you that you're using very similar techniques in both of your endeavors: dog training and management consulting. I can also see that both the work with IT people and dog people focuses on problem-solving. 

I've heard that basic dog training is actually more about people training - teaching people how to successfully interact with their dogs. Is that also true of your dog behavioral work? 

Can you give an example of how your work in one area informed your approach in the other?

Dani Weinberg replied: 

Weinberg and Weinberg works with people who do IT by problem-solving.  Dogs and Their People works with people who have dogs by problem-solving. I use the same skills—and many more (just as Jerry does)—and the same basic principles.

You might now know this.  As a dog behavior consultant, I do not teach people how to train their dogs to sit, down, stay, heel, etc.  I work with behavior issues, most of them quite serious, that cannot be resolved that simply.  In fact, many of my clients' dogs already have some basic skills.

What I do is essentially the same thing I used to do when I worked with Jerry consulting in organizations.




Jerry replied:

It's the same in my consulting. Years ago, I taught people how to write code and test programs. That kind of consulting evolved into consulting on "behavior issues, most of them quite serious." In fact, most of my clients' employees already have the basic skills of programming and testing.

Dani then wrote:

Take a look at the Table of Contents—the titles of the chapters—in The Secrets of Consulting. They describe exactly what I do in my dog-behavior consulting. Yes, it's heavily focused on the owner. I know much more about dog behavior—how to "read" and "listen to" the dog. So what I have to do is a kind of translator or interpreter process for the owner. Some of it is me doing with the dog what I recommend to the owner, allowing the owner not only to see the demonstration but also appreciate the results.

Here's a very simple example. The dog is black Standard Poodle, about 6 months old—a "teenager." The owner is a psychologist who has had many dogs in the past. The problem she hired me to help with is that the dog is constantly jumping on people. I go to the house and experience this behavior myself.

Jerry:

This type of problem is similar to a manager who complains that an employee is constantly interrupting him with all sorts of trival questions and comments.

Dani:

Turns out the dog has been taught to sit on cue. I give the cue, the dog sits quickly, and I give a high-value treat (turkey). Whenever the dog looks like she's thinking about jumping again (pure excitement and joie de vivre), I cue "Sit" again and repeat the process. In no time (like after 3 or 4 of these cued Sits), she approaches me and offers a Sit, not cued by me. I repeat the treat. She spends most of the remaining hour doing this, over and over again. The owner is delighted! Then the owner herself tries it, with coaching from me - and it works for her too.

We have taught the dog that this behavior (sitting) is rewarded heavily, whereas jumping evokes me turning my back on her. Dogs are pretty smart and realize where their advantage lies!

Jerry:


Not all programmers are as smart as dogs, but most of them are smart enough to recognize when their manager ignores them when they interrupt. Eventually, they learn to sit down and perhaps raise their hand when they have something to say—if their manager rewards their behavior by recognizing their need. You don't have to give them turkey treats. "Recognition" is their high-value reward. If the manager responds to interruptions by telling them "don't interrupt," that's still a form of recognition, and teaches the employee to keep interrupting.

Monday, June 05, 2017

Is Waterfall the Opposite of Agile?


Agilists sometimes behave unreasonably by pummeling the Waterfall approach. Personally, I think such evangelists could better spend their effort producing solid, relevant code, but evidently they are on a crusade and need an enemy. If they need an enemy of Agile, however, they could have made a better choice.

There's nothing wrong with the Waterfall approach—if applied appropriately. For Waterfall to work well, you need to solve a problem that's not destined to change much, or, ideally, to change not at all. Some Agilists claim there is no such unchanging problem, but they're merely showing their lack of experience. I've seen a number of such invariant problems, and they yield very readily to a properly applied Waterfall development.

For example, Erik, a former student of mine, made a lucrative business of converting COBOL programs to new COBOL programs adapted to new versions of the COBOL compiler. Erik's customers wanted assurance that nothing would be changed in the conversion. This was a perfect situation for a simple Waterfall approach, one that Erik could perform profitably at a fixed price and schedule.

That said, the number of such invariant problems is not large, and it's usually difficult to know at the beginning if a problem will turn out to be so stable. In Erik's case, some of his customers would decide midway that they wanted a few "tiny" improvements in the converted application. Erik controlled that situation by charging outrageous fees for even the simplest modification. Most of us, however, try to control this situation by employing some Agile approach.

Let's be honest with ourselves: one consequence of an Agile approach is the loss of our ability to work to a fixed cost on a fixed schedule. Erik could do that, but only in a few carefully controlled situations. Many managers frustrate themselves over this lack of control and blame it on Agile. What's really to blame, however, is their inability to control the world in which they live. Things do change, and much of the time it's these very managers who instigate the change.

What do frustrated managers do? Quite often, they elevate their attempts to control the change by making rules. They may start using a pure Waterfall approach, but as their frustration with changes grows, they may add a Change Control Board, or change reviews, or a Change Tsar, or any of a number of other tactics. And, when those tactics fail to produce absolute predictability, they add more of the same kinds of rules and their supporting tactics.

After a while, these rules upon rules produce an approach that, though called "Waterfall," is actually something quite different—something for which we so far have no accurate name. This "something" is what Agile is responding to, so I suggest we name it.

What are these cobbled-together approaches like? First of all, they create a sad and dismal mood among those poor developers condemned to use them. When I visit a new client, I can generally detect the use of such an approach while I take a stroll through of the premises. I can even detect such approaches over the phone. How? Simple: the mood of my clients is mournful, gloomy, sad, unhappy, doleful, glum, melancholy, woeful, miserable, woebegone, forlorn, somber, solemn, serious, sorrowful, morose, dour, cheerless, joyless, and dismal.
That's quite a sobering list of adjectives, but that's what I can sense in many so-called "Waterfall" environments. Perhaps you recognize the list, but in any case, you can find that list in your dictionary as synonyms for the rare word, "lugubrious."

Perhaps the word "lugubrious" is unfamiliar, but that's good, because we won't often find it used in other contexts. Besides, it's a rather onomatopoetic word—a word that phonetically imitates, resembles or suggests the source of the sound or situation it describes. That's why Agile was invented—to replace those mournful, gloomy, rule-dominated approaches with brain-driven judgments of the actual builders.

So let's be truly Agile and stop bashing the true Waterfall approach. Instead, let's turn our contempt on every Lugubrious approach—or, to make a noun from the adjective, Lugubriousity. Maybe this more accurate name will help us defend our Agile projects from frustrated managers' attempts to smother us with yet more rules.

Or, to paraphrase DeMorgan, who in turn paraphrased Swift:

Great rules have little rules upon their backs to spite 'em,
And little rules have lesser rules, and so ad infinitum.


Never forget that's why we do Agile, not to dry out Waterfalls but to defeat Lugubriosity.

For more thoughs on the Agile approach, see

Friday, May 26, 2017

Advice to New Graduates

It's now graduation season, time to give advice to new graduates entering the world of work. Every few years, I notice the season and republish some old, but still valid, advice I offered my youngest son, many seasons ago.

Letter to My Son, John
(On the occasion of his graduation with a degree in computer science)

Dear John,
I know some of the other fathers are giving their sons BMWs for graduation, but as a fresh computer science graduate, you're probably going to be earning more than I do as a writer.

It's not totally dishonorable being a writer. Last month, when Dani and I were in Hannibal, Missouri, we visited Mark Twain's birthplace. They've made it into a museum, and it seems to attract a lot of tourists.

Before computer scientists came along, writers used to be pretty famous, and some of them even got rich. So save this letter. You may not appreciate the advice, but someday you might be able to donate it to a museum.

On the wall of the museum, under an old photograph of his schoolhouse, was this quotation from one of Twain's letters:

"I was always careful never to let my schooling interfere with my education."

Being an old-timer in computer science myself, I didn't have to be as careful as Mark Twain. When I went to school, there was no such thing as computer science. There wasn't even a computer—unless you count me (that was my job title).

I made 90 cents an hour inverting matrices for the physics department, using a clunky old Friden, paper, pencil, and lots of erasers. No, I'm not going to advise you to complete your education by inverting some 10 by 10 matrices with a Friden. If I wanted to build your character, I'd buy you a hair shirt for graduation.

Subject Matter
I did want to tell you how lucky you were to have such fine schooling as part of your education. I hope that the next stage of your education will be half as good, which it ought to be, if only you can stay out of the trouble I got into when I was a fresh graduate.

The problems I caused myself weren't due to things I didn't learn in my schooling. As another great American humorist, Will Rogers, said, "It's not what you don't know that gets you in trouble, it's what you know that ain't so."

If my experience is any guide, there are a few parts of your schooling you may want to forget before you report for your first job.

The first and easiest thing you'll have to forget is all the specific facts you learned in your technical courses. If you had majored in Greek grammar, or in the history of rural Belgium in the Middle Ages, you wouldn't have to forget all the facts you so patiently memorized. In some subjects, the facts haven't changed in the past few generations, but you certainly can't say that for Computer Science.

Did you ever stop to think why Computer Science graduates are paid so much more than Greek or History majors? Did you think it was because of the scraggly black beard or your long fingernails? Well, it's not.

It's because Computer Science is high technology—and that means the entire subject matter is changing even as you read these words. The history student is being paid a pittance to remember a body of relatively fixed material, but you're being paid that fabulous salary largely because of your ability to keep pace with innumerable rapid changes.

Being a specialist in information processing, you should be able to understand the process that led to the information you found in your textbooks.  A fact that you found in your freshman textbook would be four years old by now even if it was brand new when you were wearing a beanie. But the book was probably two years old or more by that time, which makes it at least six years out of date.

And you also have to consider that a book takes about a year to publish after it is written, and perhaps two years to write in the first place. You can conservatively add another year for the author's inability to keep up with the latest in new technology.

That makes a nice round ten years for the age of the facts you learned as a freshman. It's not much better for what you learned as a senior—and could be worse, because advanced texts take longer to write, longer to publish, and are too expensive to keep updating every couple of years. Just how long is 10 years of computer technology? Well, I read the other day about the resale value of some System 370 models IBM introduced (ten years ago). Back then, they sold for about $3 million. Today, their book value is exactly zero. The big argument is whether to pay people for hauling them away or to call it even for the scrap value.

IBM used quite a bit of gold and silver in the connectors in these models, which accounts for any value they still have. So, unless you're in collecting precious metals, don't start your career in an organization whose computer is ten years old, either. Keep your gold fillings, but forget whatever facts you learned in school.

But don't worry. It's not so hard to forget facts. Psychological studies show that 24 hours after a lecture, you've forgotten half the facts presented. In the succeeding days, this halving process continues unabated.The same thing happens after an exam—as you certainly must have learned by now.

Once in a while, though, in spite of your best efforts to forget everything, something you learned in school will pop into your head. In that case, just keep it to yourself. The last thing you want to do on your new job is to go broadcasting your ignorance to your coworkers. Instead, close your mouth and open your ears. You might learn something that's new to replace the obsolete fact—which is even better than forgetting.

Grades
Telling your coworkers about all the facts you learned in school is almost as bad as telling them about your grade point average. I know it's hard to accept—especially after all the emphasis on grades the past 16 years of your life—but now that you've landed a job, nobody is interested in your college grades.

But forgetting your grade point average isn't nearly enough. You must also forget everything you know about grades and grading. Business is not school. You may be "graded" on your job, but it won't be on the same basis you were graded on at school.

For instance, when you wrote that little assembler for ComSci 321, you didn't have time to finish the macro facility. So you turned in a partially finished job for a B-plus.

Or that time the micro you designed for ComSci 442 gave the wrong remainder on floating point division. You took an A-minus and were glad to be rid of the thing.

Those strategies don't work on the job. There are no B-plusses for partially completed projects. And no A-minusses for hardware or software with bugs. On the job, you finish your tasks and you finish them right, or you flunk.

Or maybe you think you can take an Incomplete like you did when you didn't want to stop working on that really interesting flow tracer. Or the time you spaced off the last program in advanced programming. Well, forget Incompletes, too.

Specific Plans
If you have a good boss and you're sufficiently interested in something to want to continue working on it, you'll probably be allowed to do it—on your own time—and only after you've turned in the project as assigned. As far as other reasons for Incompletes, forget them.

If you flunk, you won't have to worry about going in to argue with the boss about getting a higher grade. Your boss will call you in before you get a chance.

But don't waste your time preparing arguments for raising your grade. Instead, prepare specific plans for finishing the project or getting rid of the bugs. And also prepare plans for improving your performance on the next assignment. If you don't there may be no next assignment.

Oh, you're not likely to get fired—not in today's business world. More likely, you'll get trivial assignments—and keep getting them until you can prove you're capable of finishing something correctly and on time.

There are no A and B grades. Only A and B assignments. Your college grade average might earn you an A assignment for your first project, but it will never earn you a second.

I know it's a bit frightening to learn that you must get an A on every assignment, but once you've mastered the art of "cheating," it's not nearly as bad as it sounds. Actually, the sound of the word "cheat" is the biggest barrier you'll have to overcome. I don't mean it in the sense of "cheating on your wife" or "cheating at cards," but more in the sense of "cheating death."

By "cheating," I mean going outside the rules that previously bound your thinking. Some instructors say it's cheating to solve an exam problem using a method that wasn't taught in class, or even by looking up the answer. In fact, some instructors still consider it cheating if you use a computer to help you solve your homework! But on the job, you're being paid to use any method that works.

You've spent the past 16 years of your life learning to play by the teacher's rules. Now you're expected to invent your own rules, and you're going to find it difficult to use "any method that works." But once you manage to forget about teachers and their rules, you'll find that this kind of cheating is as natural as drinking beer on a warm summer day.

More natural, actually. Drinking beer is an acquired taste, but breaking the rules is the natural heritage of every human being. Indeed, our superior cheating ability is what differentiates us human beings from all the other animals.

A fox is supposed to be a cunning hunter, but human beings can outhunt any fox that ever lived. How? By cheating, that's how. They "cheat" by getting other people to help them and by using tools invented by other people. You may not call those things cheating, but they sure look like cheating to the fox.

The reason you don't consider cooperation and use of tools as cheating is that you're a human being, not a fox. Your teachers had to forbid "cheating" in school in order to create an environment for teaching facts (which you'll have to forget) and giving grades (which are now worthless). They had to make you forget, temporarily, the basic ability that makes you human—the ability to cooperate.

On the job, you'd better remember your humanity. You don't sign an "honor code" saying you have neither given nor received help. On the contrary, if your boss sees you never help anyone else, or haven't the brains to ask for help when you don't know something, you'll be severely downgraded. If you do everything from scratch and fail to use the simplest shortcuts you can find, you'll be consider an ox, not a fox.

It's actually not that hard to work effectively with other people, even after all those years of isolation. Outside the classroom, where most learning takes place, you have plenty of practice getting and giving help—study groups, team projects, or just those endless conversations over cold coffee in the Union. You may have thought you were just wasting time, but you were actually practicing for the world of work.

Well, I know that's a lot of stuff to forget in so short a time, but I know you can do it if you set your mind to it. Underneath that schoolboy exterior, there beats the heart and throbs the brain of a real human being.

Before you know it, you'll have forgotten all that schooling and gotten on with the business of your education. Good luck!


Love, Dad.

Saturday, May 13, 2017

Should I apply for a great opportunity & leave my friends?

The questioner asked: "I found a great job opportunity but I'm currently managing a big project. If I leave now I will leave my colleagues in trouble. Should I apply?"

Here's my answer:

One of my sons was in a similar situation a few years ago. His current job was a dead-ender, but he did not want to leave his friends and co-workers in the lurch. To my amazement, he asked me for my opinion on what he should do.

I told him that the best thing he could do for his friends was model the behavior they might lack the courage to do for themselves—namely, leave.

I told him that once he was at this new, better, job, his former co-workers would start calling upon him, looking for jobs. They did exactly that, and he hired a number of them.

As for leaving trouble behind, first of all if you have been a good manager, then they will do just fine in your absence. (If you have not been a good manager, why would you want to stay there, anyway?)

If you have trouble visualizing how those colleagues will miss you, get yourself a bucket of water. Put you hand in the water. Then take out you hand and notice what happens to the hole you left.


for more information, see Do You Want To Be A (Better) Manager?

Tuesday, May 02, 2017

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