Loading ...
Sorry, an error occurred while loading the content.

Why there will always be programmers

Expand Messages
  • Omer Zak
    http://www.johndcook.com/blog/2008/10/27/why-there-will-always-be-programmers/ Summary: Programmers are always needed, because big programs have lots of
    Message 1 of 3 , Oct 30, 2008
    • 0 Attachment
      http://www.johndcook.com/blog/2008/10/27/why-there-will-always-be-programmers/
      Summary:
      Programmers are always needed, because big programs have lots of
      details, and somebody has to manage those details.

      Now, quick! What are your tips and tricks for managing the details of
      your projects?


      --
      Did you shave a yak today?
      My own blog is at http://www.zak.co.il/tddpirate/

      My opinions, as expressed in this E-mail message, are mine alone.
      They do not represent the official policy of any organization with which
      I may be affiliated in any way.
      WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
    • Shlomi Fish
      ... Well, I never initiated large-scale projects on my own, just contributed to large-scale ( 100K LOCs) projects that other people initiated. Well, first of
      Message 2 of 3 , Nov 3, 2008
      • 0 Attachment
        On Friday 31 October 2008, Omer Zak wrote:
        > http://www.johndcook.com/blog/2008/10/27/why-there-will-always-be-programme
        >rs/ Summary:
        > Programmers are always needed, because big programs have lots of
        > details, and somebody has to manage those details.
        >
        > Now, quick! What are your tips and tricks for managing the details of
        > your projects?

        Well, I never initiated large-scale projects on my own, just contributed to
        large-scale ( > 100K LOCs) projects that other people initiated.

        Well, first of all I make sure the projects are adequately modular and
        componentised. Each module, class, function etc. should do something and
        something well. This makes it easy to find.

        Meaningful and conventional variable names also help a lot to find offending
        code.

        Then I use tools like grep, http://petdance.com/ack/ , ctags, etc. to find
        what I want. These are especially useful with gvim's quickfix mode.

        I personally don't write too much external documentation, except for
        perlpod/etc. API-documentation for the user. I also prefer to factor out code
        with meaningful names for the extracted functions than to comment bad code.
        From my experience, external documentation tends to get out-of-sync with the
        code itself and so is not such a good idea. Your code should be
        self-documenting.

        Regards,

        Shlomi Fish

        -----------------------------------------------------------------
        Shlomi Fish http://www.shlomifish.org/
        What Makes Software Apps High Quality - http://xrl.us/bkeuk

        Shlomi, so what are you working on? Working on a new wiki about unit testing
        fortunes in freecell? -- Ran Eilam
      • Ori Idan
        ... I certainly agree that code should be self documenting as much as possible. Sometimes even in line documentation in the form of comments, tends to stay out
        Message 3 of 3 , Nov 3, 2008
        • 0 Attachment


          On Mon, Nov 3, 2008 at 9:05 PM, Shlomi Fish <shlomif@...> wrote:
          >rs/ Summary:
          > Programmers are always needed, because big programs have lots of
          > details, and somebody has to manage those details.
          >
          > Now, quick!  What are your tips and tricks for managing the details of
          > your projects?

          Well, I never initiated large-scale projects on my own, just contributed to
          large-scale ( > 100K LOCs) projects that other people initiated.

          Well, first of all I make sure the projects are adequately modular and
          componentised. Each module, class, function etc. should do something and
          something well. This makes it easy to find.

          Meaningful and conventional variable names also help a lot to find offending
          code.

          Then I use tools like grep, http://petdance.com/ack/ , ctags, etc. to find
          what I want. These are especially useful with gvim's quickfix mode.

          I personally don't write too much external documentation, except for
          perlpod/etc. API-documentation for the user. I also prefer to factor out code
          with meaningful names for the extracted functions than to comment bad code.
          From my experience, external documentation tends to get out-of-sync with the
          code itself and so is not such a good idea. Your code should be
          self-documenting.

          I certainly agree that code should be self documenting as much as possible.
          Sometimes even in line documentation in the form of comments, tends to stay out of date. I have seen case when during debugging of some software, some functions where changed but the comments stayed the same.

          --
          Ori Idan
            


          Regards,

                 Shlomi Fish

          -----------------------------------------------------------------
          Shlomi Fish       http://www.shlomifish.org/
          What Makes Software Apps High Quality -  http://xrl.us/bkeuk

          Shlomi, so what are you working on? Working on a new wiki about unit testing
          fortunes in freecell? -- Ran Eilam

          ------------------------------------

          Yahoo! Groups Links

          <*> To visit your group on the web, go to:
             http://groups.yahoo.com/group/hackers-il/

          <*> Your email settings:
             Individual Email | Traditional

          <*> To change settings online go to:
             http://groups.yahoo.com/group/hackers-il/join
             (Yahoo! ID required)

          <*> To change settings via email:
             mailto:hackers-il-digest@yahoogroups.com
             mailto:hackers-il-fullfeatured@yahoogroups.com

          <*> To unsubscribe from this group, send an email to:
             hackers-il-unsubscribe@yahoogroups.com

          <*> Your use of Yahoo! Groups is subject to:
             http://docs.yahoo.com/info/terms/




          --
          ספרים וסיפורים שכתבתי: http://www.thestories.org
        Your message has been successfully submitted and would be delivered to recipients shortly.