Schedule meetings every 2 hours, just so that the programmer never gets any flow going. Then ask in the meetings why there isn't any progress.

Better yet: Call every two hours (sometimes less), and try to get the programmer to fix a very small issue you are having. Then bitch about the code not being done. Oh, and have the programmer admin the servers. Server goes down? ick between getting shit about the server or shit about the code. Thx Zeus I'm not there any more.

Oh, server admin. That's a good one. After all, how hard can that be? You set it up and it just runs, right?

From my time as a government contractor: show a programmer a problem that causes significant waste, that he knows exactly how to fix and then forbid him from fixing it for nebulous political reasons.

When I worked over in the DoD world, waste used to send me over the edge.

Find zen by realizing that the political reasons for waste are not nebulous; the whole Pentagon system is designed to stimulate the US economy (through spending). Spending money is the point.

Politically, this waste is generally supported by legislators and their constituents. Which is why the B-2 bomber was built in 46 states. See: * Pork Barrels http://en.wikipedia.org/wiki/Pork_barrel * Spinney's "Defense Power Games" http://www.dnipogo.org/fcs/def_power_games_98.htm * Chomsky's "The Pentagon System" http://www.thirdworldtraveler.com/Chomsky/PentagonSystem_Cho...

Withold admin rights on their work computer.

Force them to remote into a slow machine on a slow network connection running Windows 98

Constantly change the requirements for a project.

Insist that they stop work on project A to work on B, C, D, then ask why they haven't made good progress on A.

Require a complex scrum planning process, approval from designers, principal reviews, extensive project financial analysis. Then on day one of the sprint, scrap all that for your personal pet project that has high VP visibility with no justification.

Find out when they come in to work every day. Schedule a daily recurring meeting an hour or 30 minutes before then. (also works if you schedule the meeting right after they normally leave).

Don't pull their pull request when they've put a lot of work into them.

To be fair, often when this happens it's due to a lack of communication on the programmer's part. Giant pull requests out of nowhere (even well-crafted ones) may not always be what the project maintainers want or need. This is why it's useful to discuss (non-trivial) fixes or design ideas before attempting to implement them.

Only take on projects that involve modifying templates from obscure and obsolete CMS's.

Ask a programmer what makes him go over the edge and send him over the edge.

Remap 1 to l, O to 0 and vice versa (but only one out of three times)

Keep them away from HN over a longer period of time.

Ask him to record everything he does ;)

Why do you want to do that?

Use windows.

Not a very general answer, many programmers use Windows. More generally applicable answer: hire programmers for a work environment on one OS. Announce one day that the company is switching to $newOS and all developer machines need to run $newOS as of next week. For bonus points, say that tools, etc, that are not available on the new platform will be worked out as they come up (and probably have no budget for replacing them).

(I appreciate it, but you should probably just use the vote up mechanism instead of adding a '+1' comment)

Grandparent is deleted, but maybe on-topic:

Making a whole post to say "+1" on a website that has built-in upvoting functionality probably sends a few people over the edge.

Meh. Virtualbox/VMware is a great detour around that now.

Still doesn't feel the same as running Linux on bar metal and also not accepted in every company.