stevans@resumix.UUCP (Mark Stevans) (11/13/90)
I invite commentary and/or anecdotes for or against the following thesis: There is, in general, an inverse correlation between the amount of source code hardcopy a programmer employs and the productivity of that programmer. In my observation, the least competent programmers tend to print updated listings of every line of every file of their source code at the same time every day, and go through them with highlighters. The best programmers I have known don't even care if "lpr" exists or not. Me? I used to print tons of stuff until I recognized this principle :-) Mark Stevans resumix!stevans@decwrl.dec.com
pds@lemming.webo.dg.com (Paul D. Smith) (11/14/90)
[] I invite commentary and/or anecdotes for or against the following
[] thesis:
[] There is, in general, an inverse correlation between the amount
[] of source code hardcopy a programmer employs and the
[] productivity of that programmer.
[] In my observation, the least competent programmers tend to print
[] updated listings of every line of every file of their source code
[] at the same time every day, and go through them with highlighters.
[] The best programmers I have known don't even care if "lpr" exists
[] or not.
Hmm. I'm not prepared to comment on most cases of this thesis, but I
will propose a lemma:
Lemma 1: The above thesis does not hold if the programmer in
question is working with code not originally written by
himself or herself.
I rarely resort to printouts of my own code (I'm sure I'm at least a
competent programmer ... :-), but whenever I have to maintain / modify
code written by someone else I generally end up having to get a
printout and wade around in it. GNU Emacs TAGS, etc. are great, but
even with 55-line windows like I have on my AViiON workstation I
sometimes can't get all the relevent info on at once ...
This is especially true (obviously) with uncommented and/or awkwardly
structured code. *My* code is quite clear to anyone looking at it, so
obviously Lemma 1 does not hold for programmers working with my code
:-) :-)
--
paul
-----
------------------------------------------------------------------
| Paul D. Smith | pds@lemming.webo.dg.com |
| Data General Corp. | |
| Network Services Development | "Pretty Damn S..." |
| Open Network Applications Department | |
------------------------------------------------------------------brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (11/14/90)
In article <46@resumix.UUCP> resumix!stevans@decwrl.dec.com (Mark Stevans) writes: > I invite commentary and/or anecdotes for or against the following thesis: > There is, in general, an inverse correlation between the amount of > source code hardcopy a programmer employs and the productivity of > that programmer. Depends. The problem with screen editing is that you can never get enough context. When I feel like I'm in a lull in coding on screen, I'll print the program out (usually with several other programs in the same state, and a few completed projects for last looks) and spend a few hours working with it away from a keyboard. I do this maybe a couple of times every few months, and for some programs it really helps. Sometimes I find it's rather useless. I still haven't had the urge to print out the pty source. The original code, along with 100 megabytes of mail and other miscellany, is archived on a tape gathering dust in my apartment, just in case disaster ever strikes. I doubt I'll ever read that tape or its companions. Or send any of the files to a printer. Occasionally it's useful *not* to have copies of a new program, because (accidentally) deleting it and starting all over is a great way to radically improve the design and implementation. But I've found that it doesn't require much discipline to do this even if you have copies. So I don't see much in your statement to agree with. (Then again, maybe I program unproductively, so maybe you're right. :-) ) ---Dan
heim@vms.macc.wisc.edu (JOHN HEIM ) (11/15/90)
In article <46@resumix.UUCP> resumix!stevans@decwrl.dec.com (Mark Stevans) writes: > I invite commentary and/or anecdotes for or against the following thesis: > There is, in general, an inverse correlation between the amount of > source code hardcopy a programmer employs and the productivity of > that programmer. I definately agree. In fact I've advanced the same theory myself at times. I've seen *several* exceptions, great programmers who print stuff alot (many times they're folks who first learned to program on a teletype). But the vast majority of people who I've seen who make alot of code listings are poor programmers. Mostly they print stuff when they're in trouble and can't get a handle on what their own program is doing (usually due to poor stucture). The place I worked at before comming here, which had several excellent programmers, didn't really even *have* a way to make code listings. Of course, I'm one of those people who never make code listings so maybe I'm just egotistical. ------------------------------------------------------------------------------ John G. Heim Internet: heim@macc.wisc.edu UW - Madison Academic Computing Center Phone: 608-262-9887 1210 W. Dayton St. Fax: 608-262-4679 Madison, WI., 53706 CIS: 71570,3712
jamiller@hpcupt1.cup.hp.com (Jim Miller) (11/15/90)
I agree with Paul, with my own code I seldom print it out. In one 2 year project I only printed the code for walkthroughs and a final copy to keep when I left the project. When I was doing extensive modification of an existing compiler, I got two tables (you know, those things with 4 legs and a flat horizontal workarea), complete listings and a complete cross-reference, as well as all the documentation available on it. I did the job in record time and the quality was -- no bugs. (ok, maybe one -- and it was for internal use only so the usage was not as large as for a released product) jim miller jamiller@hpmpeb7.cup.hp.com (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... ) Anything I say will be used against me ... But my company doesn't know or approve or condone anything of mine here.
rmartin@clear.com (Bob Martin) (11/15/90)
Interestingly enough I have noticed that several rather sloppy programmers never print their code. I think it because they don't want anything their bosses could acutally look at. I have also seen some very impressive code from engineers who did all the coding by hand first, and then typed the code into a terminal. Some engineers like to see how their code looks from someone else's point of view, so they print it out and _read_ it. Some engineers like to carefully check their code, and so print it out with a cross reference and spend a few profitable hours finding silly bugs that would have taken a few wasted days to find otherwise. Perhaps some day some manager will notice that the programmers who wear ties and come in at 7AM write the best code... It is dangerous to generalize about work habits. It borders on prejudice (meaning to pre-judge). Judge an engineer on his output and not on his manner of input. -- +-Robert C. Martin-----+:RRR:::CCC:M:::::M:| Nobody is responsible for | | rmartin@clear.com |:R::R:C::::M:M:M:M:| my words but me. I want | | uunet!clrcom!rmartin |:RRR::C::::M::M::M:| all the credit, and all | +----------------------+:R::R::CCC:M:::::M:| the blame. So there. |
3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics) (11/16/90)
In article <46@resumix.UUCP> resumix!stevans@decwrl.dec.com (Mark Stevans) writes: > I invite commentary and/or anecdotes for or against the following thesis: > There is, in general, an inverse correlation between the amount of > source code hardcopy a programmer employs and the productivity of > that programmer. I always print my header files, to have the structure defs and argument lists handy. Even on a workstation with X, there just isn't enough room on the screen. Other than that, I do without paper. Well, no, that's not quite true. Mostly, I write subroutine libraries (to do finite element analysis, if you must know). Then I write test programs to exercise the libraries and flush the bugs out in the open. (Most of the bugs are in the test programs... comments, anyone?) Then the trouble starts: one of the test programs is too useful for its own good and I end up adding more bugs --er, features-- to it. The spaghetti monster lurks. THEN I need a source listing. Printouts do help me to grasp large programs in their entirety. I'd say there is some truth to your thesis, because I print only when I am in trouble. --Pierre Asselin, R&D, Applied Magnetics Corp.
peter@ficc.ferranti.com (Peter da Silva) (11/16/90)
I think it's more a matter of the quantity of code listing is inversely proportional to the quality of the *code*, not the programmer. I find I tend to make listings, as a maintanance programmer, only when I'm working on really evil stuff. Remember, the guy who wrote the stuff and the guy who's working on the stuff are not always the same guy. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
schuldy@intrbas.uucp (Mark) (11/16/90)
I think I would change the thesis to "The quantity of UNREAD hardcopy printed during the project is inversely proportional to the quality". Good people do only what they need to do, bad people do more (or less). Sometimes (and you don't care when) I think I need hardcopy, so I get it. One guy at my last job seemed to print about 70-100 pages of source a day. Usually he wouldn't even bother to pick it up from the printer room. Fortuneatly, with skills like this he generated very little new code... so we didn't have to ignore much. schuldy
thornley@cs.umn.edu (David H. Thornley) (11/17/90)
In article <U3=6YL3@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >I think it's more a matter of the quantity of code listing is inversely >proportional to the quality of the *code*, not the programmer. I find I >tend to make listings, as a maintanance programmer, only when I'm working >on really evil stuff. > And may I suggest an inverse relation to the quality of the display and editor? A 16-line single-window terminal with a brain-damaged editor is a lot harder to use without listings than this large-screen X system I'm using right now. DHT
gwyn@smoke.brl.mil (Doug Gwyn) (11/17/90)
In article <U3=6YL3@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
-I think it's more a matter of the quantity of code listing is inversely
-proportional to the quality of the *code*, not the programmer. I find I
-tend to make listings, as a maintanance programmer, only when I'm working
-on really evil stuff.
Yes, in really difficult cases the use of colored pencils and highlighters
can help a lot. Those are best done on paper..dbc@bushido.uucp (Dave Caswell) (11/18/90)
.Then there is hope for them! They are reading the code! In my experience, .the one's I worry about *never* sit down with a listing and actually read .the code to find out what's happening. . .The single best way to improve maintainability and reliability is to run .off a listing now and then and distribute it to your coworkers to mark up. .I always challenge them to find *anything* wrong with my code, the idea .being better to fix it then than be embarassed by customers. Often the most fun projects are a group of five or less people. Before anyone's code is intergated into the project it is read by everyone. It helps to ensure a quality project and makes it far easier to replace someone who leaves. It also encourages you to be more rigorous in your development knowing your peers will be reading your work. If your peers can't easily read your work to make changes as well as to catch errors there is a problem; personel changes or whatever is the solution. -- David Caswell dbc%bushido.uucp@umich.edu
userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (11/19/90)
In article <46@resumix.UUCP> resumix!stevans@decwrl.dec.com (Mark Stevans) writes: > I invite commentary and/or anecdotes for or against the following thesis: > There is, in general, an inverse correlation between the amount of > source code hardcopy a programmer employs and the productivity of > that programmer. Must be true - I have become a much better programmer since getting my own PC and having to buy my own printer paper! :-) -------------------+------------------------------------------- Al Dunbar | Edmonton, Alberta | "this mind left intentionally blank" CANADA | - Manuel Writer -------------------+-------------------------------------------
jamiller@hpcupt1.cup.hp.com (Jim Miller) (11/20/90)
> >Yes, in really difficult cases the use of colored pencils and highlighters >can help a lot. Those are best done on paper.. ***** So THAT's been my problem ... :-) jim miller jamiller@hpmpeb7.cup.hp.com (a.k.a James A. Miller; Jim the JAM; stupid; @!?$$!; ... ) Anything I say will be used against me ... But my company doesn't know or approve or condone anything of mine here.
peter@ficc.ferranti.com (Peter da Silva) (11/22/90)
Well, we use printouts because it's hard to get liquid paper off these new-fangled anti-glare screens. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
dmocsny@minerva.che.uc.edu (Daniel Mocsny) (11/26/90)
In article <28762@shamash.cdc.com> ddh@dash.udev.cdc.com (Dan Horsfall) writes: >Granted, this is comp.lang.c, but I've been whining at length about the >complete and utter absence of such utilities for un*x f77 -- I miss my >CYBER FTN cross references, wherein you can get > o A "stray name" flag -- any symbol that appears only once in a module > is VERY likely a keying error; If UN|X f77 supports the IMPLICIT NONE statement, then the compiler will flag all your undeclared variables. When I used to code a bit in FORTRAN, I got socked a few times by typos in identifiers. Sometimes these errors are insanely hard to find, especially when you are working with someone else's code (which may contain subtle errors you haven't conditioned yourself to look for). For example, I read some code that had a variable like BLURFO, and in one place the author had typed BLURF0. Aaaagh! This was especially bad because the printout made O (letter "oh") and 0 (numeral "zero") look very similar. No compiler should simultaneously permit (1) programs of more than 20 lines and (2) undeclared variables. -- Dan Mocsny Snail: Internet: dmocsny@minerva.che.uc.edu Dept. of Chemical Engng. M.L. 171 dmocsny@uceng.uc.edu University of Cincinnati 513/751-6824 (home) 513/556-2007 (lab) Cincinnati, Ohio 45221-0171
schriste@uceng.UC.EDU (Steven V. Christensen) (11/27/90)
dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes: >If UN|X f77 supports the IMPLICIT NONE statement, then the compiler >will flag all your undeclared variables. Unfortunately, if you are assigned the job of maintaining others' code, then doing an IMPLICIT NONE will break the current stuff... >No compiler should simultaneously permit (1) programs of more than >20 lines and (2) undeclared variables. I understand (2), but why (1)? There is a lady with whom I work who insists on breaking up even the simplest procedure into many sub-procs (this is FORTRAN). In combination with ridiculously long proc and variable names, it makes it even harder to debug... But then you know what they say: there are 2 things you can't criticize: someone's religion, and their programming style... >-- >Dan Mocsny Snail: >Internet: dmocsny@minerva.che.uc.edu Dept. of Chemical Engng. M.L. 171 > dmocsny@uceng.uc.edu University of Cincinnati >513/751-6824 (home) 513/556-2007 (lab) Cincinnati, Ohio 45221-0171 Steven -- Steven V. Christensen U.C. College of Eng. schriste@uceng.uc.edu For the adventurous: svc@elf0.uucp
architec@cutmcvax.cs.curtin.edu.au (Phil Dench ) (11/27/90)
In article <46@resumix.UUCP> resumix!stevans@decwrl.dec.com (Mark Stevans) writes: > I invite commentary and/or anecdotes for or against the following thesis: > There is, in general, an inverse correlation between the amount of > source code hardcopy a programmer employs and the productivity of > that programmer. I find that I rarely do any hardcopy now that I work chiefly on workstations with multiple windows. Being able to view/edit multiple files simultaneously certainly has increased my productivity. Phil
hagins@dg-rtp.dg.com (Jody Hagins) (11/28/90)
In article <E:37__3@xds13.ferranti.com>, peter@ficc.ferranti.com (Peter da Silva) writes: |> Well, we use printouts because it's hard to get liquid paper off these |> new-fangled anti-glare screens. |> -- |> Peter da Silva. `-_-' |> +1 713 274 5180. 'U` |> peter@ferranti.com |> I thought they only did that at Clemson :-). -Jody. hagins@gamecock.rtp.dg.com
tr@samadams.princeton.edu (Tom Reingold) (11/30/90)
dmocsny@minerva.che.uc.edu (Daniel Mocsny) writes: $ No compiler should simultaneously permit (1) programs of more than $ 20 lines and (2) undeclared variables. In article <6785@uceng.UC.EDU> schriste@uceng.UC.EDU (Steven V. Christensen) writes: $ I understand (2), but why (1)? There is a lady with whom I work who $ insists on breaking up even the simplest procedure into many sub-procs $ (this is FORTRAN). In combination with ridiculously long proc and variable $ names, it makes it even harder to debug... I am pretty sure Dan meant logical "and". (There goes someone else claiming to know what Dan meant.) In other words, no compiler should allow both of these things at the same time. -- Tom Reingold tr@samadams.princeton.edu OR ...!princeton!samadams!tr "Warning: Do not drive with Auto-Shade in place. Remove from windshield before starting ignition."