>>Trustworthiness and loyalty are different things. A poor developer can be very loyal.
>
>eh. I'm confused. A trustworthiness and loyalty are synonyms aren't they (as you know english is not my native tongue, so correct me if I'm wrong). So why do you think a trustworthy developer is a great developer?
>
I am with Al on semantics here. Loyal for instance doing many allnighters even if not agreed upon because another dev left/got sick. Trustworthiness dev keeping his word on anything - with some fudge room if other side was illoyal or did not keep their (balancing) promises.

>>If a great developer gets what they carefully consider to be a better offer elsewhere, why would they not take it?
>I agree. However from a business perspective it then might not be a great developer.

Was example I think your semantics are totally misplaced. In my verbiage loyal dev would at least be open about other offer and give you chance to match that offer. Depending on earlier agreements perhaps not leaving in the middle of a project/without helping replacement a bit -here overlap with trustworthyness..

>Let me explain. This is a discussion I had with my business partner. You can hire the best developer in the world, but if it takes 9 months to get up to speed (yes, this what we are looking at) and jumps ship after 12 months, he / she is not a great developer from our perspective.

Uuuhm, 9 months is too long for a normal skill set usable elsewhere. This probably is something specific to your company or project. That should reflect in lower pay at start, higher pay later - with option to "earn" higher pay if dev is up to speed much faster then you as stakeholder expected.

>>To some extent self-interest is important for markets to operate as we expect. How did you hire that great developer in the first place, and how do you expect to retain their services?
>
>Good point, but it takes two to tango. We have had/have very loyal developers that worked for us for many years, but we've had also developers that jumped ship after 12 months without any notice and time to hand over the project to another. From my perspective, when I'm hiring a new developer I'd like to know whether this is the kind of guy/girl that will jump ship very easily or one that is looking for a more permanent position.

Embolded most important IMO. I envision your company to be small enough to haggle out special wishes of your company with specific wishes of each dev. Does create different contracts and longer discussion at start, but worth its while with trustworthy people.

>We have made some big mistakes to hire young .NET developers fresh from university only interested to fly away after a couple of months when they found something else and can put our company as a reference for experience. That was a huge waste of money.

see above - unwise of you not to expect more wishes to test possible environments by devs in first job and perhaps not equating gained experience/company benefit with rising compensation (at least not mentioned yet...). Flip side of paying at start more than company benefits to "lure" dev into ***this*** job.