Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??
Recently I had the pleasure of commenting on redsquirrel's node Perl Destroys Interview Question. In one of my follow-up nodes, I stumbled across an idea that had been brewing in my head for a while. I finally stated it in a way that I recognized it more as a thought than a feeling. I'm sure it's nothing that's not in a thousand software engineering texts, but I've come to the conclusion from experience.

So what is this nugget? A fairly large amount of programmer time seems to be spent reworking or redeveloping working designs to be more general. I further decided that it felt like I do this more now than I used to do so. I have wondered a few times since just what portions of time seem to be spent on different types of activities and how those values change with the experience of the programmer.

My own experience is probably not too typical a case but I'm sure it's by no means rare either.

  1. I spend more time now trying to generalize existing code than formerly.
  2. I spend more time trying to envision the data for the problem in more than one way, so I can choose the right representation in which to code the solution. I'd hate to choose the wrong data structure or the wrong programming style and realize it too late to change.
  3. I spend more time than I used to researching modules and libraries.
  4. I spend less time researching fancy algorithms in most cases, and I spend less time searching for (or trying to design) the best algorithm for a particular case. When I decide I do need a better algorithm, I go straight to some resource specifically for algorithms. Of course, the venerable Knuth is always a trove of information. If the naive approach isn't good enough, then a slightly clever algorithm may be. If a slightly clever algorithm isn't good enough, then someone else has probably already solve my problem.
  5. I spend less time writing complete programs up front and more testing snippets. This is from texts and howtos, but it runs counter to the texts and classes I was presented in my formal training.
  6. I spend less time debugging complex code snippets and more time rewriting them to be clearer. This isn't always done by refactoring, but sometimes it is. I've read a few things on refactoring and it seems I've leaned more in that direction in certain cases but not all.
  7. I spend less time benchmarking, and more time isolating the parts that need to be benchmarked. This is advice straight out of textbooks I know, but I've finally learned to follow it.
  8. I spend less time reading file and protocol standards and more time searching for existing interfaces to standardized formats.
  9. I spend less time writing code to use data up front and spend more of my early development on a project writing the code to get the data into and out of a program. This is because I've found that a small fixup in a read or write routine can save a lot of trouble in the central calculations.

How much of this should have been apparent to me up front, I don't know. I know much of it I should have learned from books and websites. Some of it I read several times before my experience caught up with the blurbs, anecdotes, and case studies by others. Some of it I gathered by intuition first and later had confirmed by reading or discussion.

One thing I know is that having one language which is so flexible has helped me reach all of these points. For one, the examples in almost any language are pretty easy to translate to Perl compared to translation into other languages. Different programming styles and methodologies are available in Perl, so those examples don't have to be changed from OO to procedural or other such changes in ordert to be understood and used. Closures, recursion, iteration, exceptions, and many other tools can be expressed in Perl without a bunch of extra work. Sometimes books and articles I read before learning Perl make even more sense reading them again now that I've been using Perl a few years.

Now I have to wonder not only which of these trends in my time usage are good, which are more likely experience-related versus advice-related, and which ones most programmers experience. I also have to wonder how much they have each been affected by using Perl and by being a member of the Perl community.

Christopher E. Stith

In reply to Changing times by mr_mischief

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others cooling their heels in the Monastery: (4)
    As of 2016-05-01 05:07 GMT
    Find Nodes?
      Voting Booth?

      No recent polls found