Great stuff, I also really enjoyed Robert Glass's book on facts and fallacies of software engineering, some of which touches on those supposed "facts" that are in reality merley techniques that have worked, rather than the best way to do things.
Ok here's one, not really related to the Hacknot article but interesting I think:
"Fallacy 10: You teach people how to program by showing them how to write programs".
Glass notes that in programming courses and books, all focus is on how to write code, not how to read it. He also notes that when learning any other language (including our native one), we first learn how to read it, then afterwards comes the writing.
I think this does make a lot of sense, in fact we've just started working on new project here at Numerica, which involves making modifications to a two year old product written by another company. The first thing my manager said this morning was "how on earth do you start figuring out how it all works?"
I couldn't really answer, other than "well, I'll pick an area, and start picking through the relevant code, that'll lead me to need to understand supporting modules, and then I suppose I'll start picking through that code too, and so on ..."
If anyone knows of any good tips and techniques on how to best read someone elses code, I'd be very interested to see them.
What an interesting question. For me, it's always been a matter of finding the abstractions. Programming, after all, is a matter of constructing abstractions - otherwise we'd just type in ones and zeros. Unfortunately, most people suck at making good abstractions, so their code is hard to read. But you still need to try to figure out what they're representing.
The main reason for this, of course, is to be able to figure out what you can ignore. For most of us, there's no way to hold more than a few things in your head at the same time, so the more of the code you can ignore, the better. Knowing what code you can ignore means figuring out where the interdependencies are. If module A has no interdependencies with module B, then you can ignore module B when looking at module A.
Of course, this is mostly obvious to someone that writes code, and mostly meaningless to someone that doesn't, so I don't think it would help your boss at all.
Great stuff, I also really enjoyed Robert Glass's book on facts and fallacies of software engineering, some of which touches on those supposed "facts" that are in reality merley techniques that have worked, rather than the best way to do things.
ReplyDeleteInteresting. Got an examples for us?
ReplyDeleteOk here's one, not really related to the Hacknot article but interesting I think:
ReplyDelete"Fallacy 10: You teach people how to program by showing them how to write programs".
Glass notes that in programming courses and books, all focus is on how to write code, not how to read it. He also notes that when learning any other language (including our native one), we first learn how to read it, then afterwards comes the writing.
I think this does make a lot of sense, in fact we've just started working on new project here at Numerica, which involves making modifications to a two year old product written by another company. The first thing my manager said this morning was "how on earth do you start figuring out how it all works?"
I couldn't really answer, other than "well, I'll pick an area, and start picking through the relevant code, that'll lead me to need to understand supporting modules, and then I suppose I'll start picking through that code too, and so on ..."
If anyone knows of any good tips and techniques on how to best read someone elses code, I'd be very interested to see them.
What an interesting question. For me, it's always been a matter of finding the abstractions. Programming, after all, is a matter of constructing abstractions - otherwise we'd just type in ones and zeros. Unfortunately, most people suck at making good abstractions, so their code is hard to read. But you still need to try to figure out what they're representing.
ReplyDeleteThe main reason for this, of course, is to be able to figure out what you can ignore. For most of us, there's no way to hold more than a few things in your head at the same time, so the more of the code you can ignore, the better. Knowing what code you can ignore means figuring out where the interdependencies are. If module A has no interdependencies with module B, then you can ignore module B when looking at module A.
Of course, this is mostly obvious to someone that writes code, and mostly meaningless to someone that doesn't, so I don't think it would help your boss at all.