Three dots next to the song title, menu opens, "Add to Queue", done.

I click three dots, add to queue is at the bottom of the list, need to scroll, then click add to queue.

Why do I have to do so many actions when adding an item (say a podcast) to my current playlist? Why can't there be a single button that says "add to queue," why hide an common workflow behind nested menus and actions?

Wouldn't adding songs to your current queue be an extremely common action by users? Or at least power users?

I think I might become one of those people that makes their own frontend music player for Jellyfin. Adding and modifying playlists are something I do often (wrote like 100s of collages on what.cd back in the day), but with Spotify these actions are so fucking painful.

Fair point, for me there is no scrolling required though, its like nr 3 in the list.

I wonder how long it will take for AI to learn how we work with software on an individual level and adapt the UI to fit our usage patterns.

"the spotify subreddit is actively removing discussion of the problem"

This sounds like terribly bad form, won't buy them any goodwill down the line.

> This subreddit is mainly for sharing Spotify playlists. We're not a support community, and we encourage users to use official support channels for most issues.

Literally the first line of the sub description.

yes, the correct sub for this is r/truespotify, and there are a dozen discussions on the problem.

Fair enough! Can't argue with that

More thing for Spotify is that their users are, more or less, locked in. That stickyness is what allows companies to try this dumb shit; management will hardly feel the impact of their bad choices - cause they are standing on many years of foundations.

It's like when Homer Simpson was carried up the mountain by Sherpas and thought he owned the achievement.

I switched last year and discovered I wasn’t as locked in as I thought.

SongShift moves your library from one app to another super easily. In 20 minutes my whole collection, playlists and all, moved from Spotify to Apple. And it was free.

I encourage everyone who is dreading moving to a better app to try it… it’s pretty easy now.

I’m tempted to try Tidal myself because Apple Music’s recommendations aren’t that great.

How so?

Spotify can be switched for YT Music, or Apple Music, or Deezer without any issues.

You can also just buy albums on Qobuz instead.

You can, ultimately, resort to one of the best things the internet offered since its inception - piracy.

If anything, Spotify is one of the easiest services to replace. And I say this as a paying customer.

I tried tidal for the Lossless (dont care about the 24bit, i care about no EQ and compression added to music) but i went back to spotify for their recommendation model. Its a moat for me.

I don't think lossless gives you anything other than, well, lossless compression. EQ or dynamic range compression don't really have anything to do with it.

I get that it looks bad to have vibe coding bugs creeping into your codebase for such a big company, but isn't it common sense that owning your misstakes taking accountability for them generates respect?

Cursor, Sourcegraph Cody, and honestly just Claude with a well-maintained project README already solve the "ask questions about the codebase" part reasonably well. The actual hard part of joining a new team isn't the code (today, any longer). It's getting to know the people. Understanding their strengths, figuring out where you fit in, getting past imposter syndrome, not stepping on toes. No AI for that yet.

My take after running engineering teams at multiple companies: documentation survives when it lives next to the code. File-level header comments explaining each component's purpose and role in the architecture. A good README tying it all together. If you compartmentalize architecture into folders, a README per folder. This works for humans, LLMs, and GitHub search alike.

ADRs, Notion docs, and Confluence pages die because they're separate from the code. Out of sight, out of mind.

If you want to be really disciplined about it, set up an LLM-as-judge git hook that runs on each PR. It checks whether code changes are consistent with the existing documentation and blocks the merge if docs need updating. That way the enforcement is automated and you only need a little human discipline, not a lot.

There's no way to avoid some discipline though. But the less friction you add, the more likely it sticks.

The git hook idea for enforcing doc updates is really interesting has that actually worked long term for your team or does it eventually get bypassed?

Check back in 2 years time, for now it has survived fine. Someone will be tuning it to write the documentation soon, instead of just blocking!

Jokes aside, i think LLMs will enable us to handle information in a much better and smoother way. We should use them!

> documentation survives when it lives next to the code. 15+ years ago, this was pretty much the standard. Every decision - whether major or just a hack to handle a corner-case - used to be recorded in the code itself. Then tools like Jira and Confluence came in and these things moved to undiscoverable nooks and corners of the organization. AI search tools like Glean and Rovo have improved the discoverability, though I'd still prefer things to remain in the code.

Agree!

I've been a CTO and founder several times. The bottleneck was never "getting the work done." It was always translating between the business reality (runway, revenue, growth, what customers actually want to pay for) and what the team needs to hear to build the right thing. That translation layer is hard, time consuming, and easy to get wrong.

I know plenty of founders who are great engineers, product thinkers, and salespeople. They still hire people to manage teams because there are not enough hours in the day to do it all themselves, even if they could.

If you're the person who understands the business, understands the customer, and can turn that into clear direction for the people building the product, whether those are humans or AI agents, you will be hard to replace. That's not project management as "status updates and Jira grooming." That's a fundamentally different and more valuable skill.

I worked on lab automation and scientific software early in my career. One piece of advice: keep it ruthlessly simple. In most software a bug is a bad UX. In scientific software a bug can mean contaminated samples or months of invalidated research. Every unnecessary abstraction is another place for something to go wrong silently.

I was part of building the streaming frontend for one of Sweden's largest broadcasters in Rails about 10 years ago. Handled 1M+ concurrent users on Heroku with horizontal scaling. Fun fact: someone on the team literally stayed up monitoring traffic during big live events. It worked. Rails was a great fit for that especially at the time.

I moved on, not because Rails failed me, but because the things I started building next (Streaming infra, APIs behind proxies, lots of concurrent HTTP work, infrastructure tooling, AI/ML) just fit better in other languages. I pick tools by the problem, not loyalty.

What I notice in this thread is a lot of "Rails vs X" framing when the real answer is boring: use Rails (if you like the vision and Ruby) when the complexity is in the data model and business logic. Use something else when it's in concurrency or infrastructure. The one-person-framework pitch is real, but it's for a specific shape of problem.

Also: God i miss writing Ruby, its a fantastically and beautiful language.

Also: Blast from the past: Ruby is a great DSL for Rails.

> I pick tools by the problem, not loyalty.

Good advice that I keep trying to adopt myself, but I have to confess a large personal bias for languages that I like, even if it keeps me from certain classes of problem (I like Ruby, though).

What did you move onto for those next things you started building?

I know that feeling. Just because a tool is good doesn't mean you enjoy using it. I moved deeper into streaming infra with Python, C/C++, Go, and funnily enough Elixir. Then a complete path change into fintech and later AI/ML, which meant a lot of JavaScript/TypeScript and reluctant Python. I appreciate the Python ecosystem but find the language itself ugly to read and write. Always a last resort for me. Today it's mostly TypeScript, Go, and Lua.

Ha, I can relate WRT Python. I've been doing more Elixir these days for both a really pleasant web experience and because it has some unique primitives baked into the ecosystem that most JVM projects I work on spend a lot of time approximating through grotesque frameworks.

Ha, same. I wrote a VOD transcoding orchestrator in Elixir that triggered libav transcodes and custom packaging code in Python. Loved the syntax, and in particular the pattern matching in function headers. It was so clean for recursive branching that I ended up favoring recursion over conditionals and loops everywhere. Whether that was overuse or just good taste is subjective. We did hit a real scaling problem with the BEAM though. Distributed Erlang uses a full mesh, every node connects to every other node. When we got close to 50 nodes the inter-node communication overhead was eating a significant chunk of our CPU. Adding more nodes started giving diminishing returns because the mesh traffic grew faster than the compute we gained. Interesting constraint that I haven't hit in any other runtime since.