Women in Technology

Hear us Roar

  Myths Open Source Developers Tell Ourselves
Subject:   on code reading
Date:   2003-12-12 11:43:40
From:   anonymous2
your article is interesting but i do not agree on the code reading part and i honestly believe that it's bullshit. i made huge jumps in coding practice once i started reading other's people code and reading sources and tweaking them if a fast way to learn. i seriously doubt you've ever been involved in programming to say that reading code doesn't help you improve, it's nonsense and shit coming out. the word 'stupid' was the first one that came to mind once i read your part about reading source code. you should also consider a book like "code reading" by spinellis or leave programming matters to programmers with experience.
Full Threads Oldest First

Showing messages 1 through 7 of 7.

  • on code reading
    2003-12-12 13:07:20  anonymous2 [View]

    a distinction:

    reading code to learn 'how to code'


    reading code to learn htf a project is structured.
  • on code reading
    2003-12-12 13:00:20  anonymous2 [View]

    Code only shows you the what, not the why. It's been shown numerous times that one of the biggest contributors to developer productivty is domain knowledge. E.g understanding the problem that's being solved and for what customer.

    If the code perfectly solved the right problem for the right person, you'd never need to read it as it'd never need updating. The fact is, code isn't perfect and so you need to understand how it's lacking and to do that, you must understand more than the code.
    • on code reading
      2003-12-12 18:08:59  anonymous2 [View]

      Nice point: a program is a solution to a problem. The better you understand the problem ("domain knowledge"), the better the solution will be. This is why it is easier to write a great solution to a very specific and concrete problem, instead of to a general one.

      Once you have solved 2 or 3 similar problems, you may understand the general problem sufficiently well to be able to write a general solution to that class of problem.

      Linus said something to this effect in an article, about the Linux filesystem (IIRC). He said that instead of trying to invent a whole new clever approach, he just studied the 3 main approaches, and made sure that his was compatible with all of them (so that Linux could be ported to such platforms). I think I've misremembered some details there, but the point was that thinking in terms of concrete and specific problems is an effective way to write great code (where great code is a great solution to a problem).
  • on code reading
    2003-12-12 11:54:06  chromatic | O'Reilly AuthorO'Reilly Blogger [View]

    I'm not sure where you picked up the idea that I don't recommend reading code. One of the persistent problems in software development today is that far too few people DO read code.

    That said, the myth is that pointing at a huge pile of code and telling new developers "just read it" is effective. I think that's possibly the least effective way to learn a project.

    There's no substitute for reading code. I certainly don't intend to give that impression. At some point, new developers absolutely must read the code.

    I don't think that's the best, first place to start though. Show them a glossary, an overview, completed story cards, or maybe UML. Explain how the pieces fit together. Then (and only then) let them examine the individual pieces.
    • on code reading
      2003-12-16 13:00:49  theoldmoose [View]

      Heh. The quickest I've learned code is to port it to another platform. That will force you to become aquainted with the entire code base in fairly short order. 8-)

      And while I was at it, I 'ANSI-fied' a piece of C code (a 400+ function machine vision library) that produced hundreds of warnings when fed to a modern compiler. The original code had virtually no prototypes, except those that were thought to be required for functions whose Miranda prototypes might not match.

      Of course, I uncovered several bad assumptions in that code along the way, including unused and incorrect parameter passing. Some of these were causing latent and/or re-occurring mysterious errors that applications programmers had long ago given up finding, and had coded work-arounds to in their code.

      That was the initial payoff. Having a much more maintainable piece of code continued to pay off over the 10+ year lifespan of the code as a library. It is still in use in hi-speed wirebonding machines on the Intel Pentium line.

      The library was not Open Source in the sense that we use it today, but it was shipped in source form to our machine vision OEM customers, for use by their application programmers. So, it had to be buildable on various embedded 32-bit Unix-like platforms, and useable both within realtime OS environments (like VxWorks) or running on a bare-metal C runtime library.

      It was all done with the GNU cross-compiler toolset and CVS, on SunOS workstations. Most fun I remember having in a long time. 8-)
    • on code reading
      2003-12-14 03:33:14  anonymous2 [View]

      <blockquote>At some point, new developers absolutely must read the code.</blockquote>
      Having just told you off above for panning code reading as a project intro: Graphic artists? Translators? Must read code? Hmmm...
    • on code reading
      2003-12-12 12:44:57  anonymous2 [View]

      I totally agree with you.

      If reading code is the starting point for learning, nothing guarantees that the code that one is reading is of high enough quality to emulate or incorporate into one's own repertoire of coding techniques.

      There can be no objective evaluation of the techniques that one uncovers.

      I've found that the "cookbook" approach to learning to code can be of extremely high value if one already has some solid experience, but one must know if the "recipe" is worth repeating in the first place. This doesn't just apply to bad code but inefficient code, as well.

      Once someone has learned a poor technique, it's impossible to estimate what or how long it'll take to switch to a superior one, especially in an unstructured environment.