I can’t remember the URL but I read an article a while back the work programmers hate the most is work that is random. Random work is work such as fixing other people’s bugs, trying to figure out other people’s code (esp. undocumented and/or difficult to test), and problems with no clear specifications, direction, and/or solution. This is why many programmers reinvent the wheel. Although it’s often a time loss to do so, it’s much preferable to solve a known problem with a known solution and make daily progress than guess at something that may or may not do what you want.
Probably after random work would be busywork, or work with no especial benefit or use. It’s not the work in this case but the lack of importance of what you are doing.
Conversely, programmers like challenges, especially when the challenge is important. This is why lead programmers work hard. They feel important (because they are responsible for important things), they are given challenging tasks, and the work they are given is usually time and mission critical. It’s not really because they make more money. It’s true that money attracts workers and it’s important to pay enough so that workers can live comfortably. However, what retains workers is rewarding work. Programmers enjoy working on interesting, important problems. Creating this enviroment will give you far better retention and enthusiasm than just paying more money.
The same task presented diferently can get different results. Saying to a senior graphics programmer “You have two weeks to write the grass waving system” is guranteed to demotivate and the first week will be spent on Slashdot, especially if it’s something they solved before with no new challenges. Saying to a junior graphics programmer, or a non-graphics programer, “You have 3 days to do the grass waving system. Here are some resources to get you started” will be an exciting challenge with an opportunity to learn, especially with someone more senior available to ask questions of. No deadlines, or deadlines too long, is just as bad as deadlines that are too short. Deadlines present a challenge to get the work done in time, which motivates one to work.
This is why I try, when giving assignments, to remove as much guesswork as possible with clear specifications, descriptions of intermediate steps, and a justification as to why the assignment is important. It’s very important to be able to provide a constant line of communication, help, and answers to people working. Not doing so leads to guesswork, which is random, and hence annoying and demoralizing.
Incidentally, it’s also why I’ve finally figured out why I hate a new contract I took so much. It pays very well. Until today I couldn’t understand why I would feel literally sick to my stomach to work on it. I was assigned to create a facade design pattern to undocumented spaghetti code, on a platform I never used before, with little communication or support, using primitive tools. On top of that, when I do ask questions, I’m ignored half the time, making me feel I am not important. The work is essentially random – spend a lot of time to make a guess, repeat, until I figure out the system, then write the facade. In the end, it may not work anyway. It drains away my enthusiasm to work at all, including on my own game.