Re: Self-improvement and TMTOWTDI

Today I had a talk with a friend of mine, who's a Java programmer. We kind of agreed with him that by looking at the Java code you can moderately quickly realise if the person who wrote it is a decent programmer.

Java doesn't let the programmer so much of TMTOWTDI as the Perl does. When I'm programming Java I usually end up by looking up a method in the Java docs.

Also, as experience of a Java programmer grows, he makes more and more reusable object-oriented code.

Why I'm comparing these two languages? Again, I want to stress my statement, that it's easy to tell if a Java programmer is good or not. To do the same with a Perl programmer is more difficult.

As Foxub wrote in his meditation, the style means more to the Perl programmer. And the programming style can change from month to month. The Java programmer's path is more straight, with no curves.

So, just after lurking into a Perl programmer's code, would you take him/her into your project? Or dismiss him at once? Do you need a Perl programmer or a hacker?

Comment on Re: Self-improvement and TMTOWTDI

Replies are listed 'Best First'.
Re^2: Self-improvement and TMTOWTDI by adrianh (Chancellor) on Jan 25, 2003 at 01:07 UTC
Why I'm comparing these two languages? Again, I want to stress my statement, that it's easy to tell if a Java programmer is good or not. To do the same with a Perl programmer is more difficult. Got to admit I disagree. Having seen perl code produced by job seekers (and having to deal with other peoples code in general) I find that you can very easily see whether a developer is a reasonable programmer - just as you can with any other language. There are more differences in minor areas of style, but as long as you know perl you can understand when something is sensible. Possibly we're talking about two different things. There is being a good programmer (being able to produce sane, comprehensible code). There is also having a knowledge of all the perl idioms and the various odd language corners. The latter does not imply the former, and the former does not imply the latter. I've seen code that obviously shows a deep knowledge of the various obscure corners of perl, but written in a completely non-maintainable "selfish" style. Sign of a bad programmer. Usually impossible to fix. CV goes directly to the bin. I've also seen nice code, but that is obviously written by somebody who has come from another language. Lack of knowledge can be fixed by training. CV stays on my desk. Obviously, the ideal is to have both :-) Also, hopefully obviously, you never hire on code alone. Somebody can write great code and be lousy in a team.	[reply]
Re: Re: Self-improvement and TMTOWTDI by Anonymous Monk on Jan 24, 2003 at 17:55 UTC
I would not take a programmer just based on looking at their code. I might reject someone after seeing (bad) code, but a code sample does not answer the crucial question of whether, among the many ways to do it, that programmer can live with settling on the way(s) shared by the team who has to live with his or her code. This is not to say that a good programmer would not have a significant role in deciding what the shared ways to do it are - but teamwork needs willingness to live with other people's limitations.	[reply]