we all love making websites (was Re: Bonkers)

[Nicholas Clark]

On Fri, May 04, 2007 at 02:59:21PM +0100, Simon Wilcox wrote:

> Anyway, we will also be throwing our hat into the ring shortly, it looks
> like we're going to need a CMS developer but I already know that the
> intersection of perl Community and perl developers who enjoy building web
> applications is tiny. I will post the vacancy on jobs.perl.org when the

I suspect that the following don't apply to your company, given that you
work on varied projects, and you are sane and understand technology, but
rather too many of the "Perl" jobs I see advertised fail to answer the
two big questions that spring to many minds, as I wrote about in
http://use.perl.org/~nicholas/journal/33110

1. What is going to prevent this job becoming repetitive in 3 months?
2. Two years down the line, where is my next career move within your company?


because it seems a lot of these jobs are after someone senior, technology-wise
to go in at the top of the in-house web division.

Hence:

1: The job, month-in, month-out *is*, quite understandably, to improve on a
   single product, the company's web presence
2: The website itself is not the core business. The firm isn't a technology
   firm - you're a cost of doing business, rather than a competitive advantage.
   So to do your job well, you need to do your job boring.
3: You go in at the top of the technical scale. There is no way up, other than
   management. There may be a way sideways, but it's probably quite a large
   jump, possibly even into a non-technical field.
   (No, I don't want to be a professional trench digger, even though I am,
    apparently, quite good at it. Or electrician's mate. Or dog walker.)



There's also been the concern that some of these jobs are over-spec'd.
Now, this may be an over generalisation, but the fear is that web job
adverts are because someone leaves a company, so the spec written is based
on what that person could do *at the time that they left*. ie, meet all the
skills that the also learned on the job, and the ones they didn't really
need. After all, if you're employing in a rush to fix a hole, better safe
than sorry. Hence if you then look to meet them all, you're sure to be
bored. I think that the problem is that as Perl is often a self-taught
skill, a significant minority of people here have many skills that aren't
on the spec, hence like it or not end up over qualified. Or mis-qualified.
But with the potential to be under-challenged.


Another issue has been that websites typically end up under the control of
marketing departments, or other creative types. After all, anyone can
understand a bikeshed, er, I mean website. That's why we have splash pages,
monsters that take 100K or more where 16K would do
[don't do it with tables, do it with CSS, eg http://chris.carline.org/ ]
text in images, lack of deep linking [Yahoo!, you really want to change whom
you outsource your jobs to] and appalling information architecture that even
Google can't search you past.

I'm comfortable that your firm is sane, but I fear that it's the exception
rather than the rule. Certainly, I know of a recent story where someone
spent a considerably time writing a spec, with staged development and plenty
of time for testing, that was signed off by the client.

Then the first stage was delivered, and the client kept wanting changes. So
changes were made, which ate into testing time. Finally, after much hard work
a revised first stage was delivered with which the client was happy.

"But where's all the rest of it?"
"Well, that's in the next stages"
"But I want it ALL. NOW"
"But it's in the spec that it comes in stages. And you agreed to the spec"
"Do you think that I actually read the spec? I just signed at the bottom.
 But I am the customer, I am right, and I want it all now."

IIRC.


And I remember a certain rather orange firm at which I worked, where the head
of marketing was one of the co-founders, so was *really* good at demanding
her way. And as an ex-model, she didn't seem to understand that if presented
with two options that would each take 4 weeks, that

a: it was 4 weeks from when she made her decision
b: changing her mind 3 weeks in did not mean that she could still have it
   delivered within 1 more week.

Making websites often gets you rather close to B arc people.


Also, personally I have 3 reasons why I don't really like making web
applications. These may not apply to anyone else here:


1: I don't like creating user interfaces
2: I don't like writing code that I can't automate the tests for.
   (Certainly this used to be the case for websites. It's not so true with
    selenium, but, point 3)
3: We've done all this coping with incompatibility thing before. I know about
   it w.r.t. C and operating systems. Those who do not learn from history a
   doomed to repeat it, and I really don't feel like learning a whole new
   raft of incompatibility daftness w.r.t. to the "platform" that is
   DOM/JS/Web browser, with protocols implemented over HTTP
   given that I already know much of it for the platform that is
   Databases/Perl,C,whatever/OS and protocols implemented over TCP.


Gosh, this should have been a blog post. Then, at least, I could try to
cynically exploit Google and its pagerank for all that I could milk it for.

Nicholas Clark