One of my friends has just completed his college degree and is ready to join the programmers' world. Today he has two offers, one with new projects every time, and another with software maintenance.

The remaining factors are not important to him, what he wants to know is which option is better?

My experience goes with second option because my first job was the maintenance one and I could learn how my fellow programmers made mistakes while coding . But I soon switched to a new job which required me to create new project every time. I enjoyed both but I must admit that my first job has given me a more advantage today.

But it's not necessary that my experience can give benefit to him. But I want to know what is general approach? If I have to give him final verdict on these two, what should I tell him?

Edit

Everybody deserves one up vote here, I am really learning a lot from you guys.

16 Answers
16

I think it works against a new developer to just start jumping into coding new projects from the start. It doesn't allow a developer to:

Understand the current business.

Understand the current codebase and architecture to which the business is running on.

Learn from past mistakes from other developers (as you stated).

With maintenance, the developer will generally do less coding than with jumping into new projects all the time. I think it's a mistake for junior developers to want to do only coding and lots of it when they first start their job. It's important to get a grasp of the business with a fair amount of mentoring before the coding should even begin. Generally, maintenance will also be difficult since the codebase will no doubt have little to no documentation, ugly bandaged code, and often times no one to explain why it was done that way. Yes, very sad and frustrating.

With new projects, the developer will likely be using newer technologies, coding standards, architecture, and the full SDLC-- and yes will likely be more fun and easier because they aren't dealing with legacy code hands on.

But it's not just about having fun and doing what's easier. The emphasis should be on understanding the business, to develop a deep understanding of the system, and the ugly inefficient code that has been written in the past.

I find it easier to work with and mentor new software developers that have a broad understanding of the business and little knowledge of the latest technologies, than with developers that understand new technologies, but never spent the time to understand the business and what broad problems we're truly trying to solve.

I would choose the one which provides an awesome team/mentor. Unless the person is extremely talented in learning by himself (and the Internet), lack of a mentor will be a huge drawback.

A self-learner might prefer Maintenance, since there IS a codebase from which he can learn the technology, design, programming practices, methodology, business etc., and especially the rotten nuts...

I started with maintenance of a complex project with multiple technologies handed off to our team of newbies, and I couldn't have asked for more - I could learn the entire system AND the fine grains of it... I had a grudge for not able to write/design new stuff, but I learnt not to rely on others and start my own pet projects - for productivity or otherwise...

My tips:

Check for a strong mentor/team (dont forget that they may not stay forever in the team)

If you are passionate, you can learn from either... Write new code for your work, and take up maintenance from your fav. open source project... Or maintain for your work, and take up pet projects...

If you are not so passionate, choose whichever that does not require longer work-hours and that employ popular technologies

It totally depends on the work place environment. I personally started out as a developer on our product right out of the gate, but I had a great mentor. Looking back I can see that at first he selected small projects that didn't have that much impact if any on the main product and were certainly not on the critical path in terms completion time. During each project I was asked to come up with informal design documents that were reviewed together. We also conducted code reviews. I enjoyed this methodology because it allowed me attempt design and implementation with my own knowledge first. After that my mentor would point out issues or problem areas and then I could go back and fix them. As project got more involved I learned more about the system as whole. I believe actually going through the steps and making the newb mistakes by myself under supervision was a superior way to learn, but you NEED to have a mentor that is willing to take you under his/her wing for at least the first year or so. It might even be as many as 2 or 3 years before you can really be consider an equal contributor. I learned more in my first 3 years in industry then probably all of H.s and College combined.

However, if one has a choice, then working on new projects win hands down:

More fun

Less stressful

More productive (i.e. more visible results with less effort)

Results are more visible. This leads to quicker promotions, more resume-worthy items. While you may technically know less, your career could be progressing faster.

Some advice may be biased, since us old hands feel it's appropriate for newbies to scrub the deck for a few months... we did this, and so should you. People also tend to rationalize by attributing more value than warranted to painful experiences.

if you don't have the right manager/tech-lead a "new project" role for a newbie quickly becomes a real sink/swim type situation.
–
gingerbreadboyDec 22 '10 at 12:45

1

+1 I think this is better answer than the accepted one to the question "what is better for a newbie." Starting a new project often leads to resume-worthy items and quicker promotions. Maintenance may get you better skills dealing with legacy code but does it really help the newbie much in terms of career? Leave those chores to the unfortunate ones while the lucky newbies get promoted to manages :/
–
kizzx2Dec 22 '10 at 17:58

On Maintenance you will learn to read other people code. Learn from their good practices and refrain from their bad practices. You will need to know the big picture to fix bugs. On the other hand you will have problem to change some of the system design since if it is a system with customers you will have to consider how your changes will affect them. Although maintenance is frustrating sometimes I think you will learn more as a newbie. Make sure that there are new products on the horizon so that if you will prove yourself as a maintenace engineer you won't be stuck in this position.

On the whole I would incline towards maintenance, but it depends a lot on other factors. If you're writing new code in a company that has a stronger team, better developers to learn from and a nicer working environemnt then that is going to be the better option.

Alternatively if one is in a sector that your friend would like to make their career in, that might be a better choice for the long term.

If both jobs were in the same organisation, or very similar ones, then maintenance for sure...

However, I think which ever job offers the most structure and guidance would actually be my deciding factor.

Maintenance is a good starting point because you get to see how it is done by the people who's code you are tracing through. You get to see clever things you'd never have thought of and silly/scary mistakes which in the future you will be able to sidestep.

This is all invalidated if the code base is spaghetti and you spend all of your time fire-fighting and push emergency releases out the door. If the client has a direct line to your desk walk away.

Similarly, new development coding can be great. Learning about architecture. Feeling like you're really having input. But unless you have someone watching you closely you will end up in a world of pain.

My first job started with maintaining an application written by a developer who had left the company before I joined. The application was designed and developed very badly. Some examples are using Exception try and catch clauses to implement business rules, poorly designed Classes with very long methods, badly named methods, not following Java naming standard and no consistency of naming within the same application, no proper documentation.

So it was really terrible experience for me. To understand the business rules, I have to trace code line by line. It's very frustrating when you know that something is horribly wrong and you know how to make it right, and yet you have no right to fix it.

I believe someone will have his own bad experience with new project/product as well. But if I have a choice, I'd rather choose a new project.

In my view, each job has its pros and cons. Creating a new project maybe more fun, and you have all the rights to decide on how things done. You can choose the technology, pratice planning & managing the time... And it's good.

On the other hand, if your friend experience is not enough, it will be risky. He may fail (well, the fact is that lots of projects fail). If he can accept that fact and ready to embrace risks, I think he could choose this way.

The maintenance work is just more stable, and will help your friend learn much if his background is not quite good. The bad side of this, as I see, is that it is... easier. Yeah, creating a project from scratch requires lots of hard work to make it successful, than correcting what people already make.

Since he has the chance to choose, he should go for the job that allows him to create new projects. It's much more fun, probably allows him to use the latest and greatest technologies, it lets him experience the complete software life cycle instead of the last phase only, and it's IMO easier for a newbie to create something from scratch instead of trying to comprehend an already written large codebase.

Maintenance can be a nightmare even for an experienced programmer, and even more for a newbie. You touch something - bang - something else stops working. Coincidence? Related? Don't expect to find unit tests, up-to-date documentation etc.

From what I see around me, new projects are seldom given to newbies. Usually, they start with maintenance or unit testing activities.

But I am an exception of my own observations. I started with a project which was rewritten from scratch because of a big design failure in the first version. There, I learned most of my know-how, thanks to a privileged environment: smart people, efficient coding pratices, wise management and many other little thinks that make developers feel well considered.

Without such an environment I would not advocate for starting with a new project job.

Maintenance may give you the most varied exposure to different areas as well as the opportunity to learn from more experienced developers. However, it can also teach you bad habits and ugly practices if it is a crusty legacy app where many mistakes were made. It may also lead you into accepting certain practices and patterns without knowing the reasons for them. I think a good mentor and a high level of interaction and review early on is probably the most effective thing for a new developer, regardless of the task.

I agree with your suggestion because my first job was the maintenance one and i learn a lot by reviewing the other programmers code and then when i write my own code i have couple of choices that helps me a lot, But one point that i would like to mention is that if there is a strict guidelines that one has to follow while writing code then you cannot implement your own approach which may be better if you start a new project