Micro$oft Biz'droid Lusers (was: OT email response format)

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Apr 23 10:11:35 2002

see below, plz.

Dick

----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc_at_conman.org>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, April 22, 2002 8:10 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)


> It was thus said that the Great Richard Erlacher once stated:
> >
> > It's true that there are lots of books on how to use various software
> > applications. Having lots of them is good because people will want to use
the
> > software in different ways and not always in the same way. Programmers
should
> > read these books so they know how programs are used. They should also
read
> > them to find out how useful a helpful error or diagnostic message can
help.
> > As for the quality of documentation, I've found statements in Linux
documents
> > that were so outdated as to be patently false, having omitted critical
terms
> > such as "NOT."
>
> Linux, unfortunately, is a fast moving target and by the time books do
> come out for the the kernel side of things, Linux has already moved on. I
> suppose it's one of the prices ones pays for ever evolving code.
>
What you mean here is that before the job is finished, the LINUX team has
moved on, leaving their work product essentially useless for the majority of
potential users.
>
> [ Dilbertesque situations deleted ]
>
> > No, I don't wonder. This situation can't be blamed on the mangers either,
> > though, because the programmers shouldn't tolerate this.
>
> I haven't met *any* other programmers that would even think of not
> tolerating this. One friend of mine, where he worked, was asked what
> hardware should be used for a new private phone switch (used to manage the
> phone system at a mid sized company). They didn't listen to him and picked
> PC hardware. They then asked him what OS to use. They didn't listen to him
> (he wanted either FreeBSD or Linux) and they picked Windows NT.
>
> For a phone switch.
>
> He stayed. He bitched, a lot, but he stayed. And got it working (to a
> degree). Me, personally, I would have refused to work with such crap under
> those conditions but most of my programmer friends (okay, all of them)
> would. And did. It came across as a challenge to them.
>
He obviously saw things differently than you. Where one works has to be a
considered choice.
>
> I consider them insane, but hey, they're still working and I'm not. So
> there you have it (I've quit a job because I didn't agree with the coding
> standards but that was several years ago. My current unemployment is due to
> working for a completely insane boss who's goal in life seems to be to die
> at work (``I had pnemonia for six weeks and did *I* take time off from
> work?'' And he was back to work two days after having some heart work done)
> and I took a few weeks off when I had bronchitus).
>
There's a lesson there, isn't there?
>
> > There'll always be disgreement on what's wanted, until it's written down
and
> > signed. If you can, get your boss to write you a "statement of work"
which
> > includes your precise requirements including test criteria and schedule.
> > Usually schedule and workload can be adjusted early in the project, so if
it
> > doesn't suit you, or, if, early in the progress of the work, you discover
a
> > serious obstacle, that can be dealt with rationally. If you just quietly
go
> > away, letting him plan his schedule on your acceptance of his schedule and
> > task loading, it's on you. If he doesn't allow you any input, it's on
him,
> > and you should emphasize those issues in a memo. It won't help either of
you
> > to pretend the problem doesn't exist.
>
> Again, getting back to my friend who worked on a phone switch based on
> NT---his team hired a programmer who swore up and down that he could program
> under C++ and understood networking, yet three weeks later he still couldn't
> compile a simple C++ hello world style program, and had no clue what sockets
> are and you can bet my friend screamed up and down.
>
Most programmers don't know their butt from a hot rock. Some of them are
smart enough to learn. Others aren't. This notion is not just limited to
programmers, however. It applies to managers, car mechanics, and physicians
as well.
>
> It did no good. They couldn't get rid of the programmer, and no amount of
> memo writing or walking up the management chain would fix that.
>
> > > -spc (Oh, forgot to tell you ... I won't tell you the specs at all,
but
> > > that shouldn't affect the time schedule any ... )
> > >
> > Perhaps the programmers should simply refuse to work that way, rather than
> > abjectly refusing to adhere to formal specifications, established
policies,
> > etc. Either way, they're likely to be fired when all is said and done.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Bingo!
>
> -spc (The Emperor may have no clothes, but he can still behead you ... )
>
>
Received on Tue Apr 23 2002 - 10:11:35 BST