There are times when collaboration is useful.

But nothing distinguishes a junior and a senior more than the ability to work independently.

If anything, I'm collaborating more as a senior than I did as a junior. Junior dev work often means getting a work assignment and working on that by yourself. Senior dev work often means getting together with different stakeholders to work on a design.

(Although obviously those statements aren't absolutes, hence the use of the word "often".)

And as a senior your quite often working with several external teams and having some meetings FTF produces a massive productivity boost

We are talking Months and Months" by stopping other teams going of at a tangent or flat out just not doing what they are told.

at my company the seniors are mainly responsible for driving projects/design and leading teams of juniors who do the implementation. working independently is not really an option

This is a very old model, and it's as dumb today as it was in the 1990s.

The seniors used to be called "architects," and the "driving projects/design" used to be called RUP.

architect is a higher level, they tell us why our designs are bad

LOL. I feel for you. It's the same way in a lot of places.

Your seniors should definitely be thought leaders, but when they get "too senior" or "too important" to write code, the company is done innovating. That's a major organizational smell.

why is that? isnt the main innovation done in design? anyone can code something up that has been designed for them already

If your design is so detailed that any code monkey can implement it without screwing it up, then you've probably spent more time writing design documents than you would have spent just building it.

And if your code isn't expressive enough that the design can be extracted without major effort, then the two will inevitably diverge at some point. Many bugs will appear.

If you're really working totally independently, then you're running a 1-person company. As soon as you get two "seniors" on the same project, if they're working independently, then you're just going to two different, unrelated outputs, by your definition.

Isn't this why microservices are a thing? :).

More seriously though, it's part of skilled project management to organize work in such a way that seniors don't need to constantly collaborate to stay in sync.

What one programmer can do in one month, two programmers can do in two months.

It's skilled software architecture. Some layerings of the problem into decomposable pieces allow for less communications and some layerings of the problem require more communication. The emergent but desirable property of more parallelizable is dependent on details that are small and subtle. Project management cannot possible guarantee this. The outcome of the architecture, how much do people need to communicate, is an input to the project management.

Your “skilled project management” is my “unnecessarily complex process.” There’s a reason collaboration of this sort is used in real engineering disciplines: it’s because it’s more efficient than having some middleman (and/or process) mediating all the communication.

I didn't mean middleman/process mediating communication. By "skilled project management", I meant structuring tasks and setting priorities in such a way as to minimize the required amount of communication - particularly, synchronous communication between the workers. An hour (on average) or two per day replying to messages and doing code review, an occasional meeting every other week - sure. But if your senior devs are spending most of their time each day in meetings, then either you're running a bootcamp, or something is very wrong.

We are not microservices. People in a team have a lot in common, they do systematically the same type of work albeit in a different context and they can be a lot more useful to each other when they communicate seamlessly instead of at scheduled time slots.