Obviously you've never worked on a project that involved offshore development.

Speaking as someone with 15 years of software development experience, and who has 2 music degrees + 1 degree in IS, I can say that musicians learn a lot about compositional techniques and quite of bit of a formal musical education is spent writing pieces in various styles, from 16th century counterpoint to 12-tone serialism. The reason is that if you are going to be a musician, not a "singer" or an "artist", then you need to understand what you are doing by studying these styles and then attempting to imitate them as part of the learning process. That's why Bach spent so much time copying scores by composers like Vivaldi, and Mendelssohn later studied scores of Bach, etc. I certainly wouldn't equate touch typing with playing a musical instrument, so I don't agree with the original analogy. But in general, the more you understand the theory and basis of what you are doing, the better you are going to be at it, vs. someone who doesn't study that stuff. And an important part of that is analyzing what others do, which is one reason I enjoy doing code reviews - it's a great way to learn.

We have two species of eagle here in North America. Bald eagles are primarily fish eaters and so DDT most definitely found its way into their food chain by runoff into waterways. Of course shooting is still an issue, but lead poisoning is probably the main reason for human-caused mortality they face today.

And by the way, "bird of prey" does not automatically mean "mammal eater." Many birds of prey eat fish, amphibians, birds and yes, even insects. Look up osprey, barred owl, peregrine falcon and American kestrel ... learn your raptor facts before dismissing other people's comments as nonsensical.

This question clearly demonstrates that the OP has no understanding of the software development process. I've been doing software development for the last 15 years, mostly as a consultant, and have been on A LOT of projects at many different clients. I have yet to see one with "excellent product specs" completed up front. Why? Because customers never know what they want until they see it. And even when they think they have defined something well, they don't understand what they will actually get back.

Software is very abstract and unless you are a developer or a technical person (which most customers/users aren't), then it's very difficult to conceptualize how it will work once implemented. Then there's the reality of changing customer requirements and priorities. I'd like to know how the OP is writing perfect specs when such a thing doesn't exist in the real world. And there are many other aspects to development which the OP doesn't seem to understand either. Who is doing the business and technical analysis of these requirements? What's the process when requirements change? Where is QA and user acceptance testing in all of this?

I suspect nobody is doing these things. What's really happening is that he writes something up based on vague requirements (which are likely to change), throws it over the wall to a developer, and expects a polished product to be thrown back over. Meanwhile the customer didn't understand what they were asking for in the first place, changed their requirements, increased scope, got something back that was maybe close to the written spec but actually wasn't what they wanted in their mind, with no analysis or design having been done, that wasn't ever tested by anyone other the developer who wrote it. And all of those scenarios are called "bugs" by the OP. This is a dysfunctional process that is unfortunately all too common. No wonder your developers balk at fixing this stuff for free.

I don't doubt that there are bugs in the code, especially if the OP is trying to do this on the cheap. There is no substitute for experienced programmers, and there's a reason that people who are experienced cost more. So the first problem is that the OP thinks he can get something for nothing or next to it. But the main problem here is the OP's lack of understanding about the software development process.

If you want to improve things and not have your customers complaining all the time, then start with yourself - read up on software development methodology, ditch the waterfall/throw over the wall approach, and pay up for developers who know what they are doing. I'd suggest a more agile method where customers are very involved in the process, are able to get their hands on the product as it's being developed and provide continuous feedback. Otherwise, look in the mirror and expect more of the same. Developers don't need your empathy, they need a competent project manager.

I see paired programming as just another gimmick to get around the fact that there is no substitute for having experienced programmers and effective code reviews. As a consultant, I've worked on many agile projects, including some involving strict XP paired programming, and didn't see any better quality with that than with anything else. It's all about who you have working on the project, having decent management and a true agile philosophy ... not "agile theater."

I'm an experienced developer and I've interviewed a lot of people myself. As a consultant, I've also frequently been the interviewee. It's easy to weed out the BS types by engaging them in discussions not just about what they've done, but get into the why and how, the pros and cons of various technologies, methodologies, etc. Give them hypothetical scenarios to find out what approach they would take. If they throw out buzzwords and can't explain how/when/why they used something, alternatives they have considered, etc, then things become obvious. That also goes a long way toward showing the candidate's potential, how much of a proactive learner they are, and so on, unlike interview gimmicks. I think coding tests are poor substitute for an effective interview.

Be aware that for an experienced developer, the interview goes both ways. I may want to see some examples of your code to see if your team is up to my standards, and I will certainly be asking many questions myself. If I'm expected to jump through lame interview hoops as part of the process, then it's likely not something I will be interested in - I tend to turn down those interviews.

So it's better to lift a lighter weight more often, than a heavier one just a couple of times.

No, the only thing that lifting lighter weights more often will give you is the ability to lift light things many times. That's called endurance. Lifting heavy things less often will give you the ability to lift heavy things. That's called strength. Which one is "better" for you depends on your fitness goals.

Hummingbirds only exist in the Western hemisphere. But certainly hummingbird feeders could be used for this. The feeders are usually small enough that most larger birds aren't going to be able to use them, though I do find the occasional oriole or even woodpecker on mine. An ant guard will keep other types of insects away.