Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
  • Managers don't know enough to do it themselves, and they put too much trust in what the code cowboys tell them
  • Managers don't have a strong technical background, but they like to think they do (Ed's comments here are interesting)
  • Managers don't enforce proper coding standards, or don't even have any
  • Managers don't make their technical people learn more
  • Managers don't give their subordinates the opportunity for formal training (in any subject)
  • Managers don't know how to measure productivity
  • Managers can't or won't solve personality disputes between developers
  • Managers don't make their team work as a team
  • Managers don't build a team with diverse skills and use workers are commodities
  • Managers are afraid to piss off the tech guys
  • Managers want to be liked
  • Managers don't want to work
  • Managers ultimately want to protect their ego
There are some generalisations there that I'm not entirely in agreement with - remember, managers are people too. But your comments reflect something that I've been fulminating about for quite a while.

Take a look at any job advert for an IT manager. What characteristics are they asking for? Line management experience obviously, but primarily business management skills, budget management skills etc. Technical comprehension is *way* down the list, on the rare occasions it even appears. It's my contention that to provide a good standard of service an IT manager must have a good technical understanding, as well as an understanding of business priorities. Not that an IT manager must be a world class coder, or a top notch oracle DBA; but he or she should at least understand the issues, comprehend software life cycles, testing principles, and be able to see without assistance where code can do one thing easily, and another with difficulty.

That list is specific to managing coders, but the same principles apply to managing an internal IT department. Most IT managers make choices based on sales pitch, not on technical suitability. You don't have to be Donald Knuth to understand the relative merits of different products, you just have to have some understanding of them.

Underlying this IMO is the fact that technical expertise is largely devalued by business people, so the business managers (possibly the board) who appoint the IT manager want someone with the same skills as them. The fact that they have half a dozen accountants who can manage a budget in their sleep, but no one who can tell them why a server costs more than a desktop doesn't seem to matter.

In my perfect world, the IT manager would be a business oriented person who can code, but probably not very well. Someone who can meaningfully translate between business priorities and technical feasibility (am I bitter about not making the shortlist? You bet I am).

But that isn't happening any time soon, so (to return to the topic of the thread) if we want to promote Perl to the people who make the language decision, we need to put cbrandtbuffalos very well thought out, and crucially non technical article in front of them - very few of them visit PM, in case you hadn't noticed. How can we do that? Suggestions are welcome, but perhaps identifying the right magazines, getting the right journalists on side, and getting well written, business oriented (not technical) case studies and articles out there.


"If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."

John Brunner, "The Shockwave Rider".

In reply to Re^2: Why Perl is a Valid Choice by g0n
in thread Why Perl is a Valid Choice by cbrandtbuffalo

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
    NodeReaper cracks his knuckles - loudly

    How do I use this? | Other CB clients
    Other Users?
    Others rifling through the Monastery: (8)
    As of 2018-06-18 14:07 GMT
    Find Nodes?
      Voting Booth?
      Should cpanminus be part of the standard Perl release?

      Results (110 votes). Check out past polls.