Ask HN: At your 9-5 job, how many projects are you involved with?
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. 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. In a day, it's not unusual I work on issues for 2 different projects and have to troubleshoot a Tier 2 issue for a couple of other projects. Your second paragraph seems accurate. My friends are ex co-workers that moved on to much larger companies. Just one here. I prefer to keep it that way. There have been times where I had to juggle more than one project at a time and I hated it. 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. 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. 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. 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. That's part of my frustration at my current job. Being having to work on different projects allows things like reliability and performance issues to get ignored. Agreed. When I joined this team we used to hop around a lot on projects. I came from a low level team in a much bigger division and so I'd spent the first 4 years of my career focusing heavily on fundamentals. 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. I'm a system administrator, rather than a developer, and as such I touch a lot of infrastructure and in-house tooling. 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. 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. 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. 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. How many developers in each project? Usually 2-4 on a project, depending. 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) I am an iOS developer at a small company which main product is only one app. One app = one project? Im involved in 5 but I mostly contribute just to 2.
(Other 3 need some work just once in few months) about 3 projects with deep involvement, and ~5-6 others with more shallow involvement. I currently jump between 3 clients. All of them have more than one project. Programming projects? One at a time.