Hacker Newsnew | past | comments | ask | show | jobs | submit | Dead3's commentslogin

> This will just lead to massive selection bias. If all you care about are power users go for it.

Simple things should work. The types of errors described in the article about feature creep and errors with simple user flows are all too common.

Just surf the web with the developer console open. It's not just "an error was thrown", but the kinds of errors and how they manifest. A rejected promise after localStorage access was blocked, after user clicked a submit button on a form that went through twenty seven delegation calls of Angular js using backspace-escaped method names to handle invalid HTML, and now the form can't submit because they did it using the latest tools, as per their resume. Crap like that. The level of quality of production web code is the cause of the poor user experience and outright failures. It is unacceptable and its cause is directly traceable to the design decisions and skills employed in its production.


The OP is right most production code is full of errors, and suffers from code bloat and feature creep that impacts UX.

Is this really the best we can do? It strikes me as unacceptable to ship errors to production, yet it's commonplace.

Code quality matters, and being in touch with users/dogfooding matters. But that can only address the underlying problem by eliminating the low-talent developers who win by numbers.

How to solve the relevant problems is not something hiring and recruiting teams can assess. So, hiring process uses proxy metrics like having a HS and CS degree, years of experience, brand name companies, list of tools, "best practices", trends, etc.

Teams of self-congratulating code monkeys using all the latest 'industry standard' libraries and tools, don't accept responsibility for their errant code. Instead, they blame (the user, his browser, the library), make excuses, minimize "all software has bugs". They can't fix the bugs they've created for themselves, but it can't be their fault, after all, they're doing what everyone else is doing.

The answer is to send them packing. Hire by talent, not by proxy of a hiring team (who don't know how to think/use the aforementioned proxy metrics to gauge talent).

Intelligence cannot be taught, but it can and is discriminated against. That is another problem with these faux 'team-player' follower types. Anyone on the team pointing out the code is a disaster and an attitude to fix it is not going to last. He'll be fed pushback of the same crap excuses for why things must be done the way they're done.

When a talented developer does deep dive analysis to identify root causes, most on the team don't get it. The scary bugbear of coherence is too hard and threat to the team's shared narrative.

Again, the only way to solve that problem is to send them packing.


Neat concept but looks vibecoded/authored by someone who does not know web programming. Many HTML and JS errors. Code is a mess. jQuery, angular, document.write, modernizr. Why?

Could be done at 5% of codebase size, with cleaner code, no var, better error handling ($http calls use .success(...), no zero .error()/.catch() handlers).


Neat comment but looks prompted/authored by someone who does not know Bird Law


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: