They're assets, not expenses

You must make this mental switch for all your employees, not just developers. Your team is not just a collection of inputs that create the output (product) your company sells. They are humans with their own needs and goals, and if you help them fulfill these things then they are much less likely to quit on you.

Pay matters (duh) but isn't everything

Let's get this one out the way: you already know that compensation should be market rate. You can come in a little under cash market rate if you have other attractive features like equity (do not do a 1:1 tradeoff, we both know that's bogus), remote working, etc. Office snacks and other nonsense don't count. Regardless of perks offered, cash compensation shouldn't be more than 10% under market for regular employees or you'll lose them once the going gets tough.

Most importantly: keep track of the market and increase salaries as-needed every six months or so. Set yourself a recurring calendar reminder. You'll have to pay market rate to replace someone who leaves, so why not keep the talent you have and save yourself the effort?

Professional development

As a discipline, programming changes quickly and skills rot even faster. Professional development is critical to a programmer's continue success and they know it. You don't have to pay for them to go to every conference, but you should be offering to pay for courses, books, and new tools.

New technologies and frameworks are important to developers. They will often ask to use them out of curiosity; do not dismiss these requests out of hand! It may not make sense from a business perspective, but if you view it as an investment in another asset (your developer) then it may be worth the risk. Even if you decide against using the new shiny thing you must ensure the developer knows your reasoning and that you seriously considered the idea.

Evaluation methods

You should evaluate developers based on the value they create. It sounds simple, but the difficulty lies in measurement. You must resist the urge to use "butt in seat time" as a metric — a developer who is in the office for 12 hours surfing reddit contributes less than one there for 8 solid working hours.

Here are a few factors to consider when evaluating developers. You should also simply ask your team how they want to be evaluated!

1. Are they consistently on time for the (reasonable) deadlines they've agreed to?
2. Are your customers happy?
3. How do their peers rate them? What about their direct manager?
4. Is their doucmentation, testing, etc. up to par?

Personality differences

It's commonly said that people don't quit jobs, they quit bosses. Take the time to appreciate the personality differences between you and your developers. Try to keep the small talk to a minimum if they're an introvert, and do the opposite if they're an extrovert. Don't add pressure to a developer who doesn't handle it well! You may as well fire them on the spot and prevent suffering on all sides, because it will not cause them to ship any faster.

As someone who lives and breathes your business you will be tempted to expect your developers to do the same. Resist this temptation: they cannot be anywhere near as passionate about your business as you. You likely have 25x the upside in the business that they do, so don't act surprised when they behave accordingly.

Make sure it's the right fit

If you are confident in your business' approach to the above, it's possible that problem developers simply aren't a good fit for your company. Here's how you can find out.