Dealing With Failure as a Developer

He asked, "How do I not feel like a failure when I went to one of the best schools and got one of the top internships, only to be a bad developer in the end?"

And here's what I told him:

First of all, tell yourself how lucky you are that you found out that you don’t happen to be good at development. Lots of people are good at other things, but aren’t good at development, don’t know it, and persist in doing a bad job. You should be extremely happy you’re not one of those clueless people.

Tell yourself that you failed at one thing, so far. Most people in their lives fail at many things. It’s perfectly normal.

The few people who never fail at anything are generally those who never try anything new, or risky. Tell yourself how lucky you are that you’re not one of those jerks.

When we try things, sometimes we succeed, sometimes we fail. But succeed or fail, we always have the possibility to LEARN. Many of the people who do fail at things never take up the possibility to learn, so ask yourself “What did I learn from this failure.” Keep asking like that for each failure, and you will become a very smart person.

It would also be a good idea to learn to use a different way of speaking about yourself. You are not “a failure.” You are a person who failed at something. Once. Therefore, you are a real human being. That’s pretty good, isn’t it?

For some tools to help you work through this feeling of failure, read: More Secrets of Consulting: The Consultant's Tool Kit

Which is Better, Writing on Screen or Paper?

I'm frequently asked, "Do writers and programmers feel more creative and expressive with pen and paper, or do thoughts come out as easily as when typing on a keyboard?"

It's a debate that I've listened to for more than half a century. Every tool for writing has some proponents. In other words, there’s no one way that’s better for every writer all the time. That's why the debate will never be settled. Even so, we can learn from it.

Personally, I have published a great variety of work—non-fiction, fiction, poetry, data queries, children’s stories, computer code, advertisements, polemics, applications. I've done so while writing

• by hand with pen or pencil or sharpie or marker pen

• on a manual typewriter or electric typewriter or computer keyboard

• with a stylus on a diver’s slate in a pool or shower

• with my toe in pink Bermuda sand

• with my voice into a recorder or computer voice-to-digital app

• with my bare finger on a touch screen

• with an electric router on a wooden beam

I may have used other approaches, but I can’t remember what else. I'm pretty sure, though, contrary to rumor, that I have not yet written with a hammer and chisel on a stone tablet. Something to look forward to.

Moral #1: if you’re a real programmer or writer of any kind, you would never let the lack of your favorite medium stand in the way of your writing.

Moral #2: If you want to be a real programmer or writer, for heaven’s sake, experiment with any medium you can imagine. You’ll find, as I did, that certain media are better for capturing your voice for each different coding problem, each different story, and each different type of writing.

So if your favorite tool isn't available, don't whine and don't shut down. Experiment instead!

Even if your favorite tool is available, experiment!

Besides, your primary tool is you, not the pen or keyboard or chisel, so keep experimenting with all those secondary tools that help you discover yourself.

And read Weinberg on Writing: the Fieldstone Method, which has taught thousands of writers how to experiment with their writing under every imaginable circumstance.

What should be my next step to becoming a better programmer?

What's your next step?

I'm guessing, but if you’re like most programmers, you’re already too involved in technical details, You may have mastered Python, Java, Ruby, C++, or a dozen other languages and platforms, but your ability to deal with other people is less than adequate.

Studies of programmers at work show that typical programmers spend 70% of the time dealing with other people. (Agile programmers may spend even more time). [See, The Psychology of Computer Programming]

- Do you ever misunderstand what you've been asked to do?

- Are you ever misunderstood when explaining what you're trying to do?

- Do you ever have fruitless arguments with your boss? With your coworkers?

- Do you ever have trouble dealing with people who are not as smart as you?

- Do you sometimes have trouble dealing with feedback about your performance?

If so, and you want to improve, perhaps you should devote some time to developing your People Skills.

At the very least, you'll learn how to solve "people problems" more efficiently, thus leaving you more time, in a better mood, to do the technical work of programming.

Next step? Take a look at this bargain bundle:

People Skills—Soft but Difficult

False Urgency

What should I do with a client or boss who insists that a certain task is urgent, but it turns out to be likely a false alarm?

In your mind, subtract 10% from this persons trust account, then watch for the second occurrence. It might be a one-time mistake or it might be a person who thinks every little thing is "urgent."

If it happens again, tell him or her that you charge double (or triple) for urgent tasks. If he or she isn’t willing to pay, then find another client.

If you're an employee and this is your boss, you obviously can't charge them with money, so you have to find another way to make them pay. My favorite way was simply to ignore them and proceed at my normal pace, in priority order. I never got fired for doing that, particularly when it became evident to everyone that the urgency was false.

This is just one of the ways you have to train your clients and your managers if you want to be a successful employee, contractor, or consultant.

The Secrets of Consulting

Must There Always Be Inferior Code?

Some people claim that when you learn high software standards you will never again develop in inferior ways. Is this true?

I think you can arrive at a meaningful answer by using an analogy:

Some people claim that when you learn high medical standards, a doctor or nurse will never again treat a patient in inferior ways. Is that true?

Seen in this light, the answer is obvious. Most doctors and nurses will not treat patients in inferior ways—unless it's an emergency, like an explosion or a fire in which many people need saving in a hurry. If that happens, the doctor or nurse will return to those patients when the emergency has calmed down. Same in software.

But there do exist a few medical professionals who don’t live up to such high standards. They are, after all, human beings. Yet in spite of their inferior practices, some of their patients do get better. Why? Because humans have built-in healing mechanisms—but software does not.

Software with sick code doesn’t heal itself. Those programmers who develop in inferior ways will eventually produce troublesome code. But the key word is "eventually."

The inferior programmer may not be around any longer when the code's trouble makes itself known, so some inferior programmers can get away with hacky ways for an entire career.

It’s a good manager's job to recognize these inferior programmers and replace them and their code before the true costs of their inferior work become evident.

Some managers overuse the tactic of forcing programmers to code in a hurry, as if there's always an emergency. Just as in medicine, emergency treatment of code tends to produce inferior results. Managers who care only about the short-term will not do anything about their inferior programmers, but they, too, may move out before the consequences of their inferior management become apparent.

That’s why inferior programming practices persist. And, as long as programmers and managers are human, inferior practices will always persist. But they don't have to persist in your world. It's up to you. \

Code in haste, debug forever.

Why is reading or writing something different from doing something?

First consider reading. Reading is (usually) a solitary activity, with no feedback. Without feedback, there's no check on what you believe you're learning.

Now, writing. Unless you put your writing in the hands of someone (or perhaps some computer analysis app), there's also no feedback, so there's no check on whether you wrote sense or nonsense.

When you do something, you interact with the real world, and the world responds in some way. With the world's feedback, you have the possibility of learning, confirming, or disconfirming something. That's why we strongly favor experiential learning over, say, lecturing or passive reading or writing.

If you want to teach somebody something, don't just send them to a book, or, even worse, tell them what you want them to know. Instead, figure out a way to have them experience the situation in which the learning applies.

After they've had the experience, you then might want to send them to a book where they can read about what they experienced.  Alternatively, you might ask them to write about their learning and have you read what they wrote.

You can try this out:

Step 1. Write a sentence or two about what would happen if you tried to move your desk six inches (15 cm) to the left or right.

Step 2. When you finish writing, get up and move your desk six inches (15 cm) to the left or right.

Step 3. What did you learn in steps one and two?

For a far more thorough answer to this question, see my four-volume series on Experiential Learning 

<https://leanpub.com/b/ExperientialLearning>

Then do some of the experiential exercises you find there.