Hacker News Reader

> I am wondering, what they are even working on

Without any inside knowledge, but having been part of many mega-projects like this I'm willing to take a stab at it: new features vs. QoL is a huge, huge tension that exists in projects like these.

New features get new customers, and more importantly gets execs excited and people promoted. Refactors, performance improvements, etc, are almost never appropriately rewarded or prioritized, so QoL problems tend to accumulate until a crisis moment, where the organization is forced to shift priorities to address a user experience that has badly degraded to the point of significant customer revolt.

I saw this with a front-row seat with Google Maps: features kept getting piled in to the app (did you want to know what the most popular dishes at a restaurant is? Now you can!) while renderer performance continually regressed, map overlay rendering bugs accumulated, and the original "slippy map" UX degraded. At this point the mobile app is deeply unpleasant to use - it hitches regularly and has trouble hitting 60FPS even on top-flight flagship phones. The product clearly hasn't reached the "crisis" moment yet, but it is on a trajectory to.

Teams seems like it might be at (or near) the crisis moment. It's a shame that organizational dynamics prevent these sorts of issues from deteriorating to this point, but it's a pretty common feature among product teams to prioritize new feature dev while existing (and way more core) features degrade.

The Google Maps site and application are both deeply unpleasant to use if only because, when you click on a search result, the fucking map doesn't zoom in from an almost state-level view to show you where the fuck the listing is.

Yeah, that's the kind of basic QoL stuff that's really the nuts and bolts of a product, but tend to get glossed over in planning.

When working out their OKRs teams generally do not have an entire Objective for "iterate, prevent regressions, and improve upon existing core features". They instead have a litany of Objectives to add completely new things.

Performance regressions are just the tip of that iceberg (though it is most noticeable), but a component of this upkeep is keeping up with the competition on your core already-shipped stuff. IMO Apple Maps' zoom behavior, rendering behavior, overlay behavior, etc, are far superior to Google's. It wouldn't be rocket science to implement their version of these changes, but clearly it's not being prioritized.

> refactors, performance improvements, etc, are almost never appropriately rewarded or prioritized

Another variant that I've seen: actual refinements and improvements just aren't simple enough to sell to management, or to new junior devs. So they'll be all excited about switching over to the next big framework that finally makes things fast and refreshing, for the first time ever! But the migration still has some bugs that haven't been worked out and some features that haven't been ported ... and a year later things are actually worse than where we started, so repeat with the next big framework that finally makes good software possible for the first time!

This is a huge failure of management where it occurs - and one of the chief causes for it is short leadership tenure.

Places where leadership remains stable over long periods tend to do better on this front. You pay for some big architectural overhaul, but you insist that you live on the new thing long enough to actually ship features before you go into the next cycle of renewal.

But in some companies leadership tenure is short - execs stick around for 2-3 years max, which is just enough time to complete an architectural migration but not enough to ship stuff on it!

I think google maps is close to the crisis point. Where niche alternatives exist, people will use those instead. One of the reasons I bought an iphone was to have apple maps as an alternative to google maps.

> It still gaslights Firefox users and tells them their browser is not supported

I checked in to this a few weeks, and it really doesn't work for technical reasons. They use some deprecated experimental Chrome API (which is also slated for removal). Slack in general is an absolute mess in terms of engineering.

It just so happens that I had to use Teams the other day for a job interview, and at the last possible moment it notified me that Firefox doesn't work for video :-/ Had to hastily install Chromium. Didn't look in to the reasons for that.

There's Ripcord[0], which is a native app that can connect to Slack and Discord.

[0] https://cancel.fm/ripcord/

Nice, I'll go ahead and propose to my company that has everything on Azure and is a total MS whore to switch their 10000-somewhat employees over to Discord.

> However, Slack isn't that much better. It still gaslights Firefox users and tells them their browser is not supported.

Where do you see that? I exclusively use Firefox and have never seen such a message from Slack.

If you use the built in "huddle" or voice chat.

I can tell you something they are working on and its not bug fixing but more bloat: They are adding games to teams so you can play solitaire while having a call. Not sure what kind of product manager thought that is a good idea but here it is!

https://www.theverge.com/2022/6/14/23167384/microsoft-teams-...

Teams works fine, just don't use exotic laptops, even if they are machined from solid aluminium.

This seems unnecessarily toxic. Slack is an app first, not a webpage. Just install the app.

You mean the "app" that's just a Chrome instance that wraps the webpage, and sucks up GBs of RAM while doing so? No thanks.

I leave it running continuously for weeks on my Mac, with no issues. It is currently using 700MB across all of its processes (5 by my count). Doesn't seem like that big of a problem.

I understand it used to be a much larger problem. Maybe it's time to try it out again.

My problem with the app isn't resource usage, it's that a chat client that's already a webpage shouldn't need me to install a app. It's ridiculous how far slack will go on purpose to not support the platform their app is built on.

As a chat client that facilitates communication with my coworkers, I don't want to limit it to a tab in Chrome. Chrome is an app that I close often, I can't recall a time I've wanted to close Slack.

That's fair, but don't confuse your habit of quitting your Web browser for typical behavior.

I never close my browser unless I have to, but sure that might not be the normal behavior. I still don't get why they can't give an acceptable experience on the platform they built it on without wrapping it in a useless wrapper.

Keep the app, just make sure I can use your service on the platform it's built on.

That's fine but they should make it possible to use it completely in-browser as well. I'm not a fan of having five Chromium instances constantly running on my MacBook.

Almost a GB for a chat application? I definitely see a problem there..

Memory is designed to be used. I guess if I'm memory constrained I can close it, but it's never been the source of any of my day-to-day problems while coding.

Memory is designed to be used, and there are plenty of applications that are vying for it. I'd much rather an app use memory optimally, so that I don't have to close it if I'm memory-constrained.

Toxic? It aligns exactly with my personal experience today. Coworkers often try to call me using Slack, but I'm always present "Nope in Firefox" dialog.

And if you think the Slack app is anything other than a webpage, then you really need to look into that more. As someone else posted, it is a webpage wrapped in a bundled chromium package.

It's an electron app. That's not a webpage bundled with chromium, it shares a large number of components but functions quite differently. It's not surprising that your web experience sucks relative to the app.

Slack is a not an app. It's a webpage bundled with an obese browser.

Actually I don't want the app, as I don't trust Slack as an organization. Who knows what their app does on my computer or what it could do, even if it is an electron app? I prefer running things in the browser sandbox, at least limiting them somewhat.

I installed the Slack app and it was even slower than using it from Firefox. There's a noticeable delay when typing (sometimes more than other times) like you're typing over ssh, and starting the thing takes just as long as just opening it in Firefox.