Programming and keeping context in mind

[nancylebov]

From DotMac:

A programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.

I'm not sure how much of this is really new, and it parallels the detailed material in The Logic of Failure about the ways people who were good at complex computer simulations were different from those who were bad at them. In particular, those were good put work into thinking about whether what they were doing made sense and checking on it, while those who were bad either gave up easily on the whole take, or spent their time on small problems which were easy to define but not very important.

Link thanks to Geek Press.

Comments

[captain-button.livejournal.com]

My father, a FORTRAN programmer of the old school, talks about how timesharing operating systems were bad for programming skills. He said studies had shown that as the turnaround time to get your results went down, there was a point where total time to write the program started going back up.

That is, when you do batch programming and it takes a while to get your results printout, you are more likely to think things out carefully like a Good programmer above, and less likely to make random changes like a Bad programmer above.

[madfilkentist]

Then there's the time good programmers spend building on or fixing code written by bad programmers.

Seriously, "lines of code" isn't all that useful a measure of productivity. If you're good about reusing libraries, you can do a complicated task by writing just a few lines of code to invoke it. A bad programmer, or one without a suitable infrastructure to work from, might write pages of code to do the same thing.

[whswhs.livejournal.com]

This makes me think of an inconvenient experience I had earlier this year. I had just finished the first draft of a new book for Steve Jackson Games. Then, as I was doing the final review, I made a really dumb mistake . . . and erased all the text, irrecoverably. So I had to re-create the entire manuscript from the outline and memory. It had taken me two months to write it the first time; it took me about 20% as long the second time. The difference was that I had already done all the thinking—all I had to do was the writing. The thinking had been about 80% of the work of writing the book, in other words.

[bradhicks.livejournal.com]

Yep, you are beginning to discover the horror that is the computer industry as we now know it. Now let me fill in the last, missing, detail that makes the horror complete: at the end of the first month, the good programmer gets fired and the bad programmer gets promoted. Why? Because every time the manager walked past the good programmer's cube, the good programmer was staring into space or something equally unproductive, and he only wrote 10 to 12 lines of code a day. The bad programmer was visibly banging on the keyboard the whole time he was there, and (since the bad code that had to be removed counted towards his productivity stats) he was writing 80 to 100 lines of code a day or more.

When I went into computers, I assumed it would be the perfect field for me because the outcomes were binary and indisputable: either the (expletive) code works, or it doesn't. What ruined the industry for me was that managers lowered their expectations for what counted as "working code" and that my work was being judged, in general, by people who had no idea what the heck I did for a living. Now part of my general advice for kids thinking about a career is don't ever, ever, ever consider going into a line of work where your boss, and his boss, will have no idea what you do all day.

[whswhs.livejournal.com]

Unfortunately, as a result of corporate takeovers, and the emergence of a profession of "business administration" that trains people to "manage" on the theory that the same managerial skills are freely transferrable from any enterprise to any other, nearly every occupation is now "a line of work where your boss, and his boss, will have no idea what you do all day." At least in the corporate and government sectors. Self-employed people and employees of small businesses face less of this problem in general.

Science

[(Anonymous)]

Science is similar but worse-afflicted with the same problem. The major funding agencies, paper review boards, etc, have ultimately come to define good work as "spending their time on small problems which were easy to define but not very important." and to actively oppose scientists who do other types of work. For instance, Irene Pepperberg actually lost grants and funding when she published her work on Alex.

Re: Science

[whswhs.livejournal.com]

Happens in other fields, too. The woman who published The Technology of Orgasm (a history of the vibrator and of the medical ideology that rationalized its use) lost tenure, if I recall correctly, because it was decreed that her published research did not represent a legitimate use of scholarly resources.

Re: Science

[(Anonymous)]

As far as I can tell, Rachel Maines had stopped being a professor ten years before she wrote the book. Moreover, it seems to have relaunched her academic career, though she seems not to have tenure, ten years on.

[nancylebov.livejournal.com]

Do you know about Goodhart's Law? I'm thinking about writing a piece called Goodhart's Hell.

[henrytroup.livejournal.com]

Ageed that LoC (lines of code) is a poor metric; but the stats are nothing new. I've done little but program (and lately, manage programmers) since about 1982. Better languages do more in fewer lines; today, it's not even the language but the framework.

today I and another programmer added a minor feature to our product. It was indeed about 20 lines, across a dozen or so files. Sometimes we might write a huge screed-I have one of those coming next Monday, in fact, and it requires no thought whatsoever.

I guess I'm just agreeing from my experience.

At 30 developers, we're a fairly big shop-and 10% of the company! But we still have second level managers doing some hands-on coding. I wouldn't be quick to take a job where the boss doesn't code, and very cautious if he/she can't code.