Prev: The Most Challenging Interview Question
Next: typeof eval("(function F(){})")
From: David Mark on 12 May 2010 19:40
Scott Sauyet wrote:
> David Mark wrote:
>> Scott Sauyet wrote:
>>> David Mark wrote:
>>>> Scott Sauyet wrote:
>>>>> David Mark wrote:
>>>>>> So who would you ask?
>>>>> In the end, the people paying the bills. And I'm afraid that the Joe
>>>>> Browsers of the world are much more strongly represented among those
>>>>> people than are the Richard Cornfords.
>>>> You would ask the man on the street to judge the relative competence of
>>>> Web developers? It doesn't make sense.
>>> No, I would ask the users of their products. It's their views that
>>> are probably the most relevant.
>> No. You switched arguments. We are talking about judging the
>> _competence_ of developers, which is not done in user focus groups.
>
> I've occasionally -- not too often, I'm glad to say -- been in the
> position of managing other developers.

Join the club.

> What I realized eventually is
> that technical expertise is, sadly, only a small part of what makes
> for a successful member of a development team.

It's a huge part of it in most cases. You just can't write good
software if you lack technical expertise. That's the problem with many
open source projects these days.

> For one-person shows,
> technical prowess is essential, and even for large teams I won't hire
> people without clearly demonstrated technical skills.

I don't follow. What sort of programming team would be appropriate for
non-technical people (or people with poor technical skills).

> But for these
> larger projects, a hugely important skill is thinking like a user of
> the product under development.

No kidding. UI design has been a specialty of mine for almost 20 years.

> That skill is in many ways more
> important than the technical ability.

It depends on your role. Designing and programming are two different
activities.

> I would rather clean up after
> someone who's left a technical mess but pleases the users than try to
> upgrade a wonderfully designed and beautifully implemented system that
> fails to meet the users' expectations.

Again, you seem to have a blurry picture of how software is created.

>
> I'm in that boat right now. I'm finding code like this:
>
> function splitString(aString, spliter) {
> var temp = new Array();
> temp = aString.split(spliter);
> return temp;
> }
>
> // ...
>
> domainID = splitString(ids, '|')[1];
> serverID = splitString(ids, '|')[2];
> portID = splitString(ids, '|')[3];
> formatID = splitString(ids, '|')[4];

Fire whomever wrote that. Or, if they are a whiz at design, put them on
design. But don't let them write code.

>
> This is clearly nonsense, and was written by someone who missed a lot
> of the fundamentals of Javascript.

To say the least.

> But the users are very happy with
> the results. It does what they need. They don't notice the
> performance issues, and don't care about the architectural or
> implementation decisions.
>

So transfer them. But this has nothing to do with the original
discussion. In fact, you've proven my point. Users can't judge
developer competence. They can express a preference for a UI design,
but that has nothing to do with develop competence (and everything to do
with designer competence).
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: The Most Challenging Interview Question
Next: typeof eval("(function F(){})")