What is the right reason to leave a job?

As a consultant, I frequently leave jobs. I also help many people decide whether or not to leave their jobs. I have learned there is no one "right" reason for leaving, but I've accumulated a list of many "good" reasons for leaving. I'll give some examples:

In my career, I have left jobs when 

- the job I was hired to do was finished.

- the job I was hired to do could not be finished.

- the job I was hired to do would be finished just fine without me.

- I was not able to do the job I was hired to do.

- the job I was hired to do wasn't worth doing.

- I was no longer learning new things (that's my most frequent reason for leaving)

- they told me that my pay was going to be "temporarily" delayed

- they asked me to do something illegal or unethical

You may notice that I never leave just because someone is going to pay me more money. If I was hired on to do a job, I feel committed to see that the job is finished, or going to be finished, or will never be finished. Only when my commitment is fulfilled am I ready to move on to bigger things. I don't think it's a good idea to leave behind me a trail of broken commitments.

Another good reason for leaving is not one I've experienced yet, but it's when they ask you to do something dangerous to your life or health. Very few jobs are worth dying for.

And here's a useful principle when leaving: If possible, don't quit until you have the next job set up. Why? Because it's much easier to get a new job when you already have a job. Employers tend to be suspicious of unemployed people.

Foreword and Introduction to ERRORS book

Foreword

Ever since this book came out, people have been asking me how I came to write on such an unusual topic. I've pondered their question and decided to add this foreword as an answer.

As far as I can remember, I've always been interested in errors. I was a smart kid, but didn't understand why I  made mistakes. And why other people made more.

I yearned to understand how the brain, my brain, worked, so I studied everything I could find about brains. And then I heard about computers.

Way back then, computers were called "Giant Brains." Edmund Berkeley wrote a book by that title, which I read voraciously.

Those giant brains were "machines that think" and "didn't make errors." Neither turned out to be true, but back then, I believed them. I knew right away, deep down—at age eleven—that I would spend my life with computers.

Much later, I learned that computers didn't make many errors, but their programs sure did.

I realized when I worked on this book that it more or less summarizes my life's work, trying to understand all about errors. That's where it all started.

I think I was upset when I finally figured out that I wasn't going to find a way to perfectly eliminate all errors, but I got over it. How? I think it was my training in physics, where I learned that perfection simply violates the laws of thermodynamics.

Then I was upset when I realized that when a computer program had a fault, the machine could turn out errors millions of times faster than any human or group of humans.

I could actually program a machine to make more errors in a day than all human beings had made in the last 10,000 years. Not many people seemed to understand the consequences of this fact, so I decided to write this book as my contribution to a more perfect world.

Not perfect, of course, but more perfect. I hope it helps.

Introduction

For more than a half-century, I’ve written about errors: what they are, their importance, how we think about them, our attempts to prevent them, and how we deal with them when those attempts fail. People tell me how helpful some of these writings have been, so I felt it would be useful to make them more widely known. Unfortunately, the half-century has left them scattered among several dozen books, so I decided to consolidate some of the more helpful ones in this book.

I’m going to start, though, where it all started, with my first book where Herb Leeds and I made our first public mention of error. Back in those days, Herb and I both worked for IBM. As employees we were not allowed to write about computers making mistakes, but we knew how important the subject was. So, we wrote our book and didn’t ask IBM’s permission.

Computer errors are far more important today than they were back in 1960, but many of the issues haven’t changed. That’s why I’m introducing this book with some historical perspective: reprinting some of that old text about errors along with some notes with the perspective of more than half a century.

1960’s Forbidden Mention of Errors
From: CHAPTER 10
Leeds and Weinberg, Computer Programming Fundamentals PROGRAM TESTING
When we approach the subject of program testing, we might almost conclude the whole subject immediately with the anecdote about the mathematics professor who, when asked to look at a student’s problem, replied, “If you haven’t made any mistakes, you have the right answer.” He was, of course, being only slightly facetious. We have already stressed this philosophy in programming, where the major problem is knowing when a program is “right.”

In order to be sure that a program is right, a simple and systematic approach is undoubtedly best. However, no approach can assure correctness without adequate testing for verification. We smile when we read the professor’s reply because we know that human beings seldom know immediately when they have made errors—although we know they will at some time make them. The programmer must not have the view that, because he cannot think of any error, there must not be one. On the contrary, extreme skepticism is the only proper attitude. Obviously, if we can recognize an error, it ceases to be an error.

If we had to rely on our own judgment as to the correctness of our programs, we would be in a difficult position. Fortunately the computer usually provides the proof of the pudding. It is such a proper combination of programmer and computer that will ultimately determine the means of judging the program. We hope to provide some insight into the proper mixture of these ingredients. An immediate problem that we must cope with is the somewhat disheartening fact that, even after carefully eliminating clerical errors, experienced programmers will still make an average of approximately one error for every thirty instructions written.

We make errors quite regularly
This statement is still true after half a century—unless it’s actually worse nowadays. (I have some data from Capers Jones suggesting one error in fewer than ten instructions may be typical for very large, complex projects.) It will probably be true after ten centuries, unless by then we’ve made substantial modifications to the human brain. It’s a characteristic of humans would have been true a hundred centuries ago—if we’d had computers then.

1960’s Cost of errors
These errors range from minor misunderstandings of instructions to major errors of logic or problem interpretation. Strangely enough, the trivial errors often lead to spectacular results, while the major errors initially are usually the most difficult to detect.

“Trivial” errors can have great consequences
We knew about large errors way back then, but I suspect we didn’t imagine just how much errors could cost. For examples of some billion dollar errors along with explanations, read the chapter “Some Very Expensive Software Errors.”

Back to 1960 again
Of course, it is possible to write a program without errors, but this fact does not obviate the need for testing. Whether or not a program is working is a matter not to be decided by intuition. Quite often it is obvious when a program is not working. However, situations have occurred where a program which has been apparently successful for years has been exposed as erroneous in some part of its operation.

Errors can escape detection for years
With the wisdom of time, we now have quite specific examples of errors lurking in the background for thirty years or more. For example, read the chapter on “predicting the number of errors.”

How was it tested in 1960
Consequently, when we use a program, we want to know how it was tested in order to give us confidence in—or warning about—its applicability. Woe unto the programmer with “beginner’s luck” whose first program happens to have no errors. If he takes success in the wrong way, many rude shocks may be needed to jar his unfounded confidence into the shape of proper skepticism.

Many people are discouraged by what to them seems the inordinate amount of effort spent on program testing. They rightly indicate that a human being can often be trained to do a job much more easily than a computer can be programmed to do it. The rebuttal to this observation may be one or more of the following statements:

1. All problems are not suitable for computers. (We must never forget this one.)
   
2. The computer, once properly programmed, will give a higher level of performance, if, indeed,
   the problem is suited to a computer approach.
   
3. All the human errors are removed from the system in advance, instead of distributing them
   throughout the work like bits of shell in a nutcake, In such instances, unfortunately, the human errors will not necessarily repeat in identical manner. Thus, anticipating and catching such errors may be exceedingly difficult. Often in these eases the tendency is to overcompensate for such errors, resulting in expense and time loss.
   
4. The computer is often doing a different job than the man is doing, for there is a tendency– usually a good one—to enlarge the scope of a problem at the same time it is first programmed for a computer. People are often tempted to “compare apples with houses” in this case.
   
5. The computer is probably a more steadfast employee, whereas human beings tend to move on to other responsibilities and must be replaced by other human beings who must, in turn, be trained.
   

In other words, if a job is worth doing, it is worth doing right.

Sometimes the error is creating a program at all.
Unfortunately, the cost of developing, supporting, and maintaining a program frequently exceeds the value it produces. In any case, no amount of fixing small program errors can eliminate the big error of writing the program in the first place. For examples and explanations, read the chapter on “it shouldn’t even be done.”

The full process, 1960
If a job is a computer job, it should be handled as such without hesitation. Of course, we are obligated to include the cost of programming and testing in any justification of a new computer application. Furthermore we must not be tempted to cut costs at the end by skimping on the testing effort. An incorrect program is indeed worth less than no program at all because the false conclusions it may inspire can lead to many expensive errors.

We must not confuse cost and value.
Even after all this time, some managers still believe they can get away with skimping on the testing effort. For examples and explanations, read the section on “What Do Errors Cost?”

Coding is not the end, even in 1960
A greater danger than false economy is ennui. Sometimes a programmer, upon finishing the coding phase of a problem, feels that all the interesting work is done. He yearns to move on to the next problem.

Programs can become erroneous without changing a bit.
You may have noticed the consistent use of “he” and “his” in this quoted passage from an ancient book. These days, this would be identified as “sexist writing,” but it wasn’t called “sexist” way back then. This is an example of how something that wasn’t an error in the past becomes an error with changing culture, changing language, changing hardware, or perhaps new laws. We don’t have to do anything to make an error, but we have to do a whole lot not to make an error.

We keep learning, but is it enough?
Thus as soon as the program looks correct—or, rather, does not look incorrect—he convinces himself it is finished and abandons it. Programmers at this time are much more fickle than young lovers.
Such actions are, of course, foolish. In the first place, we cannot so easily abandon our programs and relieve ourselves of further obligation to them. It is very possible under such circumstances that in the middle of a new problem we shall be called upon to finish our previous shoddy work—which will then seem even more dry and dull, as well as being much less familiar. Such unfamiliarity is no small problem. Much grief can occur before the programmer regains the level of thought activity he achieved in originally writing the program. We have emphasized flow diagramming and its most important assistance to understanding a program but no flow diagram guarantees easy reading of a program. The proper flow diagram does guarantee the correct logical guide through the program and a shorter path to correct understanding.

It is amazing how one goes about developing a coding structure. Often the programmer will review his coding with astonishment. He will ask incredulously, “How was it possible for me to construct this coding logic? I never could have developed this logic initially.” This statement is well-founded. It is a rare case where the programmer can immediately develop the final logical construction. Normally programming is a series of attempts, of two steps forward and one step backward. As experience is gained in understanding the problem and applying techniques—as the programmer becomes more immersed in the program’s intricacies—his logic improves. We could almost relate this logical building to a pyramid. In testing out the problem we must climb the same pyramid as in coding. In this case, however, we must take care to root out all misconstructed blocks, being careful not to lose our footing on the slippery sides. Thus, if we are really bored with a problem, the smartest approach is to finish it as correctly as possible so we shall never see it again.

In the second place, the testing of a program, properly approached, is by far the most intriguing part of programming. Truly the mettle of the programmer is tested along with the program. No puzzle addict could experience the miraculous intricacies and subtleties of the trail left by a program gone wrong. In the past, these interesting aspects of program testing have been dampened by the difficulty in rigorously extracting just the information wanted about the performance of a program. Now, however, sophisticated systems are available to relieve the programmer of much of this burden.

Testing for errors grows more difficult every year.
The previous sentence was an optimistic statement a half-century ago, but not because it was wrong. Over all these years, hundreds of tools have been built attempting to simplify the testing burden. Some of them have actually succeeded. At the same time, however, we’ve never satisfied our hunger for more sophisticated applications. So, though our testing tools have improved, our testing tasks have outpaced them. For examples and explanations, read about “preventing testing from growing more difficult.” 

If you're as interested in errors as I am, you can obtain a copy of Errors here:

ERRORS, bugs, boo-boos, blunders

SaveSave

What does it take to become a good management consultant?

When the question in the title came up, all the answers seemed to be answering a different question, something like 

What does it take to get a good job as a management consultant in a large consulting firm?

Lots of people who are not good consultants get jobs as management consultants in large consulting firms. And lots of good consultants can't get jobs with such firms. I know these things because I've been a consultant (a consultant's consultant) to a number of such firms.

If you really want to know what it takes to become a good management consultant, the answer begins with the observation that there are many different styles of good management consulting. The most important quality good management consulting requires is the ability to know yourself, both the good and the bad, along with the ability to retain the good things and improve the bad ones.

To take one example, consider health. I’ve watched many would-be management consultants fail because they couldn't control their drinking or eating habits when traveling on an expense account.

Or another example is would-be consultants who think their domain knowledge will be sufficient for doing a good job, but they lack "people skills." They believe, erroneously, that they can be arrogant, offensive, non-empathetic consultants but people will hire them because they're so smart and well-informed. They're wrong, and most of them never realize why they're failing. That's why I've written a number of books for consultants who wish to improve their consulting success:

Want to see a list of my books?

What's the most touching thing to say to a teacher?

What's the most touching thing to say to a teacher?

The question was, "What's the most touching thing to say to a teacher?" There were many fine answers, and all of them said more or less the same thing: thank your teacher for changing your life.

I agree that telling your teacher “thank you” can be touching, but in my 60+ years of teaching, it’s only the second most touching thing. So, what’s the most touching?

What touches me most is when a student teaches me something I did not know. That shows me that the student has become a contemporary, a grown-up person who will go on to teach others, part of the great chain of “paying forward.” When that happens, I know that I have succeeded in some small way of helping that student and the world in which we all live. That’s what touches me the deepest.

Moreover, in my career such learning has happened thousands of times. If I am a better teacher today, a better human being, I owe it all to my students. Thank you, students. Thank you.

See, Experiential Learning for more on how and why I learn from my students, so you, too, can be touched by what they teach you.

How do I find cheap freelance hardware and software developers?

The question was, "How do I find cheap freelance hardware and software developers?"

I warned the questioner to be very careful about what he was asking for:

First of all, you don’t want “cheap” developers; you want inexpensive developers.

Second, the expense of developers is not their hourly or daily rate. It’s the total cost of building and delivering the software and hardware you want.

In my experience, the least expensive developers have much higher rates than the more costly ones. The deliver what you want, the first time, in less time, with less trouble.

However, a high hourly rate doesn’t guarantee an inexpensive product. Freelance developers can charge anything they want, so price doesn’t necessarily indicate value.

Instead, speak to references about any developer you’re considering. Find out first hand what you’re going to get for what you’re paying.

And, by the way, don't think you'll save money by hiring individual developers. Your best bet will generally be to choose a team, perhaps an Agile team, but in any case, a team that has a history of working well together.

How do I choose the right career?

The question was, "How do I choose the right career?"

My answer was, "You can’t."

Other responders told you things about how to choose your right JOB, but a job is not a career. Maybe before the 21st century, the world of work was sufficiently stable that one could choose a career, but not longer.

For instance, I’m an old guy so I’ve had sort of a career—in computing. But back in the 1940s, when I asked this question, computers didn’t even exist. At least, none of my career counselors knew of them.

And even for the 20th century, I’ve had a rather stable career. My wife, on the other hand, started out to be a concert pianist, then became a musicologist, then a piano teacher, then an anthropologist, then a management consultant, then a world-class dog trainer, and right now is an animal behavior specialist. She works primarily with canines, but until she was 33 years old, she was deathly afraid of dogs.

In other words, don’t try to choose the right career, but prepare yourself for choosing many careers throughout your working life. Learn the fundamental skills that will serve you well in all your future careers, whatever you choose, whenever you choose them—people skills, problem solving, and systems thinking are what come to my mind as things you'd need in all careers. 

That's why I've studied these things, teach them in workshops, and write books about them.

What's the most complex thing about software development?

What's the most complex thing about software development?

Interesting question.

So far, on Quora.com, there have been four excellent answers to this question: discussing 

- the confusing role of people, 

-the requirements problems,

-the interactions with the physical world.

Each of these factors certainly makes software development more complex, and processes such as Agile are designed to cope with this complexity. But, the ultimate complexity factor is software testing.

Why testing? In the software development literature, testing is not usually treated as a glamorous part of development, but when we're testing, we're up against the Second Law of Thermodynamics, which warns us that perfection is ultimately unobtainable.

So, even if we absolutely knew all the requirements (which we can't, of course), kept all the human factors under control (also impossible), and knew exactly all the physical properties of the real world (once more, impossible), we would still never be able to perform the infinite number of tests to cover all possible situations.

In other words, the software could still surprise us at any time. That's what I call complexity.

Of course, we can still work hard to solve these other problems. On requirements, for instance, see our Exploring Requirements books.

But no matter how hard you try, you'll still be faced with the testing problem. To understand this problem and what you can do to reduce (but not eliminate) it, take a look at Perfect Software and Other Illusions about Testing.

Leaders: Born or Made?

The question was asked: "What's the best way to explain the phrase 'leaders are born not made'?"

That's easy. The best explanation is that it’s pure bunk, not supported by any evidence whatsoever.

But if it’s bunk, why do people repeat it? Perhaps they are making an excuse for not being a leader themselves, and not doing anything about it.

If they did want to do something about it, they could find many resources to help them grow into a better leader. My own contributions include:

Becoming a Technical Leader

and

Do You Want To Be a (Better) Manager?

But I'm not the only leadership coach. You have many choices, so if  you catch yourself arguing that leaders are born not made, stop making excuses. 

If you want to stop making excuses and start making a leader out of yourself, find yourself a collection of coaches and get busy with the making. 

improve my coding skills?

The questioner wrote, "Besides practicing, what else can I do to improve my coding skills?"

I took up the challenge with a warning:

Be careful of practice, because if that’s all you do, you’ll just be reinforcing your bad habits.

Instead, read and understand the coding of others. Reviewing code is the fastest way to improve your own code. If the reviewed code is well done, you learn good techniques. If it’s badly done, you learn what things to avoid.

If you’re on an Agile team, reviewing the code of others will be a natural part of your work, and you’ll also learn from others’ reviews of your work.

In any case, one of the very best ways to read and understand the code of others is by participating in software testing. By testing, you learn what really works and what really causes trouble.

And, of course, you should always take the opportunity not just to study code, but to watch others actually producing that code. What tools do they use? How do they use them? What’s their thinking process? What do they read to learn?

Finally, read some good books about thinking, reviewing, and learning. I’ve written some, and my own books refer to others. (http://www.geraldmweinberg.com)

How can someone prepare for consulting?

Someone asked, "How can someone prepare for consulting?"

Here's my short answer:

You can look upon consulting as having two parts (for the sake of this answer): subject matter expertise and expertise at offering advice on any subject. Obviously, you prepare tor consulting by becoming an expert in some subject matter—railroads, computers, marriage, divorce, submarines, glass, beer, management, software development, anything at all. Each subject will be different and require a different way to prepare.

The second part, though, has a great deal in common regardless of the subject matter. You need to know how to offer advice that people will listen to and act upon. Over my many decades as a consultant, I’ve frequently been asked about how to do this. So I wrote a book on the subject—and thus became a consultant to other consultants.

The book, The Secrets of Consulting, became so popular that I wrote a second book, More Secrets of Consulting, which also became a valued resource for consultants. So, unless you’d like to hire me as your consultant at $500/hour, and if you’re serious about become a consultant, or a better consultant, I’d suggest you spend the cost of a lunch and buy one or both of these books. Read them, follow their advice, and if it doesn’t help you, ask for and receive your money back. It’s guaranteed.

By the way, the person who asked this question didn't say whether s/he wanted to give or receive consulting. I assumed in my answer that they wanted to offer consulting, but the books work well either way—for consultants or those who hire consultants.

The Tenth Law of Pricing

The question was, "What can be said on the topic of generating revenue in a solo consulting practice?" You may not think of yourself as a consultant, but if you are an employee, you still have the problem of generating revenue, so this essay applies to you, too.

As a reply, I suggested reading my book, The Secrets of Consulting. The questioner then asked if I could supply a sample, so I provided a little sample from the book. In the chapter on pricing, I give my ten Laws of Pricing—laws that have made numerous consultants rich. I won’t explain them all here (or else I won’t get rich from sdelling my books), but I’ll give a summary along with the section about the tenth law:

FEE AS FEELING: THE TENTH LAW OF PRICING

The previous nine laws may sound overly analytical, but I don't perform this balancing act in any particularly analytical way. I just lay out several prices in a range and than imagine myself in a situation in which I'm turned down and am sitting at home, or the situation in which I've accepted and I'm doing the job. As I imagine myself in each of these situations, I notice my feelings. I find these fantasy feelings a particularly reliable guide to how I'm going to feel in the actual situation. Based on where I feel best on all sides, I set my price.

If the procedure sounds fuzzy, you may want to review the pricing laws:

1. Pricing has many functions, only one of which is the exchange of money.

2. The more they pay you, the more they love you. The less they pay you, the less they respect you.

3. The money is usually the smallest part of the price.

4. Pricing is not a zero-sum game.

5. If you need the money, don't take the job.

6. If they don't like your work, don't take their money.

7. Money is more than price.

8. Price is not a thing; it's a negotiated relationship.

9. Set the price so you won't regret it either way.

If you examine these laws, you'll realize that they don't talk about rationality, but emotionality. In other words, underlying all the other laws of pricing is The Tenth Law:

All prices are ultimately based on feelings, both yours and theirs.

It's important to note other feelings, such as how strongly the clients feel their need, and what they feel they can pay. It's especially important to understand what they feel you're worth. But most important is what *you* feel you're worth.

Oscar Wilde once said that people know the price of everything and the value of nothing. Since Wilde's time, however, things have gone downhill. Now people don't even know their own price. Not consultants, anyway. There may be some consultants in the world who never wonder whether they've set the right price on their heads, but I've never met any. I've concluded that, in the case of consultants, Wilde was wrong. Consultants have so much trouble talking about prices because they know their value only too well. Or, they secretly fear that they know.

So, if you're having problems setting a price on your head, take a good look at your deep feelings of self-worth. You're probably not worth as much as you hoped. On the other hand, you're probably worth a lot more than you feared.

What are the most important software quality assurance techniques?

When this question was possed on a public form, the answers were predictably things like estimation, project management, and testing. All those things are important, but not the most important.

a) By far the most important Q/A technique is telling the truth about relevant Q/A issues in a way that can be understood by your audience. 

(see What Did You Say?: The Art of Giving and Receiving Feedback)

(see also, Are Your Lights On? How to Know What The Problem Really Is)

b) Of course, you must first be able to know what is the truth, and that requires observation skills of a high degree.

(see How to Observe Software Systems)

(see also, An Introduction to General Systems Thinking )

c) And, too, you must be able to know which truths are relevant. For that you must understand the processes practiced to produc the products whose quality you are supposed to be assuring.(see the Quality Software Series)

All specific techniques are dependent on these underlying techniques. If you lack a, b, or c, you will not be able to perform other techniques well.

If you wish to learn more about any of these techniques, or others, I’ve written many books on these subjects, not just the ones shown here. For a list of these books, see my author page on Leanpub.com