What motivated you to learn to code?

I received an interesting question, today: "What motivated you to learn to code?"

Maybe it's old age, but my memory for ancient events seems to have improved. I remember quite clearly those days, back in the 1950s, when I worked as a "computer." That was my job title, computer. I did physics calculations with pencil and paper—and an eraser.

At that time,I had never seen a computing machine, nor another person who had ever seen one. 

When I left graduate school, I went to work for IBM in San Francisco. Nobody else in the IBM office had ever seen a computing machine, at least not a stored program one. We had a machine with 10 wireable instructions (IBM 604) and one 10-digit word of data storage. I was motivated to learn to code that machine by a one-dollar bet that I could turn on all the lights on the console. I won the bet.            

The first stored program machine (IBM 650, with 1,000 words of drum memory) was due in the IBM office two weeks after I started there. I was given the assignment of learning how to program it, as nobody else in the office had a clue. I learned to code by reading the machine manuals for two weeks.

Also, two weeks after the machine arrived, I had to teach a programming class to three other new hires. So, that assignment also motivated me. When the machine arrived, I was the only one who dared to touch it for two weeks, so I wrote programs for the sort of calculations I had been doing in my job as a computer.

It was the thrill of a lifetime.

How can I become a software developer who only designs?

A young programmer asked me, "How can I become a software developer who only designs the whole software architecture and gives instructions to other developers rather than actually coding by myself?"

I told him he could do that right away, as long as he didn’t care if the other developers listened to his instructions and followed them. And if he didn't care of he was paid.

In general, software developers will not follow the lead of someone for whose designs they have no respect. And why would they respect your designs unless you had previously proved yourself by what you’ve built?

So, build things, and build more things, until you demonstrate that others have some reason to follow your lead.

And, at the same time, work on your people skills, because even if you’re the greatest designer in the world, if you’re a self-centered jerk, nobody will follow you or your designs.

For more on designing, see

System Design Heuristics

Where do old programmers go?

As far as I can tell, I’m the oldest old programmer to answer this question so far. I’m so old that the title “programmer” didn’t even exist when I started.

I celebrate my 84th birthday this week, and as far as I know, most of the programmers who were around under various titles when I started (in 1956, maybe 20 of us in the USA) are now dead. I hope they’ve gone to heaven (the cloud?).

Myself, I gradually ceased writing code for money and transitioned to training younger people to be outstanding professional programmers. I still write lots of code for my own use and amusement and learning, but it’s been at least 40 years since I could tolerate writing code for a boss who didn’t understand what programming was all about.

I’ve earned multiple livings as consultant, teacher, and writer. Always about programming, but more about design rather than coding details as the years went by. If you’re good, you can do any of these things even at advanced age, but you can’t just sit around waiting for someone to find you.

If you’re not good, than either get good (it’s never too late) or retire. We don’t need mediocre programmers, and we never did.

http://www.geraldmweinberg.com

Must a Developer Know the Language?

We were asked, "Have you ever applied for a software developer job where you didn't know the language?"

My story is not exactly the same as others might have, for several reasons, but I think it does answer the question.

There are two phases to my story. My first job developing software was at IBM, in 1956. At that time, I didn’t know any programming language, largely because there really weren’t any languages other than machine code. So, I spent two weeks in a closet learning my first computer language.

Actually, it was three languages at once: machine codes for the IBM 704 and 650, plus the wired “language” for the IBM 607.

The second phase of my story takes place some years later, when I became a consultant. In that role, I have helped many, many clients who were using languages I didn’t know—even though I knew quite a few by that time, including LISP, Smalltalk, APL, PL/I, COBOL, FORTRAN, C, Pascal, Simula, several home-grown special application languages, and the machine code for the IBM 7090, 1410, 705, STRETCH, Dec’s PDP-1 and a few other machines. I had also studied in a bookish way quite a few other machines while doing competitive analyses for IBM.

I was able to help those clients largely because their problems seldom had much to do with the details of their chosen language(s). Instead, they were people problems of all sorts. The problems that did wind up with a language embodiment were usually easy to spot using my general knowledge of computer languages and typical errors people made in using them. That’s why I’ve always insisted that professional developers should know at least a handful of different language.

I think there's an analogy here with the term "mathematical maturity," something we might call "programming maturity." Here's how Wikipedia defines mathematical maturity:

Mathematical maturity is an informal term used by mathematicians to refer to a mixture of mathematical experience and insight that cannot be directly taught. Instead, it comes from repeated exposure to mathematical concepts. It is a gauge of mathematics student's erudition in mathematical structures and methods.

For instance, a mature mathematician is able to transcend notational differences, unlike my tutorial student who flunked algebra because he had learned to "solve for x," but said, "You didn't teach me to solve for y."

We could easily use most of those words to define "programming maturity," the ability that allows you to succeed in a developer job using a language in which you have no previous experience.

The Psychology of Computer Programming: Silver Anniversary Edition

How Long Can I Remain a [Ruby, Java, C++, Python, …]  Programmer?

Several respondents to an earlier post have asked me about the future prospects for workers in one programming language or another. Here's my best answer.

As others have said, "I can predict anything but the future." But also others have said that the only things we know about the future are what we know from the past. Therefore, you might get some idea of your future as a [Ruby …] programmer from the answers to a recent Quora question, "What were some jobs which existed 50 years ago but have largely disappeared today?"

It was great fun reading all these answers, many of which described jobs I held back then. I go back a bit more than 50 years, though, so I have a few more to add. Most obvious omission was the iceman. In the 1930s, we had an icebox (not a refrigerator, but an actual box that held a block of ice). The iceman’s horse-drawn wagon would come around regularly and be surrounded by us kids, hoping to get free shards of ice caused when he cut up little blocks to fit our iceboxes.

Another job only briefly mentioned was typesetting. I never held that job, but I was trained for manual typesetting for a semester in high school. At least I know where terms like upper-case and lower-case come from.

Someone also mentioned keypunch operator, a task (not a job) that was often done by prisoners who were literally chained to their machines. Who weren't mentioned, however, were key verifier operators. Not many people today have ever seen a verifier, let alone even know what one was.

Even before my time, there were jobs that disappeared, but which I read about—for instance, in a nineteenth century book about jobs for women. The final two chapters in the book were about a couple of sure-fire women’s jobs for the future (1900 was then the future).

First chapter was about teletype operators. The chapter “proved” that there was a great future for women because they could operate a telegraph key at least as fast as men (and the telephone had yet to be invented).

Second chapter was about picture tinters. There was, of course, no color photography, and it wasn’t really even conceived of. Women were supposedly much better at coloring photos because of their “artistic bent” and their more delicate hands. Though there are a few photo tinters still around today for special jobs, it’s not a career with a great future.

By the way, one future job for women that wasn't even mentioned in the book was typist (or amenuensis) in spite of the then recent exciting invention of the typewriter. Other sources explained that women would never be typists because everyone knew that women were not good with machines.

It's fun to think about these forgotten jobs, but they're also a source of important knowledge, or perhaps even wisdom. Job disappearance is not some new phenomenon caused by computers. It's always gone on through history. True, some jobs lasted a long time, so long that they were passed down from generation to generation, even becoming family names, such as Smith, Turner, Eisenhower, Baker, and Miller. (See, for example, <surnames.behindthename.com> for hundreds of examples)

Some of those jobs still exist, though often modified by new technology. Do you still recognize Fuller, Chandler, or Ackerman? And many others have largely disappeared, remaining only in some special niche, like photo tinters. Do you know anybody named Armbruster who still makes crossbows? Well, you probably know a few Coopers, but how many of them still make barrels?

No job is guaranteed. Nothing entitles you to hold the same job for life, let alone pass the job down to your children. So, for example, if you think of yourself as a "[Ruby…] Programmer," perhaps you'd better prepare yourself for future with a more general job description, such as "programmer" or "problem-solver."

In fact, there's a whole lot of people out there who think (or hope) the job of "programmer" will disappear one of these days. Some of them have been building apps since the time of COBOL that would "eliminate programmers." I've mocked these overblown efforts for half a century, but history has tried to teach me to be a bit more humble. Whether or not they succeed in your lifetime, you might want to hedge your bets and keep learning additional skills. Perhaps in your lifetime we'll still need problem-solvers and leaders long after we've forgotten the need for Chamberlains and Stringers.

Additional reading: 

Understanding the Professional Programmer

The Psychology of Computer Programming

Becoming a Technical Leader

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.

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.

My Earliest Computers

My father gave me a slide rule when I was about 7 years old. I used it to compute baseball batting averages, which was what motivated me at that time in my life. I still have that slide rule. It's a small, cheap slide rule, made from bamboo with plastic (or maybe ivory) faces. He bought them in quantity to give to the young ladies who computed customer bills for Sears, when my father worked for 20+ years, improving processes. The slide rules were used to check their multiplications, preventing enormous numbers of errors that had previously been sent to customers.

The next interactions were with tables of sines, cosines, and logarithms, used for more precise calculations, mostly in math classes and personal experimenting with numbers for fun.

At age 11, still in Chicago, I read a magazine article about computers, then familiarly known as "giant brains." By this time, I had been label as s "brainy" kid, and I longed to learn more about brains. I determined that computers were what I wanted to do with my life—and they turned out to be. I didn't know anyone who had ever seen a computer, let alone used one.

I watched and waited for signs of a computer, but went all through high school without seeing one.  Well, not exactly. I had a summer night  job in a large bakery computing recipe requirements for the following day's orders. I used a Monroe adding machine.

When I entered college at 16, I told the counselors I wanted to work with computers, but none of them knew anything about computers other than they had something to do with electrical engineering and physics. They decided I should major in Physics, because I was good in math, which would be "wasted in EE." One day, I saw a notice for a "computing course" using Monroe adding machines, given by the Monroe company. I was a short course, and I already knew most the material better than the instructor. But I passed, earning a certificate that I've lost somewhere along the way. It's the only computing course I ever took, and the only "degree" in computing that I ever earned.

My next encounter with a computer was when I looked in the mirror. I got a job in the Physics department as a "computer"—that was my job title. I was shown a Friden electromechanical calculator, which I used along with pencil and paper (and eraser) to invert 10 by 10 matrices for faculty members.

I graduated with honors in Physics, Math, Philosophy, and English, then went to Berkeley to study graduate Physics. I was perhaps two months from a doctorate in Physics (exams passed, thesis experiments finished and waiting to be written up), but I read an IBM ad in Physics Today looking for problem solvers. The ad described the work I had dreamed of since age 11, so I wrote to IBM and was hired as an Applied Science Representative—on June 1, 1956.

I was given no training, but my first assignment was to teach a programming course to three other new Applied Science Representatives who were to join IBM in San Francisco two weeks later. (I had a wife and 1.66 kids by then, so I needed the two-weeks pay, so I started early.)  The first machine I encountered was an IBM 607, which was a wired program machine with 20 wired program steps (this was the expanded version) and one signed ten-digit number of data storage. In my first week, using the library of manuals, I mastered that machine plus a bunch of older punched-card machines.

I spent the next week learning to program the IBM 650, a stored program machine that kept programs and data on a magnetic drum, but had wired control panels for input and output formatting. This was all theoretical, as there was no IBM 650 anywhere in San Francisco yet. When one finally arrived shortly thereafter, it was the first stored program machine I had ever seen.

While waiting for the 650's arrival, I earned a reputation as a "whiz kid" (the term "programmer" wasn't yet in use) by making the 607 do tricks. My most impressive trick was turning on all the lights on the 607 control panel, which won me a dollar bet.

When the 650 arrived, I immediately tried out a program I had written to compute tables of sines, cosines, and logarithms. With the arrival of computers, such tables were now totally useless, but I was in nerd-heaven. I was being paid $450 a month for playing with the world's greatest toy, a job I would gladly have paid $450 a month to do—though I wisely didn't tell IBM that.

Downgraded to Testing

Here's a letter I got from a friend overseas. I've altered any identifying information, for obvious reasons. I'm going to intersperse some comments as if I were conversing with Nicolai face-to-face.

Nicolai's Letter
One thing I still like to know from you about "Perfect Software and Other Illusions About Testing". Are there metrics or measurement criterias with which you can measure the success of Testing in the software development life cycle (SDLC)?

I am in a struggle with my employer to change my position from a system developer (am working for the auto parts industry / manufacturing planning and execution) into a software tester. I made that decision after I recognized that this job much more fits to my personality type than doing the implementation.

Jerry
That recognition is an excellent starting point for solving your problems. Many people don't really know consciously what they really would like to do.

Nicolai
But let me come back to my main concern nowadays. My problem now is that in my country and especially in my company, this issue of Testing is new. My boss's understanding of it is low and hence he wants to reduce my salary around 10%.

Jerry
Sorry, that's not why he wants to reduce your salary. That's his excuse for taking advantage of your wish to change jobs. He simply sees an opportunity to save some money at your expense. Yes, if he understood anything about testing, he should raise your salary by 10%—or more.

Nicolai
That's in contrast with the huge losses we have because of NOT using Testing at all in our processes.

Jerry
Oh, my. Your company is at Level 0 when it comes to Testing. Oblivious! That is definitely not the place to be if you wish to make a career, long or short-term, in Testing.

Nicolai
Anyway I will not stay long there anymore.

Jerry
That's the wisest thing you've said so far.

Nicolai
I will try to setup my own company (industrial import export trading consultancy).

Jerry
That's an ambitious goal, and probably long-term. You cannot afford to stay any longer in this unbelievably bad company with this even more unbelievable manager.

Nicolai
But in the meantime I have to feed my family and I need an advice from how I can measure the success of Testing. Based on such criteria, I can improve my salary negotiation and make Testing much more tangible to everyone even myself. Once I have the criteria or indicators, I can make a some percent part of my salary depending on the success of implementing Testing into the SDLC. I think that is fair enough.

Jerry
Your boss has demonstrated he has no interest in "fair enough." And no interest in your career or your family. Your approach is all wrong. You should first find yourself a job in an organization that already values Testing, at least slightly.

In my experience, an organization like yours is never (at least in your working lifetime) going to value testing enough to value you, or pay you what you're worth to them. Nor will it be a good place to learn the profession. All you will learn is what I'm telling you now: that is, you shouldn't stay in this job a moment longer than you must in order to see that your family is fed. (For example, if your wife works, see if you can simplify your finances so you can live on her income, at least for a short time.)

But, in any case, you should immediately begin searching for a new job, in a much more compatible place. (And do it without letting anybody know. The kind of boss you have will not react well to news that you're seeking a new position. Let him know when you're saying goodbye, when you've already been hired by the new place.

Nicolai
What would be such indicators of a successful integration of Testing into the software development life cycle (SDLC)? I know you use the FFR, but this says something about the quality of the software development team. What would be indicators that say something about the quality of the software test team?

Any hints from you are very welcome.

Jerry
What you need now is one or more ways to put a cost on the software errors that are already reaching your users. (For example, you can use methods described in Quality Software series of eBooks—particularly Volumes 3 and 4: How to Observe Software Systems and Responding to Significant Software Events.)

Use these methods to arrive at average and extreme costs of each software bug that leaves your development group. And a count of how many bugs you ship with how much software. Then you can produce a report that says, "If our Testing is X% efficient at finding bugs, and if our developers are Y% efficient at fixing them before release, then we can expect to save Z-dollars by having a Testing group."

If you really do no Testing now in your SDLC, you can expect Z to be a very large amount. (And if it's not a very large amount, then Testing is really not important there, and you shouldn't be working there.)

Even if you're already in a Testing group, you should make such measurements, so you can get the support you need. And be appreciated.

I hope this helps.

References

Responding to Significant Software Events

How to Observe Software Systems

A Code of Work Rules for Consultants

I frequently meet a consultant who is deeply troubled by the implications of the work of a consultant. What we do today may affect the lives of thousands or millions of people for many years to come.

Moreover, most of those people we affect won't have any way to relate a discomfort in their lives to what we are doing today.

They will, perhaps, sheepishly accept the explanation, "That's the way the computer must do it," or the even more insidious, "that's the way things are."

Some consultants I know, particularly those working in shops where nobody ever looks at anybody else's work, salve their conscience by sabotaging their client's information systems.

In many cases, it's difficult to tell whether this is intentional or unintentional. In other cases, there is no doubt.

Many programmers, analysts, and consultants have complained to me that their work holds no meaning for them. They don't know what is being done with the piece of design or specification they work on, or they know and don't approve.
Their response is to stay on the assignment, draw their fee, and badmouth their client at every safe opportunity.

I think it's time we stood up to be counted. We have an enormous responsibility to the people whose lives will be impacted by the organizations we work for.
If we don't believe in what our client is doing, or we don't understand it, then why are we working there? To draw a fat fee? Then what does that make us?

For some years now, I've been giving a set of principles to consultants who are seeking a new assignment, or are considering changing their present assignment because of such doubts.

In recent years, as the job market shrinks, the number of such doubters seems to be increasing so I thought that many professionals would like to see these principles written down:

1. I will not work for an organization whose goals are not consonant with my beliefs.

2. I will not work on projects whose goals I do not understand, or cannot agree with.

3. Before becoming part of a project, I must first obtain agreement on what percentage of my time I can (and must) spend on continuing professional development, and what resources will be provided me for that purpose.

4. I will not work under measurement schemes that pit one person's performance against another's. Rather, I will co-operate totally to help others in the project achieve their full potential, as I expect them to help me do.

5. I will not accept work without understanding what is to be done, and why. Nor will I pass work to others without their similar understanding.

6. All my work will always be open and available for critical comments (circumscribed, as appropriate, by security considerations). Furthermore, I will always stand ready to review the work of others in exchange for them returning the service to me.

7. As long as the above conditions are met, I will devote myself in the utmost to achieving the goals of my client and their project.

Over the years, I've found that people who ask these questions and set those conditions don't wind up in jobs that make them miserable. Sometimes, when they ask them honestly they leave their present position for something else that makes them happier, even at a lower fee scale.

Sometimes, a client manager is outraged at one of these conditions, which is a sure indication of trouble later, if not sooner.

Many of us lost souls need some guidance, and it might have been easier to have a set of principles when the job market wasn't so tight. But over the years, I've learned that consultants following these principles are more successful at landing good contracts–ones that make them richer and, more important, happier.

How to get a job or assignment

One of my colleagues recently wrote about her difficulty in landing consulting assignments. She has some great unique models, but, as she says, ...

The Problem

Most large companies (w/ no R-D labs) have the resources to take risks but refuse to.

Small companies have the guts to take the risks, but do not have the resources or the macro set of processes to do it. ...

What do you think?

Some Solution Ideas

It's one of the paradoxes of the consulting business.

Sometimes, the trick is to choose medium-sized companies. :-)

Seriously, people retain your services only when they know you enough to trust you. Consequently, my preferred method has always been to have a stepped-variety of offerings so they can start to know me in safe, tiny steps (books, keynote addresses at conferences, blogs, comments on blogs, ) ...

Then have medium steps (like workshops, tutorials at conferences, ) ...

Then larger steps (consulting visits)

Then really big steps (consulting contracts ).

Then retire rich.

Solution Ideas for Getting Hired on a Job

These days, it's not just consultants who are having a hard time finding the work they want. In the same mail, I got the following email from Liam, a recent PSL grad:

"As you were advising me to start looking for a new job in the Spring of '09 at PSL, you won't be surprised that lost my job at XYZ at the end of last year."

Not surprised, but disappointed. Still, in the long run, these changes usually work out for a much better situation. Losing the job is just confirmation of a lousy situation.

"I am still looking and would welcome any ideas or advice you might have."

The Problem of Getting Hired on a Job

Well, I just finished an email to another grad who's trying to establish his consulting business (which is getting a number of jobs, so there are many similarities). I'll quote what I told him:

Sometimes, the trick is to choose medium-sized companies.

***[Liam: this might apply to job-hunting, too. In any case, whatever you're doing now, change something--bigger, smaller, more or less medium, you know.]

My preferred method, though, has always been to have a stepped-variety of offerings so they can start to know me in

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

- Then have medium steps (like workshops, tutorials at conferences, ) ...

- Then larger steps (consulting visits)

***[Liam: interview visits, but also visits to help you show off by
doing something for them that's specialty of yours, just a talk, maybe]

- Then really big steps (consulting contracts).

***[Liam: hiring, which is a really big step these days, so perhaps hiring for a trial period, to minimize their risks]

Then retire rich.

Applying My Own Advice

Well, I'm already rich, haven't wanted a "job" for half a century, and have more consulting requests than I can handle. BUT, I'd like to be "hired" more often in my new "career"–writing fiction that entertains while teaching, or teaches while entertaining. I'm trying to apply my own advice to this new situation:

- tiny steps (books, speeches at conferences, blogs, comments on blogs, ) ...

***[Jerry: A book is already "tiny" for your consulting business, but in the book business, that's it! Well, no it isn't, so I'm trying to make samples available (see one example below in the Appendix, my email signature, which is another tiny step) ]

- Then have medium steps (like workshops, tutorials at conferences, ) ...

***[Jerry: I offer workshops and tutorials for writers (writers are a small part of my potential audience, yet can be quite influential). I set up a book table at conferences, where people can actually put their hands on books. I've tried book-signings, but they're pretty painful when nobody shows up. And larger samples.]

- Then larger steps (consulting visits)

***[Jerry: I haven't really figured out how to do this. Well, I've just become a member of Book View Café, a writers' cooperative, where I have serialized one of my books for free, and will blog pretty regularly http://www.bookviewcafe.com]

- Then really big steps (consulting contracts).

***[Jerry: I've had some offers to write books-for-hire, but that's too much like a job. I suppose I'm fantasizing that some huge publisher will see one of my books and offer to make it into the next Harry Potter, but that's just a fantasy. And if they offer me a movie option, I'll turn it down. I used to live near Hollywood, and the smell of it was more than enough for me. (but I do love going to movies, but I saw what they did to the book of a friend of mine--and no thanks. He now wears a t-shirt that says, "Don't judge a book by its movie.")]

Then retire rich.

***[Jerry: You already did that, so take $$$ out of the equation. Write for fun, but get as many readers as you deserve, neither more nor less.]

A Cry for Help

After sending those two replies to my students, I immediately realized I had failed to mention the most important possible solution. (Isn't that what always happens when you hit the SEND button? Maybe I should sell SEND buttons to writers who need inspiration.]

What's that solution idea? Obviously:

- ask your friends for solution ideas.

So, friends, any ideas for my fiction business?

- And, oh, yes, you can ask your friends for jobs/assignments.

So, friends, I wouldn't object if you bought a book or two.

- Motivate them, or why would they want to do it.

Well, I believe my books ought to be self-motivating, but I have to motivate potential readers to actually look at them. So, perhaps because you know my non-fiction, or my teaching, you might be motivated to buy one of my books (either e-book or paperback). And, if you read it, and don't like it, I'll personally refund your money.

But if you do like it, I wouldn't object at all if you told me, and even wrote a review of it for Amazon, Smashwords, Powell's, your blog, or any other place that accepts reviews. If you do, I'll give you the free book of your choice, as a small thank you. Heck, I'll even give you your money back, if that's what you prefer.

And, yes, I really mean it.



Appendix: My Email Signature Inviting Sampling

How to sample my novels (try before you buy):

Suggestion: Go to the CreateSpace website for each of the books below and see a short description of the book.

Or, if you want a sample, click on , then click on a title you're interested in sampling, then "buy" the book and ask to see the sample.

Or, for most of the books (not fully updated yet) you can read smaller samples on my website (below).

http://www.geraldmweinberg.com/Site/eBOOKS.html



Or, if you prefer them as quality paperbacks:
First Stringers: https://www.createspace.com/3463980
Second Stringers: https://www.createspace.com/3464933
The Hands of God: https://www.createspace.com/3466119
Mistress of Molecules: https://www.createspace.com/3390916
Freshman Murders: https://www.createspace.com/3469259
The Aremac Project:
Aremac Power
Earth's Endless Effort