Hopefully I can ask this in a way that makes sense. At your main place of employment, how many different projects are you involved with at a given time? I'm a Ruby developer at a small company. In the past month or so, I've probably worked on 4 or 5 different projects, either to fix a bug or to implement a new feature. I want to know if this is normal at most places or not. It seems like most of my friends either work on one single project at a time or they move from project to project, but really only work on a single project at any given time.
Depends on how you define "at any given time". If it's measured in the
intervals of day (two different projects touched the same day), then I rarely
do more than two of them (one being the main focus and the other being an
emergency, if any). If it is months, then I haven't switched for a long time,
but four or five is not an unusual thing.<p>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.
I lead a team that currently has 9, soon to be 10 people (if you include designers) with about 15 projects at various stages of progress at the moment.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
One big project that includes a lot of smaller projects like: reliability, performance, deployment, new features. It's a platform so lots of room to pivot around.<p>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.
I'm a system administrator, rather than a developer, and as such I touch a lot of infrastructure and in-house tooling.<p>In an average week I might touch anywhere between 1 and 20 projects, albeit only minimally.
I am assigned to one project at a time. Sometimes other projects can "borrow" me temporarily when they need help, and relevant people communicate and share knowledge between projects, or for example integrate changes back up to the engine if they would be useful for other projects.<p>Most developers at my work belong to one project, but there are some central teams that serve the entire studio and work between projects.
It's hard to measure.<p>I would say I am currently leading three projects, one I am the solo developer, the other two is mainly architecture and code review.<p>I am also involved in the monitoring/installation/maintance of an elasticsearch cluster and a rabbitmq server.
I run my own startup, and there's a total of 51 repos (that's repos for projects written by me - not counting forks) I touch about 20 of them a month, but only 4 of them I would consider "large" projects (>50k loc).
I (together with my team) maintain 4 main services. On top of that, I'm one of the main contributors to one cross-company project, and help out with my old team's projects every once in a while.
I'm a Program Manager, currently manage 16-20 projects at any given time. My developers work 3-5 depending on the nature. I'm usually fighting management to keep them on the lower end of that.
As someone in more of a systems architect role, directly this week I touched 2. Indirectly I dealt with another 2-3 (more along the lines of consultation)