I wish I had some wise words here. Brad, you seem to be on an assembly line. But worse. You are on an assembly line working under conditions of uncertainty. Unsure of which, if any, fix will work and ever conscious of the boss who hears the clock ticking.
A situation conducive to obsessional behaviour (step on a crack and all that...) "let's see if I wear my yellow raincoat today, perhaps things will go better as they did last week when I wore the yellow raincoat, etc....." This is terrible. To say that it is more the norm in the workplace than the exception doesn't help you much. Chris, what is your experience there in Europe. Same? Or different? Even to drag out all the old productivity arguments that people work best when they know more rather than less about the whole project is useless. (in your case it seems that you are consciously "kept in the dark" doing your own part of the project for reasons of corporate security. All the best. Arthur -----Original Message----- From: Brad McCormick, Ed.D. [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 11:56 AM To: [EMAIL PROTECTED] Subject: [Futurework] Changes the computer revolution is making in work [specific example] I've been working at computer programing for 30 years now. There has been some definite progress in computer programmers' work: Because a lot of computer programming is now done on "PCs" -- individual workstations --, there is less need for programmers to work nights and weekends. And the tools programmers now have for developing code enables programmers to produce more and better code than 30 years ago. As to the "net" of programmer productivity, I can't imagine any consensus, although many note that time a computer programmer spends learning new productivity tools is not directly productive. Should video games be counted as productivity or as costs of production? Etc. Here I wish to describe briefly a kind of work situation that is thispast wek getting me depressed and anxious, and which I doubt would have occurred before (1) the PC "Windows" era -- say, during the past 5 years, and (2) what is called "Object Oriented Programming" (OOPS), which also became prevelant about 5 years ago. I work on a single graphical user interface program on which at least 3 persons have been working full-time for over 5 years. All it does is display information about the health of the "boxes" in a company's "network". It also allows users to change some settings in those same "boxes" (routers, etc.). I want to make the point that this is a pretty complex program to have absobed so much effort for such a narrowly circumscribed function (there is a whole different group that gathers the information from the devices being monitored. I think that group (plural: groups) is bigger. So here I try to describe the characteristics of this work task that is "getting to me" (keep in mind that I feel under time constraint in all of this!): (1) My manager thinks (surely after reviewing it with more senior technical management): The program already does something "similar to" what it needs to be changed to do, and all we are doing is to change some of the ways it gets done and some of the details. Oh, yes, there are some new things that will have to be added, but they shouldn't be major changes. (2) I have never hardly even seen this part of the program, and it's not clear to me how to do the work. First I try to "shoehorn in" the changes, since they supposedly aren't so big, but it soon becomes obvious that a lot of the code needs to be rewritten (often because it was just slapped together fast the first time it was written). (3) The changes required turn out to be a lot bigger than expected in #1, but it is also obvious that due to my learning curve, it's going to take me more time than it would take someone who was familiar with the code. Part of the reason here is that I keep trying to guess how to rewrite the code so that it will be easy to add in those new functions at the end of #1, while I still do not have a really good sense of what needs to be done and what is merely including "hooks" to permit addition of functions that nobody will even want to add. (4) I finally get the basic code reworked (see below...), and then comes trying to add in those things at the end of #1. The project keeps dragging on and I don't get a good sense of "where I am", and I keep hoping for the moment when I will "see the light at the end of the tunnel". (0-5) However, there is another attribute that pervades the whole thing and which contributes greatly to the stress: I encounter something I can't figure out, or I don't even have a goid idea where to start looking, and I have to ask my manager for help. After he has offered enough help that he thinks he would have needed to get moving again, he starts getting frustrated with me, and I fear for my job (needs too much hand-holding even after being hereover 4 years). I try my best to solve problems myself, and I do succeed something between sometimes and often. Often I run up against something where I feel I need an answer from my manager before I go further, since I don't want to waste time going down a wrong path. This "dead time" is really unnerving since I keep thinking of the "meter ticking". If I felt I had a handle on what I was doing, I'd use this time o do something for myself, but here I feel too guilty about my lack of progress to let myself do that. My personal reaction it to bury myself in trying to make effort -- which I hope against hope may lead to progress even though I have no idea how to make progress instead of just heat (incl. "friction" with my manager, as per above). I withdraw, I get anxious, I get depressed. I have timidly brought up this with my manager, and he says that he can help me if I can clearly formulate what I'm stuck about, and he even once acknowledged that may be difficult for me to do. I keep trying to plug along. I keep tryingto do anythiung I thiunk I *can* do, in hopes that will help me figure out more.... Here is an example of how "deep" I am (over my head?) in this particular project. Frequently in my computer programming work, I will curse when something doesn't work. BUT HERE: I'm too frightened to curse much -- partly become I'm becoming superstitious and think the code might attack me even worse than it already has. HOWEVER: On Friday, I figured out one small thing that was wrong. I had plugged away at my detective work for a couple hours, and suddenly I think I've found either the root of the problem or at least a *BIG* part of the problem. So I make my little change to implement the little correction I have figured out. And, when I try my fix and find the function that wasn't working works (remember: It has now just worked once, so I don't know yet if the problem is *fully* fixed!)::: Seeing the code work, I SHOUT: "Ya-Hoo!". As previously said, I often shout curses in doing my computer programming work, but I can't remember the last time I gave a "positive" exclamation -- unless maybe I had found one other such fix, a day or two earlier, in this same task. (When I am not in this stressed condition, and I solve some problem or make big progress, I generally will breath a sign of relief or satisfaction, and maybe walk around the office quietly for a couple minutes [a kind of discreet "victory lap" to cool down], but I never shout about it. (Oh, yes, I take a backup so I don't lose it!) -- I know I have left out all the details. But have I described the "game" (ref. Wittgenstein's "lauguage games", etc.)? Can I clarify further for you? Does anyone see anything to discuss in this work structure? I think it may be fairly common in the world of computer programming work today, in part because individual work stations tend to chop programming up into "programmer-and-workstation" symbiot chunks, and also because of the way "Object Oriented Programming" (OOPS) tends to make code more reusable and therefore give management more of an idea that all the programmer has to do is plug the existing functional units ("classes") together in a certain pattern, and maybe add a relatively small amount of new code, and that everything should be prety easy for the programmer to understand, since it's all built from standard units (those "classes", again). Any thoughts about this, for work life in our place and time? Anybody out there se any "ideas" ideas how to do better with my situation? Because it's quite poossible I can't see the obvious. (One suggestion that is not likely helpful: (1) Find a better job -- I am convinced this is a better job. Sure there may be a better job in Boseman Montana, but I'm not likely moving, and, to repeat, I really do think this job is at least 75th percentile, or maybe even 90th.) I hope this has been of some list-related interest. \brad mccormick -- Let your light so shine before men, that they may see your good works.... (Matt 5:16) Prove all things; hold fast that which is good. (1 Thes 5:21) <![%THINK;[SGML+APL]]> Brad McCormick, Ed.D. / [EMAIL PROTECTED] ----------------------------------------------------------------- Visit my website ==> http://www.users.cloud9.net/~bradmcc/ _______________________________________________ Futurework mailing list [EMAIL PROTECTED] http://scribe.uwaterloo.ca/mailman/listinfo/futurework _______________________________________________ Futurework mailing list [EMAIL PROTECTED] http://scribe.uwaterloo.ca/mailman/listinfo/futurework
