Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

comment on

( [id://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

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



  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (6)
As of 2024-03-28 15:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found