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

comment on

( [id://3333]=superdoc: print w/replies, xml ) Need Help??

Lately I've been busy correcting the work of lots of unsupervised programmers, and I've come to think something different about this whole debate. It's not the tool that matters, but the people choosing the tools. Their decisions are not rational or based on technical merit, and we can't solve this problem with reason or merit. There are good reasons to choose Java for some things, just like there are good reasons to choose Perl for other things, or even Python or Ruby or something else.

The problem doesn't have much to do with the language. It's a failure in management. Now, I know the you (Jim) use Perl in your department, but that you also have regular training for everyone, comprehensive code reviews, and that you follow the technology. Not too many places I run into seem to do that, even at the technical worker level.

Thinking about that, and after listening to an interview with AT&T's Ed Amoroso, and probably after reading a bit too much Joel Spolsky, led me to think that the lack of management is the problem in these cases. Aside from the usual, puerile generalizations about pointy-haired bosses, in my fire-fighting work I've noted several things that set up the problem. (Update: I'm not generalizing about managers, just some patterns of behavior I've seen from some people in those positions. Being a manager doesn't mean you do any of these things :).

  • Managers who don't know enough to do it themselves, and they put too much trust in what the code cowboys tell them
  • Managers who don't have a strong technical background, but they like to think they do (Ed's comments here are interesting)
  • Managers who don't enforce proper coding standards, or don't even have any
  • Managers who don't make their technical people learn more
  • Managers who don't give their subordinates the opportunity for formal training (in any subject)
  • Managers who don't know how to measure productivity
  • Managers who can't or won't solve personality disputes between developers
  • Managers who don't make their team work as a team
  • Managers who don't build a team with diverse skills and use workers are commodities
  • Managers who are afraid to piss off the tech guys
  • Managers who want to be liked
  • Managers who don't want to work
  • Managers who ultimately want to protect their ego

There are all sorts of reasons why any of those things might be true, and not all of them are bad or even the manager's fault:

  • Ill-conceived company policy
  • Limited dollars and resources
  • Lots of work, not enough people
  • Fear of losing good employees because they might get better jobs if they knew more
  • Time wasted in useless meetings
  • Incompetence
  • ...and so on...

No language is going to solve any of those problems, but I've heard many Java proponents say that they can take mediocre programmers and turn them loose without worrying about them. The problem there isn't Java, it's the lack or worry (which you should really read as "supervision"). Managers don't want to manage.

A language like Perl, however, just makes the management problems more apparent, mostly because Perl doesn't let you blame some things a Java programmers gets to blame (and sometimes with good reason).

  • the JVM
  • the browser
  • the operating system
--
brian d foy <brian@stonehenge.com>
Subscribe to The Perl Review

In reply to Re: Why Perl is a Valid Choice by brian_d_foy
in thread Why Perl is a Valid Choice by cbrandtbuffalo

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 imbibing at the Monastery: (3)
As of 2024-04-19 18:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found