52

The majority of my work over the last three years has largely been around maintaining legacy systems that needed patching up or the occasional revamp before being sold again.

I understand the critical role dedicated maintenance programmers have to play in companies with a large number of projects and limited developers on hand.

But as I judge my current career progress and look at my peers; contractors and corporate developers alike; I do feel as if I am lagging far behind since I've gained a great deal of breadth in terms of the areas I've touched but not much depth. I've begun to address this by starting a blog, working on my own little git-hub projects and rescheduling my life to have time to do personal coding after work on a regular basis.

I feel that were I to interview at other companies to escape maintenance work I would have to represent myself as being quite junior in skill level since I would not have the depth of level of knowledge required of a person with three years experience focused on a particular path in feature development would. So half my current work experience would count for naught in the long run.

But this leads me to my main questions, apologies if this feels too centered around my personal dilemma,:

Do dedicated maintenance programming roles end up being detrimental to an early career? Are other programmers right to avoid roles like these? Does doing this line of work lock you into doing similar tasks unless you're prepared to start over as a junior?

gnat
  • 21,442
  • 29
  • 112
  • 288
Gyurme
  • 450
  • 4
  • 7
  • I would think the technology you work with early in your career is (far) more important than whether you are doing maintenance work or new development. If you did new development in an in house language or an older language with little demand it would probably be much worse than not doing new development in a higher demand language. – stoj Jun 04 '13 at 15:28
  • 6
    It certainly builds character. – quant_dev Jun 04 '13 at 17:26

5 Answers5

68

Do dedicated maintenance programming roles end up being detrimental to an early career? Are other programmers right to avoid roles like these? Does doing this line of work lock you into doing similar tasks unless you're prepared to start over as a junior?

First up, you should know that you're considered a junior for quite a while. You may get arbitrary promotions because you're good and this is the only way to give you a decent payrise, but you'll still be considered a junior as you head on to your next job.

Second, if I'm hiring someone with 2-4 years' experience, I don't really care whether their work was purely maintenance. If you've spent 10 years in maintenance and I'm hiring for a greenfields project, I may have questions but, for the first few years, I honestly kind of expect it.

On the other hand, if I'm hiring someone who has NEVER worked in maintenance, I'm going to be more suspicious. I've had many candidates for jobs who have spent their first 4 years skipping from one "good" job to another and every single one has learned nothing about what makes for maintainable code. And, make no mistake, if I'm hiring for a greenfields project I intend to stick with, I don't care whether YOU are going to maintain the code, I care that you know how to leave it maintainable for future developers.

These other programmers you mention, who avoid jobs like these, generally avoid them because they're less fun, not because it hinders their career.

Finally, you should know that a very large percentage (I would conservatively guess at about 80%) of software development jobs are more than 50% maintenance.

So, to cut through all that and answer your question: No, I don't think it's going to hinder your career. Unless you stay there for far too long. The common rule of thumb is "once you start feeling like you're getting the same year of experience every year, it's time to go." If you feel, each year, like you're a better developer than you were last year, you're fine (and that goes for me, 20 years into my career, as much as you).

pdr
  • 53,387
  • 14
  • 137
  • 224
  • 25
    +1 Doing maintenance makes someone a better development. –  Jun 04 '13 at 10:15
  • 8
    +1 Doing maintenance on your own or someone else's project forces you to appreciate and learn from the consequences of decisions that were made earlier on in the project. – Ophidian Jun 04 '13 at 13:59
  • While having experience with maintenance is ideal, my opinion is that what you learn from developing a successful project > what you can learn maintaining someone else's project. Maintenance may teach you what not to do, but as best said by Jason Fried: [learning from failure may tell you what not to do the next time, but that doesn’t tell you what to do next time](http://37signals.com/svn/posts/1643-failure-is-overrated-a-redux). – Korey Hinton Jun 04 '13 at 22:15
  • @KoreyHinton: I'm sure that Jason Fried, a successful entrepreneur, believes what he's saying, in terms of being an entrepreneur. I would argue that a) he doesn't actually know what he could be doing better, because things have gone very right for him, b) backing DHH and Rails was 90% of 37signals' success and that's a gamble that wouldn't pay off 90% of the time, and c) even Jason probably wouldn't claim that advice about being an entrepreneur necessarily translates to learning from having to piece together badly-written software. – pdr Jun 05 '13 at 00:54
  • @pdr You're right, the two things don't translate exactly. As I am still a student I was speaking from opinion rather than experience. I guess personally I prefer writing new code as opposed to maintaining code written by others but it sounds like maintenance is something I'm going to be doing a lot of in this field. – Korey Hinton Jun 05 '13 at 12:39
13

In any job, the experience you get is specific to what you are doing, which limits your range of possibilities when applying for other jobs based on that experience. It isn't specific to maintenance. I think other questions are more relevant than whether something is maintenance or new software development:

  • How widespread are the specific technologies you are working with? If you are maintaining something that is obsolete and rarely used elsewhere, then that would limit your future career opportunities (but so would developing new software for a system/platform/technology that is not widely used).
  • How does your current work equip you for the work you want to do in the future? Maintenance work, as you pointed out, is important and will always be around. There is nothing wrong with having a career focused on this type of programming; there will always be lots of possibilities for system maintainers. But maybe it is not what you want to do. It is a concern if your current work is not preparing you for what you are interested in.

However, I would not be too worried. One thing you say is:

I've gained a great deal of breadth in terms of the areas I've touched but not much depth.

Don't think of this as a problem, because it can be used to your advantage. Having broad experience means there is a wide range of things to which you can say "yes, I have done that." Lots of jobs ask for experience in several different technologies and tasks. You would likely have an advantage over a developer who has very deep experience in one technology.

Furthermore, lots of jobs involve a mixture of maintenance and new development. If you wanted to do more new development, you could use your existing maintenance experience to transition into a mixed role that will give you more development experience.

In conclusion, your resume is probably better than you think it is. A lot of it will come down to how well you analyze the strengths of your experience, and then communicate those strengths in the application and interview process.

  • +1 On the *broad experience*. Having done 15 years of development and the last year in maintenance, I can tell from personal experience that I've touched many more languages and platforms than I would have staying in development. As a freelancer, having a great deal of breadth *(generalist)* gives me a comforting feeling of not likely to run out of a job soon. Perhaps this is at the expense of the possibility of making more money when specializing *(specialist)* but I'd rather reduce the risk. – Lieven Keersmaekers Jun 05 '13 at 05:11
2

Do dedicated maintenance programming roles end up being detrimental to an early career?

More often than not - YES, assuming:

  • that career here means expertise in many different technical skills.
  • that you spend more than X years there, where X is enough to "set" your ways of thinking.
  • that you don't do anything aside.
  • that "dedicated maintainer" (see EDIT, below) means you don't code to maintain as well as code new things, but that you almost always code to maintain or even work on a project in maintenance mode - no new features, required least changes in code to fix the bug.

This doesn't mean that is always the case.

People maintaining software rarely are encouraged (see EDIT, below) to do research, rarely can plug in new library or DB and spend few days finding out how it works. It's (usually) a steady job that requires minimal changes to existing code base and thus "shapes" the way you approach problems later on. I can name quite a few companies that have a policy for maintaining software that explicitly states "less changes in the code = better", despite bad things this can bring.

Are other programmers right to avoid roles like these?

I know very good maintainers who like their jobs and wouldn't want to apply for something else precisely because it's comfortable where they are. Not everybody likes to learn new things every now and then. So - avoid or look for it depending on your preferences.

Does doing this line of work lock you into doing similar tasks unless you're prepared to start over as a junior?

More often than not - YES. Because you already have experience doing that, because you already "know the ropes" etc. But shift is definitely possible and can happen without applying for a junior position. You already started doing things aside, keep at it! That's actually very worthwhile and can shrink the 'skill gap' you noticed.

EDIT: Dan has pointed out (very rightly), that maintenance tasks can often be done WITH research. That is true. I've changed the answer above in two places to better address this.

Such tasks surely COULD be done this way and if they are - great! However AFAIK most DEDICATED maintainers of LEGACY systems have policies or management expectations and deadlines that - again, more often than not - coerce them into solving the problem with least changes possible. Often the pressure is high enough that even if you can do it this way, you may not want to. Especially if it's not YOUR code: without theory (as per Ryle and Naur) behind it you risk damaging more than you fix.

Nevertheless it should be noted: I don't have hard global data, I speak from my own experience - I worked in a situation as OP, I recruited people with 4 - 10 years of experience as maintainers, I talked to many maintainers and I know people working as dedicated maintainers. Not just people who code new things but also code to maintains a project - dedicated maintainers, who's only job is to do bugs and patches and not even one new feature, because it's old project and it's now only in "maintenance mode".

LAFK says Reinstate Monica
  • 164
  • 5
  • @dan1111, which parts aren't? Despite this being a duplicate I'll gladly make my answer better. – LAFK says Reinstate Monica Jun 06 '13 at 09:33
  • Thanks Dan. I'll somewhat expand my answer to highlight parts that I believe contain the answer to your comment. – LAFK says Reinstate Monica Jun 06 '13 at 17:33
  • +1 for the additional work on the answer. Particularly, explaining the extent of your own experience is helpful to establish the credibility of the answer. –  Jun 07 '13 at 09:05
  • "People maintaining software... rarely can plug in new library or DB and spend few days finding out how it works." That's not really my experience. Maintenance programmers have to be good at diving into something unfamiliar and quickly understanding its essence (whether its a program or a library). At least, that's the case if you're maintaining different things; if you're maintaining the same thing all the time, for years, then the negatives that come with that aren't caused by "maintenance", they're caused by working on the same thing too long (regardless of where it is in the lifecycle). – user1172763 Aug 01 '14 at 17:10
  • Hi @user1172763. I must say, your maintenance definition is quite extraordinary. I believe the part I've added for *Dan* addresses more interesting cases of maintenance, like yours. However I don't believe it to be standard maintenance. Just to verify - the reason for down-vote is because your experience doesn't match my answer? Then please state your sources, as I stated mine, so others can read and decide. – LAFK says Reinstate Monica Aug 04 '14 at 07:35
  • @LIttle Ancient Forest Kami- I don't downvote everything I find wrong. I do vote on things I consider common misconceptions. My source is my experience (14 yrs.) doing work of all kinds. New projects seem to me to involve a lot of design sessions full of speculation and waste. I'd rather dive into an existing project and see someone else's approaches to a problem and their results in production. That gets me quickly to a point where I understand a language or technique. As for dissatisfaction among code maintainers, I think it's a nice outlet for frustration to say "I could have done better". – user1172763 Aug 04 '14 at 18:39
1

I would have to represent myself as being quite junior in skill level since I would not have the depth of level of knowledge required of a person with three years experience focused on a particular path in feature development would

Correct. You would not be able to say "3 years experience designing systems from scratch using X, Y, and Z", you'd have to say "3 years experience MAINTAINING systems from scratch using X, Y, and Z" unless you want to out right lie on your CV.

I feel that were I to interview at other companies to escape maintenance work I would have to represent myself as being quite junior in skill level since I would not have the depth of level of knowledge required of a person with three years experience focused on a particular path in feature development would

If you want to say "I design and build systems from scratch" then yes, you would have to class yourself as junior.

What is quite common in IT, (and I'm not saying this is what you are doing) is for people to assume that because they have been working for X years, they have X years experience and after {indeterminate number of years} they should be considered a Senior {Widget} developer.

Now, don't get me wrong, there is nothing wrong with maintenance work, everybody has to do it at some time or another, but what you have realised is that being stuck doing that for too long will likely make it hard for you to get away from that role in the future. This often goes hand in hand with being "stuck" not learning newer technologies/tools/methods.

Ideally, you want a mix of "new" system work and legacy work.

On a positive note, you presumably have seen a lot of different architectures (good and bad), different approaches, how bad decisions can make the legacy programmers work much harder later down the line. These are all positives than can be accentuated.

Good luck!

ozz
  • 8,322
  • 2
  • 29
  • 62
0

Looking at this from a different angle, I think selling yourself as an expert in maintenance is a marketable opportunity.

As an owner of a software company that has multiple projects on the go, one of the biggest risks I have to minimise is developers who jump ship, and the subsequent maintenance of their code.

So assuming you're capable of growing passionate about maintenance work (which I would guess to be the case since you're prepared to blog about your experience), if you came to me offering your services as a maintenance guru - guaranteeing to polish all of my developers' various projects by refactoring, optimising and documenting their code for long-term maintainability - and you had a track record to back up your guarantee, I'd hire you in a flash.

My advice would be to give this a proper try. Position yourself as a maintenance expert and cultivate your blog. You may be on to something.

Kosta Kontos
  • 307
  • 2
  • 8