You seem to be working in a company that makes decisions based on the availability of incompetents, that it wishes to treat as incompetents, and then justifies this on the basis of it being too hard to find and retain competent people. As a result when they get a competent person (you), that person finds it miserable and doesn't want to remain there. Thereby justifying their opinion that it is too hard to get and retain competent people...

For the record I am a Perl programmer, working with several other Perl programmers, and we do a reasonable job of having code standards. Plus we don't seem to have trouble maintaining an (admittedly small) group of competent programmers. (We are a small company in a niche field and our primary job is analyzing bonds - not developing software.)

Then again we chose people who were programmers first, and Perl programmers second. In fact we tend to hire competent people without regard to whether they know any Perl. We think we can teach Perl pretty easily. (And we don't just teach baby Perl either!) It is much harder to teach competence to someone who doesn't care...

tilly wrote:

As a result when they get a competent person (you), that person finds it miserable and doesn't want to remain there.

Annoyingly enough, I have discovered a dilemma. Most of the companies that I have worked with that use Perl are small. However, I clearly prefer to work for larger companies. They are more likely to have documentation, project managers, procedures, etc. Smaller companies seem more likely to "wing it" and that's a recipe for frustration and failure.

Damn. Never thought that I would think 33 is old, but I'm clearly a getting to be a fuddy-duddy. I want a bit of predictability and stability in my job. Sheesh.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Damn. Never thought that I would think 33 is old, but I'm clearly a getting to be a fuddy-duddy. I want a bit of predictability and stability in my job.

Oh, to be 33 again ...

Cheers,
Ovid

The official Perl 6 wiki.

-- Randal L. Schwartz, Perl hacker

To counter #1, keep in mind that the evolution of the Internet has made it possible to contract and work with developers in many countries. For example, a buddy of mine has sucessfully started a home based business working on contracts from clients based across the U.S. Heck, even my few clients are distributed.

While this adds to the administration angle, careful management of the project helps reduce the risk for problems. As long as everyone is clear on the expectation and there are well documented tasks and deliverables, the process itself goes quite smoothly.

To counter #2: that is an issue in any language and/or environment. There are C++ "experts" who zealously believe their personal ideas are paramount. Similarly, you will find, with little effort, VB/VBScript developers with the same attitudes. Even in my baliwick (Delphi), there are hard nosed people who will not open their minds to an alternate approach.

It's up to the project lead to ensure that all resources are following the expected standards. One way to do that is to (loosely) tie compensation to behavior. Code reviews should be part of the approval/acceptance process. "It works" is not good enough. It must work, be clear, and meet all expected benchmarks--including documentation, standards adherence, and so on.

That said, standards must not be straight-jackets. They must be flexible enough to evolve and to adapt for new information and/or ideas. Do not dictate trivial elements (number of spaces to indent, brace cuddling, and so on). Standardize the important stuff: consistency, a design for reuse, documentation, security, implemention direction, corner-case unit testing, testing requirements, and so on. Programmers will resist changes to their personal coding style, but the good ones will adapt to guidelines designed to make their code better.

There is a creative element in programming and a good manager will seek out individuals that know when to think on either side of the box.

Personally, I would ask your manager if he really wants "sheep" working for him. Personally, I wouldn't. I'm not afraid of having my ideas questioned; I encourage discussion, because software is rarely designed well in a vacuum. I am afraid of being slavishly followed, for I know that I don't know everything and I'm always willing to learn something new, even from an intern working on his first gig.

These really are issues that should be brought up during the initial interview process. If he cannot get someone to open up and honestly admit whether or not they can work with his requirements, then he shouldn't be hiring them in the first place.

Programmers aren't code monkeys and the wise manager will look for those who tackle all problems creatively, even the mundane ones such as following coding standards or keeping the schedule/budget in mind. (Not trying to say that standards are trivial, but that they're often used to bludgeon submission, which is wrong in my book. Standards are vital to a success development organization. Documented standards are even more so.)

Your next step, my friend, is to see whether or not your manager has an open enough mind to explore the possibilities with you. His response to that will suggest your next course of action, e.g. can you work within the constraints he's laid out?

(I know you you already know this; it's just a button with me because I've worked with good managers and I've had bad ones. The ones I've personally respected the most were willing to give my ideas a fair hearing and were willing to back down when they were wrong. Many stories there, but this post is too long as it is. *grin*)

--f

Update: Added the following for a minor bit of credibility:

P.S. This isn't just the point of view of a JAPH or an "in-the-trenches" programmer. As (briefly) outlined in my home node, I have been a programmer, a tech writer, a QA tester, a support tech, a product manager, a consultant, and a team lead. I have seen many management styles and worked with many programmers. The styles that work and the people I respect are those that that understand, at least implicitly, the principles outlined in the Software Maturity Model.

P.P.S. If anyone knows of a Level 5 organization in the Seattle area looking for help (or one willing to with with a Seattle-based telecommuter), please let me know privately. *grin*

This lit up my bogon detector.

I once had a serious run-in with a manager who said much the same thing about a different technology. He was (in my jaded opinion) a Control Freak. It was very important to him to extert an aura of being in control. Managing meant getting the good little sheep to go along with procedures, though in that strange way that often seems to happen, the procedures had gradually lost relevance to the work at hand.

Systemically, the affects were similar to what tilly described above. The good programmers got fed up and left, reenforcing his viewpoint that he needed to hire sheep that would behave. His department became an obstacle that the rest of the organization became creative in working around. The damage at that company took years to undo. (That company also had the codependent viewpoint that managers were to be supported in any argument with subordinates.)

If you're in the position of butting heads with a manager like this, it's tempting to hold on to the particular technical issue that you're trying to win approval for, but that's really not the underlying issue.

Ovid, if this is what you're running in to, I have a recommendation: Choose a font for your resume that faxes well. There are bigger organizations using Perl. They're just quieter about it.

Ovid - I hate to say it, but those arguments are pretty damned valid. If I were in your shoes, I would stick it out - just because you are in Amsterdam. It can't be __THAT__ bad. Amsterdam!

Let me tell the story of the pre-Perl jeffa - (crickets chirp lightly in background) . . .

I started out after graduating with a CS major at a Mircosoft Shop as a 'consultant' where

$truth{'consultant'} = 'junior programmer';
[download]

Anyways, I worked on that project for about 3 months. Sometime around the last month, one of my fellow 'consultants' who was assigned to the same client asked me if I knew awk. I said, why not use Perl. So, next thing I knew, I had written a Perl script that parsed his data.

The bug bit me. I hadn't written Perl in about a year. I remembered how powerful Perl was with it's regular expression engine brandished before it like a Paladin's Holy Sword.

Two months later I found myself programming in Perl for a dot com.

So, my point is: sometimes we have to do something else to appreciate how much we really love what we did. Ovid, think of having to program in VBScript as a catalyst that will make you really appreciate your next gig with Perl.

And most importantly - enjoy your stay in Amsterdam.

Jeff

R-R-R--R-R-R--R-R-R--R-R-R--R-R-R--
L-L--L-L--L-L--L-L--L-L--L-L--L-L--

I have to say that I genuinely found Perl quite nice to handle: Okay, my first few programs looked like bad BASIC with C syntax but this is to be expected. In time I learned about 'coding standards', although I would call these 'standardised coding standards', mainly because I already used a series of my own devising. Most were in the style of indenting code in loops, map blocks and so forth: The first was, of course, use strict; at all times.

The last rule, when boiled down to its essence, was that they didn't care too much what code standard we used provided that the code was easy to read and maintain and that there was plenty of commenting on the code itself: It must be noted that this kind of mindset, ie. "You've got a brain, use it!", tended to be fairly common. You were expected to just get on with it and use your common sense to know when to shout for help, rather than just ploughing on regardless.

My conclusion is that provided that your code does things in a sensible manner, is secure and is readable and maintainable, imposing extreme or artificial coding standards can waste more time than it saves. I would guess that this depends on the standard of the coders involved.

Just, as they say, my £0.02.

Elgon

Elgon wrote:

My conclusion is that provided that your code does things in a sensible manner, is secure and is readable and maintainable, imposing extreme or artificial coding standards can waste more time than it saves.

It would seem that way, but as an organization gets larger, you wind up with a much greater range of ability and style. This can have a significant impact on code quality and maintainability.

Consider the following:

• Bob decides that the best way to deal with a particular issue is to use a pseudo-hash. Hmm... well, that's an experimental feature. Is it appropriate?
• Jane thinks that CGI has too much overhead, so she uses CGI::Lite. No one else uses it. Hmm...
• Irving uses incredibly descriptive sub names like grab_the_headers_and_look_for_a_id_cookie(\@headers). Well, it's descriptive and he argues that it cuts down on documentation.
• Sally hates having subs that require arguments be passed in a particular order, so she keeps writing wrappers for everyone else's code that allows her to pass a hash.
• One of the coders I work with right now refuses to declare hashes. Instead, he always declares a scalar and makes it a reference to an anonymous hash. (%hash = (); versus $hash = {};). As an interesting side note, he's gotten in trouble for writing production programs in Perl :)
Every one of the above programmers could make an argument for their particular coding practice. They may even be reasonable arguments. How do you settle issues like that? That's what coding standards are for: to remove that guesswork. I think that it does take some of the fun out of coding, but it does tend to ensure a bit of sanity in larger shops.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Okay, you've got a slightly different problem here. You need to encourage a culture of communication and idea-bouncing.

It may help to encourage a discussion area where the team can asked stylistic questions and learn from each other's experiences.

In one of my previous "lives," we held these during lunches, called these "brown bags," and kept them very informal. It took some time to get everyone on board, but eventually, we were all learning from each other and the resulting code because more consistent. You could still tell each person's style from their bits, but you could also see where the discussions had made a difference.

I forget who said it, but one of the classics on software development practices notes that it takes ~18 months for an organization to move up a level in the Software Maturity Model. The same source also notes that each level must be met. This means it'll take roughly six years to move from a Level 1 organization to a Level 5 (world-class) organization.

It may also help to ensure that each resource has time for research. Personally, I like to allocate 15-20% of my time to that, for if I'm not allowed to try things out, I can never learn new things except by experimenting with them in production code--which is a bad thing.

Also, leave room for some disagreement and try to find the compromises.

--f

Ovid, it's a fair point:

I agree with your point in general but footpad below makes some good ones too: There is a difference between a coding style making sense to one person and it making sense to a group of people who have, in essence, to peer-review the code when it needs updating.

Bob, for example, is dead wrong unless there is an extremely compelling reason for using them: Some data structures just lend themselves to certain ways of doing things. Pseudohashes are, as you say, experimental and from what many have said to me, not the greatest tool in the world. In business situations it pays to code defensively.

Ultimately, though, settling issues like that should be (IMHO!) by coder fiat: If your manager is a coder (mine was) and there is a dispute, they rule on it. Otherwise the most senior/competent coder (alpha geek ;-) rules on the issue, which, I guess ultimately leads to a coding standard, sigh.

I certainly agree that life is different for small and large businesses: Where I worked (and will hopefully be working again this summer) is going through the transition phase.

Cheers, Elgon

Kickstart

You can obfuscate anything. The projects we get to "finish" are always in very bad state. Bad design, unreadable code, terribly inefficient, totaly unreadable ... all in VBScript. I can asure you that I saw things that forced me to scream.

Just a little example. The *&%@#(*$^%*#*&&#^$% was using three variables j, k and l throughout the whole page, then passed them to the next page, and used again j, k and l, but the meanings were exchanged. What used to be k was now l and vice versa. Bleargh. (In the end none of those variables were needed. The design was bad.)

On another page they first wrote the posted data into a file, then made a few useless obfuscations, read the file back in and processed the data. Of course the name of the file was static and there was no locking. But it took a few hours to decipher the code only to find out 90% is worse than useless.

Generaly I think that the quality of the average VBScript code is much worse than the average Perl. Because "just about anyone can write VBScript". So often people not only without education, but also without brains spit out horrible VBScript for living.

But the management is happy ... if the boss looks at the code he doesn't see any strange characters, there are normaly looking english words, it all looks readable ... until you try to read it.

Jenda

I just take one look at this code, throw is away, and rewrite the whole thing. Rarely is it worth all the extra time to decipher it and maintain it in the future.

Sadly, many managers do not share this opinion.

I understand his arguments and in fact think they are very valid from his perspective. Let me explain that in more detail:

• I've met "really really bad" Perl coders. They were quite experienced in Perl and their craft was often nontrivial. So why were they THAT bad? Well - they thought they were very good. They were intelligent, they obviously knew (or thought to) that they "master" an extraordinary language, so they felt like XPs.

  What happened? Most of these guys were young and had no experience in larger scale projects. They virtually laughed at requests like commenting code and programming cleanly, using a certain indentation and set of idioms. In that sense, the 2nd argument of your boss was right.

• But in my opinion this problem applies only to young wild Perlies AND to (project) managers that are not strong enough to either persuade the Perlies for the necessity of discipline or to take the bitter consequence to fire a young programmer that could develop into a real elite if only he had more insight.

  Then again, this also supports arg 1 of your boss.

• Perl is complex. To harness its power in large scale projects needs many things: good people (skill, discipline) both at the programmers and the project managers side, the WILL to solve problems and the bias towards elegant technological solutions, i.e. not only programming to solve something, but to program to solve a problem ELEGANTLY too. Especially with perl. This is very contrary to most perl scripts out there because Perl often serves the glue/guick'n'dirty paradigm!

Then again, if you feel different about this, you're in the wrong company.

There are companies, that wouldn't touch VBScript even if they'd need to fly the right Perl programmers in from all over the world.