Software projects from a business perspective
Hello, I've seen the term "maintenance projects" (basically, projects where you do bug fixing most of the time) and green field projects (projects where you write code from scratch).
I've been told that the maintenance projects are generally the ones that you want to avoid since you won't learn much.
I didn't see this view against software projects on TARO, like to divide the projects in to these categories from a high level view and I was wondering if you guys can tell me more about this business view of the software projects.
Are there other categories besides maintenance and greenfield? How can I avoid maintenance ones or recognize them?
Discussion
(3 comments)- 017 days agoEng @ Taro
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.
- 0
17 days agoTech Lead @ Robinhood, Meta, Course HeroFixing bugs is tremendously underrated, especially identifying them. At bigger companies, there's no shortage of huge bugs hidden underneath the surface: They're effectively diamonds in the rough for your taking if you're willing to put in some extra effort.
In fact, discovering and expertly fixing a huge bug was one of my crown jewel promotion projects as I was growing from mid-level -> senior at Meta. I broke it down here: [Case Study] Solving A Multi-Million $$ Instagram Bug
- 017 days agoTech Lead @ Robinhood, Meta, Course Hero
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:
- Good impact projects
- Not good impact projects
That's it. That's what truly matters. Now here's the interesting part:
- 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?"
- 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.
