I've been reading Carmine Gallo's book, The Presentation Secrets of Steve Jobs, because of the obvious motivation: I want to improve my presentation skills. To my happy surprise, Gallo also makes a few brilliant observations about leadership that I believe can help any programming team lead, IT manager, or CIO. Primary among them is the importance of passion about what you and your team are doing. I haven't even finished reading the book, yet, and I want to share this with you.

One element in a successful presentation (whether to the board of directors or to your staff) is, as Gallo describes it, to speak with passion, enthusiasm, and energy. Behind Jobs' charisma is a messianic sense of purpose. "Communicators such as Steve Jobs and [Starbuck's] Howard Schultz are passionate about how their products improve the lives of their customers," writes Gallo.

Jobs convinced his programmers that they were changing the world together, points out Gallo, making a moral choice against Microsoft and making people's lives better. For example, the iPod was never just another MP3 player, but a way to bring music back into people's lives. "It's a wonderful thing," said Jobs in 2003. "And in our own small way, that's how we're going to make the world a better place."

Such people create loyalty and user dedication because they talk about things that are more important than money. Despite our cynicism, people really do want to participate in something that's larger than they are, and to believe that their actions can improve the world. Gallo cites research by the authors of Built To Last: Successful Habits of Visionary Companies, which concluded that individuals are inspired by core values and a sense of purpose beyond just making money. If you're thinking in terms of improving your skills at PowerPoint you likely think of those individuals as the people to whom you must sell — customers and users in other company departments. But the advice applies equally to the staff you lead. If your team shares your passion and your vision, you may create inspiring products... even if that's just the greatest accounts payable web application the world has known.

Maybe you think that your IT team's products aren't quite as important. (Though if Apple had positioned the iPod as "just another MP3" player, it wouldn't have been such a game-changer, either.) Don't sell yourself short. As Gallo eloquently writes, "Most of us are selling a product or working on a project that has some benefit to the lives of our customers. . . You have a magnificent story to tell. Dig deep to identify that which you are most passionate about. Once you do, share that enthusiasm with your listeners. People want to be moved and inspired, and they want to believe in something. Make them believe in you."

Steve Jobs said: “We’re here to put a dent in the universe. Otherwise why else even be here?” Why indeed?

I asked dozens of people — developers and others — to tell me the story of their worst hiring decision. What made it the worst? What could they have done differently, if they'd known better? (And could they have known better?) How did that experience change their hiring practices?

My intent was to identify typical mistakes, so that you, O Faithful Reader, might avoid them. You may be in a position to hire someone today, or next year... or you might be the hire that didn't work out. See how many of these situations seem uncomfortably familiar.

I found the answers to fall neatly into a few categories:

• Making an emotional decision instead of considering the facts
• Not objecting to the hire when you knew better
• Imagining that everything would be different despite the candidate's earlier experience
• Failing to test for domain knowledge

Making an emotional decision instead of considering the facts

The majority of the worst hires came from people choosing an employee an emotional reason (such as "I wanted to her give a chance") or, on the flip side, by refusing to listen to one's own emotions. This is admittedly contradictory (what else is "This person seems like a good fit with the team" other than an emotional decision?) but perhaps the lesson here is to trust your intuition.

For example, Craig was promoted to manager at an early age — he was just 19 — and found that he repeatedly hired the wrong people. Finally, he realized "I'd hired them on the basis of me 'liking them' and not on the basis of 'their ability to do the job' or 'the skills they would bring to the team.'"

Craig is far from the only person to be distracted by emotional responses. Several years ago, Ann needed to bring on an assistant for her role as marketing research director at a mid-sized company. As she explained, "We had a difficult time finding the right person, and some of the candidates who were good were lured by a larger salary, elsewhere. So when Chris showed up, I was feeling desperate. His resume was good; several years of experience with all the kinds of things I needed him to do. He seemed pleasant, if a bit formal, but he was European, so I chalked it up to that."

Now, Ann wishes that she listened to the inner voice that was uncomfortable with Chris, even during the interviews. Although his resume was quite appropriate, "My instinct told me there was something not quite up to my standards," she said. "I should have listened to it and not hired him."

Unfortunately, Ann found, when Chris got to work, he was slow. Really slow. Worse, his work was mediocre. "With a lack of productivity, mediocre just didn’t cut it. If I had to review and correct everything he did, what good was he to me?" she said. "I knew I had to fire him after only six weeks. It was clear he wasn’t going to get any better." With HR's help, Ann met with Chris to give him the good news (things he did well), the bad news (things that needed improvement), and asked him to write a plan for how he would improve those things. "He never did it," Ann said. "A couple of days later, I asked him for the memo regarding his plans. He responded that he had no intention of writing such a memo because he didn’t agree with my assessment!" Chris didn’t last much longer at the company.

These reasons aren't always based on ill intent or incompetence. At one point, Eugene's company permitted him to hire contract programmers to help out the team. One candidate, who was older than most of the other developers who applied, appeared to have the right experience. "I myself was already close to the 'protected' age so I thought that we had to give the guy a chance," Eugene explained. "I had (and still have) quite personal aversion to age discrimination."

However, choosing a developer for one good reason caused Eugene to ignore other problems. The contract programmer had a substantial commute time, and — apparently to beat the traffic — he was on the road quite early. "As a result, he was literally sleeping in his cubicle," sighed Eugene. Certainly, that didn't help out the team, and the developer was released before the end of the contract.

Not objecting to the hire when you knew better

Sometimes, the problem isn't that you didn't listen to your gut. It's that you didn't have the nerve to speak up, or the authority to say No.

For example, Ida's company once brought in a job candidate with cowboy boots, pony tail, and "the biggest whitest teeth you will ever see." Although he had a great background and met all the requirements, Ida didn't want to hire the applicant because she got a bad vibe about him. But the general manager liked the candidate, an opinion he soon regretted, Ida said. Only two weeks later, the new employee began to show up late, and he ignored company policies. "Later, we found out that the references we called were buddies he worked for," muttered Ida. "All that this guy would talk about was how much money he spent on his teeth." He — and his teeth — departed after only three weeks. "Sometimes following your instincts is the best path to take," she concluded.

Donna, too, wishes that she trusted her instincts. She had been hired as the editor for an international church magazine, and was expected to hire an assistant editor quickly. Her director recommended an acquaintance with reasonable credentials. "I had a fleeting but strong negative feeling in the interview — no specific problems I could identify," said Donna. "But my director and the departing director loved her! I didn't, but I didn't have the gumption to say so." Needless to say, the assistant editor was a disappointment. "She was difficult to work with, even belligerent." The relationship never became easy. "This situation was especially challenging because our parent company is a church which wants to see the best in everyone," added Donna.

"Next time," concluded Donna, "I will listen to my intuition and follow it. I will dare to say, 'I just don't get a good feeling about this person.' I will urge my superior to allow me to take the time to find the right person, even if my concern is based only on a 'gut feeling.'"

Sharon's worst hire was a forced choice, too. The position to be filled primarily required analytical skills, interpersonal skills, and personal organization. Sharon had five qualified candidates. The two top contenders included one person who was then working at the company as a contractor, and a graduate student working elsewhere in the industry in a more specialized field," she recalled. "My interview with the graduate student revealed a lot of drive and a wish to work somewhere else in our company. My interview with the current contractor revealed a willingness to continue to do the job," she said. Sharon wasn't entirely satisfied with the contractor, but she could tell the graduate student would not stay.

"Because I felt pressured, I agreed with other interviewers and managers and decided to hire the contractor — against the best judgment of the person then my boss," Sharon said. The result was "an experience of intermittent mediocrity, with occasions of inappropriate behavior." It also became a dividing factor between Sharon and her boss." The moral of her story: Don't make compromises. "If neither choice A nor choice B are compelling, stand your ground and ask for choice C. Even if choice C is going back to the drawing board and getting a whole new set of applicants, it's better than known dissatisfaction," Sharon learned.

Imagining that things would be different from the candidate's earlier experience

We all want to believe in others' goodness, but sometimes it isn't justified.

Twenty years ago, Deborah needed to hire an experienced TV tech for a temporary position. The TV station where she was assistant chief engineer moving to a new facility that had to keep operating during the move, and the staff was spread thin. Deborah interviewed a fairly young guy with over 10 years experience at a competitor. When she checked his background, she learned that he had been fired, but peers at the other station told her, off the record, that the firing had been questionable. "He had fallen asleep on duty after several very long shifts. My personnel person checked with her peer and they said the guy was a real problem and they were happy to be rid of him. But the choice was mine," said Deborah.

Yet, this was a temporary position that could be terminated at any time; Deborah gave it a try. "Well, the personnel person was right. The guy showed up late and was a problem. Even before his temporary assignment was over, I had to fire him." She wishes she hadn't comprised her job selection criteria. "I really wish I had never hired this guy!"

Sometimes, the error is even more basic. Richard learned to check references after one bad experience in which "I placed a professional con-man into a role with one of my key clients," he said. The candidate claimed 10 years of B2B sales experience (both on his CV and face-to-face) and said he'd generated millions of pounds of sales. "In reality he had no relevant experience for the role and his CV was a complex tissue of lies and half-truths," said Richard. The candidate was, however, adept in one thing: getting the job. He demanded and received a hefty signing bonus and a guaranteed commission for his first three months. But the salesman was fired after a few months when it became apparent that he wasn't actually doing anything. "When they later followed up on his references it turned out that he'd run this scam on at least a half-dozen other companies over the previous few years; e.g. joining and demanding a bonus, car, guarantees, etc., then completely under-performing."

Perhaps we all have reason to distrust the validity of job references. But situations like Richard's make it clear that doing so can save you from at least a few disasters.

I'm all in favor of phone interviews — as a telecommuter, most of my job offers came after a phone interview — but Matt's experience demonstrates why you might want to bring in the candidate before signing the paperwork. Matt's company brought in a developer on contract, hired via phone interview. Shortly after the developer started, the supervisor asked Matt to work with the developer, who had a slight but distinctive lisp. Working with the contract developer was an odd experience, said Matt; the programmer had to be told what to do every step of the way. "For example, he was doing database programming, and he didn't understand that when he had compiled some code, it had not run. He couldn't figure out why the values in the database hadn't changed."

Eventually, Matt realized that the contractor regularly was visiting a friend in a different department; the friend would fix his code. After seeing this happen two or three times, Matt asked the developer if he had actually ever programmed in PL/SQL before; he said yes. "I told him that if he was new, that was okay; I just needed the truth. He said yes, it had just been a long time. So I asked him, 'When you wrote code in PL/SQL before, what did it do?'

"Long pause. Finally he says 'looping.'"

Matt told the supervisor about the problem. The supervisor said, "You know, the guy we talked to on the phone interview? I don't think he had a lisp." Matt added, "That was one of two hires where we called the vendor and got our money back."

Failing to test for domain knowledge

The purpose of a job interview is to find out whether the candidate is suited for the position and the team. But sometimes we make mistakes that seem obvious — in retrospect. (There's no better evidence than my earlier blog post, 19 Ways to Know The Software Development Job Interview is Over.)

Seven years ago, when Eric was an IS manager at a Minneapolis-based company, he hired a system manager/support technician — perhaps in title only. "I asked him to make a 8’ CAT5 cable. I then left for the day," said Eric. The next day, Eric found the cable on his desk with a note, "I've tested it and it works." But when Eric picked up the cable, both the terminators fell off. "Not only were the wires not in any particular order; they hadn’t even been punched! This seemed to me the computer equivalent of hiring an auto mechanic who tells you a car has been road tested, and when you pick up the car you find that the tires have been stacked in the back seat."

Eric said he should have better evaluated the fundamentals during the interview, rather than just seeing if the candidate knew the lingo. Don't trust that experience on a resume means comprehension, he learned. "I hire now based more on tests and challenges (like Google does) versus just talking. Heck, in the IT field, evaluating a candidate based on their communication ability could weed out some of your best candidates!" he said.

Eric might have decided to use more assessment tests, but Anthony has learned not to put too much trust in them. "I have had people who have scored so-so and turned out to be my best hire — and then my worst hire to date scored off the charts."

The "test-taking success" was a referral of one of Anthony's best workers, which you think would also be a good sign. But, said Anthony, the candidate's work statistics were sub par at best. Anthony spent extra time time with the guy. "I had to speak with him about goals and warn him about performance," he added. "A few weeks later I come back from lunch and he is on a poker site, gambling!" Anthony took the employee into a private room to explain that it was a violation of company policy. "He did not understand why he was not allowed to be on a gambling site; since he was on his lunch break, it should be ok. He went on to say, 'It's not like I am looking at porn.' I was almost amazed that he didn’t get it, much less said that in his defense." A few days later, Anthony found the employee sleeping in his cubicle. "So much for assessment tests," Anthony grumbled.

Most important in domain knowledge, perhaps, is understanding the real qualifications for the job. As evidence: Ian's first job was executive director for a small, rural animal welfare organization. Part of his responsibility was managing the staff of the animal shelter, and among his first duties was replacing one of the kennel attendants. "The kennel attendant's primary job was to make sure the animals were fed, and that their areas were kept clean. They scooped a lot of poop for $5 per hour," Ian said.

Full of his 22-year-old's wisdom about hiring from college management classes, Ian obviously knew exactly what to do! "I ran an advertisement in the local paper, collected applications, and reviewed them thoroughly, looking for excellent work histories, strong references, etc. I selected 10 for interviews and spent the week asking each about their career goals, strengths/weaknesses, etc. At the end of the week I selected the 'best' candidate. She had an associates degree, seemed smart, outgoing, and expressed interest in being a veterinarian some day." But the woman turned down the job, as did the back-up selection. The third accepted the job but quit on the first day. And so on.

"Luckily, my shelter manager (and 10 year veteran of the organization) Vicki, poked her head into my office," Ian said. "She could tell I was distraught. She asked me if I'd like her to show me how to hire a kennel attendant. Absolutely."

Vicki tossed out applicants with bachelors or associates degrees, and re-inserted the ones Ian had rejected for not graduating high school. "She then looked for those who had the toughest recent jobs — chicken house workers, unskilled manual laborers, etc. — and made a pile." Vicki sorted the pile in order by who was made the least amount of money. At the top of the list was a young woman who was making $4.75 at a chicken house on the evening shift." Vicki has Ian tell the woman to start the next day. "I followed Vicki's instructions, and sight unseen our new kennel attendant showed up the next morning ready to work. She appreciated the $.25 raise, was very excited about day shift, and didn't say much, so spending all day with the animals rather than co-workers at the chicken plant was just fine with her. She stayed for well over a year, an unheard-of tenure in that position."

The lesson — even for developers — is to think about every hiring situation as its own unique event. (There's probably also another analogy about shoveling animal poop, but I'll resist that urge.) Said Ian, "Each position has individual requirements and challenges that will define the best strategy to attract and retain the right person for the job. Most importantly, I learned the value of asking questions of those who have the subject matter expertise before anything else. You can only make good hires if you invest the time in truly understanding what the right hire looks like."

Share your own "worst hire" story — and let's see if it fits into the categories I identified. We can always make new ones!

You probably should follow me on Twitter. Because, y'know, you just should.

This is an old question, but it's one that comes up at least once in every developer's career: How do I get a job using the skills or tools I want to use, if my current employer doesn't give me an opportunity to use them? I just found a variation on the question on a developer's discussion forum (edited slightly for clarity):

"I'm looking for work and am considering doing a sample website. What should I put in it to be appealing to prospective employers? Should it just be a content management website? I want to do the site in C#.NET to show I can, because my work experience is with VB.NET. I've been thinking about using modules from 'BeerHouse' done in ASP.NET 2.0, and dress it up in different CSS, but maybe that's trite."

This developer's example is .NET-related rather than Java, but obviously the technology isn't the issue. It's a question of selling yourself. And for that, I have some advice to share.

Primarily, the answer to the developer's question (or your question) depends what you want to accomplish. If the site is meant to be your Hello World project to teach yourself a new skill, and you expect to cheerfully make your mistakes in public, then it doesn't matter much what content you use.

But it sounds as though the developer who wrote that post is hoping to turn the website into a showcase of his skills to attract an employer and to demonstrate that he can use a technology that doesn't appear (yet) on his résumé — a desire that you might have, too. In that case I'd tune the site to the technologies (languages, Ajax, etc.) that you'd use in your ideal new job. (i.e. "In the best of all possible worlds I'd use the Dojo toolkit and...") If you're going to the effort, be sure the skills you display are the ones you actually want to sell!

However, employers often are dubious about "See, I can do it!" sites or projects. For good reason, I think. First, the employers know that in a "sample" site, the only arbiter of quality is you. You might be happy with the results even if the code sucks underneath and it's completely undocumented. Also, there's no guarantee that you know how to finish a project in that language, using that CMS, or whatever. That's fine for a "hello world" project but it doesn't demonstrate that someone else signed off — which would indicate that someone besides you thought this was good (or at least good-enough to say Yes to, presumably including a check).

If you want to demonstrate your non-résumé skills to a prospective employer, I have two suggestions.

First: Find a nonprofit or other local Good Works organization and volunteer to build their website. At a minimum, doing so is a healthy thing to do for karmic reasons; presumably you'll pick an organization you want to help. If nothing else comes of this, you will have helped an organization you believe in, and that's worth quite a bit emotionally.

Since the community organization isn't paying you much less setting any specs, you can use whatever tools you like, whether that's the latest CMS you've been wanting to pick up or a new programming language. Also, they can't hold you to a deadline. So, if you discover that the new language is ill suited for the task or that you have to rip it out and start all over, you don't have to make compromises. That is: You can diddle with the technology as much as you like, and nobody is going to stop you.

Since you can make the project scope as big or small as you're willing to take on, nothing forces you to supply every possible bit of functionality. I recommend under-promising and over-delivering; freebie clients have a way of being the most demanding! Alternatively, map out the project in phases. If you do get a job in the middle of the project, you don't want to leave the organization with a site half-done. (This might be a good time to develop your Agile skills, too.)

Yet, the resulting website can help you get a new job because you've demonstrated that you can work with the technologies, not just play around with them.

In most cases, you'll have a grateful organization and a reference to include with your job application. Plus, because it's pro bono, it's a good way to pick up the new skills and ready yourself for the next position while you're working at a job where you can't wait to hand in your resignation notice; it's not like your employer can complain about where you volunteer.

Don't be surprised if the volunteer gig leads directly to real work. Organization members just might say, "Hey, can you do a website for my company, too?" I wouldn't count on it, but those happy users may know someone and be happy to refer you or pass along your résumé. There's a reason people are always telling you that networking is a good way to find a new job.

This is important: Nobody has to mention that you weren't paid for this project. The new employer doesn't really care what your billable rate was; they just care that you can create a working site using those cool new technologies. If someone does mention that you did the work for free, it will be with expressions of "Oh how nice!" rather than "He did it for peanuts so clearly is desperate for work and will accept a low salary offer."

Aside from the technology exercise, working with the community organization also lets you show off project management skills, as you'll interview the users to find out what they want, design the application, and so on. That can't look bad when you apply for a new job, even if it's not your primary goal here.

My only caution is to think carefully about the Good Works organization you choose. If you aim to use the experience to get new work, you may want to steer clear of religious or political organizations. That doesn't mean you shouldn't help out your local church (because presumably you want to help those you believe in) but consider carefully if your choice could offend anybody. Why annoy your manager before you have the job, when it's so much more fun to wait until you're hired? If a prospective manager happens to be aligned with an "opposite" belief system — well, why hurt your chances? I think of this as flame war avoidance.

If you don't want to take on an entire project, or no nearby Good Works organizations appeal to you, another alternative is to get involved in an open source project that uses the skills you want to sell to a prospective employer. As with the local community support effort, you get the benefit of something to show off. However, you also have the opportunity to learn (and hone) the technical skills by working with other developers from whom you can learn. I wrote about this at length elsewhere, including how to describe your open source experience when you apply for a job, so I won't belabor the point here.

Either way, these are good options for any developer who wants to polish a résumé. Any hiring manager (at least the ones you want to work for) wants to bring on passtionate developers who are willing to do something extra to improve their skills, and the volunteer contributions are a great way to prove it.

You probably should follow me on Twitter. Because, y'know, you just should.

One topic I haven't particularly addressed, however, is who pays for a remote staff member's expenses. I don't mean the laptop the company gives you to work on; I think your basic computer hardware is a given. I'm thinking about the other bits and pieces that an employer supplies in an office environment, such as long distance expenses, telephones, Internet access, and office chairs.

This was brought home to me (so to speak) sometime in the past few years. My chair broke one day. It just toppled over. The right arm fell off and the screw came out the bottom. Faced with yet another trip to the office supply store, I contemplated just how much time it takes to wear out a chair (mine seem to last two or three years) and noted — with some attitude, I confess — that most of that time was in the service of my employer. So I asked my Human Resources person if the company would pay for a new office chair. After all, I reasoned, if the chair broke in the office they most certainly would give me a new one. After some negotiating, she gave me an "allowance" of $400 for a new chair. That felt fair; if I wanted to spend $1,000 on a chair, then the company would have done its part.

But when I got in a conversation with a telecommuting coworker about the subject, she was astonished that I had even asked. (You aren't. By this time you know that no one ever described me as shy.) Her chair had broken too (a $49 typing chair — sheesh, folks, don't you believe in quality?! —but that's a rant for another day) and she was going to ask if the same policy could be applied to her. I don't know if she did so; I've wondered.

As it turned out, the chair was fixable, so I fixed it. I might have invested in the better chair, except around then I also decided it was time to start looking for another job. I hadn't discussed with the HR person if, when I left the company (in a month, a year, or five years), they'd expect me to send back the chair they'd paid for. If I left within the next few months, I was pretty sure her answer would be Yes (who'd blame her?), and I didn't want to contemplate the mess it'd be to box a chair to send cross-country. And what if I did buy a more expensive model? Plus I wouldn't have anything to sit on. So I just let it slide.

But all of this demonstrates how ill-prepared any of us are for working-at-home while we're employed by someone else. A programmer might feel justified in asking for a large monitor or at least an extra mouse. Another boss gave me a company BlackBerry to use for all my interviewing so I didn't have to worry about expense reports for my long-distance bill. But when I asked one employer to cover my Internet cost, he said No because I'd pay for Internet access from home anyway.

Obviously, there's little consensus about what employers do or should cover. Many businesses are reluctant to let people work from home except under duress, a fact that continues to irk me.

But some of it may be an issue of education, even with telecommuting on the rise. According to a recent Cisco study of 502 U.S. based IT decision makers, 53 percent reported that less half their employees were currently set up to work remotely. Most businesses (especially their HR departments) are conservative about change, and letting people telecommute (much less encouraging it) is definitely a big change — with little useful business guidance. It's been a couple of years since I really pored over any of the books about telecommuting, but when I last did so, most were pretty lame. They were mostly oriented towards someone who needed a pep talk to understand the experience (such as warning you to train kids to understand you aren't to be disturbed, and many people do need that lesson). Several are aimed towards the self-employed for whom "work at home" is a synonym for "become an entrepreneur." The newest crop of telecommuting books appears to recognize that telecommuters require slightly-different management, so perhaps they're better now. I hope so.

So perhaps we can enlighten each other with the poll I put together. If you telecommute for an employer (other than yourself), or you did so in a recent situation, please answer it so we can all see what employers will commonly cover. (Note that polldaddy's multiple-choice option shows odd percentages. If you check two items, it "counts" each as 50%" rather than reporting that, say, 100% of employers pay for laptops. But it'll still show us what's most and least common.) Also add to the comments sharing your experiences in asking the boss to cover telecommuting expenses. What worked, and what didn't?

You probably should follow me on Twitter. Because, y'know, you just should.

For instance, one Heinlein comment that has a prominent place in my Quotes file (and I used often back when e-mail .sig files were common) is, "They didn't want it good, they wanted it Wednesday." Heinlein unquestionably understood (and was frustrated by) the deadlines his editors demanded. I can't for the life of me remember where I read about Heinlein's annoyances with the editors, particularly with regard to his "juveniles," but their (to-him) unreasonable requirements were part of what chased him away from that market.

The point is, though: Deadlines are real. They are incredibly annoying to anyone who has a creative spirit, but (speaking as a longtime editor here) sometimes the issue is less about getting a project done perfectly than it is about getting it done on time. Then again, as any manager knows, one must wrest a creation from its creator because, left to that creator, it will never be considered done. "Art is never finished, only abandoned," admitted Leonardo da Vinci, and the people who have the silly idea that a creator should deliver on a schedule have been cranky every since.

If you have a boss or a business client who understands that "good" ought to trump "delivered on time" (particularly when it's an arbitrary and capricious deadline), appreciate her.

"The most important lesson in the writing trade is that any manuscript is improved if you cut away the fat." This quote, which I found in Advice to Writers: A Compendium of Quotes, Anecdotes, and Writerly Wisdom from a Dazzling Array of Literary Lights, probably doesn't need much explanation to software developers, or at least I hope it doesn't. Elegant works of creation (whether software or stories) are almost never cluttered. The first draft is only a first draft — and it should never been confused with a finished piece. It isn't done until it's re-done, and that usually means turned into something that's more concise. Nowadays we'd use terms like "refactoring," but I have an old quote from Grady Booch in which he said, "The task of the software development team is to engineer the illusion of simplicity." That usually includes "cutting away the fat," no?

Here's one Heinlein (character) sentiment that I agree with and disagree with: "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a well, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."—Lazarus Long, in Time Enough for Love. I've spent most of my career trying to find a balance between "specialist" (deep but narrow knowledge) and "generalist" (knowing something about everything, but nothing about everything); I suspect you've struggled with that, too. When I first became a computer consultant, I had a long argument with a friend about the subject. Paul's view was that it was important to be considered the #1 expert in at least one category (his was accounting software, at least in the Columbus, Ohio region), because people want to hire the expert. I came to agree with Paul that it's easiest to build a career as a specialist. Yet it's easy to know everything about left-handed widgets and nothing about the right-handed variety, or about anything else, for that matter. That's a particular danger when the market for left-handed widgets goes away (as I learned painfully after becoming one of "the" experts on IBM's OS/2 operating system). So I agree with Heinlein about the importance of self-sufficiency... and I also disagree with him. The Heinlein quote helps me keep myself in balance.

I tend to write a lot about making programming teams successful, as you may have noticed (when I'm not writing about things like 10 Business Lessons I Learned from Playing Dungeons & Dragons). And one premise which I accepted long ago was the advice given to the teenage Podkayne by her uncle, "Politics is good even when it is bad... because the only alternative is force—and somebody gets hurt," in Podkayne of Mars. As much as we all hate "office politics," Heinlein (speaking through the uncle) is right when he says, "Politics is not evil; politics is the human race's most magnificent achievement. ... Politics is just a name for the way we get things done without fighting." I try to keep this in mind during serious team hissing-and-spitting. Not always successfully.

One attribute of Heinlein's personal philosophy with which I can wholeheartedly agree (even during the aforementioned hissing and spitting) is the importance of opinion diversity in a team. My father taught me, "When two business partners agree all the time, one of them is unnecessary" and I have always believed it's among my duties to question authority. (My father appreciated that attitude less when I reached my own teen years and it was his premises I challenged.) Certainly, you've seen me write rather often about the necessity of being wrong in order to achieve a higher degree of wisdom. This viewpoint has a distinct influence from Heinlein, who said both that A society that gets rid of all its troublemakers goes downhill (a viewpoint I touched upon in my other blog last week, The Decline and Fall of the Idealistic Spark) and I never learned from a man who agreed with me.

Sometimes, I learned from Heinlein indirectly. One such lesson is: Your initial work is rarely your best; give yourself permission to fail, as long as you learn from the failure. This isn't a Heinlein quote, per se, but my own observation after reading his first-written novel, For Us, The Living: A Comedy of Customs, which was released several years after his death. He couldn't get the book published in the early 1930s when he first wrote it (for reasons that are obvious to a modern reader). Yet it's obvious that he used it as the source of many other story ideas. In fact, that was one of the many weaknesses of that first novel: It tried to do too much. (Does your software?)

On the other hand, the not-so-hotness of For Us, the Living should encourage you that even if you aren't a great programmer today, with dedication to your craft (and a willingness to write a lot of code), you could become one. Heinlein wrote For Us, the Living two years before he submitted "Lifeline" (his first short story) to a magazine; two years after that (according to Spider Robinson's book introduction), Heinlein was guest of honor at the Denver SF WorldCon. This novel demonstrates how much even a master has to learn — and what's really astonishing is how fast Heinlein learned it. (Four years from this to the WorldCon?!)

That's some of the things I learned from Heinlein. (And perhaps I inspired you to do a little more SF reading.) What did he write that influenced you?

You probably should follow me on Twitter. Because, y'know, you just should.