OT: The Economics of Incompetence

[Tom Leylan]

It's turning into the economics of automobiles

The relativity of things is an important point. All things considered
however it might be a better idea to drive a Mercedes Benz or BMW in Germany
considering the Jaguar is an import and seats two. It isn't uncommon to see
a Mercedes Benz taxi in Germany, a Jaguar taxi I've never seen.

Happy New Year.

 

[RobinS]

Man, that makes me wish I lived in Germany. Although once I get
over 100, I feel a bit nervous.

Of course, if the Jaguar breaks down, you're screwed.

They used to have a saying here: If you're going to own one
Jaguar, buy two. That way you have one to drive while the
other one is in the shop.

Robin S.

 

[RobinS]

Well, that's the question, isn't it? I've worked with people who are
completely full of crap, but management likes them because they talk
slick. I don't deal well with people who are pompous.

I guess people could read Consumer Reports and see what the
history of the car is, much like people can call my references.
Of course, it's not like you're going to give someone a reference
who's going to say something bad about you. And it's not like
someone in management wouldn't just *love* someone who was
ineffective because they were clueless (see previous comment
about 'slickness').

There's no way to know for sure, but I go back to Joel Spolsky's
advice, and have to say it certainly would help one to have a better-
than-average chance of success.

Robin S.
----------------------------------------

 

[Cor Ligthert [MVP]]

Tom,

It seems you have a very small view on what is a Jaguar, in Europe the name
of them has been a long time "a poor mans Rolls", a very reliable car but
not as expensive as that (however still expensive). I seems that you are
only talking about the 2 sitters, which were more build for design and
speed. Therefor again in this anology, you should not give a judgement if
you are not able to see to complete scope.

http://www.jaguar.co.uk/uk/en/home.htm

Cor

 

[Tom Leylan]

Yeah I goofed on that but I couldn't recall the message after I posted it
I was thinking of the XKE model. I'll stick to programming questions!

 

[Tom Leylan]

I had read it before but I just read Spolsky's blog again. Viewed from a
practical perspective however I believe there are gaps in his reasoning.

He assumes a fairly large programming department ("You should always try to
have at least six people interview each candidate that gets hired, including
at least five who would be peers of that candidate (that is, other
programmers, not managers).") And he assumes it is a well-run department
("If even two of the six interviewers thinks that a person is not worth
hiring, don't hire them.")

Bob Johnson's point (in starting the thread) was that companies have groups
of unproductive people already. If one is interviewing at a place where 85%
of the projects are failing or behind schedule it is the people interviewing
you who form the core of the systemic problem. The average "this is good
enough" coder looks to hire more "this is good enough" coders but is this
what the company needs?

I often can't pass the test as I don't recall the third parameter of a
little-used function I can however see the big picture when the
"superstar" who does know the intricate details is repeating the same chunk
of code in 11 places. I can see where he sets up dependencies between
generic functions and specific controls and know how this could have been
avoided. Any development effort needs programmers but it also needs
architects. The six programmers one interviews with may not recognize this.

Tom

 

[RobinS]

I agree with you. The last few jobs I've worked, I was hired by small
business units inside large corporations who just wanted someone to
help them get their jobs done by automating some of their work. The
people interviewing me had nothing to do with IT at all.

And he *is* assuming that the people already there are exemplary,
and you're right, that often is not the case.

I also would have difficulty remembering the parameters (isn't that
what Intellisense is for?), but I don't think that's how they would
judge you. He talks about writing a function to check and see if
a character is an uppercase A-Z -- I'd do that by checking the ascii
code or unicode #'s, but I'd have to look up the corresponding number.
But the fact that I would do it that way, rather than a big IF
statement with 26 letters in it must say *something* about me. And
there are some people who wouldn't know how to do it at all.

There's no magic bullet. It's just a difficult thing all the way
around, isn't it?

Robin S.
---------------------------------------

 

[Tom Leylan]

I think these types of discussions are rare but important (in moderation) in
a programming newsgroup.

By all means solving the A-Z question using a loop rather than 26 case
statements tells us something. Among them that you're efficient in your
solving of the dreaded uppercase A-Z conundrum This can reasonably be
translated into "he thinks logically" and this is a programming asset.

Does this translate into "he can write applications?" I'm fairly certain it
does not. Lots of programmers are (algorithmically speaking) top notch but
are barely able to create a useable application. I fix code all the time,
these days usually taking over projects that have been abandoned by other
developers. In every case the code works, in some cases it was a creative
solution (not too often though) but in almost every case the "application"
shouldn't have worked that way.

I can't give detailed examples in a message but I find a menu option for
"Search" and sub-menu items for "By Code", "By Name", etc. The user is
forced to decide too early which method to find something, if the code he
keys in isn't found then he has to choose the menu and another sub-menu and
try again. Clearly the user just wants to find something so all search
options should be available from a composite search form. Having keyed in a
code and getting a "not found" dialog the user would simply try typing in a
name not navigate down a menu tree again. I don't even want the user to
have to dismiss a dialog box it's annoying after the 3rd or 4th miss. And
of course the thing should support (as an option) wild-card searches.

I'd say a good number of projects fail not because there isn't a lot of code
but because they are coding the wrong thing. When complete it isn't what
any user really needs though it may be want the user said he wanted.

I ran across a case where "reprints" prompted "Enter Invoice Number:" and
then reprinted one. The user often needed to reprint multiples so it was
suggested I let the user key up to 5 invoice numbers. Uhhh.... how about I
display the list of available invoices and they select as many as they feel
like? That eliminates having to check (and report) that the invoice number
doesn't exist (if they key it in wrong), the repeated selection of the
"Reprint" option and it means they could select several dozen and go off and
work on other things.

Are those questions asked during the interview? Is the goal to write
applications quickly or with the fewest lines of code or (once complete) to
make the company run more efficiently? The hotdog who wrote "Enter Invoice
Number" surely did it faster than my rewrite. I may have taken 5 times as
long to write it but I saved the users hours per week from them on. It
isn't my salary that was the offset it was the cumulative cost of all the
user's salaries.

 

[RobinS]

I use my clients as references, which is a good thing. I can also
show applications that I developed, which gives a sense of what I
can do. You're right, in that being able to write a function does
not mean you are able to put an entire application together.

You also need to be able to see how the user will *use* the
application, which will enable you to make leaps of logic to help
discern between what they *say* they want, and what they *really*
want, and to make it as usable as possible, as in your examples.
I have no idea how you would test that.

I wrote a medium-sized application at my last job, and the clients
asked me to demo it to their boss because they liked it so much.
He really surprised me -- he took it for granted that the app
functioned effectively based on feedback from the clients, and
congratulated me on the little things that make the users happy,
like using masked edit boxes for the dates so they don't have to
type the slashes, using a listbox on one screen so the users could
pick several items at once, being able to run a report two
different ways because the group couldn't reach consensus on which
way was best, and things like that. People don't usually notice
that stuff, but it makes a huge difference.

On the other hand, my boss asked me to give this other guy
something to do. He had taken a VB class. I asked him to copy these
two screens that were basically a grid showing a table, and an
add/change/delete screen to update the grid, and make them work
for another table. It took him 4 weeks, and multiple consultations
with me going over his code explaining stuff like "you have to change
the field names." (He had no pattern recognition skills at all.)

But here's the thing that really cracked me up. One of the input
fields was a Project ID that needed to be in uppercase with no
leading or trailing spaces. To resolve this, he checked it for
leading/trailing spaces and lowercase letters, and if he found
any, he popped up an error to the user telling him to fix it.

I was like, "Um, couldn't you just uppercase and trim the field
for the guy? We're talking about one line of code here."

He said, "Well, they should put it in right."

Sigh.

Robin S.

------------------------------------------------

 

[Cor Ligthert [MVP]]

Robin,

I was like, "Um, couldn't you just uppercase and trim the field
for the guy? We're talking about one line of code here."

He said, "Well, they should put it in right."

I have seen more than one who answered on this obvious beginners error: "No
it is his error, it is good to show him that"

Cor

 

[RobinS]

Robin,
I have seen more than one who answered on this obvious beginners
error: "No it is his error, it is good to show him that"

Cor

Well, that's at least *nicer* than "they should put it in right,
I'm not going to fix it for them."

As for the user, I don't really think that's an error. Think
about license keys, and how you'd feel if you typed in the
25-character license key, and then a box popped up and said
"You have to put in uppercase letters." Now, if he was
putting weird characters in the project id, that would be
occasion to give him a message telling him he couldn't do that.

I explained that to the jr. programmer, and how you need to make
an application user-friendly -- make it as easy as possible for the
user to use, even if it's "inconvenient" for you. You're only
going to write it once, but they're going to use it hundreds
of times, so it's worth throwing in an extra hundred lines of
code to do something that's going to save the user hundreds of
hours. The happier you can make your clients, the longer they
will keep you around. I was hired for a 3-week contract; they
kept me for 4-1/2 years.

He was just lazy, and wanted to put out as little effort as
possible. He complained about how hard everything was, and how
you had to type in all this code, etc. I thought he was in the
wrong field!

Robin S.