Sunday, June 25, 2017

How do I get better at writing code?

Nobody writes perfect code. Anyone, no matter how experienced, can improve. So, you ask, how do I get better at writing code?

Of course, to get better at writing code, you must practice writing code. That much is obvious. Still, just writing the same poor code over and over, you're not likely to improve by much.

Writing is a different skill from reading, but reading code is necessary if you want to improve your writing. As with writing natural language, you build up your skill and confidence by reading—and not just reading your own output. So, find yourself some examples of good, clear code and read, read, read until you understand each piece.

Be careful, though. There’s lots of terrible code around. You can read terrible code, of course, and learn to analyze why it’s terrible, but your first attention should be on good code. Excellent code, if possible.

Where can you find good code? Textbooks are an easy choice, but be wary of textbooks. Kernihan and Plauger, in their book, The Elements of Programming Style, showed us how awful textbook code can be. Their little book can teach you a lot about recognizing bad code.

But bad code isn't enough. Knowing what's bad doesn't necessarily teach you what's good. Some open source code is rather good, and it’s easy to obtain, though it may be too complex for a beginning. Complex code can easily be bad code.

Hopefully, you will participate in code reviews, where you can see lots of code and hear various opinions on what’s good and what’s less than good.

Definitely ask you fellow programmers to share code with you, though beware: not all of it will be good examples. Be sure the partners you choose are able to listen objectively to feedback about any smelly code they show you.

If you work alone, use the internet to find some programming pen pals.

As you learn to discern the difference between good and poor code, you can use this discernment in your reading. After a while, you’ll be ready to start writing simple code, then work your way up to more complex tasks—all good.

And date and save all your code-writing examples, so you can review your progress from time to time.


Good luck, and happy learning!

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?