From: Scott Sauyet on 10 May 2010 09:15 Andrew Poulos wrote: > On 10/05/2010 1:17 PM, Scott Sauyet wrote: >> Andrew Poulos wrote: >>> On 10/05/2010 12:15 PM, Scott Sauyet wrote: >>>> David Mark wrote: >>>>> Garrett Smith wrote: >>>>>> David Mark wrote: >>>>>>> Why? Everyone already knows [Google's] developers are incompetent >>>>>> Many, if not most non-developers tend to disagree. >>>>> And on what basis could a non-developer judge the competence of a >>>>> developer. >>>> On what basis can a non-designer judge the competence of a designer? >>> That it seems many people slavishly follow whatever the current trend >>> might be is indicative of a lack of understanding of design and hence to >>> know good design when they encounter it. >> Are you a professional designer, then? Or on what basis are you >> making that claim? > It seems that you're claiming that I need to competent in an area to > make a judgement. It seems that you've forgotten which side of the argument you're trying to defend. :-) -- Scott
From: Scott Sauyet on 12 May 2010 09:12 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. As I said, I personally might disagree with them on technical grounds, but if you think technical arguments win most decisions in software development, you're living in a very different world than I. -- Scott
From: David Mark on 12 May 2010 09:37 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. > As I said, I personally might > disagree with them on technical grounds, but if you think technical > arguments win most decisions in software development, you're living in > a very different world than I. > Not the "real world" argument. :( Yes, software development is a technical business. You may be confusing UI design with development. The line may be blurry in some cases, but it is still there.
From: Scott Sauyet on 12 May 2010 10:54 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. 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. For one-person shows, technical prowess is essential, and even for large teams I won't hire people without clearly demonstrated technical skills. But for these larger projects, a hugely important skill is thinking like a user of the product under development. That skill is in many ways more important than the technical ability. 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. 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]; This is clearly nonsense, and was written by someone who missed a lot of the fundamentals of Javascript. 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. -- Scott
From: Garrett Smith on 12 May 2010 13:34 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. > [...] > This is clearly nonsense, and was written by someone who missed a lot > of the fundamentals of Javascript. 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. > That problem is very basic in nature and supported natively by ECMAScript, as revealed in line two of the body of the function. That basic problem is addressed by five lines of code, four of which are clutter. That's 80% of clutter. Its easy to see what is going on, as you point out. The water wings are working. He's over his head but he's not going to be succumbed by a riptide. Consider a Scheduler for a CMS now. Not a basic problem at all. This is a larger problem that will require a much broader and much deeper understanding of several technologies -- not just javascript strings and arrays -- but will involve the DOM, Events, HTML, CSS, and server communication. A good solution will also need more sophisticated abstractions and code organization strategies. Good abstractions deal with the problems at a level that they can be understood. Good javascript abstractions also address the additional constraint of dynamic deployment environment. By that, I mean browsers, configurations, screen sizes, cache sizes, CPU, forwards and backwards compatibility. Had that developer been assigned to a complicated task like that, the result would be at best, nipped in the bud at early stage, second to that, a complete and total waste that got trashed, and at worst, something that the manager tries to have everybody maintain when it really needs rewriting. Unfortunately, that worst possible outcome is the most common. It could get nipped or transferred if the manager realizes that the progress is not being made soon enough. If he has been working on the problem for a month or so, stopping him at that point will be more painful. The effort spent may be perceived as being greater than the amount of effort required to get it done and so the manager says that: "get it done!" The five lines above, while senseless, would be nothing compared to a wretched mess of unmaintainable two thousand lines. Shipped late, with bugs. It's all about the water. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: The Most Challenging Interview Question Next: typeof eval("(function F(){})") |