Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Re: A Perl aptitude test

by tilly (Archbishop)
on May 05, 2003 at 15:35 UTC ( #255650=note: print w/ replies, xml ) Need Help??


in reply to Re: A Perl aptitude test
in thread A Perl aptitude test

I keep on seeing people saying this, and here I am thinking to myself, "Gee, and here I would only give myself even odds of getting #6 right." I know what the operator is for, I know how to use it perfectly well as a sort function, I know how to use complex combinations to do sorts on complex data.

But do I know whether the comparison function is supposed to return a 1 or -1 to sort to say that the left side is smaller than the right this time...? I could guess but I never remember that. If I really need to know it, I can look it up any time. All that I need to know the vast majority of the time is that whatever way it goes, sort and the comparison functions agree on how it is done. (And this tidbit is of a kind I find hard - for instance I still have to think about whether in a LEFT JOIN the table you want to fill in blanks for should be on the left or the right.)

EDIT AUG 2009 Somehow this node got badly messed up. I've filled in the end with what I think is my original thought, but it is unlikely to be right. :-(


Comment on Re: Re: A Perl aptitude test
Re: Re: Re: A Perl aptitude test
by BrowserUk (Pope) on May 05, 2003 at 16:46 UTC

    (Indeed anyone who develops an understanding of obscure constructs by constantly experimenting with how many language constructs they can use is a hazard to your code base...)

    Interesting viewpoint.

    Do you have a feel for which (perl) language constructs you would deprecate from your codebase?

    Would this be a single, hard & fast list or would it vary by codebase or project?

    Is it just knowing the obscure constructs that constitutes the hazard? Or does the person have to use them before they are guilty?


    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
      It varies by codebase, project, and most importantly, who you expect to work with and then maintain it later.

      The problem is that TIMTOWTDI is a maintainance headache. Anyone who wants to abuse it forces you to have all maintainance work done by someone who has more expertise than the regular programmer. Not the same, because someone who is merely the same may just know a different set of tricks, but better so that they are likely to know all of the tricks that the first show-off used.

      The answer is to decide which ways to do it you will settle for based on other factors, and to stick to them so that someone else can pick up the code and be brought up to speed in a reasonable amount of time. Having people who know lots more ways to do it is fine and good and may be a good thing (knowing your choices in advance makes it easier to pick a good set of choices to stick to), but actually using them all all of the time is a bad thing to do unless you are trying to be hard to understand.

        Sorry, this got a bit wordy. I trimmed it twice, but came close to failing to explain my pov.

        It varies by codebase, project, and most importantly, who you expect to work with and then maintain it later.

        I understand where your coming from, and in any given environment it may make sense to deprecate specific subsets of language constructs through a local coding standard. In the general sense, especially if the granularity is at the project level within a given organisation or codebase, then I have distinct reservations. My major concern is that it then becomes increasingly difficult for any given programmer to move between projects as he will constantly have to review the local coding standards in force on that project before setting to work. And applying a single set of restrictions across the whole codebase, especially in organisations that code projects into many different project arenas (eg. database, financial, scientific, embedded etc.) is likely to limit one or more areas to using less than optimal solutions in order to comply with the coding standards.

        The problem is that TIMTOWTDI is a maintainance headache. Anyone who wants to abuse it forces you to have all maintainance work done by someone who has more expertise than the regular programmer. Not the same, because someone who is merely the same may just know a different set of tricks, but better so that they are likely to know all of the tricks that the first show-off used.

        This identifies (for me. YMMV) the crux of the problem. Many, many organisations whilst agreeing that maintanance is a sizable proportion of the cost of software development, still tend to relegate the process of maintainance to a 'second string' section of the development team as a whole. They often pay large sums for their development 'stars' and considerably less for the maintenance team. This second string status doesn't limit itself to just salaries either. It is also evident in the training and personal development budgets and even access to conferences, symposia, reference materials and beyond.

        They then proceed to hamstring their stars, by imposing coding standards that stiffle innovation, creativity and in-depth knowledge -- that has usually come at the cost of considerable effort and dedication -- to only using that subset of their knowledge that's deemed as understandable by the maintenance team.

        Beyond just the inequalities observed, this process of delineation between job functions seems self defeating as it precludes making full use of the inherent skills of the one group of individuals and condemns the other to never progressing beyond the limits set for the 'average joe' programmer.

        My observations and experiences suggest to me that the problem lies in the whole concept of seperate development and maintenance teams. In fact, the whole practice of building project teams as mono-functional, kick-off to release entities is flawed (IMO). The best software organisation I was ever involved with took a radically different approach.

        Breifly, when a project was in the pre-approval stage, a single project leader was designated. This person, more manager than analyst or coder was charged with putting together the project plan. S/he then employed the skills of one or more members of the analysts group, as & when required, to assist gathering and analysing user reqs, generating ideas, writing and checking proposals.

        Once the project was approved, they would produce a project plan in terms of Job-roles rather than named individuals. The requirements for analyst time would be 'requisitioned' from the analysts group and the same with the coding group. The two groups having considerable overlap with people moving from one to the other as daily/weekly/monthly requirements arose.

        The Job-roles "owned" the code in perpetuity, and when effort was required, whether green field development or maintenance, the "next available coder" would be assigned to the task.

        This would be influenced by the scale and nature of the specific task and the experience required, but generally, the "next available coder" tended to be a less senior member -- by definition, they usually had less on their plates. They would do the initial assessment, code the solution if they could, but frequently refer it back to a more senior member if they got stuck. Regardless of who did the coding, it was always peer reviewed with at least two other coders. The upshot of this is that all projects were planned in terms of job-roles and all work was carried out in those terms.

        There were no stars, and everyone took there fair share of the glory work and the humdrum. This caused the least strong team members to be constantly encouraged to raise their game, without any of the infighting or demarkations that I've seen elsewhere. They also had, collectively, the highest standards of coders and analysts, along with the highest rates of productivity I have ever seen. The architect of the system had a compicated football analogy, something about strength-in-depth and a 22-man first team. Football isn't my thing so I won't try to re-create it.

        The really interesting part was that I never saw the situation were anyone was reluctant to ask for assistance, no matter how senior they were. Nor did I ever see such a request refused.

        It was a true revelation to work in such an environment, and probably the hardest thing coming into it was simply believing that it could be true. I have also never seen any coding group given such a high degree of freedom or produce such a high level of product. It's just a shame that sometime after I moved on, the company was taken over and the new management had more traditional ideas. The company went down hill rapidly thereafter and bit the dust, along so many others, in the tech sector shake out. A real shame.

        As with most things, our ideas are the product of our experiences and influences, and each persons set is different. The next time I'm charged with setting up or heading up a team or project, insofar as I can influence it, this is the model I will try and adopt.


        Examine what is said, not who speaks.
        "Efficiency is intelligent laziness." -David Dunham
        "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://255650]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (9)
As of 2014-12-20 20:07 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (97 votes), past polls