34

So I've kind of been getting angry about the current position I'm in, and I'd love to get other developers' input on this.

I've been at my current place of employment for about 11 months now. When I began, I was working on all new features. I basically worked on an entire new web project for the first 5-6 months I was here. After this, I was moved to more of a service oriented role (which was still great, all new stuff for me), and I was in this role for about the past 5-6 months. Here's where the problem comes in.

Basically, a couple of days ago I was made the support/maintenance guy. Now, we have an IT support team, so I'm not talking that kind of support, I'm talking more of a second level support guy (when the guys on the surface can't really get to the root of the issue), coupled with working on maintenance issues that have been lingering in the backlog for a while. To me, a developer with about 3 years of experience, this is kind of disheartening.

With the type of work place this is, I wouldn't be surprised if these support issues take up most of my days, and I barely make it to working on maintenance issues. Also, most of these support issues aren't even related to code, they are more or less just knowing the system architecture, working with making sure services are running/getting started properly, handling/fixing bad data, etc. I'm a developer, so this part sucks. Also, even when I do have time to work maintenance, these are basically just bug fixes/improving bad code, so this sucks as well, however at least it's related to coding.

Am I wrong for getting angry here? I don't want to really complain about it, but to be honest, I wasn't spoken to about this or anything, I was kind of just sent an e-mail letting me know I'm the guy for this type of thing, and that was that. The entire team took a few minutes to give me their "that sucks" talk, because they know how annoying it is to be on support for the type of work we do, so I know I'm not the only guy that knows it's not that great of an opportunity.

I'm just kind of on the fence about how to move forward. Obviously I'm just going to continue working for the time being, no point making a bad impression on anybody, but I'd like to know how you guys would approach this situation, or how you think I should be feeling about it/how you guys would feel.

yannis
  • 39,547
  • 40
  • 183
  • 216
  • 4
    Doesn't Microsoft classify this kind of work as *escalation engineer*? If you want to be part of a development team, then do some open source work and build your chops, but giving up a job just because you feel "slighted" doing an important job is probably not a great career move; it instead sounds reactionary. – Jared Farrish Oct 09 '11 at 22:18
  • @Jared Farrish - Oh I was never contemplating leaving at all, I just wasn't sure if I should keep quiet or not. –  Oct 10 '11 at 00:19
  • I've been there a few times before, where I wanted to do or be something that my managers didn't want me to be or do (for one reason or another). You just have to find out what you want to do and what you need to get there, and find a way to do it. Sometimes that means leaving to find opportunity elsewhere. – Jared Farrish Oct 10 '11 at 00:21
  • Yeah, I've been in that spot too. I actually came to this job from another where I felt like that 11 months ago. Doing that again so quick would be entirely unfavorable to my resume though at the moment. I think right now, having something 2-3 years long on my resume is more important than moving because of my above issues =/ The decision to stay has already been made, I just wasn't sure if I should kind of sit still and do what I'm told, or push forth the issue that I shouldn't have to become 2nd layer support for this company when I was hired as a developer. –  Oct 10 '11 at 00:24
  • 2
    I would be careful; if you're not a pushy person, or conniving or crafty or whatnot, don't force yourself to be something you're not. Make your action in response calm and inquisitive, ie, "Hey Bill, I'm doing this maintenance work and it's good work. However, my passion is X and I'd like to work on that specifically. What do I need to do to get there?" And listen. If they shoot you down in a dismissive way, find a way to change their mind. Ask them how they did it; "If you were in my shoes, what would you do?" – Jared Farrish Oct 10 '11 at 00:29
  • It may just be they need someone responsible and capable to take the lead on maintenance. Take to organizing professionally and you may find yourself in a good position. I knew a college student once who was a film editor, and he wanted to be a professional editor. He worked for a year as a "darkroom assistant", until his editor has a problem with a junior editor and offhandedly told him to "clean the darkroom". He set to cleaning it, plus organizing it, and by 9am the next day (he didn't go home that night), he had a job as a junior editor because he conquered the task at hand professionally. – Jared Farrish Oct 10 '11 at 00:38
  • You say you have three years of experience. That's a relatively small amount of experience; I think you're wrong to expect this amount of experience to qualify you to write only new code. Maintenance and support should be part of every programmers background. – Bryan Oakley Mar 19 '12 at 11:22

7 Answers7

44

You can look at this as either a as time in limbo; or you can turn it into an opportunity to grow.

The core idea of being a maintenance developer is to put yourself out of a job. Each time you have to fix something; take the time to understand the problem well enough so that your solution (which could come a few weeks after you put out the fire) means you (nor any other living soul) will ever have to solve that problem again.

Since it's a legacy system you're supporting, you can usually get a way with some solutions that wouldn't be "ok" for mainline products; you can use cron to periodically restart buggy services; You can hard-code exceptional logic for particular customers since the number of customers using that product won't increase.

Another part of it is extracting useful knowledge out of the system; You probably don't want to do this, it's not very much fun; but by documenting what the working system does (even if it does it wrong), you can make the task of mantaining that portion of the application an order of magnitude easier (ten minutes to read two paragraphs that explain a module, instead of three days reading the module code). Better yet, this same documentation can be used to implement the functionality in the mainline product, so you can stop supporting the legacy system altogether (for that feature, at least).

If you're the "go to guy" for a project, even if that's legacy maintenance, you probably (or at very least, you should) have considerable latitude to approach problems in your own way. That might mean rewriting sections in your favorite language or platform, suggesting workarounds instead of solutions, or just responding to issues with "wont fix, use supported products".

Edit: You might be misinterpreting your boss's intent; Maintenance requires a different set of skills from other parts of the development cycle; He might be putting you on a job because he thinks, out of all of the people he has available, you are the best for this role; not because he thinks you're not skillful enough for something else.

Maintenance requires a focus on reading code, more than any other role you might have. If you are good at reading, you will be good at maintenance. There are lots of developers, even ones of many more years experience, that just don't have the knack for reading other people's code (or worse, their own), even if they are brilliant at other things.

When you put yourself out of the job of maintenance, you aren't 'convincing management that you would be good enough to do something more important', you are literally taking the work of maintenance away from the living. When you stop doing that job, it's because there's nothing left to do. All problems are solved, either because they have been migrated out of the legacy application, because manual tasks are now automated, or you have convinced the customer that they don't want or need it and never will. If your boss interprets that as 'he's good at this, better keep him here', doing nothing at all, then he is a fool.

SingleNegationElimination
  • 4,657
  • 2
  • 26
  • 22
  • 2
    +1 for the "put yourself out of a job" line. I definitely want to show that I know enough to not be on maintenance for very long, however doing that could also backfire if my boss sees me as a guy who is so good at it, that he doesn't want anyone else doing it ever again but me. Your other points also make sense, I can approach issues with an amount of creativity (albeit limited by the pure fact that it's maintenance), so I guess I'll just have to do that, see if I like it, and see what happens over time. If it's still an issue down the road I guess I can address it then. – slandau Oct 09 '11 at 20:25
  • +1 - There are lots of developers that can never be a good maintenance developers no matter how many years experience. It takes special skills. However, that doesn't mean that being stuck with maintenance programming doesn't suck. – Dunk Oct 10 '11 at 18:54
  • 5
    @slandau I think you are looking at it wrong. Being a maintenance developer is not a step down, especially with how you are describing the role. You have been identified as being able to handle the position, it is a good thing. It means you are more than just a coder, you understand the system and are able to communicate with people outside the group to solve problems. Maintenance/support is probably one of the best ways to really understand an application. On a small team I use to be on, we actually rotated that position, as it made everyone one better in the long run. – Jacob Schoen Oct 14 '11 at 21:34
17

Being a maintenance developer != being left on the bench. Maintenance dev work can be some of the most frustrating, painful and annoying work in the world as you fix the weird issues the original developer missed.

It can also be some of the most rewarding, both personally and professionally, and educational work you can do. If you can take out a bug that's existed in the system for 6 months+ and has a direct knock on effect to 10% of the customer base your bosses will love you, 10% of the customer base will love you as well. By improving software incrementally and fixing bugs that take a week to track down effectively you'll be increasing your knowledge of not just that system, but what bugs that you can potentially see under specific conditions, and then you take it on board and become a better developer.

I love creating systems anew, but most of the tricks in my programming bag came from doing maintenance work and come in handy more times than I care to think.

Nicholas Smith
  • 1,621
  • 10
  • 11
  • 5
    "It can also be some of the most rewarding" - so true. – Jetti Oct 14 '11 at 16:13
  • 2
    Maintenance programming is one of the best tutors. You learn a whole lot about how not to develop systems. – mcfinnigan Mar 19 '12 at 09:41
  • Too true. I've spent days on a single issue which gives you extraordinary satisfaction and knowledge once fixed, which significantly reduces the time you spent fixing issues not just in legacy systems, but in code you've just written. – Ian Newson Jun 12 '12 at 20:40
8

Don't knock it. I've done plenty of time as a maintenance programmer. If the product is interesting and the other developers any good, you might learn something. And if they're bad, you'll learn what makes code unmaintainable, and you can use that experience when you're writing your own code. And after a while there, you'll be the guy they turn to when they need to know something about the code, because you'll know all of it, not just somebody's little silo.

And after you've learned your way around the code, you'll know which parts need refactoring and can propose projects to do so, which of course you'll be perfectly poised to lead.

Paul Tomblin
  • 1,949
  • 1
  • 15
  • 19
  • Yeah this is kind of the mindset that I HOPE I have throughout this role, but we'll see if I can keep it up after getting bombarded with support issues and barely having any time to actually do any maintenance =/ – slandau Oct 09 '11 at 21:02
  • 1
    Being a maintenance programmer can be a good fun thing, or it can be a career dead end. Which it is depends more on the company culture than anything you can do, unfortunately. I've been fortunate to have a lot more of the former than the latter, but when it's the latter, I've usually been smart enough to move on quick. – Paul Tomblin Oct 09 '11 at 21:12
  • Yeah, I've been here for 11 months, so I think what I'll probably do is, stick this out for at least another 7 months or so, HOPEFULLY I can make it another year (if I happen to still be doing maintenance, if not I definitely will), and then re-evaluate. – slandau Oct 09 '11 at 21:15
5

It's worth noting that the role of maintenance engineer is not one, in a smart organization, given to someone because they're not good enough for something else... it's given to them because they ARE good enough to handle the particular role. Keeping existing systems up and running is an extremely important role and, depending on the company, many millions of dollars can balance on the tip of said engineer(s) doing their job well.

That being said, while most managers will intuitively understand that the role needs a skilled individual to handle it, most don't recognize the achievements of said programmers, and it can be hard to get recognition for your work. It's entirely too easy to be put in the role because you are skilled, and them forgotten about as raises and promotions are handed out later... because the sign of you doing a great job in your role is that nobody notices that you're doing a great job in your role.

It's possible to fight for the recognition you think you deserve for fulfilling the role, but I'm not entirely sure it's worth the large effort involved. Instead, I'd recommend discussing with your manager the concept of (as others have mentioned) rotating the role through the various developers available for it. If possible, have at least one person in the role full time and one person part time. The part timer can learn about the systems and what's involved in maintaining them from the full timer. When it's time to rotate, the part timer can take over as full timer, and a new person comes in as part timer (and learns from the now full timer).

If it makes you feel any better, the people in Ops are in the same position... the sign of a great Ops person is that nobody notices how well they do their job. Only, for an Ops person, they can't really rotate out because it IS their primary role. I'm a big fan of always praising the Ops people I work with, publicly and vocally, because dev is one of the few groups that can see how much better they make everyone else's lives.

That tangent aside... if you do rotate the position of maintenance, the next time you come into the role make sure to give the people before you their chops if you see they did things that make your life easier now that you're back in the role... do so publicly and vocally.

RHSeeger
  • 221
  • 1
  • 6
3

The constructive approach recommended by the other commenters is very good. As Token pointed out, you have a lot of leeway in that kind of position so long as the problems get solved and you don't break anything.

If you find that you can automate common solutions, or prevent them, you can buy yourself a lot of free time - and if the bosses' expectations of the demands on your time remain uninformed by this - to do other kinds of work that you enjoy more or that you think would be more productive for the company. My first "programming" job turned out to be a data-entry job, but I quickly discovered that a lot of the data entry was scriptable, and later, that it could be generated. I freed up about 7/8ths of my time, and used it to re-write the data entry system from scratch, including in it all the scripts and generators and more efficient UIs. It was a dead-end government job anyway, but the experience turned out to be invaluable.

kylben
  • 2,288
  • 14
  • 13
  • I definitely love the idea, but we have a crazy long backlog of minor maintenance projects, that are more or less already scoped out. Also, one of my main worries is that I'll be stuck taking support issues all day and not even get to do any coding =/ – slandau Oct 10 '11 at 00:22
  • 3
    Sure, but if you get things like "my month ending excel payroll sheet didn't roll over right, can you do it for me?" and it takes half an hour, and you get five or six a month (this is close to a real example from my past), and you can script it to take 5 minutes, then **don't tell anybody**, there's 2 hours a month free time. – kylben Oct 10 '11 at 02:12
  • Good point. I'll keep an eye out for those opportunities. – slandau Oct 10 '11 at 15:47
1

Talk to you manager about rotating developers into the position (say on a monthly cycle or something). If everyone knows that it sucks then everyone will understand why the work is being distributed around the whole team. Maybe in talking to your manager you'll find out that this is already the case, and you've just gotten rotated in.

Kevin
  • 1,341
  • 8
  • 12
0

You need to ask why you were put in a role everyone thinks sucks. If your manager has half a brain, he'll know no one likes it and if he thought there are those that do, he could of at least asked. Find out how long this situation will last and if there are opportunities to move back to new development. You never know, you may walk into the office the next day and be given a brand new project. Stranger things have happened.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • Yeah I think for at least the time being I'm here because of a lack of resources, but if we start to hire more developers, and they are working on new things and I'm not, then it's time to bring it to the forefront definitely. – slandau Oct 10 '11 at 18:52