What is it that you want your developers to do? I suspect that you want them to write code. The smaller the company, the more additional tasks there may be. But fundamentally, it's about writing code.
So how do you as an employer or manager ensure that they can do this most effectively?
There is much to be balanced. Lets try to dissect the options, paths and consequences, ranging from make-or-break to petty annoyances.
General office environment noise
The office must be reasonably quiet, but not silent.
Bad: sales people yelling down phones. The words enter the consciousness of the programmer, causing them to name variables after whatever product the salesbod is selling. The lies, ignorance and half truths also affect their state of mind: my thoughts are still swimming with a statement made by a salesbod about four years ago, regarding how Linux was so much easier to hack than Windows since you can see the source code.
Total quietness is bad too, at least in shared offices - you don't want to hear every creak of the office chairs, every slurp of coffee. Create some ambient noise with some desktop computers or aircon.
The computer
Programmers really do tend to need very good computers. Yes, even when hacking PHP/HTML. It's also a good idea to allow the programmer to use their platform of choice. If you're writing cross platform code, as everyone outside of Microsoft now does, then platform should not matter.
This, however, is much more than allowing your coder to have a Mac or Linux box. It must permeate the very fabric of your IT infrastructure.
I once tried to run Linux within a wholly Microsoft office. It did not go well. There is no reason for it not to have worked, but every aspect of the network fought against the alien invader. Exchange would not talk to open clients, network shares defaulted to settings which resulted in poor performance or even lack of connection with Samba, and more.
It's not just the infrastructure but also choice of software, as I'll come on to in a moment. Case in point: Microsoft Dynamics CRM. This truly awful, bottom of the barrel CRM software is a web application - however, it's a web application which runs only in Internet Explorer. Not only must you only connect from Windows, but you're locked into using IE no matter what your browser preference.
The computer must work for the developer. It must not be a continual uphill struggle to get anything done.
Software - development
You can code using only a text editor, but while that's fun for a bit you'll need more to keep developers happy and to improve productivity. I spent many years with only a text editor, even one which doesn't colourise code. You can learn much from coding in that way, but a business is less about learning and more about doing - get tools that help with the doing.
Thankfully much of the best software development tools are free for most development environments, but don't be afraid to spend. Example: Trac is quite a wonderful tool for ticketing and viewing source and changes in a Subversion repository. But if you have a few developers and the budget, then Atlassian products are a much better proposition.
Don't be afraid to spend if your company is profitable. Especially, don't dither over essentials - if your development environments are contained on VMWare images, ensure that your new Mac developers have a copy of VMWare Fusion. Don't leave them to spend months using every email address they have to continually download expiring trial versions - it will infect their thinking for years to come.
Software - office
You hope that your developers should never need to touch anything but their IDE, but in small companies it will be the case that developers need to raise sales orders, consult the CRM, query the ERP, connect to their email, use the phones, ...
I've touched on this above. Basically if you base your infrastructure on an MSDN subscription then you'll only keep .NET programmers happy. Good luck with that.
Of course, there's the other side to this - many non-programmers will be conditioned to use Windows, Office, and Outlook. Be careful that those not ready to use a non-Exchange mail server are retrained and don't poison the project - it is possible for an incorrectly used Outlook to make it appear that Zimbra is broken and certain types of people will use that to destroy the working atmosphere.
The computer - my home
So, you standardise your company on Windows. You have a Windows Server or five to run the network. You decide to ensure uniformity across your field of view in the office and implement Group Policy from Windows Server. You force a bland image with the company logo as a desktop image onto every Windows client desktop.
Good: no more sci/fi fantasy images. No more car images. No more nakidity.
Bad: your programmer probably had only a black backdrop, visible only for the few seconds that it takes to swap applications. Like one of a million paper cuts, this adds to a general sense of depression.
You go further. You announce that all webpages visited are tracked and monitored, and action will be taken if anything bad is accessed. 'Bad' is not defined, but you announce that you're already tracking people going to job sites. MSN is banned, then allowed, then conversations tracked. I understand this and recognise the business requirements, but you should also realise that it continues to poison the thoughts of those who never took advantage, never used MSN, but did like to check the news pages at lunch time. Especially if implemented before announced (if you announce) that it is happening.
You go further. You start blocking websites. Perhaps you have an employee who spends all day on Facebook. Fine, discipline them. Don't take it out on everyone else. Very especially, don't blanket ban websites for minor causes. Don't ban BBC News because some sales bod keeps watching the boxing results. This can have consequences beyond getting an extra minute or two of sales call time.
My example: every Monday morning I'd listen to Goon Show on BBC7 while trudging through the mindless tasks of the day. The same tasks, each Monday, performed with my eyes closed and my mind switched off. I'd often return and listen to other BBC shows throughout the week. Yes, this used bandwidth - but I took advantage of my position of being able to see MRTG graphs of utilisation to ensure that this 30kbit/s never impacted the business. As noted, my 5 minute lunch break would consist of browsing the news sites, and BBC News is the one site to rule them all. Imagine the impact on my day if the BBC was blanket banned. The BBC of all things.
Push your developers
Lack of challenge will turn them away. Real programmers want new challenges. New languages. New opportunities to push the boundaries. If the opportunity is there, push them into doing something new. Some will grumble early on, but the rewards from success blot out any and all negative aspects.
Don't push your developers
In non-coding aspects, don't push so hard. Programmers want to be stretched in technology, science, maths and logic. They don't like being needled about things irrelevant to the task in hand until they submit. Time sheets are a good example of this. How closely are you watching?
Get buy-in
Not just from developers, but in general: ask opinions of those involved before implementing policies.
"We're putting a new wall across your office."
"We're changing the CPU in your computer."
It gets difficult when you start scaling the numbers, but for a team of less than 10 its not difficult.
The developer abstraction layer
Read: http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html
Some will want to be involved in raising invoices, the sales process, etc. etc. - these people may well become managers. Most find this a distraction.
Don't insult or threaten
Here's another general point. No matter who you employ, unless they do something incredibly stupid then you really shouldn't tell them their work is awful (at least when done to spec), or indeed threaten to kill them for asking where the printer paper is. Just good manners.
