tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
[personal profile] tim
A brief rant since I don't feel much like talking about the specifics of the progress I haven't been making lately. People I work with, don't take this personally; it's more about a general trend :-)

I'm not very good at reading code, or perhaps it's that I don't like reading code and so I don't do it, and don't get better at it. I'm not sure. In any case, I certainly prefer writing code to reading code. This probably makes me like most programmers. Still, you're supposed to get something out of reading code, and I often don't.

Part of the problem is that code often doesn't have very many comments in it. When I'm writing code, I'm not always the best at commenting it either, but often I find I have to write comments just to keep track of what I'm doing, because otherwise I lose my train of thought. When I read un-commented code, I think "this person must be a better programmer than me, because they can hold so much stuff in their head without writing it down". I get intimidated and my mind shuts down and I think maybe I should be a bus driver.

Maybe people who can keep all that state in their heads are better programmers, I don't know. But when it's just in someone's head, it's not available to someone else who might want to work on the project. A friend wrote recently about the ways in which lack of documentation excludes new contributors from open-source projects, particularly new contributors who have plenty of ability but aren't comfortable joining an often-frat-boyish IRC channel to get documentation. Some people need documentation more than others, depending on their social placement.

I'm already in a project, so I should be able to get information the informal way, but sometimes I feel like I ought to know already. Because I don't like reading code that isn't well-commented, I'll do almost anything else to figure out what's going on -- running it repeatedly with lots of print statements added, for example, which incurs a high cost when builds are slow. Or tweaking test cases fairly randomly and observing the change in behavior, or reading the code the compiler generates, which for whatever reason is cumbersome (just making it visible, not understanding it). That takes a lot of time when in some situations, it would probably just be faster to read the code and develop a mental model in it in my head than to -- as I more often do -- develop a model of what it does using the scientific method, treating it as a black box.

But reading the code often brings up an intolerable amount of performance anxiety for me. I can't understand it because my brain is going "you ought to be able to understand this better". Comments would help because it would remind me that the person who wrote this isn't omnipotent, and had to think hard about it in order to get it right. That they went through a process in order to create it, and the product didn't suddenly spring fully formed from their brain.

(no subject)

Date: 2012-11-03 06:31 am (UTC)
From: [personal profile] puzzlement
I don't read code very often and don't have a strong feeling about whether I'm unusually bad at it, I'm certainly not unusually good. The one most effective thing I've been part of was code walkthroughs, sort of like more extensive and shallower reviews, where we printed out 20 pages of code and the room read through it together with the authors and people asked about stuff they didn't understand or mentioned some libraries that could have been used or missing error checks or etc.

Though, I guess it's like the research seminar model: you either learn that everyone asks the same questions you wanted to, or you find that they don't. Then the latter has two explanations: they understood more than you did, or they were intimidated by the atmosphere just like (hypothetical, general) you. But while the seminar model is not especially socially comfortable or natural for me personally, I have found that it gradually increases my ability to both understand and to criticise code and/or research reports.

(no subject)

Date: 2012-11-03 09:39 am (UTC)
azurelunatic: Prayer to the Bastard from Lois McMaster Bujold's Paladin of Souls (Default)
From: [personal profile] azurelunatic
I sympathize on the too-many-questions front. Due to the way my brain is organized, I wind up taking lots of notes when learning actively from live input; this tends to be about 25% questions ("but what if--?" "do we have a thing where--?"), 50% projects-I'm-working-on, because it won't leave me alone that long, and 25% pure-random. Sometimes the questions get resolved during later parts of the thing, sometimes I decide they're not important, sometimes I ask them, and on one gloriously chaotic occasion, my question (about whether a series of checkboxes were meant to be OR or AND, and how the operator would know this) threw the room into ten minutes of experienced designers yelling at each other.

Our situations are substantially different, I think -- I'm not expected to know the guts of what the rest of my team are working on, but I'm attempting to wring out every last drop of the advantage of my unfamiliarity -- if I understand it as a neophyte, it might be sufficiently intuitive; if I don't, then it might need some improvements. I won't have this perspective forever, but I might as well do something with it while it lasts. But the lack of expectations frees me to feel comfortable asking what's going on and why.

(no subject)

Date: 2012-11-04 04:11 am (UTC)
darius: (Default)
From: [personal profile] darius
This bugs me too. Sometimes I'll add comments as I figure things out (which of course risks being wrong). In principle that could make the problem more visible -- here are all these things the authors could have easily noted which took significant work to reverse-engineer before I could make progress. In the worst case for me I was more interested in documenting the problem than the code.

Arguing against the comment-haters: http://stackoverflow.com/questions/499890/what-is-your-personal-approach-take-on-commenting/500268#500268

(no subject)

Date: 2012-11-04 11:12 pm (UTC)
ext_17921: (Default)
From: [identity profile] lindseykuper.livejournal.com
When I read un-commented code, I think "this person must be a better programmer than me, because they can hold so much stuff in their head without writing it down". I get intimidated and my mind shuts down and I think maybe I should be a bus driver.

I often feel that way, too. One thing I do to learn my way around a piece of code someone else has written is to write, myself, the comments that invariably aren't there. I've done this a lot when working on Rust.

I also keep a running text file of notes-to-self, and if I understand so little about the code I'm looking at that I don't even know where to start commenting, then I write in there about what's confusing me, and that helps me figure out what questions to ask. If I keep writing, then I keep thinking, and I make progress, however slow. I've always liked what Manuel Blum says about the power of "writing what you read":
In the case of mathematics or physics or anything especially hard, try to find something anything that you can understand.
Read what you can.
Write in the margins. (You know how useful that can be.)
Next time you come back to that book, you'll be able to read more.
You can gradually learn extraordinarily hard things this way.

Consider writing what you read as you read it.
This is especially true if you're intent on reading something hard.

I remember a professor of Mathematics at MIT,
who would keep his door open whenever he was in his office, and he would always be at his desk writing.
Writing. Always writing.
Was he writing up his research? Maybe.
Writing up his ideas? Maybe.
I personally think he was reading, and writing what he was reading.
At least for me, writing what I read is one of the most enjoyable and profitable ways to learn hard material.

You are all computer scientists.
You know what FINITE AUTOMATA can do.
You know what TURING MACHINES can do.
For example, Finite Automata can add but not multiply.
Turing Machines can compute any computable function.
Turing machines are incredibly more powerful than Finite Automata.
Yet the only difference between a FA and a TM is that
the TM, unlike the FA, has paper and pencil.
Think about it.
It tells you something about the power of writing.
Without writing, you are reduced to a finite automaton.
With writing you have the extraordinary power of a Turing machine.

(no subject)

Date: 2012-11-05 07:14 pm (UTC)
ext_17921: (Default)
From: [identity profile] lindseykuper.livejournal.com
Well, with code, you don't have to get out a pen and paper; you can just write comments inline. If it helps, think of it as doing a favor to some future code-reader (me, for instance, since other things being equal, I'd be happier reading code that's been commented by you than reading code in which there are no comments), and only incidentally as a way to learn.


tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier

December 2016

4 5 678910

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags