Software projects from a business perspective

For more mature companies, it can be harder to find opportunities to work on greenfield projects, so you may have no choice but to work on maintenance projects. But, I don't think this is necessarily a bad thing for your career. The most important thing to consider is what kind of impact does your work have at the end of the day.

A bug may also have wide scope. There are some really obscure and gnarly bugs that can span multiple levels of the tech stack and can have extremely high impact on important business metrics.

I don't think discriminating against projects based on whether they're maintenance (also referred to as "incremental") or greenfield (also referred to as "0 to 1") is the right way to go about it. At the end of the day, there are 2 types of projects:

1. Good impact projects
2. Not good impact projects

That's it. That's what truly matters. Now here's the interesting part:

1. Maintenance projects often have incredible impact - This is very much the case at massive companies like FAANG where most of the work is incremental. Most of the work I did at Meta was incremental. In fact, there are literally L6+ engineers making well over $500,000 per year who do nothing but fix bugs all day. This Staff+ engineer archetype is called "fixer" at Meta and "solver" across the broader industry: "What does a path to staff look like in a coding-heavy environment?"
2. Many greenfield projects have terrible impact - Writing code from scratch often has lower technical complexity than maintaining existing code, because there are naturally less intricacies to consider. At Meta, I knew tons of engineers who were stagnant (i.e. stuck at the same level) because they worked on teams spinning up new apps and those apps never went anywhere (Meta in particular is horrible at creating new apps). Another downside of 0 to 1 work is that there's no metrics to measure your success. It is harder to make a case for why you deserve to get promoted vs. this other engineer who also wrote a bunch of code.

So when it comes to evaluating projects and choosing teams, you need to zoom out and use your personal intuition and product sense to figure out if that scope has real business impact for the company. And of course, make sure that the team surrounding that scope is very supportive. I have almost always found that the quality of people is far more important than the project itself. People learn the most from other people after all.

I talk about this way more in-depth in our new promotion course. Check it out here: [Course] Nail Your Promotion As A Software Engineer

The "Project Credit And Scope" section will be the most relevant to your discussion.