lowenbjer

Fair enough! Can't argue with that

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.

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.

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?

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

"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.

Agree!

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!

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.

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.

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.

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.

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.