It's not a nitpick. There are some industries and jobs where employees truly are fungible. There's never going to be a security guard or Starbucks barista or janitor who does such an amazing job that they're able to negotiate significantly higher wages than their peers because of how much value they deliver. "Software developer" is not that kind of job, at least not right now.

> my overall point does not change that tech unions will depress wages for high earners.

And this goes back to the original point which is that unions only depress wages for high earners if the unions negotiate terms which depress wages for high earners. As has been pointed out in the thread there are many existing examples of unions for collections of high-earning employees.

Because I gave examples of unions which contain and are beneficial to high wage earners, and you dismissed them as irrelevant because tech employees are "fungible" except for the ones who aren't. Except those unions also contain far more "fungible" employees (background actors, backups, practice squad players) than they do star actors and quarterbacks, so it's a close comparison. There's currently 2,314 members of the NFL Players' Association but only 32 starting NFL quarterbacks.

Fungible means all employees are the same, that's the exact definition of fungibility. If certain employees have a measurably different impact on delivery, that is the definition of non-fungible. Just because most employees deliver near-average performance does not change this--it's tautologically expected!

??? This doesn't make any sense. There's a hell of a lot more background actors, which you can call fungible, than there are Tom Cruises, but they're all covered by SAG-AFTRA. "Tech workers are fungible except for the ones that aren't" is tautological and doesn't support your argument.

"Shitty" companies have legal obligations to include these kind of clauses though, because investors and board members don't want to deal with a situation where there's exactly this ambiguity about what counts as "obviously not-related software". HR exists to protect the company. What counts as obviously non-related to you may not count as obviously non-related to a board member who hears about the new optimization algorithm you wrote and realizes the company can monetize it.

> On the contrary, using a nonzero amount of working hours to work on something pretty clearly makes it company property.

How recently have you seen a tech employment contract where you were obligated to work exactly 8 to 5 with a 1 hour lunch break? Flexible hours means any hour is potentially a "working hour".

Strongly disagree with this, and I'm in 'tech management' now so I'm not saying this out of self-preservation.

Tech workers are similar to athletes in skill disparity IMO. A handful of superstars makes a massive difference. Look at those superstar AI developers who are allegedly getting 8 or 9 figure compensation from Meta etc. They're still technically "just" tech workers.

High earners benefit from unions if union rules are made which benefit high earners.

The most well-known example of a high-earner union is SAG-AFTRA and they provide benefits to established performers, the big one being name exclusivity. e.g. even if your real life birth certificate says your name is "Tom Cruise" you cannot advertise your name as "Tom Cruise". Obviously, actors are still negotiating their own pay.

Another good one is the NFL Players Association which capped the rookie pay scale in 2011 to ensure the salary cap was going more toward veterans, people already in the union. However they still independently negotiate their compensation.

I don't know what people would want out of a tech union specifically but the idea that "union = payscale based on seniority" just plain isn't true.

The problem is there's no clear legal definition of what "logistics software" is. A video editor is a seemingly obvious example of what is not, but what if you came up with a novel optimization technique which is not necessarily only applicable to logistics? Could you spin off that software into a separate business? What about something more fundamental, like tooling? Think about something like Slack, which was just meant to be an internal messaging tool created as part of the development of a video game. Imagine after Slack took off, that an employee claimed that because they had written Slack at least partly outside of working hours and it was not "video game software", the company didn't have ownership of the software.

This is why the common approach is that the company owns everything except anything explicitly carved out, it avoids ambiguities like this.

The tricky part is that sometimes "a new thing" is really "four new things" disguised as one. A database table is a great example because it's a failure mode I've seen many times. A developer has to do it once and they have to add what they perceive as the same thing four times: the database table itself, the internal DB->code translation e.g. ORM mapping, the API definition, and maybe a CRUD UI widget. The developer thinks, "oh, this isn't DRY" and looks to tools like Alembic and PostGREST or Postgraphile to handle this end-to-end; now you only need to write to one place when adding a database table, great!

It works great at first, then more complex requirements come down: the database gets some virtual generated columns which shouldn't be exposed in code, the API shouldn't return certain fields, the UI needs to work off denormalized views. Suddenly what appeared to be the same thing four times is now four different things, except there's a framework in place which treats these four things as one, and the challenge is now decoupling them.

Thankfully most good modern frameworks have escape valves for when your requirements get more complicated, but a lot of older ones[0] really locked you in and it became a nightmare to deal with.

[0] really old versions of Entity Framework being the best/worst example.

> The consumption of AI-generated music on the platform is still very low, at 1-3% of total streams, and 85% of these streams are detected as fraudulent and demonetized by the company.

Even pre-AI, music has always been a winners-take-most business. Per an article from 2022, the vast majority of artists have fewer than 50 monthly listeners[0], which I suspect is far lower now due to the flood of AI.

Not sure about Deezer, but for Spotify there is some kind of minimum to get you into any algorithmic rotation. People try to game this with bots, i.e. botted streams, but the problem with bots is that the accounts are bots, so the recommendations just become music for other bots, hence the part where 85% of the streams are botted. So it doesn't actually work, and you have to rely on old-fashioned promotion to get into any algorithmic playlists.

So 44% of uploads being AI-generated sounds bad, but it's extremely unlikely anyone will ever encounter them naturally, the same way that people don't naturally discover random, non-AI artists with 10 monthly listeners and tracks with less than 1000 plays. This isn't a defense of AI music slop, by the way; it's more pointing out that the "making a song" part only takes you about 20% of the way to becoming an artist people want to listen to. A harsh lesson our friends in /r/SunoAI are learning.

[0] https://www.musicbusinessworldwide.com/over-75-of-artists-on...

If I'm building out an internal tool for, say, a hospital lawyer to search through malpractice lawsuits, I want my tool to be the most familiar, obvious, least-surprising UI/UX possible. Just stay out of the way and do what it's supposed to do.

The trick is, of course, that the human is still responsible for knowing when homogenous is fine, or when there's real value in the presentation. If you're making a website for, say, a VST plugin for musicians, your site may need to have a little more "pizzazz" to make your product more attractive to the target audience.

Replicating the basic functionality for most SaaS is trivial, it's the "everything else" part that you're actually paying for.

This is a really funny comment to make when the entire Western economy is propped up by computers doing multiplication of extremely large matrices, which is probably the single most obvious CompSci 101 example of when the placement of data in memory is really, really important.

The most obvious way you can tell this is inorganic is how all of the "Discovered On" are artist-specific playlists: "Eddie Dalton music", "Best of Eddie Dalton", "Eddie Dalton Hits", etc. A real artist may have some artist-specific playlists but generally their Discovered On will be more general genre playlists, like "Pop Hits" or "Hype" or "Gym Music" or whatever.

And how do you think their assistant will interact with external systems? If I tell my AI assistant "pay my rent" or "book my flight" do you think it's going to ephemerally vibe code something on the banks' and airlines' servers to make this happen?

You're only thinking of the tip of the iceberg which is the last mile of client-facing software. 90%+ of software development is the rest of the iceberg, unseen beneath the surface.

I agree there will be more of this but again, that does not preclude the existence of more of the big backend systems existing.

I agree that there will be more small, single-use utilities, but you seem to believe that this will decrease the number or importance of traditional long-lived codebases, which doesn't make sense. The fact that Jane Q. Notadeveloper can vibe code an app for tracking household chores is great, but it does not change the fact that she needs to use her operating system (a massive codebase) to open Google Chrome (a massive codebase) and go to her bank's website (a massive codebase) to transfer money to her landlord for rent (a process which involves many massive software systems interacting with each other, hopefully none of which are vibe coded).

The average YouTuber not caring about the aperture of their lens is an apt comparison: the median YouTube video has 35 views[0]. These people likely do not care about their camera or audio setup, it's true. The question is, how is that relevant to the actual professional YouTubers, MrBeast et al, who actually do care about their AV setup?

[0] https://www.intotheminds.com/blog/en/research-youtube-stats/

Strongly disagree with this thesis, and in fact I'd go completely the opposite: code quality is more important than ever thanks to AI.

LLM-assisted coding is most successful in codebases with attributes strongly associated with high code quality: predictable patterns, well-named variables, use of a type system, no global mutable state, very low mutability in general, etc.

I'm using AI on a pretty shitty legacy area of a Python codebase right now (like, literally right now, Claude is running while I type this) and it's struggling for the same reason a human would struggle. What are the columns in this DataFrame? Who knows, because the dataframe is getting mutated depending on the function calls! Oh yeah and someone thought they could be "clever" and assemble function names via strings and dynamically call them to save a few lines of code, awesome! An LLM is going to struggle deciphering this disasterpiece, same as anyone.

Meanwhile for newer areas of the code with strict typing and a sensible architecture, Claude will usually just one-shot whatever I ask.

edit: I see most replies are saying basically the same thing here, which is an indicator.

It's not inherently bad in the same way that a first draft of a novel is not inherently bad.

But if someone asked me to read their novel and it was a first draft that they themselves had clearly not bothered reading or editing, I'd tell them to fuck off.