Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Re^2: Why Perl is a Valid Choice

by g0n (Priest)
on Feb 01, 2006 at 11:22 UTC ( [id://527029]=note: print w/replies, xml ) Need Help??

in reply to Re: Why Perl is a Valid Choice
in thread Why Perl is a Valid Choice

  • 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".

Replies are listed 'Best First'.
Re^3: Why Perl is a Valid Choice
by cbrandtbuffalo (Deacon) on Feb 01, 2006 at 13:48 UTC
    The way I've addressed this issue of technical and non-technical managers is to try to champion Brooks' The Mythical Man-Month. Despite the age of the book, his conclusions are as amazingly relevant to coding today as they were when he wrote them.

    The bit that I've pulled out and harped on is that there should be two advancement paths within a technical department: project manager and technical manager. Both need to be equal paths, and people with equal experience and skill in each need to be treated equally in the company (authority, pay, etc.). Each significant project should have both a project manager and a technical manager assigned and they work together, each focusing on their expertise.

    This has been very successful in our shop. We have several people who are certified project managers and do their job very well. They handle allocations, schedules, and dealing with stakeholders. I work as a technical manager where I keep my hands out of the project management software and make sure the technical challenges of the project are taken care of. I know about other projects going on, I help with code reviews, and I make sure coders know about all of our shared code and best practices.

    You can't get this to work everywhere, but I feel rewarded for plugging away until we tried it. And the success has kept it going. The project managers really like having someone on the project whose job it is to know the technical bits. And I feel my time is better spent away from Gantt charts.

    As for you other point, I thought about working this into something that we could share somewhere else. I just wanted to vet it through perlmonks first. I'm in The Perl Foundation, so maybe I can ask about throwing up a page on the TPF site somewhere.

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (2)
As of 2024-06-17 03:48 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.