Hacker News Reader

Comment by _Microft | Hacker News Reader

User to Dev: the memory usage is excessive. Dev with 256 GB RAM to User: WFM

I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers. Combine that with fresh or minimal installs while testing the software, without lots of data that accumulated over month or years of use and in consequence they experience their products as super snappy.

Summary: they maybe never experience their products as a normal user would.

View on HN

Why is everyone assuming that just because someone works for Google has to be competent? Solving algorithmic puzzles is not an indicator or actual technical skills.

To me, it looks like a work of incompetent developers led by incompetent technical managers upon requirements of clueless and ignorant product managers.

Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. They're attempting to maximize their velocity, maximize their API stability, and make programmatic usage of their system as easy as possible.

GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).

I thought Terraform provider was developed/maintained by Hashicorp, not Google. Are Google employees actively involved? I also did encounter annoying issues (which have slowly been getting better though).

I guess it might speak to a solid, if somewhat slow, API.

Yeah they've got a nifty tool called Magic Modules that partially auto-generates the Terraform Provider (along with Ansible and InSpec) from the GCP API:

https://www.hashicorp.com/resources/google-provider-new-terr...

My understanding is that it is actively maintained by GCP employees, but yes Hashicorp owns the repo.

The terraform provider is usually a near 1:1 mapping of the provider's APIs.

> Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. They're attempting to maximize their velocity, maximize their API stability, and make programmatic usage of their system as easy as possible.

Yep, already covered that under incompetence and cluelessness.

> GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick. Probably the best one of the bunch (Azure, AWS, Oracle, OVH, ...).

In that case, I would assume that backend team indeed consist of competent people, as opposed to web team. But TFA was about front end experience which is abysmal.

They had some big outages over the last year. I’m therefore still skeptical to bet on them from a “backend” operations reliability standpoint also. To be fair I’m not sure they are doing worse than AWS though when looking into details. I’m thinking recent AWS Kinesis us-east issue - move fast and break things? Maybe uptime is more important than a gazillion new “feature” services. I also prefer good terraform provider stewardship over any “fancy” new cloudformation CDK or “beautiful” GUI actually. It’s complicated.

> Cloud service providers aren't really optimizing for the same thing that the average website is optimizing for. (snip) GCP's UI? Yea it's pretty bad. GCP's terraform provider? It's really slick.

That's still incompetence. That counts as incompetence, too.

"This restaurant is filthy and full of bugs, but that's OK, because they're take-out only, so they're not optimizing for the same thing the average sit-down restaurant is. Sure, that place is disgusting, but the food in box still tasted pretty good..."

A better comparison:

"This restaurant only has one table and 1 chair with a broken leg and gum stuck to the seat but that's ok because they're take-out only"

Coding for Android has taught me that is definitely not the case.

They managed to make a mess worse than JEE, the native layer took 10 years to finally use Android Modules, they keep fixing the header files, still don't have proper C++ bindings and force everyone to write JNI boilerplate by hand.

Android is really the worst platform for developers. Context? Let's make a god object, and also create application context and activity context, and screw liskov substitution principle. Also create a library to fix all our bugs in all versions of the platform, but also have a shit ton of bugs.

Microsoft did nail windows phone apis, 10 freaking years ago, too bad it didn't survive.

Yeah, keep using my Lumia and playing with UWP.

The Android base wasn't written by Google. Google bought the company that made Android 2 years after it was written. That's a lot of time to create a base system and a lot of time to create cruft.

By now, it's too late to rewrite the whole thing from scratch, hence a new OS https://en.wikipedia.org/wiki/Google_Fuchsia

That is no excuse. They had 10 years to fix it, and many issues steem from Google's HR to promote doing shinny toys instead of fixing broken stuff.

I think by attributing it do incompetence you're missing the incentives problem.

Others point this out, but Google just has no incentives to improve this UX. Think about who makes the decisions to use Google cloud and what criteria they are using.

The snappiness of the gcp ui is not likely to be near the top of their list

DigitalOcean built a big business off of easy to use cloud hosting.

Yes but I don't know that they have much success convincing already huge companies to switch to their cloud

B2 large business is different than b2c or b2 small business

It's all about who is making the decisions

No incentive? AWS is crushing them, the UI is the product.

Slow software doesn't indicate a lack of skill.

It indicates that speed is not a priority for management.

Because it is both kind and safe to be charitable, and many problems can be explained without having to assume idiot developers.

I used to think Google hires only "top" developers. Lately I think they mostly hire average or below-average people which resulted in products of average or below-average quality.

Besides well known computing idols, it is basically who is able to put up with their hiring process and manages to score a job offer.

The puzzles make sure you can write the O(good) algorithm, knowing the coefficients is a question of experience and knowledge of the shoulders your code stands on.

I don't think it is just that. Google is just shockingly bad at web frontend. All their properties are terrible, except maybe Youtube which I find quite agreeable. For example I just made a search on google.com, the most popular website in the world, and it can't even fit the content into this reasonably sized window [1].

[1] https://i.imgur.com/ER5yfbd.png

Which large companies aren't bad at web frontend? UX seems to always be far down on the list or priorities for modern websites.

>Which large companies aren't bad at web frontend?

I know it's popular to shit on them, but Facebook (and to an extent Instagram). Despite all the expansion, and third part integrations, at least for me (13" MBP 2017, i7/16GB):

1. Everything "feels" like Facebook. 2. It's relatively quick. I can hop from posts, to events, no notifications.

I hardly use Facebook, except for marketplace, so I can't say for sure if users find the interface confusing, but the UI at the very least is well done.

But then look at FB Ads Manager - it's hard to imagine that such a horrible UX drives billions in revenue and yet no one seems to care.

I find Github and Amazon's main site to be pretty reasonable in comparison.

Amazon is about the last site I'd use as an example of a good UX. They've clearly been working on making it better, as the account drop-down has shrunk, but the amount of items on this screen is such that it really should have its own search to navigate it. A simple thing like buying a new gift card for someone is surprisingly clunky.

https://i.imgur.com/ZNKOkMN.png

As someone who regularly uses other e-commerce front ends, I find Amazon to be quite cluttered and messy. Also it‘s surprisingly difficult to quickly find a specific product.

I am simply happy that Amazon has not embraced the ridiculous trend of low-information density with large amounts of whitespace.

Give me a cluttered UI that has everything available any day.

Totally. Cmd+F FTW, if you wanna search.

One pet peeve I have is getting to prime video. They own primevideo.com, but it just tells you to watch on Amazon. It's also the first result when you search (on google) for amazon prime video. There's no direct url to get it (afaik).

amazon.com/primevideo and amazon.com/video both go there.

The situation with primevideo.com is strange, but it seems to have something to do with non-US territories?

PrimeVideo.com is the website (in addition to apps on mobile and living room devices like TVs and consoles) where customers outside of the US, UK, Germany, and Japan can watch Prime Video. In the aforementioned four countries, customers can watch Prime Video directly on their amazon.* retail website instead.

Thanks, I had no idea!

I felt the same way with Amazon. Before then it was easy to navigate and finding the product that I want to buy. Now, I couldn't navigate it well like I did in the past. And asian-sounding names products took over first few pages of result which made it difficult to filter out. And they are crap quality products. It is easily to tell which products is made in. Hint the brand name is all capitalized.

Really? Criticizing Google's frontends but praising GitHub and Amazon? If I had to pick a large tech company with a bad frontend Amazon would be top of the list. GitHub is not great either. I guess this kind of thing is just subjective though.

Github's site is really fast. Many of the pages it displays are dense with information and I think it displays everything well, for example viewing diffs in Github is very good, it smartly wraps all the text so you can view everything on the screen and everything loads fast. Try comparing it to Bitbucket's diff view, which can't wrap text amongst other things. It's light years better in comparison. It looks good at any window width with little wasted whitespace.

Amazon's site works pretty well. Their product range is quite a mess to navigate but I've never been annoyed much by their front end. It seems pretty well engineered, eg. [1]

[1] https://bjk5.com/post/44698559168/breaking-down-amazons-mega...

On the whole GitHub's UI is good, though I still find it unreasonably difficult/slow to do a review commit by commit compared to kiln.

I'd really like it if they added a way to thumb between commits in one click without page loads, kinda like flipping through pages of a book

What do you find lacking about GitHub's frontend?

For one, they're using some sort of link / browser history hijacking (something like https://github.com/turbolinks/turbolinks, IIRC) which is buggy, for example:

* say you're on page A

* navigate to page B

* navigate to page C

* click your browser's back button, hoping to be back at page B

* the github UI screws up and keeps you on the same page while changing the URL in the address bar

* so you click back again

* now your on page A, completely skipping page B

* clicking forward takes you back to C

Additionally, GitHub is insanely slow. This page, for example, takes 3 seconds to load: https://github.com/Boemska/create-sas-app/commit/85224fe6622...

Couple broken history back/forward navigation with long page load times and GitHub is easily one of the most frustrating web sites to use.

Don't get me wrong, I'm not arguing that GitHub doesn't have value -- it most certainly does -- but that doesn't excuse bugginess and absurdly long page load times. If they fixed these problems it would be 100% awesome.

The page switch fuckery I'm noticing is not quite as severe as what you described, but still annoying:

* say you're on page A, an open pull request

* merge the pull request

* switch to a different site entirely

* go back to github's page A

* notice how it shows the pull request as if it wasn't merged yet

* refresh the page and see the status switch to merged

I'm using Firefox and I've never tried reproducing this on Chromium.

For me this page render instantly. i5 2500K, 16 GB RAM on Linux (I do have some aggressive tweaks).

Back and forward work great on GitHub. My mouse has additional buttons for these.

> For me this page render instantly. i5 2500K, 16 GB RAM on Linux (I do have some aggressive tweaks).

My machine: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz, 128 GB RAM on Ubuntu Linux 20.04.

> My mouse has additional buttons for these.

Similar. As a sibling post mentions, the history hijacking does some nasty stuff -- unless you're lucky or something, I guess.

What browser are you on? The navigation issues don't happen for me on Chrome.

The latest Chrome. This has been a problem I've experience for years.

github is great, both web and mobile (especially mobile). and their new homepage is great too.

target's item pages are really good right now. I love the information density and layout on their site, which to me is suggestive of thoughtful human-oriented design rather than amazon's (highly effective) a/b test shit shoveling.

amazon has "ship-it" UI standards and a lot of variance in page section order (could be a/b testing, or just discrete developer teams).

they have lots of really interesting ideas scattered around for how they can reach customers with unique contextual information, but I have a hard time with how dynamic the layout is and they also don't know how to make good hero pages. too many over-compressed image banners and image tables.

amazon and github both have crappy search which is kind of interesting to me. amazon sort basically doesn't work either, for price or for rating. not sure why.

/ecommerce rant lol

I personally love Airtable’s frontend. That’d be a project I’d love to work on.

> Which large companies aren't bad at web frontend? UX seems to always be far down on the list or priorities for modern websites.

which web frontend is good ? (except HN)

Youtube UI/UX is horrible, try moving items in a long playlist, it takes forever to drag scrolling. Imagine a search engine company that doesn't have a quick search inside a playlist. And you need browser extensions like Youtube HD to fix several issues. It has been this way for years.

The elimination of dedicated playlist pages also sucks for resuming progress in the middle of a playlist

This is something that really concerns me about the new M1 based Macbooks. We as developers in the first world are very likely to be the first ones getting these, and this will make the gap with the average end user which usually does not have a mac a lot worse.

I'm not far from imagining a non so distant distopic future where everyone just gets used to slow, laggy, clunky websites and applications. Oh... wait...

As a developer you should 1) have the fastest possible code / test cycle - i.e. it's worth overpaying for faster machines 2) treat performance as a feature and formally measure it across configurations

I've worked for many companies, small and large, corporate and startups. None of them had performance as a priority, or even considered at the product level. Any minimal performance optimization or win we had was because a developer cared enough for it.... but maybe I'm the only one and just had bad luck with the product managers/owners I had.

Amazon retail website ruthlessly optimized for latency as they discovered the slower it is, the more likely customers are to abandon their carts.

The only companies I have worked for that really cared for performance were betting companies, because speed is money in that sector (esp. in live betting).

In my experience performance became a secondary (not primary!) priority once big customers began to threaten to not renew their contracts

I have seen the same basic cycle, management says don't focus on perf, just "knock out" (I despise this lingo) the features. They have this overconfidence, but flop on the next release and patronize the dev team about perf.

1) tracked from the beginning so it is drained from the system merge by merge

2) architected in at the design level and not applied as a spell.

I really like what the rust team is doing with tracking rustc compilation times. Another reason that integration tests are the best tests.

https://perf.rust-lang.org/status.html

We definitely promote performance as a primary (and a half) concern. Mainly because the alternative is throwing more money at servers and/or dealing with disgruntled customers. I wish we dedicated more resources to it but we also don't ignore it.

Oh! yes... certainly that was mi experience too. I was referring to frontend... where you won't pay for the performance, but your users will (by having to upgrade their compures and/or just suffering it)

And their material UI is ugly.

That idea is very common, and very silly.

Who says that if they experienced the software the same as a normal user, they would automatically improve its performance?

This may apply for parts of open source development, where developers work on stuff for their own use. But even they may have other priorities.

And as a commercial developer, your backlog is constantly full. You may have some leeway to choose what you work on, but there is absolutely no guarantee it will be performance, just because you personally experience bad performance.

The way to get performance improvements is to make it a business priority to measure and improve performance.

And for that, it is absolutely not necessary for developers to be slower in everything they do, just so they can experience their software's performance "realistically".

I’m unsure why the original idea seems silly, when it simply states a possible reason for this problem today. Giving a developer observability is the first step, that’s what they are pointing out —- some ways developers interface with features don’t include information that could deliver a higher value feature. A company can choose whether to deliver that higher quality or not with that information, ignorance removes that choice.

If a company has that information and doesn’t care, that’s one thing. There’s more than a handful of companies that just don’t have the information to even know if they should care.

I think most people would agree that we should use tooling to make it so that developers are aware of their blind spots, such as supporting systems with lower resources or a more inconsistent network. The Netflix blog had a nice post that included a tool they used to observe the UX under certain failure cases, which is a nice example of this [0].

[0] https://netflixtechblog.com/keeping-netflix-reliable-using-p...

I use this UI all day, every day on a Ryzen 3900 with 12 cores, 24 threads, 32GB RAM, 300Mbps connection. It's always extremely slow, takes up obscene amounts of CPU and RAM. It's mind-boggling how they think, "this is ok".

The move to, "let's show them a pretty G spinner to compensate, because research shows that'll make them think it's fast" irks me to no end.

Here's a couple of tabs, one is a dashboard taking up 1.5GB RAM, the other is a k8s deployment page, taking up 1GB. It seems any tab takes up a ton of RAM. CPU also locks up completely in those tabs routinely. The chance that occurs correlates with how long a tab is open.

https://imgur.com/a/i9L45ZM

This happens with web design a lot. I have a great monitor with a 1080p budget monitor on the side. It makes a huge difference when thinking about shadows, UI changes, etc which are almost invisible on the 1080p sometimes. I test my sites on both.

I agree. I have a second, crummy old laptop for just this reason. I can't quite bring myself to develop on an underpowered machine, but it is useful to have one as a reference. Also, my phone is old because I'm a cheapskate, so that helps tremendously with assessing mobile performance.

>> I agree. I have a second, crummy old laptop for just this reason.

Learned this the hard way. Made an editor, everyone loved it. Added features, people loved it. Kept adding features...then it was called slow, bloated etc.

Everything seemed fine on my new-at-the-time iMac.

Went into a conference room where we had one of the first Intel MacBook Pros...there were portions of the editor where you could literally see things being redrawn. A night of optimizations later, performance was restored.

> I would not be surprised if a lot of these problems could be traced back to developers having above-average network connections and super beefy computers

More realistically, they're serving up the assets from a web server on their machine. Which means that network I/O time is effectively nil.

I suspect there's something in that comment on above-average network connections - the people working on Google Cloud's UI are going to be doing so from Google networks, or over a Google VPN, which means they'll be seeing much lower latency to your average person who has to be bounced around their ISP network and then across a couple of peering providers before getting there.

There can be some more nuance to this. The devs can often see the problems, but know more optimization is needed. They've done everything to implement what a PM asked.

When the PM views it with ideal network conditions they assume it's more than ready. At this point their focus is on shipping sooner so the next thing can be worked on. The devs can never talk them back. Users then complain on Twitter about the crappy perf.

This is a process and cultural failure too. The perf can be quantified and tracked to some extent. Even proxy metrics like the growth of assets over time can help.

Cultural events like poor handling of weekly demo days can create undue pressure on shipping poor implementations. Someone implements a great idea badly, it catches management attention (or helps the sales team), and next Monday it gets released. Over time this behavior can hurt customers and it always frustrates internal efforts to do the right things for perf.

Throughout 2020, this hasn't actually been true.

This stuff is dead slow even on a fast machine with fast connections.

The problem isn't people don't know. The problem is the software is drowning in layers of complexity and abstraction, and it's all in JavaScript not an optimized native language.

My company fixed this by making us use under dimensioned VMs for development. Unfortunately it has not fixed the issue.

> above-average network connections and super beefy computers

Googlers have been WFH since March on laptops and residential Internet & WiFi.

Thats so true, devs also should try out a 5 year old phone and a slower ISP.

Reply on news.ycombinator.com