Showing posts with label performance appraisal. Show all posts
Showing posts with label performance appraisal. Show all posts

Sunday, December 10, 2017

Do programmers really know how to program?

I was asked, "Do programmers really know how to program?"

I believe this question is unproductive and  vague. What does it mean by “program”?

The person who asked this question seemed to think programmers were not really programming when all they did was copy some existing program, using it whole or perhaps pasting it in as part of a shell.

To me, programming a computer means instructing it to do something you want done, and to continue doing it as desired.

If that’s what we’re asking about, then yes, of course, some of us out here know how to program. (Some do not, of course.)

It is irrelevant how we do that. Whether we use genetic algorithms, cut-and-paste, or divine inspiration? Do we use Scrum or Agile or Waterfall? How about the programming language? C++, or Java, or Lisp, or Python, or APL? Well, none of those choices matters.

Then what does matter? How about, "Can we satisfy someone’s desires?" In other words, can we provide something that someone wants enough to pay what it costs, in time or money? That’s what counts, and we certainly know how do that—sometimes.

Sure, we fail at times, and probably too often. But no profession succeeds in satisfying its customers all the time. Did your teachers always succeed in teaching you something you wanted to know? Do surgeons know how to do surgery?

So what about using existing programs? To my mind, the first and foremost job of a programmer is knowing when not to write a program at all—either because the needed program already exists or because no program was needed in the first place.

In other words, not writing a program when no program is needed is the highest form of programming, and one of the marks of a true expert.




or Kindle for the book in paper or ebook format

Wednesday, August 23, 2017

Basic skills of a good programmer?

Many outstanding programmers were asked, "What are the basic skills required to be a good programmer?" Lots of good and useful answers were given to this question, such as, test before coding, use a particular tool, or use Agile methods.



For me, though, with more than 60 years of programming experience, the one thing that made me a better programmer was my ability and willingness to examine myself critically and do something about my shortcomings. And, after 60 years, I'm still doing that. You could say it's incremental development applied to myself.

I also examine my strengths (long-comings?) because I know that my greatest strengths can quickly become my greatest weaknesses.

For instance, one of my great strengths as a programmer was speed. If something had to be done quickly, I was the guy to do it. But the weakness in my speed was my tendency to omit the last few hours of testing that would make the project rock solid. I had to learn the importance of taking the time to do a precision job.

Many programmers do examine themselves critically, but then they work to improve their greatest strengths, to the exclusion of their weaknesses. That practice takes them a certain distance, but the nature of computers is to limit your ability, by highlighting your greatest weaknesses. 

A computer is like a mirror of your mind that brightly reflects all your poorest thinking. To become a better programmer, you have to look in that mirror with clear eyes and see what it's telling you about yourself.

Armed with that information about yourself, you can then select the most useful external things to work on. Those things will be different for you than for anyone else, because your shortcomings and strengths will be unique to you, so advice from others will often miss the mark.

Good programmers make good use of their best tools, and you are your best tool, so sharpen yourself.


See, for example, 





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.


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.

Sunday, September 04, 2016

Busy Manager's Guide to Performance Appraisal

I was busily converting my old paper files to digital format when I ran across this wonderful chart to use when making performance appraisals. It's the best I've ever seen, but I don't know where it came from. If you read this and know whose work it is, let me know and I'll update this entry to give credit.

If you want to be a better manager, you may use this chart, or perhaps you may want to read my book: