Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Changing times

by mr_mischief (Monsignor)
on Jan 14, 2004 at 22:19 UTC ( #321404=perlmeditation: 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

Replies are listed 'Best First'.
Re: Changing times
by exussum0 (Vicar) on Jan 15, 2004 at 17:46 UTC
    I'm sure those who have worked developing products for companies, the bottom line of the ideal business-man is, it works well enough to sell and keep selling. They don't want the perfect, most efficent, most elegant product. They want it to do X, Y and Z right now, and when A, B and C gets thought up, they'd love it tomorrow.

    The ideal programmer wants things to work really well, easy to develop for etc etc.. with infinite time, or at least until it bores them. :)

    As an idealist to some degree, I push for refactoring, doing things right, prototyping etc etc.. while I get a huge pushback for getting it done within acceptable deadlines. There are process related routines and standards that companies can get to, so that business can start an idea, and developers can polish off a finished product.

    For instance, prototyping. You can test all the points in preliminary prototypes, to show some sorta baseline of comparison to how it should work. Think of it like the omega(), as there is minimal load and users hitting the systems with weird sitatuations. If development is a much slower environment, it may be closer to real life. But you get a feel for what you are doing. Eventually, you can port your prototype to your ideal language or grow it to your final product. A research phase also helps, where you can create pre-prototypes and architectures to play around with.

    But at any rate, perl is a great language for at least research and prototypes. It's a VERY quick-to-write language. You can flush out architectual mistakes quickly. Many script languages are like this, and it is typical to have some sorta RAD interface for building these throw-away things. Or create non-throw-away stuff if you wanna grow your final product.

    Not sure what you were looking for in a response, but adding my two cents.. for whatever it was worth :)

    Play that funky music white boy..
      I'm not sure what I wanted in a response myself, or if one was even necessary. That you replied with a particular poitn of view does add some texture to the topic, though.

      I write most of my code either for internal use at my daytime employer or for internal use at one of my freelancing customers. It's never good enough to sell and keep selling, because it's code written for hire. I'm fortunate to keep copyright over most of it, and am allowed non-exclusive use clauses by many of my clients. So some of the code does get released, but not much. Also, many of my clients insist that if I release anything that they paid me to write, that it becomes Free Software under the GPL. Some even insist it gets released free of charge. I'm more interested in selling repeat business to these customers in the form of more new code or other services, and code written for a custom need isn't necessarily the best mass-market product in the first place. When there's an upgrade for this code, it's generally at the customer's pace, not at the pace of a marketing department.

      Some of my code I write as a hobby or to support my other hobbies. I'm either writing this for myself or for a member of a community to which I feel attached, so I'm interested more in a better program than a faster turnaround here as well.

      So whatever pressures some people face, some of us have the luxury of creating a solution to fill a need, instead of creating a need that needs a solution. That's the point of view from which I've developed my habits and philosophies.

      Christopher E. Stith

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://321404]
Approved by valdez
Front-paged by broquaint
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (8)
As of 2018-07-20 20:55 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (441 votes). Check out past polls.