Gerald M. Weinberg
Gerald M. Weinberg
Copyright 2011 by Gerald M. Weinberg
License Notes
All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of both the copyright owner and the above publisher of this book.
Dear Reader: Even with many layers of editing, mistakes can slip through, alas. But, together, we can eradicate the nasty nuisances. If you encounter typos or errors in this book, please send them to me at: <> Thank you!Jerry Weinberg
Contents
How Long Does It Take to Make a Programmer?
Can the Handicapped Succeed as Programmers?
What Are the Paradigms for a Professional Programmer?
Can a Professional Be Happy in This Job?
The Impatient Psychiatrist: A Fable
Programmers Are Too Valuable to Be Trusted to Computers
Training for Flexibility
The Cricket Who Wanted to Play Cricket: A Fable
The Cricket Who Wanted to Play Baseball: A Fable
Personal Chemistry and the Healthy Body
What a Programmer Needs in Order to Change
Fooling with Rules
All I Want Is a Little Respect!
The Butterfly and the Buttercup: A Fable
Why Don't People Think?
What Kind of Thinker Are You?
Is It Concentration or Compulsion?
Can a Brain Be Unhealthy?
Why Don't I Run Out of Ideas?
The Eager Beaver and the Clever Cleaver: A Fable
Overrunning the Output Recipient
Re-writing and the Preparation H Test
Say What You Mean, or Mean What You Say
Iatrogenic Pathology
How to Be Misunderstood with Statistics
A Lesson from the University
The Mouse and the Iron: A Fable
Job Rotation Around the Mid-City Triangle
Large Organizations, Small Computers, and Independent Programmers
Management Views the World by Moonlight
Productivity Measurement: We've Probably Got It Backwards
Can Humor Be Productive?
The Order of Maria Theresa
The Phox and the Pheasants: A Phable
What Will Programming Be Like in One Hundred Years?
How Long Should a Programming Career Be?
How Long Should I Stay in Programming?
How Can I Prepare Myself for the Future?
Books for Consultants (and others)
The Quality Software Series
The Systems Thinking Series
Technology/Psychology
Novels: technology lessons framed in fiction.
Foreword
In 1944, when I was eleven, I read a Time magazine article about computers! At that age, my mind was a clean slate looking for a piece of chalk, so the article made a great impression. I recall sitting in the high wing-backed chair in the living room, Time in my lap and time on my hands, deciding I was going to become a "computer person." (The title of "programmer" didn't exist until years later.) Much has happened to computers since 1944. Much has happened to our lives because of computersespecially to my life. But one thing, at least, hasn't changed. It's a lifetime later, and now I'm writing the computer articles instead of reading them. Yet even today nobody understands what "computer people" are, what they really do, and what they ought to be doing.
I shouldn't say nobody knows. The problem today is everybody knowsbut everybody knows something different. After a lifetime of computing, the dust still hasn't settled. Computer people still have the freedom to choose what they might doand with it the freedom to choose what computers might do. Perhaps in another fifty or one hundred years, computer people will be slotted into rigid pigeonholes for life, but today our fate still seems to be in our own hands.
The computing business until now has depended on the free flow of ideas. In the old days you could go to a meeting once a month and talk to at least one person from every important installation in, say, Los Angeles. Now some old-timers go to the XCC and try to reestablish the former environment among 75,000 people from till over the world, but it's not the same.
And it will never be the same. What we once accomplished naturally, by some sort of lemming instinct, now has to be accomplished by more explicit structures. For instance, at big meetings there's no room for little ideas. And at little meetings there's no room for the little shot, who's come to hear what pearls of wisdom the big shots might cast.
In the past, we depended on meetings because little was written down. When I started working for IBM in 1956, I read every piece of technical literature (including the entire SHARE library) in the San Francisco branch office in less than one week! That library-in-a-closet was pretty much all the technical literature IBM possessed in 1956.
Today, we are so swamped with technical literature we have little time for face-to-face exchanges and seemingly no time at all for "informal" reading. So computer people everywhere are losing contact with one another, losing the flow of ideas not sufficiently technical to put in manuals or textbooks. In losing those ideas, we're losing contact with a significant portion of our reality. Our work suffers.
I sense this loss of contact most strongly when I read the letters from readers of my regular columns Stateside, Phase 2, and From Eagle, Nebraska. There are computer people in Dubuque, Dublin, Delhi, and Dunedin who share so much but who will never have the opportunity to meet face to face. If they did meet, they would instantly recognize one another as "computer people"just as they have recognized themselves in these essays. What do I mean by a "computer person"? I mean the kind of person who reads these essays and says now and then, "Yes, I do that," or "I feel that way," or "I wish my manager understood that," or "I can use that technique," or even "This guy Weinberg has lost touch with the kind of environment I work in."
These essays are for people who want a better understanding of computer peopleprogrammers, analysts, managers, designers, trainers, testers, maintainers, operators, administrators, architects, chiefs, or whatever they're called. I've tried to make the essays interesting, so as not to waste any of the very scarce reading time of the average computer person. You can pick up one of my books whenever you have five minutes to spare (like while you're waiting for some website to respond), open it at random, and read a complete idea. It may not be the world's greatest idea, but it's all there and it might do some good. And if not. it might give you some pleasurewhich will do some good in its own way.
Preface
The word professional carries several well-defined meanings as well as a heavy baggage of implications. To give the reader a better definition of the scope of this book, I'd like to explore which of those meanings I intend in my title.
My American Heritage Dictionary says professional means "of, related to, engaged in, or suitable for a profession," which only throws the meaning back on the definition of profession. This would lead us into arguments of whether programming is a profession, whether it should be, and how it is to become one. I do not intend to engage the reader in these arguments, though no doubt many of the essays here will throw some light or shadow on the subject.
The second and third definitions emphasize the receipt of pay for work. The professional programmer, in the sense I intend, probably receives pay for programming work, but not necessarily. Moreover, there are many who receive pay for programming work who I would not regard as professionals, for reasons that will become clear to those who read these essays.