At a really small company you can have a voice that will be heard. If you are good (and don't depreciate yourself!), you can make changes and shape how things are done because you're a big part of it.

At a big company, *if* they've grown right, there should be things already in place. And they are much more prone to cover their backsides with security and such because they know the truth behind the lawsuit. So suits want you to code as defensively as possible (while still getting everything done yesterday, that doesn't change). Words like 'legal exposure' or 'negative impact to the company reputation' do wonders for getting them to see you side.

IMHO, anything you do for an outside client (such as web sites) must have proper specs, otherwise they can always come back and claim that it wasn't how agreed upon and force changes. Companies should love hard specs, they can make lots of money off change orders as the clients change their tune. A good project manager will require them.

Wish I had a job for you, but my company is stuck in the dark ages when it comes to languages of choice due to other concerns.

Good luck!

=Blue
...you might be eaten by a grue...

Some developers welcome someone to look at their code, others feel it's a violation. I for one, have always seen benefit to a large project. I've also had to maintain code that had never been seen by anyone but the first developer.

Specs need to be flexible enough so that if time requirements out weigh features that you can modify the spec. However, they have to be clear enough so that the customer (being an outside customer or the marketdroids upstairs) can't come back with "improvements". If you're coming from a security view, you have to have solid specs. Adding features after the fact just opens loopholes.

Previous companies, CPAN was used whenever possible, but since I was the only Perl junkie in the department...

All programmers have a LOT to learn. And the smart companies will welcome having thier security holes patched.

Already, I have a couple of interesting leads to follow up on. In the meantime, I thought I would toss out one of the more amusing debacles that occurred here.

The IS director was writing some code and asked me a question about it. It seems that he was writing a routine that recursively searched directories and deleted old files. Can you say "File::Find" boy and girls? I knew you could.

I mentioned that the File::Find module could handle that safely and he replied "this code is so simple that I don't need a module to do this." -- Yeah, you can see this coming a mile away, I know :)

I cracked open the Cookbook and took about two minutes to write AND test the code that he was developing. My boss took about an hour. Once he was satisfied with it, he ran it on our development server. The code went wild and got into an infinite loop and deleted most of our development environment and crashed the server. It took about half a day to restore everything from backups and get to work again.

Cheers,
Ovid

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

Jeez - and I thought that I had it bad when I worked for the inspiration for this node. All I can say is, look for another job.

I am currently on my fifth job since I graduated, two of them were just __NOT__ going to work for me - I made no hesitations to move on.

Jeff

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
F--F--F--F--F--F--F--F--
(the triplet paradiddle)

LOL! I've written my own versions of File::Find and know it's easy to screw up. I always tested it to death before letting it loose like that.

Why did I write my own?


It was prior to that module's release and I needed something that would convert filenames and directories to 8.3 Uppercase format (Just 8 for dir) without clobbering exisiting files. (Novell, OS/2, Unix, and Windows files) It worked well and I kept using the sub for my own use. (It's not as flexible as File::Find, I had to tweak things often enough)

I believe you _can_ do it without good specs (we all do, I am sure). But, it always tends to lead to some problem or another. At my last "real" position (which I left partly for this reason) my Project Manager (I use the term very very loosly) was terrible at giving specs. She would give me printouts with pen marks and say "Make it look like this". Well, you couldn't since there were about 50 things that needed to be done in the background to make that happen, which are what specs are for. I would say back "No, when you give me specs I will make it happen". Would she get me specs? Nope. "Kevin, how is that project going?", "I don't know, you tell me. Where are the specs I asked for?". So, basically I would push back at my manager to do her job, so I could adequately do mine.

Do most Web development companies take security seriously, or is it treated as an afterthought?

I think this varies from company to company. When I worked for DEC, we were very secure. The job I spoke about above, we were very secure (I implemented the security model). At my current place of employment, it is very important. A few consulting places, it wasn't. The best way to make sure things are secure is to simply do it while programming. A CIO, or IT manager may not as for 'tainting', so you just have to do it yourself. Why wait to be asked to do it? Just Do It! (I hope Nike doesn't sue me).

Is your company averse to installing CPAN modules, even if they have been reviewed carefully?

Not this company, or any other I have worked for.

o you have a job for a Portland, OR monk ;)

Maybe if that Monk wants to move to Floriduh. (No positions at this moment, but I know some will be created next year)

Generally, whenever I have walked into a new company and looked at the Perl code, I have been disgusted. I generally hear things like "That was first written by (SA's|C Programmers|Monkeys) and never updated, since it worked." Then, I promptly start redoing things, because I can't stand it (and find holes). Many people, I think, have Perl in their toolbox in case they need it but don't know how to use it properly. For example, I have a faucet wrench thingy in my toolbox. So, when I had to change a faucet I took it out thinking "This is the perfect tool for it." But, I don't really know how to use that wrench, so I did a terrible job with it. It took me likely 3 times as long, much more cussing, and less red knuckles than someone who actually knows how to use it. AND, it leaked after a day so I had to call a plumber anyways. Perl has the curse of being able to do a lot, by knowing a little. So, crap code and the like are easy to create. I fear it is something that we have to live with, and try to help cow-orkers, and the company to realize the benefits of good, solid, quality code.. as well as what developers need to create it.

Cheers,
KM

My advice on this (from bitter and good experiences) is to focus on the main thing. It's perfectly acceptable to take notes on things to change for later, but resist the temptation as much as you can. When you've done the main thing, then stop holding your nose and fix what worked but needed improvement.

Web sites and specs

There's no reason you can't have adequate specs. If your customers don't know what they want, how will you know when you're done? If the specs keep changing, your mission keeps changing, and you will lose your focus and spend more time and money that way. (I think we all know that, but it takes a lot of work to tell a customer that, and stick to it. More power to you!)

Web companies and security

Anecdotal quote from a R_____fish employee: "What do I look like, an Infrastructure Engineer? I'm an Information Architect!" Dunno if that's a pervasive attitude, but security is hard enough to do well even when you're trying that I doubt many companies are as secure as they think.

CPAN

Again, I defer on the company thing. Personally, with the software I write, I try not to use modules unnecessarily. (I have a lot on my development machine, but I try to reduce dependencies in deliverables as much as possible.) You won't see me writing my own XML Parser to give to a customer, for example, but you may see me write my own leap year routine (much to my chagrin, monks who've been around for a while will remember my last attempt was not so good.) I do take the attitude, "Love me, love my modules."

There is no shame in being ignorant... choosing to remain ignorant is another matter. Your colleagues are have the blessing of working with someone who knows more than they, and they waste it. I feel pretty sure your IS director is being disingenuous, and would simply rather reinvent the wheel than learn how someone else's modules work. It seems to me that your basic problem here is not conflicting standards, but conflicting attitudes. You care more than they do.

So what are you to do about it?

IMHO, cover your bases and take care of your responsibilities. Your employers, regrettably, seem to care about nothing more than keeping their clients happy... and your employers are your clients. You need concern yourself with nothing more than keeping them happy. And in the meantime, interview with various companies, and wait for the one that feels right. If you've got a dream job with some company, write them. You're not the only one who cares. Find a forum where your passion will be appreciated.

The fact that I'm not willing to speak about the quality of code where I work should speak for itself.

You mentioned in your post:
The only consolation that I have is that these are a bunch of really nice people that I enjoy being around.

In my 22 years of work expirience this is an asset that carries far more weight than ones job description. The ability to enjoy working witht the people you work with is an unusual priviledge that should not be taken lightly. It is so hard to find groups of people that aren't just a pain to be with everyday, and that added stress diminishes the quality of life to the point that what a person is working on almost becomes irrelevant.

It's hard to soar with turkeys, and birds of a feather can be hard to find - except on perlmonks of course!

J/K but I'm really am in the RL opposite situation. I'm in charge of setting the rules and writing the specs (as well as writing about 95% of the code, welcome to the world of startups) and I'm just not sure where to go with it all.

Taint is a must, CPAN is a must, writing modules vs. hacking code is a must. The problem is the spec changes every day as we think of new things and the priorities are all over the map. One day I write documents for a big presentation, the next day billing code, the day after that I tinker with modules that I want to rebuild the hack jobs I kicked out last week on... Some days I'd rather have unreasonable, blind bosses and a clear direction of failure to head in. Not many tho and whenever it seems bleakest Ovid seems to cheer me back up. =)

--
$you = new YOU;
honk() if $you->love(perl)

First, thank you for the courage to put a question like that on here.

Point for point:

• Which brings me to my point: I'm considering hunting for a job where I can develop my skills in an environment where the programmers know what they are doing. However, after finding this code and seeing some of the "production code" posted here, I am concerned as to whether I am Questing for the Grail. The only consolation that I have is that these are a bunch of really nice people that I enjoy being around. - I personally have not met a whole company where everybody knows what they are doing (at least not at the level I wanted). I am just right now working in a team where we start to know each other better, so that a feeling like "as a team, we know what we're doing" emerges. Also, you should ask yourself if you want competent coworkers, or something like mentoring being available. Alas, I myself would really like some mentoring, but people able to do that seem to be rare.
• Do you believe that developing Web sites means you can't have adequate specs? - No, definitely not. Web site development is not black magic, and it is not much faster or slower than other development, I think. Customers have an exaggerated expectation fueled by Web hype, though. For more on that, I'd like to recommend Information Architecture for the World Wide Web, it has detailed information on how to gather requirements for a big web site. There *is* a big difference in approach between "old-style", document-centric websites, where business processes are everything, and "new-style", application-centric websites, which are more like client-server applications (just with a browser as a GUI), but that does not mean you can't develop adequate specs.
• Do most Web development companies take security seriously, or is it treated as an afterthought? - In my experience, security is treated seriously, but usually rules out Perl in the first place due to political arguments, and results in Java taking over the place, and not getting done anything. Also, Perl is often used for rapid application development / prototyping, and security is often not the first priority in such a setting.
• Is your company averse to installing CPAN modules, even if they have been reviewed carefully? - No, not at all. We use all the CPAN stuff we can, to enhance productivity. We have no time to reinvent the wheel.
• Do you have a job for a Portland, OR monk ;) - No, I am located in Germany. Sorry. OTOH, if you are able to make that move, you will sure be welcome!
• While I feel that I am a generally solid programmer, I realize that I have a LOT to learn. I feel that I can better do that in a company that takes programming and security seriously, but I am seeing many examples where companies using Perl don't appear to be doing that. Will I be disappointed with most companies? Am I being conceited? - I think you really want an environment where you can get some mentoring. BUT, at your level of technical expertise "the air gets quite thin", and you will have to do a lot of searching to get what you want. Maybe you can do an internship at some *really* cluefuel place, like a research center at a big company, or a "legend" company like ActiveState, and maybe you can make the grade. The other option is to grow alone, with "remote support" by communities like this. Regardless of the way you take, I wish you all the luck you can get. You will need it.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

You have my sympathies. Your situation seems pretty much like my own. I have been brought into a medium sized company to program back-end database code for them. Not a particularly hard thing, you may be thinking... DBI you may be thinking.

Then imagine my shock and horror to find that my predecessor had built his own database system... one that had huge problems with multiple use!

I'm not sure he had even heard of CPAN, let alone knew it's use.

Finally, he took the notes in perlstyle and did the complete opposite. No comments, meaningless variable names, a naming scheme that is_sometimes_like_this and SomeTimesLikeThis and SOMETIMESLIKETHIS :P

None of the sites he developed for are trivial and all of them have had to be changed.

Do you believe that developing Web sites means you can't have adequate specs?

I believe that any nontrivial program needs a full and complete spec. By nontrivial I mean any program that performs more than one simple task or branches or requires user input.

Do most Web development companies take security seriously, or is it treated as an afterthought?

After 4 year's work in the internet industry I am sorry to say that very few companies take security seriously. All of them do things like installing firewalls but very few of them will sit down and try to work out, for example, how a script can be hacked.

Is your company averse to installing CPAN modules, even if they have been reviewed carefully?

They aren't any more now :P

Do you have a job for a Portland, OR monk ;)

Considering the difference in pay between the US and the UK I would stay where you are ;)

My experience has been that security is a concern, but only one of many concerns. Ease of use and speed usually won out over security when they came into conflict--and that's not necessarily a bad thing. Not everything must be bulletproof.

I know some stuff I've written wasn't perfectly secure. For instance, when I've written little file manipulation scripts for use in controlled situations, they haven't always been sophisticated. They didn't need to be, either.

When I was in the last job, at a very large corporation, I found that I could make things as good as I cared to make them (time constraints did often crowd my style), and that, over time, I could influence others' standards.

The advice given elsewhere in this thread about proper use of buzzwords to get support in company politics for good practices is exactly right--I've done the same and benefited by it. I realize that even saying the phrase "company politics" causes many people to get out the garlic and the wooden stakes and, if they could only get enough of them and use them with sufficient efficiency--but they can't, so we must learn to live with the monster.

(I've learned to live with it...if you can avoid it, send notes on your method--I'm willing to learn.)

I've never worked anywhere that came up to my highest standards, nor ever produced work that came up to those standards--yet I've worked on some hot teams, and done some fine work. I just happen to have very unrealistically high standards, which, if you happen to have a personality that allows you to hold standards like that without perpetually beating yourself up over falling short of them, are not a bad way to keep yourself aimed at the top.