On the other side of the spectrum, there’s me, working for a large company with around 24,000 employees. Overall, though, the experience is not entirely all that different.
There are product managers which are largely responsible for the requirements of a product or feature set. They are in tune with customer needs, doing interviews and presenting ideas, etc., as well as work devs and others to get an idea of what we want to get done and what can be done.
Often at the start of a project devs will work with them to develop specs and define DoDs (Definition of Done) so that we know what we’re doing and what it takes to know that we’re done. Devs are also involved in their own explorations making PoCs (Proof of Concept), exploring possible technologies and various approaches or implementations to see what is possible and what will work, or just see if something cool can be done that we can slip in because they had a good idea and thought it might be easy to do. Project managers largely steer the ship, but devs can have influence too.
When everything is decided, we have tasks in our issue tracking software that get assigned out to the devs for them to work on. We have 2 week sprints where they’re given a certain amount of the tasks in the larger backlog collection to complete, and teams will meet every 2 days (though some teams may meet every day or less than every 2) to cover what was accomplished and what blockers anyone ran into that’s preventing them from getting their work done.
The dev work can vary. You may be working on something brand new or be working on older, more legacy code, doing more maintaining than creating. Most of the projects are fairly large, even when they’re new. Having so many people means there’s usually a large number of people working on the same thing so even new projects can seem to get bloated quickly. And even new things can depend or rely on the old or be made of older components so you never know when you need to break out those ES5 Backbone skills.
Depending on what you’re working on, completing a task could require a lot of research. This may include research on approaches out in the wild (google) or finding out how things are already being done in the massive codebase you’re working in. Some internal documentation may exist, but it’s largely non-existent or out of date. Sometimes things can move so fast its not worth doing documentation early and then things are too far along for anyone to want to do it from scratch so it just doesn’t get done. We’re trying to be better about it but so far it hasn’t been working out :–P
Once a task is completed, it gets submitted as a PR (Pull Request). Automated systems kick in to make sure it can build correctly and doesn’t fail any of the tests, then human reviewers will read over the source code and check to make sure its good. When it is, someone from QE (Quality Engineer) will go over and make sure it actually works right and does what it should in a working stage build. Once that gets the ok, it gets submitted to the mainline branch and work on the next task begins.
Depending on the project, new releases could happen every few days, or take months. Every time you submit code it needs to be complete and in working order since it may go live. It’s ok to add incomplete code, but only if its not user-facing. For example for larger features you may submit a small part of the feature that the user never sees just to get it reviewed and checked in. You generally want to avoid having massive PRs because they’re harder to review.
Then the whole thing starts all over again.
After a few years, your product might reach its end of life and you’ll be moved on to something else,
or you may move as a result of re-org or if you simply decide you want to work on something else. The company is large enough that its not hard to move people around if they’re unhappy with what their working on now and managers are usually very understanding (though this is easier for larger teams than the smaller ones). I myself have worked on about a half-dozen projects throughout my 16-ish years at this company, though some do more than that, and others less.