Maintenance is not a bad word
One of the worries I hear most from fresh grads going into industry is whether they’ll be “stuck doing maintenance projects.” Let’s dig into what exactly that means, and what exactly they should be worried about.
That seemingly simple issue is actually the tip of the iceberg for a bundle of intertwined complex ones. It usually encompasses some or all of the following:
- Maintenance is boring, bad, and uninteresting.
- I only want to work on new and interesting stuff. I want sexy projects.
- I want to work on projects that will advance my career, and maintenance projects are not it.
Maintenance is boring, bad, and uninteresting.
No, maintenance is important.
Look around you, at the modern civilization you live in. The primary activity of civilization is maintenance. A new building or a new road pales in comparison to an existing city. They also have to connect with the existing city. Engineers who work with things other than software (mechanical, civil etc) seem to have a deeper understanding of the primacy of building on existing infrastructures.
All this is to say that maintenance doesn’t get its due. Software now is just as much a part of the infrastructure of civilization as roads, bridges and cities. As time goes on, its maintenance will get more important, not less.
I only want to work on new and interesting stuff. I want sexy projects.
Innovation is often misunderstood. We have a tendency to mythologize innovation as a “Eureka!” story, but zoomed in, innovation looks like a long thread of small, incremental steps.
In a paper delving into the challenges that new grads faced in their first software engineering jobs, the authors found that:
Our study reveals that new developers find themselves in situations that differ considerably from the university [software engineering] class… We see new developers joining large, preexisting teams of software developers as the most inexperienced member, and spending their first several months resolving bugs that predate their employment, with little access to easily consumable documentation. Many of the problems they have are not due to lack of experience in programming, design or debugging. In fact, all of our study subjects said their university preparation in these areas was more than adequate. The problems instead centered around the particular social conditions of a new software job. Instead of a greenfield project, a more valuable experience would provide students a large pre-existing codebase to which they must fix bugs (injected or real) and write additional features.
Of course, this is true not just of fresh grads, but of experienced engineers as well. The vast majority of their time is spent extending existing systems.
Truly green-field projects are rare. And they are risky, which helps make them rarer. But the fact is that you would make a crappy green-field project if you had no experience maintaining a real system. Because–guess what–very soon your green-field system won’t be green-field any more and you will have to maintain and extend it.
The shift away from clients towards large cloud systems only increases the slant towards incremental changes, because an online service cannot be replaced in one shot. It has to be changed piecemeal, akin to changing parts on a plane while it is flying.
How will you tell a “sexy” project from one that’s not? All the things you think will indicate a “sexy” project–management excitement, newness–have no correlation with the ultimate success and impact of a project. When you say you want to work on a sexy project what you’re really saying is that you want to be on a successful, celebrated project. And you can’t spot those a priori.
I want to work on projects that will advance my career, and maintenance projects are not it.
So far I’ve been debunking. But this part of the concern is actually valid.
You want to be judged by impact of the projects you worked on. Whether they are “maintenance” projects or not is immaterial. Instead of specific projects to work on, look for a place that has a performance process that is objective, gauges impact, peer-based and not reliant on just your manager.
Previous related post: Shitty legacy maintenance.