Hacker News Reader

Comment by exelius | Hacker News Reader

It was never about the code.

It was always about the products.

Agreed and up-voted. I think that is what I was trying to say in my rant. I guess as a developer though it's hard to come to terms with the fact that you are creating crap.

I went through the same thing when I was a musician so it stings doubly.

The media fetishized a "techno-genius" that never really existed. Design and development are two very different skills, and it's rare to find a person who is good at both.

But all things equal, a good product person can make do with shitty developers. Good developers can never overcome shitty product design. If you want to design apps, go to school for design.

I see what you think are shitty developers and raise you actually shitty developers.

Craigslist finds your argument unpersuasive.

Craigslist is great design. I'll take that over what "UX experts" come up with any day.

Craigslist seems overwhelming and like bad design when you first encounter it, but start using it for awhile and being able to go exactly where you need to go with one click and know exactly where on the page it will be located, without scrolling, and have your mouse ready to click it, is actually really nice.

Craigslist only seems like bad design if you've been programmed to use successful application of current design trends as a shortcut to figuring out whether a site is abandoned, under-funded, or incompetently-executed. Which we all have, and that signal often works so it's not useless. With some "badly designed" (several design trends out-of-date) sites that signal's incorrect, though.

For most sites I really miss the blocky header+sidebar-nav+footer-fallback-nav trend of 2006-2012. Fast, efficient, predictable. Current design trends are much worse to use for most purposes. But, of course, if I see a site still using the former design, I assume bad things about it until proven otherwise (at least until I see a recent date associated with something) and I'm not inclined to trust them with any money.

Even better is you can bookmark what you want, no navigating through an animated SPA.

"Never" isn't accurate though. If you step away from vapid content sites for a minute, to a place where real money and products are exchanged, there are strong cases for load time affecting the likelihood of purchase or cart abandonment, or whether they'll resubscribe to your SaaS.

It does largely depends on how much the user thinks they specifically need you but if it's between your flabby website, taking seconds to load each page, and a competitor's fast website, you can bet you're losing money to them, even if they're slightly more expensive.

Slow websites frustrate users and look unprofessional.

I know this article is aimed squarely at content but articles like this lead to people making silly comments —like the one I'm replying to— that make absolute statements about all web development, all the time.

Of course some schmoos can get away with some bloat, but that's very different from saying it's only the product that matters.

Everything you mention is something that is the concern of a product manager, not an engineering lead. It becomes the engineering lead's problem when the product manager tells them it is. A huge problem at a lot of companies is when engineering teams go "off script" and build solutions for problems that nobody has. Is it an accident that Google's "10% policy" has largely evaporated as pressures on efficiency and productivity have come in from Wall Street?

Also speed on the type of sites you mention is a solved problem. CMSes these days have an option to generate static content and push it to a CDN. Is it free? Nope. But it's a problem with a solution.

I don't think I could disagree more with your post.

Every developer you have should be capable of weighing up performance ramifications of their decisions, and be able to discuss and justify them. Not saying that every line needs explaining but come on... Not their concern? I'm all for getting stuff done but doing a crappy job the first time more than doubles the TTL.

Moreover, telling your developers to ignore this stuff means it becomes a lost skill. When you do need them to double-back and profile and bisect everything back to 0AD, they'll be much less capable than a performance-conscientious developer.

I don't disagree that over-optimisation is a thing, but a hands-off approach is far more toxic. Big ticket optimisation rewrites should not be something a single developer takes on without their lead signing off. Letting developers do that is a management issue.

And "the type of sites I mention[ed]"? I think you misread my post because I was very explicitly talking about e-commerce and webapps. Not CMSes and not usually something you can run entirely static from a CDN.

And just because it's static and/or on a CDN doesn't mean it's not bloated to hell and back; that's really the point TFA is making.

Reply on news.ycombinator.com