Then I always have a side project I'm playing with for new ideas. Sometimes these get integrated into Big Project and sometimes they go nowhere.
After getting comfortable in my new team, I started to push for having each big project have at least one person whose job it is to think about the fundamentals for their respective projects.
This has really improved our engineering discipline. The more senior engineers each own a big project and the younger engineers get to rotate through the projects and see what they do and don't like working on so that they can decide to specialize.
That being said, I only encountered this at companies with smaller IT headcount. In corporations it's a little different, as project structures are much more rigid and transferring people takes time, so programmers usually don't jump between assignments that much.
Your second paragraph seems accurate. My friends are ex co-workers that moved on to much larger companies.
I'm peripherally involved in all of them (in a project and product management capacity and for code review), but work directly on programming, architecture, and design for 3-4. I only contribute code on one or two at any given time.
Most of our individual contributors are generally only working directly on one significant project at once, two tops if one is in acceptance testing, and maybe planning for a third; plus maintenance as it comes up.
If they have more than that, there's a clear order of priorities such that we expect them to finish one thing before turning their attention to the next.
But the "plus maintenance as it comes up" part can mean someone can have easily two dozen open tickets assigned to them. Again, we have prioritization rules of thumb. We expect one ticket to be at least deployed to an acceptance testing environment before picking up the next - unless we get something else that comes in as higher priority. Fixing a ticket rejected from acceptance testing takes higher priority than starting on a new one with the same nominal priority in our issue tracker.
If you're working on a larger project, you're only supposed to interrupt it for tickets above a certain priority or to fix acceptance testing bug reports on your last project. Then each engineer takes a 1-2 week break between projects to clear the project board a bit.
The result is that an engineer can easily end up working on a dozen different maintenance tickets in the space of a particularly bad week (we have a legacy codebase with little automated test coverage, and certain deploys result in awful cascades of bug reports). And one can easily have a very full backlog of assigned tickets. But no one has more than one active, one in-testing, and one in-planning project large enough to really consider a project.
In an average week I might touch anywhere between 1 and 20 projects, albeit only minimally.
Most developers at my work belong to one project, but there are some central teams that serve the entire studio and work between projects.
I would say I am currently leading three projects, one I am the solo developer, the other two is mainly architecture and code review.
I am also involved in the monitoring/installation/maintance of an elasticsearch cluster and a rabbitmq server.
