Welcome to the intrinsic problems with team dynamics.
The problem is indeed one that Brooks described. When we go from one person to two, we have 2 sets of hands that work, but we have a line of communication that is needed. When we go from 2 to 3 we have 3 sets of hands, but 3 lines of communication. When we go from 3 to 4 we have 4 sets of hands but 6 lines of communication. And so on. The number of lines of communication grows quadratically, the amount of energy to do work linearly, and at some point you reach a point of diminishing returns. Your team is probably about at that point.
In fact there is empirical data on this subject. In Steve McConnell's Software Estimation he has a chart, I forget on which page, correlating team size to calendar months to complete a project of around 50k lines of code. It has an interesting shape. As you add people, the number of calendar months drops, but the efficiency per person does as well until you reach a minimum at groups of 5-8 people. Then calendar months RISE as teams get larger, then start to decline. Only when you get to around 20 people does the calendar months for a 50k line project reach what it was for a 5-8 person team. (There probably is less functionality because a 20 person project is going to have more wheel reinvention.) But after that it continues to drop. So your team is right about that size where diminishing returns make growing the team useless.
So what can be done to improve productivity, either for a team or a personal level? The answer is to eliminate the needs for lines of communication. There are two basic strategies for this. One is to divide up the work such that people are in small teams that need to communicate with each other a lot, but not so much with others. (Common trap, management declares that it has so divided the teams, but it isn't really divided. If X winds up having to talk to Y then that is communication overhead, no matter what the org chart says.) The other strategy is to move towards having a process that guarantees that there is documentation of everything that needs it. So that instead of people directly talking, people consult documentation.
Of the two strategies, the first is by far more efficient, and is far more fun for programmers. However the second produces results that are far more predictable, repeatable, and appeals to management. (In theory it also can scale to faster overall development times. In practice, of course, a small team of very good people can beat a large team of average ones. In theory a large team of very good people should be better still, but finding a small team of very good people is already hard, finding a large team like that is hopeless.)
As a programmer, you should follow a mix of the two strategies. First seek opportunities to work in the parts of the project that you already know well. This reduces how much you need to ask questions. Also when people have to ask questions about stuff that you did, think hard about how you could have prevented them from having to ask, or have made sure that if they did ask, they needed to take less of your time figuring it out.
And a final note that is tangential to everything else. In one of McConnell's books (I forget which one) he recommends keeping track of bugs by component. IBM found that a very large fraction of their bugs would be confined to a very small fraction of their components. Then they rewrote those components from scratch. By rewriting under 5% of their application, they managed to reduce bug counts something like 50%. (And that 5% turned out to be easier to rewrite than people expected.) You're unlikely to be in a position to get your organization to do this. But keep track, and see if you can figure out the most intense ball of mud in your application. You probably don't need to keep track - it is that bit that everyone dreads that keeps breaking. If you can get your organization to rewrite just that piece, it probably is not as hard as everyone dreads, and people's lives will get better. Including yours.