Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site unc.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!unc!fsks From: fsks@unc.UUCP (Frank Silbermann) Newsgroups: net.social Subject: Re: Work Ethic Message-ID: <279@unc.UUCP> Date: Fri, 24-May-85 17:04:09 EDT Article-I.D.: unc.279 Posted: Fri May 24 17:04:09 1985 Date-Received: Sun, 26-May-85 00:38:33 EDT References: <686@udenva.UUCP> Reply-To: fsks@unc.UUCP (Frank Silbermann) Distribution: net Organization: CS Dept., U. of N. Carolina at Chapel Hill Lines: 38 Summary: In article hollombe@ttidcc.UUCP Jerry Hollombe (The Polymath) writes: > >For a person's work to be meaningful to them certain conditions must be >met. An analogy was drawn with the activities of a bowling team. On the >face of it, rolling a ball at some pins is a pretty simple, mindless >activity -- much more so than most of our jobs -- yet people pay for the >privilidege of doing it. The motivations are revealed by changing certain >aspects of the game and watching the results. > >Second, suppose the pins are there but there's a curtain across the alley >so you can't see them. You have to rely on someone else to tell you how >many you hit, or you get no information about it at all. Suppose you >didn't think you could trust the person who was giving you the information. Boy did that article strike a raw nerve with me! When bowling, suppose your score was based upon what the previous bowler rolled, whereas your pins hit were awarded to the next guy in line. How would that affect your morale and motivation? This is the situation that programmers routinely face. If I develop a kludgy new system as fast as I can, the boss rewards me for being a competent (i.e. fast) programmer. The next guy who must maintain my system takes forever to get anything done because my system is so hard to understand. The boss punishes him for his incompetency. Suppose I take the time to develop a system that is clean, simple and predictable. Since the boss won't read my code, he doesn't appreciate its quality. Since I take longer to complete the project, he has a reduced opinion of my skills. But, when I'm gone, the next guy has an easier job. Not only does this situation produce programmer burnout, it's probably the reason most code today is so bad, and why program maintenance budgets are soaring. Frank Silbermann