Top 10 changeable factors that influence programmer productivity

There are a number of factors the productivity of a programmer. Some differ from person to person. Others are broadly accepted as being shared complaints among all programmers, while others are complaints of just workers in general.

The physical space

• Open Floor Plan Offices - a disaster.  To much noise and movement.
• Placement of desk in an office. Even a small office can be an issue if the desk where work is carried out is near doors or places of activity.
• Uninspiring surroundings. There is a reason all the best tech companies have funky offices full of interesting designed objects, exposed steel and brick work. Because it makes an inspirational work place. Compare this to a typical office used by solicitors, blue carpet tiles, wooden tables, and white strip lighting - and it's easy to see why these places will never turnout anything nice.  You can build a beautiful product from an ugly company.
• Poor toolchain provisions. A company that doesn't cater for the needs of the programmer should give up.  If a company wants a programmer to work for them, they need, they must, provide the required toolchain.  This includes the basics of a solid table and chair to work at. It includes a new computer system with at least two large monitors. A stable and fast Internet connection.  Access to all the relevant and best licenses software.

The corporate space

• Other workers interrupting you - especially for 'Hey, did you get that email I sent?'.  The company should lay down rules about not bothering programmers when they are working.  This doesn't mean the first level tech support person should make application critical design decisions on the spot just because the system architect was busy.  But it does mean that if there is a paper-jam in the printer, someone else sorts it out.  There should be a clear set of boundaries of what and what not to bother a programmer for.
• Effort fatigue & ignoring the programmer - there is nothing worse than wasting time.  When the opinion of an expert is enlisted by a supervisor, there shouldn't be any need for a decision on weather or not to accept it.  Getting programmers to give opinions on technical topics, and then ignoring them and picking the opposite, is a quick way to lead to fatigue.  The programmer thinks why should I bother, and it's all downhill from there. This sort of approach is common when working with older CEOs who usually adopt a top-down approach compared to their younger more modern equivalents who are more collaborative in nature.
• A weak company culture. Office staff can still be perfectly diligent in their work, but they're still not involved in their work. These are the folk who follow the status-quo and work the 9-5. 5:01pm they're out the door and a programmer in the zone will want to carry on. This makes the programmer feel like they're the only one making any effort. Other workers don't want to engage and make the workplace an unpleasant sterile environment to be in. Everyone on the team should go for socials together, wither that be drinks in the pub every other Friday night, or attending tech meetups together during the week. The culture of companies that don't have any of this social aspect have stark drops in the happiness of a programmer compared to other companies.
• Poorly skilled programmers mixed with highly skilled programmers. It's quite natural to have a range of experience in a group of programmers. And it's good to match juniors and seniors together. But being poorly-skilled and not a junior is a problem. These are the indiviuals hired into the company without any technical interview, the people whose father pulled a favour with management, or someone tagged along and absorbed from an earlier company and now is just along for the ride (even if the company has changed well beyond what they were originally hired for). These are the people that don't learn, don't seem to care, and see the job as just a stepping stone or are here because they can't find anything better. These people are toxic. They drag down the skills of the best programmers because they require so much supervision. All their work needs checking and they need help even to acomplish the basics. A pro-active company will weed out these programmers quickly, or assign them to other more suitable tasks. But a company (usually a company on a very very tight budget that cannot afford to hire better skilled programmers) that does not address this will eventually (and permanently) force out their best programmers simply because of the frustration that comes with feel like 'working in a crèche'.

The emotional space

• Not caring about the product.  This can be caused by a number of reasons ranging from disagreements with management about how the product is made, falling out with new company owners, and generally coming to the conclusion that the product will never succeed in it's goals because of factors beyond the programmers control. Creating something is part of the reward for the programmers effort. But there is no point for the programmer to do anything if the company sales pitch is poor, feature-sets are watered down or badly designed, or if company management has no ambition to create something of quality.  No decent programmer want to put their name to some piece of nasty work.
• An uninteresting product. This could be caused by the product not very relevant, built using old obsolete technologies; or having to deal with a large quantity of old broken code.  This sort of work adds an emotional tax to the work, and makes it very hard to get motivated.