What do you do when a kid beats your solution?

We were asked, "Has a software engineering interviewee ever come up with a better solution than the expected best answer?"

The question told me that the one who posed it hadn't done many interviews. As an interviewee, I did this often, though it was often met with defensiveness from the interviewer.

As an interviewer, it happens to me all the time, and I've tried awfully hard not to be defensive as I'd seen so many interviewers become.

Once on the job, too, software engineers frequently come up with better answers than their managers, teammates, or team leaders knew and expected. Or, I must admit, better than their consultants.

When this happens in any of these situations, it's important for the interviewer, manager, team leader, teammate, or consultant to accept the answer graciously, thanking the person for teaching them something new.

Even if the new idea isn't "better," if it's new, it's an opportunity to learn, so you don't want to spend your efforts trashing the idea. Just take in into your mind and offer thanks.

When I was a little boy, my father challenged me to learn something new every day before allowing myself to go to bed. Learning new things all the time is perhaps the most important behavior in my life. It's certainly the most important behavior in our profession

Generally, the most powerful learning occurs  when someone produces a better solution than you had imagined. If your ego cannot deal with “better” or even “different” solutions to problems you pose, you have no business being in a leadership position in software engineering.

Or maybe anywhere.

Read: Becoming a Technical Leader 

Some Advice on Advice

I was asked, "I'm very bad at taking my own advice but love helping people with their own personal issues. Does that make me a hypocrite?"

You seem to equate “advice” with helping people, but there are many other ways to help people without offering advice. And, of course quite frequently, even the best advice doesn't help at all.

(Note that I wrote “offering,” not “giving.” You offer, but they need not accept. Nor do you have to accept your own advice. You test it in your mind, or with small actions, and either follow or not, depending on the test’s outcome.)

If you like helping, try asking people what kind (if any) help they want from you. Perhaps they merely want a friendly listener. Or a pat on the back. Or a kick in the rear. Maybe they want you to clean their house. Or carry their heavy package. Maybe they just want a smile.

Stop worrying about labels like “hypocrite,” and start seeking ways to help people the way they want to be helped. Forget the advice business. As Ambrose Bierce says in The Devil’s Dictionary, “Advice is the smallest common coin.”

Can a Boss Take Corrections From Subordinates?

We were asked, "can a boss take corrections from subordinates?"

Certainly, some bosses can, but there are ways you can increase the chances of changing your boss, or at least your boss's mind.

I think that if the subordinate offers “corrections,” the leader is less likely to respond less well than if the offer is for “information.” That principle actually goes both ways. Most people are somewhat reluctant to take “corrections.”

So, if you are asking how you, as the underling, can “correct” your boss, I suggest you learn how to offer (not “give”) information. The boss can then decide whether or not to act on this new information, and how to do it. 

Again, this goes both ways. Leaders do better offering information than correction.

What Did You Say?: The Art of Giving and Receiving Feedback Revised Second Edition

So, study the feedback process and become proficient. That will be your best chance, but be prepared for failure. Some people simply will not change, even if banged on the head with a two-by-four.

If your boss happens to be one of those frozen people, it will be up to you to do the changing.

Maybe change your behavior. 

Maybe change jobs.

Becoming a Change Artist

New: #System #Design #Heuristics

You'd think that after publishing books for half a century, I'd know how to write a book. If that's what you think, you'd be wrong.

Sure, I've even written a book on writing books (Weinberg on Writing, the Fieldstone Method), and I've applied those methods to dozens of successful books. But way back around 1960, I started collecting notes on the process of design, thinking I would shortly gather them into a book. Back then, I didn't call these bits and pieces "fieldstones," but that's what they turned out to be: the pieces that, when assembled properly, would ultimately become my design book.

Ultimately? Assembled properly? Aye, there's the rub!

Building walls from randomly found fieldstones requires patience. So does writing books by the Fieldstone Method. My Introduction to General Systems Thinking took fourteen years to write. But a writer only lives one lifetime, so there's a limit to patience. I'm growing old, and I'm beginning to think that fifty years is as close to "ultimately" as I'm going to get.

So, I've begun to tackle the task of properly assembling my collection of design fieldstones. Unfortunately, it's a much larger collection that I'd ever tackled before. My Mac tells me I have more than 36,000,000 digitized bytes of notes. My filing cabinets told me I had more than twenty-five pounds of paper notes, but I've managed to digitize some of them and discard others, so there's only a bit more than ten pounds left to consider.

For the past couple of years, I've periodically perused these fieldstones and tried to assemble them "properly." I just can't seem to do it. I'm stuck.

Some writers would say I am suffering from "writer's block," but I believe "writer's block" is a myth. I've published three other books in these frustrating years, so I can't be "blocked" as a writer, but just over this specific design book. You can hear me talk more about the Writer's Block myth on YouTube 

[https://www.youtube.com/watch?v=77xrdj9YH3M&t=7s]

but the short version is that "blocking" is simply a lack of ideas about how to write. I finally decided to take my own advice and conjure up some new ideas about how to write this design book.

Why I Was Stuck

To properly assemble a fieldstone pile, I always need an "organizing principle." For instance, my recent book, Do You Want to Be a (Better) Manager? is organized around the principle of better management. Or, for my book, Errors, the principle is actually the title.  So, I had been thinking the organizing principle for a book on design ought to be Design. 

Well, that seemed simple enough, but there was a problem. Everybody seemed to know what design is, but nobody seemed able to give a clear, consistent definition that covered all my notes. I finally came to the conclusion that's because "design" is not one thing, but many, many different things.

In the past, I ran a forum (SHAPE: Software as a Human Activity Practiced Effectively) whose members were among the most skilled software professionals in the world. We held a number of threads on the subject, "What is Design?" The result was several hundred pages of brilliant thoughts about design, all of which were correct in some context. But many of them were contradictory.

Some said design was a bottom-up process, but others asserted it was top-down. Still others talked about some kind of sideways process, and there were several of these. Some argued for an intuitive process, but others laid out an algorithmic, step-by-step process. There were many other variations: designs as imagined (intentional designs), designs as implemented, and designs as evolved in the world. All in all, there were simply too many organizing principles—certainly too many to compress into a title, let alone organize an entire book.

After two years of fumbling, I finally came up with an idea that couldn't have been implemented fifty years ago: the book will be composed of a variety of those consulting ideas that have been most helpful to my clients' designers. I will make no attempt (or very little) to organize them, but release them incrementally in an ever-growing ebook titled Design Heuristics.

How to Buy System Design Heuristics

My plan for offering the book is actually an old one, using a new technology. More than a century ago Charles Dickens released many of his immortal novels one chapter at a time in the weekly newspaper. Today, using the internet, I will release System Design Heuristics a single element at a time to subscribing readers.

To subscribe to the book, including all future additions, a reader will make a one-time payment. The price will be quite low when the collection is small, but will grow as the collection grows. That way, early subscribers will receive a bargain in compensation for the risk of an unknown future. Hopefully, however, even the small first collection will be worth the price. (If not, there will be a full money-back guarantee.)

Good designs tend to have unexpected benefits. When I first thought of this design, I didn't realize that it would allow readers to contribute ideas that I might incorporate in each new release. Now I aware of that potential benefit, and look forward to it.

Before I upload the first increment of System Design Heuristics, I'll wait a short while for feedback on this idea from my readers. If you'd like to tell me something about the plan, email me or write a comment on this blog.

Thanks for listening. Tell me what you think.

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.

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, 

Becoming a Technical Leader 

The Psychology of Computer Programming

Get the Free “Change Your Life!” ebook

Do you want some great actionable tips and advice on how to improve your life from many top personal development experts (including me)?

You can download the free ebook “Change Your Life!: Experts Share Their Top Tips and Strategies for Reaching Your Highest Potential” by clicking the link below and signing up to the mailing list.

Click Here to Get the Ebook

There are many great personal development tips from dozens of authors and course creators. I’m sure you’ll get a lot of value from the free ebook and I’ve included my own best advice as well.

The free ebook is part of the Better You Bundles for Good promotion at the end of July. There will be dozens of courses and ebooks, worth thousands of dollars, all for one low price. If you are serious about becoming your best self, you won’t want to miss this opportunity. The Better You Bundle only lasts for 4 days so make sure you check your emails to be notified of the sale.

The best part is that 25% of the proceeds from the sale are going to support Courageous Kitchen, a charity helping refugees in Bangkok. As little as $100 per month can get a family off the streets in Thailand, so we can make a big impact with this promotion.

Here is the link for the ebook again.

Get the Ebook

Enjoy the book!

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.

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)

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:

Do You Want To Be A (Better) Manager?

Three Samples to Read: People Skills—Soft but Difficult

Over more than half-a-century as a "technical consultant," I've learned that most of the problems I've seen are not fundamentally technical problems, but problems arising from people—problems solved or prevented by the application of so-called "soft" skills."

When we call these people-skills "soft," we imply that they are "easy" problems. Not so. If anything, they are hard problems—especially for those of us who have chosen some "technical" profession.

I've gradually developed some skill at handling such "soft" problems. I've also developed some skill at teaching others to improve their ability to solve such problems. "Teaching," of course, is another one of these "soft" skills. Writing is yet another "soft" (but not easy) skill, and I have written a number of books on a variety of "people skills."

My clients have often asked me to write one giant book covering "all the people skills," but such a book would have to have more that a thousand pages, so I have not done so. (One of my people skills is understanding that there are few people who would even attempt to read a thousand-page book.)

Recently, though, one of my clients pointed out that I had already written much more than a thousand pages on people skills (duh!). Once I let that "obvious" information into my thick skull, I realized that I knew a way to make some of those pages more readily available to my readers. And so I created a bundle of seven e-books anyone can buy at a saving of 25% of the original prices.

To help you decide if this bundle is for you, I've created the following sample of small lessons clipped from three of my books.  You can read and enjoy these samples and decide if your own "people skills" could be improved by reading dozens of such little lessons, plus a number of large lessons in the form of pragmatic models of human behavior. If your answer is "yes," then I invite you to purchase the bundle—risk-free, with Leanpub's "100% happiness guarantee."

So, here they are. Enjoy!

Sample #1: Discussing the Indiscussible 

(from More Secrets of Consulting)

Over the years I’ve come to believe that they key moment in an relationships occurs when one or both partners feels there’s something that can’t be talked about. This could be one thing, or many things, and for a lot of different reasons. When that moment arrives, the one thing that must happen is that the two partners talk about that thing. 

As a consultant, one of the most important things I can do to improve relationships is get that indiscussible subject out and on the table—but that seems risky. When I begin to fear this risk, I remind myself of the terrible consequences I’ve seen when the partners don’t discuss the taboo subject.

For instance, I was asked to work with Bill and Sherman, the co- developers of a software product who weren’t talking with one another. In this case, the thing that Bill and Sherman needed to talk about was that the Sherman didn’t want to talk to Bill. He didn’t even want to talk about the fact that he didn’t want to talk to Bill, so I decided to approach the subject indirectly, to reduce risk. I went to see Sherman and showed him my Courage Stick, letting him hold it and feel it’s smoothness. 

“It’s nice,” Sherman said. “What is it?” 

“It’s my Courage Stick. I brought it with me because I wanted to talk to you about something and I was a little afraid you might not like it.” 

“You, afraid of me? I’ve never seen you afraid to say anything.”

“Oh, I get scared about lots of things I need to say, but my Courage Stick reminds me that there are also fearful consequences when important things aren’t said.” 

“Like what?” 

“Like if I don’t tell you what will happen to your company if you and Bill don’t talk about some essential subjects. Like how you’re going to have a product that sucks, and how everybody is going to infer that Sherman is a lousy software architect.” 

You see, I didn’t know why Sherman was afraid to talk to Bill, but I knew that this would tap into one of Sherman’s greatest fears and change the Fraidycat Formula. I never tried to get Sherman to admit that he was afraid of talking with Bill, and after a little more coaxing, I led him by the elbow down to Bill’s office. I stayed for a while to act as referee, but soon Sherman’s fear was a thing of the past. Later, Bill told me that it took a lot of courage for Sherman to approach him. I didn’t bother to correct his impression. 

Sample #2: Changing Geography

(A case study from Becoming a Change Artist)

Change is a long-term process, but a living organization lives in the immediate present. Thus, without careful management, long-term change is invariably sacrificed to short-term expedience. And short-term expedience is taking place all the time, everywhere in the organization, essentially out of the view of high-level management. That's why change artists have to be in every nook and cranny, as the following case illustrates.

DeMarco and Lister have given us much useful information on the effects of geography on software development effectiveness. One manager, Ruben, reading Peopleware, was inspired to change the seating geography to improve customer relations. His semi-annual customer satisfaction survey had given the developers very low marks on communication. So, instead of seating people for efficient performance of today's work, he wanted to seat them to encourage communication, by putting eight developers in the customers' offices. However, when he surveyed customers six months later, Ruben found a large decline in their satisfaction with communication, precisely in those offices into which he had moved a developer.

What had typically happened was this. The developer would move to the customer's office and set up shop. Communication improved, but the first time there was a software emergency, the developer would rush back "home" to get the problem solved. Emergencies were rather frequent, and soon the developer would find it expedient to establish a "temporary" office in the developer area. 

After a while, the temporary office was occupied 99% of the time. In terms of the Satir Change Model, the foreign element—Ruben's move—had been rejected. Even worse, the customers were left staring at an empty office they were paying for, which reminded them of how hard it was to communicate with developers. 

Ruben noticed, however, that in one customer's office, satisfaction increased. In that office, the scenario had been different. Polly, a customer and change artist, sat in the office next door to Lyle, the developer, and noticed how often he was missing. She listened to comments made by other customers, and then she took action. 

Interviewing Lyle, she discovered that there were two main reasons why he kept leaving to solve problems: 

• The PCs in the customer office had less capacity than the ones in the developers' office, and that capacity was needed to run debugging tools effectively. 
• There were two other developers Lyle needed to consult on most of these problems, and they still resided in the developers' office. 

Polly knew these were typical problems of the Integration phase of the Satir Change Model, so she simply arranged to have Customer Service upgrade Lyle's PC. She then explained the benefits of having the two developers come to the customers' office, which was, after all, only two floors away. They were only too glad to come, and the customers were fascinated to learn how much work it was to fix "simple" problems in software.

With Polly as Lyle's neighbor, Ruben's strategic concept was implemented. Without using his survey to connect the strategic and the tactical, he would never have learned that it was possible to make the new geography work, and the success would have been limited to Lyle's area. Polly was sent around to the other developers who had moved, and she managed to get five out of seven working smoothly by similarly upgrading their PCs and encouraging developers to solve problems close to where they occurred. 

Polly also had the change-artist's skill to recognize that the remaining two departments were having deeper problems with information systems—problems that wouldn't be solved by upgrading PCs or encouraging proximity. Indeed, she saw that proximity was only making matters worse because the people were unskilled in handling interpersonal conflict. Thus, instead of blindly applying the same solution to everyone, she suggested to the managers that certain people could benefit from training in teamwork skills. 

Sample #3: Context-Free Questions

(from Exploring Requirements)

Once we have a starting point and a working title for a project, our next step in the project is invariably to ask some context-free questions. These are high-level questions posed early in a project to obtain information about global properties of the design problem and potential solutions.

Context-free questions are completely appropriate for any product to be designed, whether it's an automobile, airplane, ship, house, a jingle for a one-minute television commercial for chewing gum, a lifetime light bulb, or a trek in Nepal.

In terms of the decision tree, context-free questions help you decide which limb to climb, rather than which branch or twig. Because context-free questions are independent of the specific design task, they form a part of the designer's toolkit most useful before getting involved in too many enticing details.

Context-Free Process Questions

Some context-free questions relate to the process of design, rather than the designed product. Here are some typical context-free process questions, along with possible answers for the Elevator Information Device Project. (Notice that because these questions are context-free, we don't need to understand anything about the Elevator Information Device Project, an example started earlier in the Exploring Requirements book).

To appreciate how these questions can always be asked, regardless of the product being developed, also try answering them for some current project of yours, like "Trekking in Nepal."

Q: Who is the client for the Elevator Information Device?

A: The client is the Special Products Division of HAL, the world's largest imaginary corporation.

Q: What is a highly successful solution really worth to this client?

A: A highly successful solution to the problem as stated would be worth $10 million to $100 million in increased annual net profit for a period of five to ten years. The product should start earning revenue at this rate two years from now.

Q: (Ask the following context-free question if the answer to the previous context-free question does not seem to justify the effort involved.) What is the real reason for wanting to solve this problem?

A: The Elevator Information Device Project is a pilot effort for a range of commercial (and possibly even home or personal) information transfer devices. If we can demonstrate success during development and early marketing phases, this project is expected to spawn an independent business unit with gross revenues in seven years of $2 billion per year.

Q: Should we use a single design team, or more than one? Who should be on the team(s)?

A: You may choose whatever team structure you desire, but include someone on the team who knows conventional elevator technology, and someone who understands building management.

Q: How much time do we have for this project? What is the trade-off between time and value?

A: We don't need the device before two years from now because we won't be ready to market it, but every year we delay after that will probably reduce our market share by half.

Q: Where else can the solution to this design problem be obtained? Can we copy something that already exists?

A: To our knowledge, nowhere. Although many solutions exist in the form of control and information display panels for elevators, the approach adopted here should exploit the latest in sensing, control, information display, and processing—so copying doesn't seem appropriate. We have no objection to your copying features existing elsewhere, and you should be aware of what else has been done in the field, so you can surpass it.

Potential Impact of a Context-Free Question

Are context-free questions really worth such a fuss, and why do they need to be asked so early? Let's look at another example—extreme but real—of an answer to the second question, "What is a highly successful solution really worth to this client?"

At 3 a.m., a man in dirty jeans and cowboy boots showed up at the service bureau operation of a large computer manufacturer. Through the locked door, he asked if he could buy three hours' worth of computer time on their largest machine—that night. The night-shift employees were about to turn him away when one of them said, "Well, it costs $800 an hour. Is it worth $2,400?"

"Absolutely," said the cowboy, who emphasized the urgency by pulling a large wad. of $100 bills from his pocket and waving them at the employees on the other side of the glass door. They let him enter, took his payment in cash, and allowed him run his job on the machine. It turned out he owned a number of oil wells. As result of his computations, and especially the courteous treatment he received, he bought three of the giant machines, at a cost of some $10 million. If the employees had assumed the answer to the "What's it worth?" question based on his appearance, there would have been no sale.

The People-Skills Bundle

To learn more about all 7 books in the bundle, take a look at 

https://leanpub.com/b/peopleskillssoftbutdifficult

If you like what you see, buy the bundle with its 100% happiness guarantee. And perhaps you have a friend or two who could profit from reading their own copy.