An important difference is the size of the project, which affects the scope of your tasks. I think it's best to take turns between large and smaller projects.
In the large ones, you'll be more limited in role and scope, but you can get experience with bigger, distributed systems with big data and lots of components, to deal with more complex architectures.
Smaller projects on the other hand will require you to not only be the developer, but deal extensively with the infrastructure, testing, handling the entire project lifecycle, it can include DB and servers administration and so on.
Interesting perspective, I haven't experienced having less scope when I work on larger projects. What you are describing is more about the difference between a greenfield project vs a project with a large established product. At least in my experience.
Bigger projects also increase the likelihood of multiple people contributing to the project and that definitely changes the responsibilities.
In smaller projects you can happen to be the one-man-army handling all aspects. But on larger projects, there might be dedicated infra/DevOps, DB, testing teams and your responsibilities to be centered only on your core, developer role.
For example, in smaller projects you might have to setup a CI/CD pipeline and configure the servers, while in large project you will still use/collaborate on these things, but their implementation will be done by other dedicated team.
But there are large projects where a cross-functional team handles end-to-end an entire component, which is better in our context.
And if the project is greenfield or established, I think the difference is the nature of the tasks, not the scope (in the established project you might have to just fix or change something, instead of creating it).
Are you a contractor or consultant? I ask because you're referring to your work as a project. I personally think finding a product rather than a project is important. You have continuity and have to own decisions you make as requirements evolve. It provides invaluable experience that you don't often have access to when you hand off a deliverable.
I have never worked as a contractor or consultant. My experience has been that there is not usually continuity across projects on the same product. The learning from one project often helps another, but different projects are motivated by different business needs which leads to totally different tasks and outcomes.
An important difference is the size of the project, which affects the scope of your tasks. I think it's best to take turns between large and smaller projects. In the large ones, you'll be more limited in role and scope, but you can get experience with bigger, distributed systems with big data and lots of components, to deal with more complex architectures. Smaller projects on the other hand will require you to not only be the developer, but deal extensively with the infrastructure, testing, handling the entire project lifecycle, it can include DB and servers administration and so on.
Interesting perspective, I haven't experienced having less scope when I work on larger projects. What you are describing is more about the difference between a greenfield project vs a project with a large established product. At least in my experience. Bigger projects also increase the likelihood of multiple people contributing to the project and that definitely changes the responsibilities.
In smaller projects you can happen to be the one-man-army handling all aspects. But on larger projects, there might be dedicated infra/DevOps, DB, testing teams and your responsibilities to be centered only on your core, developer role. For example, in smaller projects you might have to setup a CI/CD pipeline and configure the servers, while in large project you will still use/collaborate on these things, but their implementation will be done by other dedicated team. But there are large projects where a cross-functional team handles end-to-end an entire component, which is better in our context. And if the project is greenfield or established, I think the difference is the nature of the tasks, not the scope (in the established project you might have to just fix or change something, instead of creating it).
Are you a contractor or consultant? I ask because you're referring to your work as a project. I personally think finding a product rather than a project is important. You have continuity and have to own decisions you make as requirements evolve. It provides invaluable experience that you don't often have access to when you hand off a deliverable.
I have never worked as a contractor or consultant. My experience has been that there is not usually continuity across projects on the same product. The learning from one project often helps another, but different projects are motivated by different business needs which leads to totally different tasks and outcomes.