On Wednesday 06 June 2007, Yona Shlomo wrote: > On Wed, 6 Jun 2007, Shlomi Fish wrote: > > I seem to have trouble accepting every one of your "facts": > > 1. Workplaces don't give their workers adequate conditions. Either the > > pay is too low, but often the other conditions are bad - overworking > > them, not enough (or even non-existent) snacks, bad co-workers, > > unrealistic schedules, bad software management, too few paid vacation > > days, etc. > > Is this a fact? I disagree. > Sure, there are places like that. But not all workplaces are > as you describe.
I met with two Perl-ILers in a cafe, and told them that I was expected to work *at least* 9 hours a day at my previous workplace. Only I found that I could not work more than 8 hours, and often left early for FOSS meetings. They told me that practically all workplaces expect you to work at least 9 hours a day, and don't have a flexible schedule. Granted, at the work before that, I was employed for 40 hours a week, and was not expected to work more. (and had a global pay). I also found that I was given computers without DVD+RW writers (at my previous workplace I got a standard CD-ROM drive), without enough diskspace, with recycled hardware, with recycled software (Windows 95 on which two developers had worked previously - %-)), no VMware licences to run Windows, incredibly crowded offices, etc. Have you read my "End of IT Slavery" article? http://www.shlomifish.org/philosophy/computers/software-management/end-of-it-slavery/ There are many other employment anti-patterns there. > Moreover, the more you are an attractive employee, the more > the company will (probably) invest in you. > Like I say in the article: {{{{{{{{{{{{{{ Moreover: if you want to employ people like me (and you do), you should not give us only good conditions - you should give us exceptional ones. Otherwise, we'll probably leave, or be fired, much to your misfortune. }}}}}}}}}}}}}} > > 2. Workplaces cannot recognise good workers when they see them, or let > > them get lost in confusion, bureacuracy or politics (happened to me many > > times), and are too clueless to know how to keep them, and that they > > should in fact do their best to keep them. > > That may be sometimes true. There's a lot that an employee > can do in order to play the game correctly. It requires some > social skills, though and some experience too. > "Social skills" - don't you know that some talented or even very talented people lack them? "Experience" - that's the chicken and egg problem. I've often did everything I could humanly possible do to "play the game correctly". But these employers were too arrogant (or full of "hubris" if you may), didn't give me what I wanted, or thought that I was a bad employee. And guess what? They fired me or I quit being dis-satisfied. An employer should know that a good developer is a long-term investment. They don't grow on trees, and they come in all shapes and sizes. Please don't shift the blame to the employee here - the employers are the clueless here. I am an enlightened employee. I know many programming languages and technologies, read many tech blogs and news sites, am interested in software management, am very conscious about spoken language syntax and semantics (se Dijkstra) and am also writing several essays, stories, and prsentations and so have better perspective than people who are just programmers. As such, my standards are very high, and I often can tell that I know better than my employers in some respects. But I'm not the only one. At the Ruby-ILers meeting, I met someone who read most of Joel-on-Software and Paul Graham, and also found his current job on the Joel-on-Software job board. > > 3. Workplaces want their programmers to know Perl (or whatever) > > yesterday, instead of training bright and intelligent ones, and expecting > > them to grow. Now Perl does not have a hype machine, and actually got a > > lot of negative FUD, so few programmers seem to learn it now not as part > > of their jobs. > > A good programmer should be able to pick up Perl (or any > other programming language) independently. I don't get your > complaint here. Many workplaces want "1 year of experience in Perl and QA", "3 Years of experience with mod_perl, etc." Haven't you read this - http://www.perl.org.il/pipermail/perl/2006-June/007956.html ? Or looked at most job ads at jobs.perl.org? I admit that a good programmer can pick up Perl very quickly. But workplaces and HR departments don't want that - they want experience. And furthermore, between being able to write and understand most simple scripts, and between being someone who: 1. Writes semantic, modular, and idiomatic Perl, 2. Know how to handle and debug most problems properly. 3. Has a lot of working knowledge working with mod_perl, POE, wxWidgets/Tk/Gtk, UNIX multi-tasking, XML, web automation or other important Perl programming niches.[1] ------------ Perl may be easy to start coding, but becoming experienced enough with it for many purposes takes time and a lot of it. It can often take several good years. {{{{{{{{ [1] - for the record - I don't have a lot of experience working with mod_perl and close to zero working with POE, and knowing that these two are complex topics, I don't think I can work at jobs that require a lot of expertise in them. }}}}}}}} > > And regarding issue number 4: > Perl has quite good documentation, and literature, in my > opinion. It is also fairly easy to get the list of "must > read" according to your level in Perl. I'm still not sure the online Perl documentation is very accessible or organised, but that's not the point. I was talking more about how the central Perl sites are not designed according to Marketing constraints and often don't immediately tell what Perl is all about and why should the prospective hacker care. And as Shmuel Fomberg noted - yes the online core Perl documentation is often inadequate and there are better commercial books which are not legally available online that were often written by the central figures of the Perl world who are responsible for making sure that there will be good, free documentation. Right now, I'll recommend people to either buy these books, or download them from P2P networks[1] or from http://www.g2p.org/. Regards, Shlomi Fish [1] - http://www.shlomifish.org/philosophy/case-for-file-swapping/ --------------------------------------------------------------------- Shlomi Fish [EMAIL PROTECTED] Homepage: http://www.shlomifish.org/ If it's not in my E-mail it doesn't happen. And if my E-mail is saying one thing, and everything else says something else - E-mail will conquer. -- An Israeli Linuxer _______________________________________________ Perl mailing list [email protected] http://perl.org.il/mailman/listinfo/perl
