After 15 years in the industry, I'd say there are three classes of software developers: 

	* The natural coder. This is the person with an intuitive grasp of technology, who sees the similarities in software architectures and reuses concepts across disparate technologies. Alas they are rare, maybe 1/10 qualify. 

	* The "steady Eddie" programmer. The vast majority of support staff, documenters, etc. are "steady Eddie" types. They do the job, they follow instructions and designs, but are not necessarily creative or intuitive about it. They're the people who form the corporate infrastructure, and about 7/10 fall in this category. They are much slower than the natural coder, but do get the job done. 

	* The clueless wannabe. Fortunately there aren't too many of these on projects I've worked on, but there are still more of them than natural coders -- I'd say about 2/10. 

The original poster's commentary indicates that it's a relatively young/naive developer who is either a natural coder or a steady Eddie with an overblown ego doing the writing. Either way, I am guessing that he is quick to grasp concepts and ideas, and gets easily frustrated with people who don't -- and it shows. Even if such people try to be understanding or are "open" to questions, the way they phrase their answers is often intimidating to their peers. 

You need to make sure people understand the project is truly a team effort, not a blame game, and encourage questions. If no one is asking questions, check with them daily to see how they are doing, but handle it as an offer to help out or clarify specs rather than just getting their status. 

Learn the skills of your people. Those who can't code are often good at other things -- debugging, screen layouts, build management, etc. Very few people are actually useless, they just aren't necessarily good at what has been assigned. 

When working with a team of juniors, start out by creating the outline of the code -- makefiles, interface headers, and stub code. Don't get into the details of your code -- make sure the overall project has been outlined. It helps juniors a lot to have a solid interface they are expected to implement, and it helps to modularize the system code. 

When people ask questions, don't give them the answer, even if you know. I'm serious! Guide them with questions that lead to the answer, but let them come up with the solution if at all possible. This helps them to learn how to think (your questions show what they should be asking and thinking about), and they gain confidence by coming up with solutions "by themselves." 

Ignore all the postings you've seen about beer, pizza parties, and threats of layoff or termination. You'll never succeed with a project if you are wasting your time and budget on frills and turning your staff into nervous wrecks. 

If you do encounter a truly useless clueless "developer" who just doesn't "get it", make sure they're working on something non-critical and that their access is restricted. If you have to keep them on the project, try to use them as testers or for "grunt work" like build management. Even the most clueless person can follow a checklist to test software or compile code, and sometimes they can actually become quite good at it. Believe it or not, you need people who will be happy doing the mindless work -- most of the work on a large project is mindless. 

Don't create your schedule on the assumption that everyone is going to code as fast as you. Be realistic, and then double the time allotted. Sad to say, I've often found that still doesn't allow enough time for some people. 

If you find anyone on the team playing the blame game, snuff that thread. If someone complains about weak specs, redirect the discussion to suggestions about how to improve the specs. If someone is blaming other people for being late with interfaces they "need", redirect to a discussion of modular programming and how the interfaces can be designed without a full implementation. Whatever you do, don't let people get away with blaming others for their own shortcomings. 

Perhaps most important, don't use the "big stick" of layoffs and termination to encourage people to work. If they are any good, you'll just scare them into finding another project, leaving you without resources. If they really are useless, no threats will improve their skills and you're going to turn the team into quivering, terrified blobs who would rather chew their own arms off than ask you for help or guidance. 

Failing all of the above, make sure that management is aware of delivery issues and potential schedule changes early on. Even if you think you can recover lost time, make sure management knows the time has been lost so that it isn't a surprise if things don't turn out as you hope. Ensure that you've got a feature prioritization so that you know which features to sacrifice if it's critical to get "something" out for a given date. 

Finally, keep smiling and keep it light. When all is said and done, it's just another project, not your life, and you'll only get ulcers by stressing excessively. More often than not things don't work out as you'd like, so learn how to manage them in the direction you need when they take a turn. 

Being an arrogant SOB myself, it took me years to learn to be more gentle with my coworkers. Rather than bluntly stating my disappointments, I find it's much better to provide them with the interface headers (potentially with stubs), and let them code from there.