Surveys say that despite the record unemployment in the U.S. and much of Europe, jobs are still going unfilled in software development. Hiring managers cite a shortage of qualified candidates. This makes it more important than ever for development organizations to hang on to the workers they’ve already got.

We know, however, that in general, developers tend not to stay in one place for long. Employee retention plans aren’t working.

If you’re in charge of a development team, you want to hang onto the workers you rely upon. So it’s important to understand why they leave. I found a good analysis of the factors leading to worker defection in an article at forbes.com. Author Eric Jackson lists 10 reasons large companies lose their top talent. I think most of the reasons apply to small and medium-size companies too.

First on Jackson’s list is bureaucracy. No one likes rules that must be followed just because they are rules. Jackson says that when an employee cites meaningless rules as the reason for their departure, what they really mean is that they had no voice in creating the rules. Nothing creates worker alienation faster than being shut out of decisions about how they do their work.

The second reason workers leave, Jackson says, is that they are assigned to projects that don’t interest them. We don’t often ask our employees which projects they’d like to work on. If we did, there’s a better chance they’d remain excited about the work and stay on the job.

Rushed, superficial performance reviews are third on Jackson’s list. When supervisors don’t take the time to do a thorough review of a worker’s performance, the worker can rightfully conclude that the company isn’t invested in helping him do a better job and advance. Rushed reviews show a real lack of regard for the employee’s future.

The employee’s future is key to Jackson’s fourth factor as well. Too few companies, Jackson says, take the trouble to engage employees in discussions about career advancement. To keep key employees, take the initiative in discussing career development. Outline how they can gain more authority, autonomy, and compensation with your company.

Fifth on Jackson’s list is shifting whims. When the company changes its course frequently, and is always pushing employees to commit to a new set of strategic priorities, workers understandably feel jerked around. Employees are happiest when the company has and maintains a long-term vision.

Next: feedback. Workers, even top workers, need to hear what they could be doing better. If nothing else, it demonstrates that managers are aware of who workers are and what they are doing.

Number seven: Get rid of the deadwood. Competent developers want to work with other competent developers, and the best developers enjoy the challenge of working with other superprogrammers. It’s hard to let underperforming employees go, but their continued presence takes a toll on the rest of the team. Hang on to the bad performers and after a while they may be all you have left.

In position number eight is vision. This should be obvious. Developers want to work in an organization that is pursuing a worthy vision, and they want to feel they have a role in defining the vision. Duh.

Jackson’s ninth factor is close-mindedness. Everyone wants to feel that decision-makers will listen to their suggestions. If you don’t listen, then the very workers who have the most to contribute will get tired of bumping their head against the wall and leave for greener pastures. You’ll be left with a department full of yes-men. Good luck with that.

Finally, Jackson says, some people leave because of bad middle managers. It’s not uncommon to find that certain managers lose team members at an accelerated rate. It could well be because they are bad managers. You can replace the manager or try to fix him, but you’ve got to do something or you’ll have a permanent talent drain in the manager’s department.

You can read Jackson’s article here. I thought it was a worthwhile list, and if nothing else, it reminded me that we all have to do a better job of hanging on to good workers.

Web recommendation: Could programmers make it possible to crowd-source government? That seems to be the central question behind this interesting CNN article and the TED presentation behind it. It’s an intriguing and unlikely thought. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He lost a couple hours to National Geographic videos of dangerous predators today. Those guys really know how to make nature interesting.

I got hooked on creative programming during the brief few years I sullied the field of software development by working as a programmer. I had a clear sense of myself as an explorer, taking the Apple II places no one had ever taken a computer before. The industry’s relatively few books on algorithms and program structure were unknown to me, and I wouldn’t have understood them if I had blundered into them. So I learned to program through trial and error, intuition and experimentation. When I got a program to run – and I’m still proud of the apps I created in those days – my triumph was both practical and artistic. For me, programming was a creative endeavor.

I know I’m not alone. I’ve talked to many programmers over the years, and the chance to exercise creativity is one of the things they like best about software development. Many of the developers I talk to these days are preoccupied with mundane tasks like extracting data from mainframe tables, formatting information for output, and patching up apps with new layers of data-security scaffolding. It doesn’t look like creative work to me, but I’ve learned that creativity refers to the way you approach a problem, not the problem itself. Even the most mundane task can be accomplished in a creative way (without compromising the quality of the app or missing the project deadline, of course) by practitioners who see themselves as creative.

I hope you see your work as an outlet for creativity. For me, that was what made programming satisfying. Yes, I liked solving users’ problems. I loved dismantling complex challenges and finding the inner simplicity. But mostly, I saw programming as a means of personal expression.

Everyone who works in a creative discipline draws a blank sometimes. It’s hard to be creative on demand, especially when facing tight deadlines.

Of course, little we do as developers is truly original. For me, at least, a creative triumph was when I arranged well-known, frequently used programming tropes in novel ways that met my application’s needs. You might call this “combinatorial creativity.”

I was reminded of this the other day when I happened upon a letter that Mark Twain once wrote to Helen Keller. It seems that Keller had been accused of plagiarism. The charge was dismissed, but Twain still had more than a little to say about it, and about creativity itself:

Oh, dear me, how unspeakably funny and owlishly idiotic and grotesque was that “plagiarism” farce! As if there was much of anything in any human utterance, oral or written, except plagiarism! The kernel, the soul – let us go further and say the substance, the bulk, the actual and valuable material of all human utterances – is plagiarism. For substantially all ideas are second-hand, consciously and unconsciously drawn from a million outside sources, and daily use by the garnerer with a pride and satisfaction born of the superstition that he originated them; whereas there is not a rag of originality about them anywhere except the little discoloration they get from his mental and moral calibre and his temperament, and which is revealed in characteristics of phrasing. When a great orator makes a great speech you are listening to ten centuries and ten thousand men – but we call it his speech, and really some exceedingly small portion of it is his. But not enough to signify. It is merely a Waterloo. It is Wellington's battle, in some degree, and we call it his; but there are others that contributed. It takes a thousand men to invent a telegraph, or a steam engine, or a phonograph, or a telephone or any other important thing – and the last man gets the credit and we forget the others. He added his little mite – that is all he did. These object lessons should teach us that ninety-nine parts of all things that proceed from the intellect are plagiarisms, pure and simple; and the lesson ought to make us modest. But nothing can do that.

Web recommendation: I know too much about how computers work to consider robots a threat to my life or my job. But this series of articles got me thinking. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He enjoys a shot of Scotch now and then.

The world is full of people eager to sell you training and specialized information. Authors and publishers push books. Consultants sell insights by the hour. Speakers at seminars and conferences promise to revolutionize your thinking.

I’m the last person to disparage these conduits to learning. Although it is commonplace to dismiss these teachers as principle-free cynics who craft their messages to the marketplace, my experience is that authors, consultants, and conference speakers believe in their messages, very often passionately. In general, the money you spend on this kind of information is money well-spent.

But when I say “become a better developer,” I’m not talking about picking up the basics of a new programming language, or learning how to manipulate a new set of APIs, or grokking how to craft code for a new platform, or seeing how to translate the principles of a development method into practice. Those are all examples of skill acquisition, and skill acquisition is a fine thing. But it doesn’t transform you. If you were a mediocre programmer before a course in Dart or F#, then at the end of the course you’ll be able to code in a mediocre fashion using a new language. You’ve acquired new skills, but you’re the same developer you always were, not a better one.

If you really want to be a better developer, you’ve got to look inward. Understanding lambda expressions may help you write better code in certain situations, but being a better developer is more likely to come from a higher level of commitment to quality, a greater level of enthusiasm, enhanced patience, and more willingness to communicate clearly, frequently, and honestly with colleagues.

That’s the secret behind McCarthy BootCamp, which I wrote about recently. Jim and Michele McCarthy don’t teach any programming tricks during their training sessions (what they teach, mostly, is personal integrity – but you didn’t hear that from me). Nonetheless, they may just help you become a better developer.

Because when it comes right down to it, there’s just one way to be a better software developer: Become a better person, and then develop software in whatever way seems most natural.

Web recommendation: This is an amusing slide show that does a pretty good job of displacing a belief that is held by no one I know. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He’s done some simple home repairs today and is feeling uncommonly proto-masculine.

The other day I told you about NELL, the Never Ending Language Learning system at Carnegie Mellon. NELL is an AI system that is acquiring its knowledgebase by browsing, parsing, and assimilating content from the Internet. NELL is the real-life analogue of one of my favorite characters in modern literature: Helen, the AI system at the heart of Richard Powers’s astonishing, heartbreaking, brilliant Galatea 2.2.

There is no way I can set out for you all of the wonders of this wonder-packed novel. First, you should know that the main character spends a year training a neural network in hopes of winning a Turing test consisting of a comprehensive graduate examination in literature. The book provides more than a bit of detail about successive versions of the net and how they are structured and trained. A former programmer, Powers gets the technical details right.

You should also know that the main character is named Richard Powers, and that he shares many biographical details with the author of the novel. You can never be sure, reading the book, when you are reading fiction and when you are reading autobiography. This ambiguity sounds confusing or distancing in theory, but in practice it adds to the complexity of the novel in a delicious way and supports one of its major themes.

The book is densely layered with allusions to current events, computer science, the novels of Richard Powers, and, especially, literature. The story of Pygmalion and Galatea plays a central role, as you might guess from the title. There are liberal borrowings from Proust as well, and any number of other books.

I don’t think the literary baggage should prevent you from reading the book. It’s a terrific stand-alone read. The allusions and literary in-jokes make the reading experience richer if you get them, but you can enjoy the book just fine without them.

You learn all about these extra layers when you pursue a literature major. For example, I learned something interesting about the plays of Shakespeare and his contemporaries. They were written, as you probably know, toward the end of the 45-year reign of England’s Elizabeth I. Succession was a taboo issue in those days. Elizabeth had no heir and had not named a successor. Everyone knew that she was an old woman and wouldn’t live forever. But talk about succession could get you thrown in the Tower of London as a traitor. Shakespeare knew that these events were on the minds of his audiences. That’s why so many of his plays deal with ambiguities and battles over royal succession. None precisely mirrored the situation with Elizabeth – Shakespeare couldn’t risk execution as a traitor – but he broached the issue delicately, to the delight of contemporary audiences. Most modern theater-goers don’t know these historical details, and it doesn’t matter. The plays are still entertaining. It’s just the same with Powers and his allusions.

It’s fruitless to attempt to name a favorite book. But I have read and reread Galatea 2.2 many times, and recommended it to others who have found that they, too, love it. The writing is lively, erudite, engaging, and creative. The double-plot includes inversions and interplay that draw you in. The characters are memorable and all of them, ultimately, touch you with their humanity.

You can’t spend all your time coding. Pick up a copy of Galatea 2.2. You’ll be glad you did.

Web recommendation: Well. I didn’t realize the P vs. NP problem was so central to computing. This article is fascinating. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He loves every Richard Powers book he has read, and he has read them all.

I heard the Indigo Girls song Galileo this morning. It’s not their best song, in my opinion, but it’s among their most popular. The song evokes Galileo as a symbol of the highest achievement of human intellect: How long till my soul gets it right? / Can any human being ever reach the highest light? / I call on the resting soul of Galileo / King of night vision, king of insight. Lyricist Emily Saliers employs Galileo as a metaphor for the search for meaning.

The song got me thinking about Galileo. I idolized great scientists and mathematicians and inventors when I was young, and Galileo certainly belongs on that list. In A Brief History of Time, Stephen Hawking wrote: “Galileo, perhaps more than any other single person, was responsible for the birth of modern science” – who am I to argue with Stephen Hawking?

But Galileo wasn’t on my Top 10 list. I knew of him, as kids do, as the inventor of the telescope (which, of course, he wasn’t). But my intellectual idol was Leonardo da Vinci.

I don’t mean to embark upon a debate over which of these great thinkers made the more important or substantial contributions to the modern world. Such debates are pointless at best. No, what I find interesting about my childhood preference for da Vinci is what it reveals about the way we encounter and assimilate information. I want to talk about that today. And that means I’m going to have to delve into the past a bit.

My dad was a rookie newspaper reporter when I was a kid, and my mom stayed home with a house full of toddlers. I was too young to know it at the time, but looking back, it’s clear that we didn’t have any money. My childhood was spent in a series of undersized rentals filled with hand-me-down furniture. Other kids got all the latest toys, but my sisters and I did without.

I recognize now that my mom and dad had to scrimp and save to maintain our rowdy household. But in one area, they spent like millionaires. I grew up in a house full of books. I mean it – there were books everywhere. Thousands of books, hardcover and paperback, filling shelves in every room. My dad, who never owned a new car in his life, was so idealistic he got his kids not one, but three sets of encyclopedias.

You remember encyclopedias, right? They were big multiple-volume reference works packed with articles on all kinds of topics: art, history, science, mythology, math…every branch of human knowledge. We had the Encyclopedia Americana, the Encyclopedia Britannica, and the World Book Encyclopedia. (Plus, as I recall, the beautiful Time-Life Science and Nature series of stand-alone volumes on individual topics.) These weren’t picture-book references for kids, but full-scale grown-up reference works of the kind typically owned by libraries. Each was more than 20 oversize hardcover volumes. I’ll never know how my parents were able to afford them.

These (and many other wonderful reference works) didn’t appear when I learned to read, nor when I started school, nor when my academic assignments began to require research. No, they were there from the beginning. And my parents didn’t put them away on a high shelf to protect the onion-skin pages and leather bindings. The encyclopedias were on the bottom shelf so we toddlers could browse through them at will, starting before we could read. By the time I entered first grade, I had spent hundreds of hours with those encyclopedias. I had probably read 1,000 articles. (I’ll make no claim regarding the depth of my understanding.)

In some ways, my unfettered access to these thousands and thousands of pages of reference material was similar to my current access to information on the Internet. But the information differed in one significant way.

On the Internet, I can launch a query and obtain links to scores of relevant documents. With encyclopedias, access was alphabetical by topic. I couldn’t ask the encyclopedias of my childhood for a list of the Top 10 contributors to modern science. I could learn about Galileo only by picking up the G volume and flipping to the appropriate page. If I wasn’t looking for Galileo, I wouldn’t encounter him.

I think that’s why I was a confirmed da Vinci loyalist. I knew about da Vinci, because I had happened upon his entries in the reference books. I’m sure the pages devoted to da Vinci were illustrated with his drawings and paintings, which would have caught my younger self’s attention. In fact, I remember studying da Vinci’s Vitruvian Man (this link is well worth following).

I think it’s reasonable to conclude that Emily Saliers, who is about my age, happened to stumble onto different articles in her childhood exploration of history’s great thinkers. She bumped into Galileo, and I found da Vinci. It’s as simple as that. In the age of the printed word, chance and happenstance could have lifelong repercussions.

I have begun thinking about how today’s children will embark upon their intellectual quests, and what the lifelong results will be. The Internet is an unorganized heap of questionable facts and articles of dubious merit. My encyclopedias were produced by professionals with resources for fact-checking and a commitment to objectivity, neither of which is a strong point of the Web. But the Internet’s searchability means it can provide meaningful answers to broad, naïve questions. If you can pry the kids away from YouTube and Facebook, they just may find exploring the Internet just as rewarding, and life-changing, as my own encounters with printed references.

Oh, and about the encyclopedias. I’m sure my parents intended for them to serve as long-term resources for my academic career. But I quickly found that these secondary resources are not held in high esteem in the academic world. The pursuit of knowledge led me to consult original works rather than the encyclopedias’ condensed summaries of the works. So I outgrew them fairly quickly.

I am grateful to my parents for making the encyclopedias and other references available to me as a child. Browsing through a house full of books led me to a fulfilling information addiction, an addiction I feed now through Chrome and a broadband connection. I’m sad that today’s children won’t have the same experience.

They’ll learn to acquire knowledge in a different way, through a searchable, highly responsive broadband Internet. I wonder what effect that difference will have on the way they think, decades from now.

Web recommendation: I love Jeff Duntemann. I seem to recall that the two of us had a falling out, long ago, when we were editors of rival magazines, but I can’t remember the details now. Duntemann is a superb writer and a careful thinker. When I stumbled across his blog the other day, I realized how much I had missed reading his editorials and articles. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He intends to make a lot of ice cream this summer.

Let’s start with the basics, shall we?

We are not born with the ability to write software. Though most agree that individuals have different potential for success in the coding craft, the undeniable truth is that we all start at square zero (or square one in Cobol, Fortran, RP/G, and Smalltalk). What I’m trying to say is this: Programming is an acquired skill. It’s something we learn.

The pioneers who were the industry’s first programmers were self-taught. They had to be – there was no one to teach them how programming ought to be done except, perhaps, Ada Lovelace. So we have all these computers, and none of them are a bit of good without software. To get software, we must have programmers. And to have programmers, we must teach programming.

That’s where it gets tricky. As I have observed here, here, here, here, here, here, and here, and as the Editorial Board of SD Times has somewhat belatedly agreed here, there is a fundamental mismatch between the skillset embodied in the typical university computer-science program and the actual skills required by actual programmers doing actual jobs. The widely acknowledged mismatch between the university curriculum and the real-world needs of IT departments has been the source of a great deal of anguished hand-wringing, as manifested in the hyperlinks I listed a couple sentences back.

Let’s back up a step. Our lamentation over the skills gap is based on an unexamined premise: the notion that the mission of colleges and universities is to prepare students for employment. This premise is not universally accepted. Among the places it is most critically rejected is within colleges and universities. The idealism at the core of the American educational system is that colleges and universities exist in order to imbue students with educations. They set up elaborate programs of required subjects (music appreciation for those seeking degrees in electrical engineering, for example) and struggle to ensure that students are well-grounded in the history of ideas and developments both outside and within their majors. The unquestioned premise at the core of the university system is that knowledge is valuable in and of itself, without regard to whether it makes the student more employable.

The gap between the computer science curriculum and the needs of IT is therefore a manifestation of a fundamental question. Are universities primarily intended to prepare graduates to make a living, or do they have the luxury of preparing graduates to live more fulfilling lives by exposing them to our culture’s history of important ideas and events?

As public funding for education falls, as unemployment rates rise, universities are coming under increasing pressure to serve as trade schools – though, as they point out, there is no shortage of for-profit two- and four-year trade schools for those who value employability over wisdom.

Our field has always had an ambiguous relationship with academia. Most employers don’t require a degree. Our best practitioners sometimes lack academic credentials. A substantial list of accomplishments and a presence on GitHub are more likely to impress enlightened HR departments than a university degree. And rightly so.

When we say that universities are not doing a good job of preparing graduates for software development’s on-the-job challenges, we are echoing practitioners in many other fields. The point is, preparing graduates for work is not what universities are for.

Web recommendation: This blog post is fascinating reading. It is, of course, just one developer’s point of view. But it’s a coherent, nuanced view, and I think the writer has some valid insights. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. At this very moment he is sitting in an outdoor café, listening to a young woman hum “Yellow Submarine” as she rocks a baby in her lap.

Have you read the 501 Manifesto? It’s a short document – it’s posted online here – that is obviously based on the Agile Manifesto. It’s a statement of principles asserting that developers should have lives aside from coding. Here’s the core of it:

We are software developers who take pride in our work but choose not to be wholly defined by it.

As such, we are proud to say that we value:

• Our families over the commercial goals of business owners
• Free time over free snacks
• Living our lives over maintaining our personal brands
• Sustainable pace over muscle-man heroics
• Our personal creative projects over commercial products the world doesn't need
• Having money for nice clothes over getting free t-shirts from Microsoft
• Playing fußball in the pub with our friends over playing fußball in the office with our team leader
• Not being a dick over being a rockstar

That is to say, we value the things on the left more than we value the things on the right. And some of the things on the right aren't even on our radar.

The manifesto is named, it turns out, for those programmers who save their work, log off, and leave work at 5:01. They go home to spend time with their families while their colleagues – you know, the ones described in decades of stereotypes – keep cutting code far into the night.

The 501 Manifesto is mostly just good old common sense. We work to make the rest of our lives possible. If we’re lucky, we are also able to wrest some enjoyment out of our work. Yes, extra hours are sometimes required, and sometimes we get caught up in hack-attacks and the hours fly by until we look up and find we are still hacking past midnight. But yeah, we get it. We work to support our real lives.

Nonetheless, the manifesto has generated substantial controversy on the Internet. Some programmers resent being described, albeit indirectly, in terms of stereotypes. Others object to individual words or statements, usually found in the text framing the manifesto proper. And of course, the Internet being the Internet, some folks object just because they’re in the mood to be ornery.

I’m sympathetic to the 501 Manifesto. It’s too bad, I think, that the authors felt the need to spell out such commonplace facts of life.

The 501 Coder blog is worth visiting, if you’re interested in an overview of the arguments for and against the manifesto. There’s some interesting stuff there, including this insight into the state of nerdiness: “Here’s the thing: If you are truly a nerd, being pitied by ‘normals’ is part of the deal. It’s not contempt, don’t mistake it for that. It’s a kind of rather-you-than-me bewilderment at your current life choices. That’s all.”

Web recommendation: The Internet keeps spawning new ways of representing information. The Newton Tour was a new one for me. I like the idea behind this project, and I foresee a day when such data might be collated on-demand, for arbitrary individuals, based on Web-scouring strategies. Why not? J.D. says check ’em out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He is looking forward to seeing a six-year-old take a look through binoculars for the first time.

I can’t deny it, I’m officially skeptical about the Agile movement. I’ve read a lot about the Agile philosophy over the past year, and the more I read, the less impressed I am. The principles at the heart of the Agile movement are self-evidently true, but they haven’t translated into a useful set of methods for software developers. As I wrote in a recent post: “This is no way to achieve reliable, repeatable results. It’s de-evolution in action, a return to the days of late-night hack attacks and reliance upon the heroic contributions of uncommonly talented superprogrammers.”

I admit that my criticism is disarmed somewhat by the first statement of values listed in the Agile Manifesto itself: “Individuals and interactions over processes and tools.” So Agile hasn’t translated into a heavyweight set of processes and tools? Duh. It was never intended to.

This morning I stumbled across a blog post titled “Agile is a Sham.” It turned out to be an invitation to an entire subculture of Agile skeptics. I thought for a moment I’d found some likeminded thinkers to spend time with. But I couldn’t have been more wrong.

I followed a trail of hyperlinks that led me through a rising tide of dissatisfaction with Agile. Not because Agile hasn’t translated into a useful set of tools and methods, but because Agile imposes too many tools and methods! This anti-Agile community is contemptuous of consultants and trainers who are peddling Agile as the new cure for everything that ails software development. They despise Scrum and Kanban as snake oil that managers buy in an effort to get superior results out of inferior programmers. The blogger summed up his Agile skepticism like this: “[T]he success of the coding part of a project is dependent on the caliber of the engineers doing that coding and not the process they follow.”

Maybe you recognize this line of thought. Our industry is vulnerable to a very unattractive elitism. There are lots of programmers who believe the best way to ship working software on time is to get rid of onerous development processes, sweep out the below-average programmers, and leave the competent programmers – the real engineers – alone to do their thing. Just get out of their way, and they’ll make the code work.

Members of this elitist clan argue that project management and formal development processes are just obstacles to their brilliance: “If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.  If you are a good programmer, you know yourself how to communicate and create your ‘process’ as you go along.”

I find myself totally at odds with this community of Agile skeptics. Their cynicism about Agile consultants and trainers is probably well-founded, I admit. But their insistence that raw competence makes methods obsolete – and that reliance on methods is an admission of mediocrity – sets my teeth on edge. Their elitist views are demonstrably incorrect and patently offensive.

So yes, I’m an Agile skeptic. But I’m the other kind – the kind that would like to see Agile principles instantiated in more discipline, more tools, and more methods. That’s how you translate good ideas into working processes. Our field needs more discipline, not less.

Web recommendation: The open-source Go language has achieved a milestone: Version 1.0 is now available. I like what I read about this lightweight language. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He is hopeful that a certain video clip he saw today, featuring himself, never reaches the public eye.

The best conference presentation I ever attended was at the Software Development Conference in 1989. I was editor of Computer Language magazine, the sponsor of the conference, and I had major responsibility for signing up speakers and assigning topics for the keynotes and technical sessions.

Larry Constantine spoke at our conferences, and Grady Booch. Bjarne Stroustrup and P.J. Plauger and Adele Goldberg. Bill Gates spoke several times. Ed Yourdon was a regular. Our conference attracted the industry’s best-known thinkers.

The session I’m talking about wasn’t delivered by one of software development’s legendary figures, but by a technical manager from The Whitewater Group, a small company that published an object-oriented programming language called Actor. Jim McCarthy had proposed a seminar on project management and slipped deadlines that he called “Slipping without Falling.”

Jim’s talk was both extremely entertaining and extraordinarily insightful. Drawing on his experiences in project and process management, he delivered a series of memorable, colorful aphorisms, each of which expressed in shorthand a profound truth about the messy process of shipping software. Jim focused on techniques for building healthy teams, a black art that is still almost universally mismanaged.

One of Jim’s most memorable bits of advice was this: “Beware of the guy in a room.” Many projects, he explained, have at their core a challenging bit of code that is assigned to the development team’s acknowledged superstar. This programmer takes custody of the crucial module and retreats to his office. The team spends the next weeks tiptoeing past his door so they don’t interrupt his intense focus. No one asks for forecasts, bug-tracking data, or progress reports. The team knows that its success hinges on this single programmer and his brilliance. His code will be ready when it’s ready.

This dynamic is common and pathological. It is anathema to teamwork. The pattern reinforces harmful stereotypes about the relative value of programmers and superprogrammers. It reduces meeting deadlines to a game of chance. As McCarthy said, “the results are uniformly fatal to the professional development organization.”

McCarthy’s observation hit home. I had seen organizations held hostage by a guy in a room. Worse, I recognized that on a few occasions, I had been the guy in a room. I had helped erode healthy teamwork in companies where I had taken sole custody of creative challenges and everyone else just waited for me to deliver.

Jim’s insights into team leadership led him to Microsoft, where he led the team that developed Visual C++ – a team that is legendary for its productivity and innovations. He expanded his Software Development Conference talk into a book called Dynamics of Software Development, which I commend to you as essential reading. Jim now runs The McCarthy Show, which offers leadership training. If you visit the Web site, which you should, be sure to check out the Episodes page, which currently offers 115 podcasts on elements of McCarthy’s leadership principles.

Curiously, Jim’s warning about the danger of “a guy in a room” is not unique in our industry’s literature. In 1971, Gerald Weinberg wrote an extraordinary book called The Psychology of Computer Programming. Like McCarthy, Weinberg focused on effective teams. His book included a short section called “The Ten Commandments of Egoless Programming,” which listed rules for functional teams. Item number nine on the list was this: “Don't be ‘the guy in the room.’ Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.”

I don’t know if Jim picked up the “guy in a room” concept from Weinberg or it occurred to him independently, and I don’t really care. It’s an important insight with wide applicability.

Does your team rely on the efforts of a guy in a room? Are you the guy?

Web recommendation: McCarthy’s still got it! You can catch a video of his Agile 2008 presentation, “11 Commitments for a Shared Vision,” by clicking here. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He had such a nice day today.

I read a lot of programming blogs these days. It’s amazing what you can find out about people who think no one will ever read what they post on the Internet. What they have for breakfast, why they regret their college educations, how their employers are totally blowing it…any random thing at all.

I’ve noticed one interesting trend. Many developers prefer to listen to music while they are working. They post some fascinating playlists.

Most developers who listen to music while programming say they opt for music without lyrics. That makes sense to me – who wouldn’t find lyrics a distraction? Beyond that, the variety is wide. I’ve run across bloggers who listen to classical music, movie soundtracks, techno, jazz, klezmer(!), baroque organ music, opera, and bossa nova. Some people listen to retro video-game music. (Hey, there’s no accounting for taste.) And many, many programmers say they are more productive when listening to metal. Honestly, Metallica is probably the most frequently cited band on programmers’ blogs.

Me, I can’t listen to anything while I’m doing creative work. I did my best programming in the early, early morning, before the rest of the world had awakened, when it was just me and the keyboard. Now, when I’m writing, I have a terrible time focusing if there’s music playing. For me, focus is too fragile to survive an encounter with music.

So what’s your story? Do you write code with headphones on? Or do you, like me, find that silence is golden? Let me know in the comments.

Web recommendation: I’m writing this piece on March 19, 2012. It happens to be the 538th birthday of patent law, according to this interesting and informative page. J.D. says check it out.

J.D. Hildebrand has written hundreds of articles for dozens of publications and online communities dedicated to software development. He doesn’t have much of an appetite these days – must be the lingering effects of that headcold.