How do you break out of the role of a code maintainer? [closed]

Question

In my last three jobs, I was a code maintainer. In all three cases, I was hired after the majority of the code for the project was already written.

I'm a self taught programmer. Before I ever started my first professional job, I had maybe a dozen projects under my belt that I started and shipped successfully.

Writing new code and maintaining existing code are two completely different jobs. Its like comparing an aeronautical engineer with an aircraft mechanic.

It especially sucks when you're an aircraft mechanic working on an airplane that was designed by an engineer who made no attempt to engineer the plane to be in any way logical or easy to maintain.

I'm starting to feel like to be around when the project is first starting out, you have to be one of those special people who has somehow transcended the rest of the people in the computer science field. What does it take to be in that position?

I kind of feel like this question doesn't really have any easy answer, but could anyone give me some insights? Have you ever been on the ground floor of a new project? What did it take to get there?

Answer 1

Maintenance means different things to different people, and comes about for different reasons.

• Worst case, the initial system was thrown together in a hurry, the initial team took credit for the whole thing. They followed the 80/20 rule, so while there might be a minimum viable product that can be sold, lots of customers need lots of fixes and small improvements. Many problems, but not much glory remain. You have the hardest job, and its thankless. I hope this is not your situation.
• Better case, you have shown that you are careful with your work and can be trusted to make changes to fielded product without breaking it. What problems remain are too hard for the people who hammered the original system together. Maybe they failed to build the system to last, and you are there, perhaps as their replacement, to set things right and rescue the customers, the project and the profits.
• Very likely case, 60% of projects costs come during maintenance. Perhaps it is timing, perhaps your organization segregates between new development and maintenance, but you are in the 3/5th majority because many of us do maintenance.

Here are a few things to try:

• Do a great job, have a great attitude, be an idea leader.
• As much as possible, work in teams, not alone.
• Learn newer languages.
• Learn newer platforms.
• Request to work on smaller programs, maybe even apply with smaller companies.
• Get skilled and get involved in documentation. When projects start, even in the post waterfall era, they need a lot of written coordination to road-map, document, evaluate, and clarify requirements.
• It is dangerous for projects to start in the hands of people who don't appreciate requirements management, estimation, and risk assessment, so learn and practice these skills as much as you can.
• Get more formal training or certifications. This may increase your status and make you a more attractive choice when teams for new development projects are formed.
• Start a company or some consulting on the side. This give you creative outlet to target your favorite kind of work, and gives you a better appreciation of what it is like to start with no code or documentation.
• Get closer to your boss and to people who plan new projects.
• Conversely, if you are super close to testers and QA, their output is often the input to maintenance, so guess who your boss thinks you work really well with?
• Make as many friends, and win the respect of as many greenfield developers as you can.
• New developers are the can do people, so be cautious about any hint of criticism or negativity. Give them your ideas freely without blame or judgement. Your ideas need no introduction, just say them. Never say, we used to do it this way, or that doesn't work, try this. Never say, I don't know, but this might work. Just say the idea. Or better, show it.
• Find and take any opportunity to build a proof-of-concept that might turn into your new project.
• Watch out who assigns you work. Usually, it should be someone in your chain of command. If it is your peers, push back some of the time. If it is someone you supervise, there needs to be a good reason control is inverting. If it is QA or test, make sure it matters to your chain of command and is not scheduled in a way that delays work you promised earlier.
• Beware of perfection. New development is often reserved for fast people, even if they cross the eyes and don't dot the t's.
• Spend time learning and practicing early project skills appropriate to your line of development. This could include: creating source repositories, defining the build environment, configuring the constant integration server, working closely with the hardware team to bring up new boards with board support packages or writing power on self tests. It might even help to know how to work with purchasing to buy new development tools, training, and COTS hardware.
• Make sure you move on before your maintenance project is closed, perhaps by shopping your skills internally to team leads and maybe managers, or externally.
• Be fluent in every technology you know, and know a lot of technologies.

A maintenance role can be turned to your advantage in several ways.

• You can potentially work on every project your group or even company makes.
• If new development and maintenance is separated, you can potentially follow a less competitive leadership track. Lead on new projects is highly coveted, but maintenance lead might be available to you for the asking. If you have encouragement and mentoring to give, members of that team may appreciate it more.
• If the project is in maintenance, you are more likely to interface with customers. Handled wrong, this ends careers. Handled right, it gets positive attention outside development that is hard to find without being a manager.

Having said all this, I am the counter-example not the role model. Much of this perspective comes from experience and observation.

There are many new programs that still need to be written.
Be ready and you will be working on one surprisingly soon.

Answer 2

I have bad news for you: a lot of the applications humanity needs are already written, it's just that they should be fine-tuned to the constantly changing environment.

Some day, you'll be asked to write a new part of the system, like, a new module, and you can leverage your knowledge on green field development.

Until then, you can try to learn refactoring legacy applications to clean modules.

A good read is "Working with Legacy Applications" and "Refactoring to Patterns". If you didn't read the original Refactoring (Fowler), please do so. And learn Test-Driven Development (TDD), always helps.

In case you're working with PHP, I wrote a hands-on article this code still runs...

Have fun!

Answer 3

The easiest route to escape is to change your style of programming entirely and also add new skills in the same time. For example, you could try to be a Researcher. It might not be a prestige job for the first year, and certainly it is not as highly paid as normal programming jobs (in the first year if you are Researcher / Research Associate in the team of a University - of course as Senior Researcher is pretty much in line with the rest of the industry), but it will definitely put your skills to work on the hardest problems you can find today. After such a job you could easily jump into a better position, provided you have some interesting projects to show to your next boss.