How do I explain that I don't want to maintain old projects?Addressing unnecessary daily meetings with manager?How can I stabilize a hectic project without offending the unofficial Project Manager?How do I effectively handle this situation of no workflow?Should I inform my colleague/manager that I get sudden “bad days”?The new project my team is supposed to start makes me feel a déjà vu of a past failed project. How to proceed?

What are valid bugs

Implement batch option --yes in bash script

Is it ok to return default argument's value by const reference?

Why does this Ultramarine have red armour?

Dodging a Deathbeam travelling at speed of light

What could cause the Boeing "Pickle Fork" issues?

Did the disagreement between the Catholic Church and Protestant Church on the issue of salvation by grace alone end 1999?

How to persuade players not to cheat?

How to deal with a 6 year old who was "caught" cheating?

Can I say: “The train departs at 16 past every hour“?

Would rocket engine exhaust create pockets of gas in space which could hinder further space exploration?

How to make sure change_tracking statistics stays updated

What is David Chalmers' Naturalistic dualism?

Change date format with sed or awk in file

Lvl20 Samurai+true strike=9 attacks all with advantage?

How to check whether the permutation is random or not

Why do we worry about overfitting even if "all models are wrong"?

Why would gloves be necessary for handling flobberworms?

Mechanics to keep mobs and environment alive without using tons of memory?

What does it mean by "commercial support available" for an open-source platform?

What is the difference between the Ancient Greek religion and the Ancient Roman religion?

Can Zombify target a creature card that isn't in the graveyard?

Is it possible to be admitted to CS PhD programs (in US) with scholarship at age 18?

What is Trump's position on the whistle blower allegations? What does he mean by "witch hunt"?



How do I explain that I don't want to maintain old projects?


Addressing unnecessary daily meetings with manager?How can I stabilize a hectic project without offending the unofficial Project Manager?How do I effectively handle this situation of no workflow?Should I inform my colleague/manager that I get sudden “bad days”?The new project my team is supposed to start makes me feel a déjà vu of a past failed project. How to proceed?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;









69

















I am currently working as a programmer with 3 years of experience in the Netherlands. At the start I worked at some projects I started from scratch and I really enjoyed those. I also acted a bit as support on other projects and have done a fair share of fixing and improving existing projects.



However, for the last 6 months, I have been put to work on a project that has been in development for over 6 years by 5 other programmers before me. The project is finished on paper, but it's done really messy and every week a new bug shows up which I often have to spend weeks on. As other programmers might know, it's not easy to understand another person's code, especially if there's no documentation.



To say it in the least, I hate it. I got to the point I start to feel down when I see a mail from one of the users that contains something like "bug" or "error". I just don't want to do this anymore.



My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?










share|improve this question























  • 85





    I know we all think we produce perfect code, but just as a mental exercise, picture the person maintaining your starter projects. What would that person say about it?

    – nvoigt
    Jul 5 at 12:16






  • 8





    FYI, a common term for the concept on working on a brand-new project unencumbered by legacy code is greenfield (versus brownfield).

    – Basil Bourque
    Jul 5 at 19:33







  • 2





    What sort of bugs do you have to spend weeks on?

    – Neuromancer
    Jul 5 at 21:35






  • 10





    @jpmc26 I finally work with someone who writes code that I understand first time. It's amazing! I open files and think "This looks like I wrote it, but I don't remember writing it", and it's always written by this same person. I hope that you, too, one day find your codemate ;-)

    – Aaron F
    Jul 6 at 18:33






  • 2





    see it like that: that project is 6 years old. It has been new code for 1 year, and maintenance for 5 years. means that for every new project you work on, you'd work on 5 older projects. So, there's that.

    – njzk2
    Jul 7 at 5:58

















69

















I am currently working as a programmer with 3 years of experience in the Netherlands. At the start I worked at some projects I started from scratch and I really enjoyed those. I also acted a bit as support on other projects and have done a fair share of fixing and improving existing projects.



However, for the last 6 months, I have been put to work on a project that has been in development for over 6 years by 5 other programmers before me. The project is finished on paper, but it's done really messy and every week a new bug shows up which I often have to spend weeks on. As other programmers might know, it's not easy to understand another person's code, especially if there's no documentation.



To say it in the least, I hate it. I got to the point I start to feel down when I see a mail from one of the users that contains something like "bug" or "error". I just don't want to do this anymore.



My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?










share|improve this question























  • 85





    I know we all think we produce perfect code, but just as a mental exercise, picture the person maintaining your starter projects. What would that person say about it?

    – nvoigt
    Jul 5 at 12:16






  • 8





    FYI, a common term for the concept on working on a brand-new project unencumbered by legacy code is greenfield (versus brownfield).

    – Basil Bourque
    Jul 5 at 19:33







  • 2





    What sort of bugs do you have to spend weeks on?

    – Neuromancer
    Jul 5 at 21:35






  • 10





    @jpmc26 I finally work with someone who writes code that I understand first time. It's amazing! I open files and think "This looks like I wrote it, but I don't remember writing it", and it's always written by this same person. I hope that you, too, one day find your codemate ;-)

    – Aaron F
    Jul 6 at 18:33






  • 2





    see it like that: that project is 6 years old. It has been new code for 1 year, and maintenance for 5 years. means that for every new project you work on, you'd work on 5 older projects. So, there's that.

    – njzk2
    Jul 7 at 5:58













69












69








69


13






I am currently working as a programmer with 3 years of experience in the Netherlands. At the start I worked at some projects I started from scratch and I really enjoyed those. I also acted a bit as support on other projects and have done a fair share of fixing and improving existing projects.



However, for the last 6 months, I have been put to work on a project that has been in development for over 6 years by 5 other programmers before me. The project is finished on paper, but it's done really messy and every week a new bug shows up which I often have to spend weeks on. As other programmers might know, it's not easy to understand another person's code, especially if there's no documentation.



To say it in the least, I hate it. I got to the point I start to feel down when I see a mail from one of the users that contains something like "bug" or "error". I just don't want to do this anymore.



My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?










share|improve this question

















I am currently working as a programmer with 3 years of experience in the Netherlands. At the start I worked at some projects I started from scratch and I really enjoyed those. I also acted a bit as support on other projects and have done a fair share of fixing and improving existing projects.



However, for the last 6 months, I have been put to work on a project that has been in development for over 6 years by 5 other programmers before me. The project is finished on paper, but it's done really messy and every week a new bug shows up which I often have to spend weeks on. As other programmers might know, it's not easy to understand another person's code, especially if there's no documentation.



To say it in the least, I hate it. I got to the point I start to feel down when I see a mail from one of the users that contains something like "bug" or "error". I just don't want to do this anymore.



My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?







software-industry software-development projects netherlands






share|improve this question
















share|improve this question













share|improve this question




share|improve this question








edited Jul 8 at 11:12









NicolasB

1034 bronze badges




1034 bronze badges










asked Jul 5 at 9:44









Mr Den 12Mr Den 12

3671 gold badge2 silver badges4 bronze badges




3671 gold badge2 silver badges4 bronze badges










  • 85





    I know we all think we produce perfect code, but just as a mental exercise, picture the person maintaining your starter projects. What would that person say about it?

    – nvoigt
    Jul 5 at 12:16






  • 8





    FYI, a common term for the concept on working on a brand-new project unencumbered by legacy code is greenfield (versus brownfield).

    – Basil Bourque
    Jul 5 at 19:33







  • 2





    What sort of bugs do you have to spend weeks on?

    – Neuromancer
    Jul 5 at 21:35






  • 10





    @jpmc26 I finally work with someone who writes code that I understand first time. It's amazing! I open files and think "This looks like I wrote it, but I don't remember writing it", and it's always written by this same person. I hope that you, too, one day find your codemate ;-)

    – Aaron F
    Jul 6 at 18:33






  • 2





    see it like that: that project is 6 years old. It has been new code for 1 year, and maintenance for 5 years. means that for every new project you work on, you'd work on 5 older projects. So, there's that.

    – njzk2
    Jul 7 at 5:58












  • 85





    I know we all think we produce perfect code, but just as a mental exercise, picture the person maintaining your starter projects. What would that person say about it?

    – nvoigt
    Jul 5 at 12:16






  • 8





    FYI, a common term for the concept on working on a brand-new project unencumbered by legacy code is greenfield (versus brownfield).

    – Basil Bourque
    Jul 5 at 19:33







  • 2





    What sort of bugs do you have to spend weeks on?

    – Neuromancer
    Jul 5 at 21:35






  • 10





    @jpmc26 I finally work with someone who writes code that I understand first time. It's amazing! I open files and think "This looks like I wrote it, but I don't remember writing it", and it's always written by this same person. I hope that you, too, one day find your codemate ;-)

    – Aaron F
    Jul 6 at 18:33






  • 2





    see it like that: that project is 6 years old. It has been new code for 1 year, and maintenance for 5 years. means that for every new project you work on, you'd work on 5 older projects. So, there's that.

    – njzk2
    Jul 7 at 5:58







85




85





I know we all think we produce perfect code, but just as a mental exercise, picture the person maintaining your starter projects. What would that person say about it?

– nvoigt
Jul 5 at 12:16





I know we all think we produce perfect code, but just as a mental exercise, picture the person maintaining your starter projects. What would that person say about it?

– nvoigt
Jul 5 at 12:16




8




8





FYI, a common term for the concept on working on a brand-new project unencumbered by legacy code is greenfield (versus brownfield).

– Basil Bourque
Jul 5 at 19:33






FYI, a common term for the concept on working on a brand-new project unencumbered by legacy code is greenfield (versus brownfield).

– Basil Bourque
Jul 5 at 19:33





2




2





What sort of bugs do you have to spend weeks on?

– Neuromancer
Jul 5 at 21:35





What sort of bugs do you have to spend weeks on?

– Neuromancer
Jul 5 at 21:35




10




10





@jpmc26 I finally work with someone who writes code that I understand first time. It's amazing! I open files and think "This looks like I wrote it, but I don't remember writing it", and it's always written by this same person. I hope that you, too, one day find your codemate ;-)

– Aaron F
Jul 6 at 18:33





@jpmc26 I finally work with someone who writes code that I understand first time. It's amazing! I open files and think "This looks like I wrote it, but I don't remember writing it", and it's always written by this same person. I hope that you, too, one day find your codemate ;-)

– Aaron F
Jul 6 at 18:33




2




2





see it like that: that project is 6 years old. It has been new code for 1 year, and maintenance for 5 years. means that for every new project you work on, you'd work on 5 older projects. So, there's that.

– njzk2
Jul 7 at 5:58





see it like that: that project is 6 years old. It has been new code for 1 year, and maintenance for 5 years. means that for every new project you work on, you'd work on 5 older projects. So, there's that.

– njzk2
Jul 7 at 5:58










16 Answers
16






active

oldest

votes


















151


















Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project.



However, there are things you can do to maybe make your life and future a bit more livable. I'd start with mentally breaking down the current project into modules, and then asking for permission to refactor, or rewrite those, one at a time, in accordance with more stringent coding standards. Make sure to write plenty of tests around anything you write, or improve.



This should see your work life improving slowly and steadily, as this approach will get your more familiar with the application, improve the readability of parts of it, and make bugs less common.



How to sell this to the owner/leader/boss will vary widely depending on the corporate structure and personalities involved. But if this really is unbearable for you, and you get no power to improve things, then finding a different kind of job might be for the better.



In general it seems like consultants will in general work on more recent code, and they do have more flexibility in being moved from one project to another, or to focus primarily on new(ish) applications.



However, legacy code will always be a part of your chosen profession, and you are going to have to learn to get along with it, and live with that fact.






share|improve this answer























  • 37





    Nice answer. Just one small part to add: If you go and rework the code, make sure to also add proper documentation, to not leave the next poor soul in the same situation you find yourself in now. Justify it to your boss(es) by the time lost by anyone new having to first understand wtf is going on in the code, the amount of bugs that produces, etc.

    – Dirk
    Jul 5 at 12:46






  • 13





    I also want to add that refactoring doesn't really need to be something that is a big task unto itself. It should be part of the development process as you go. You'll very rarely be able to take on a week to rewrite a major section of code, but 15 minutes to refactor a bloated function you have to work with as part of a 4 hour task should be considered part of the task.

    – Derek H
    Jul 5 at 19:51






  • 4





    I wouldn’t hope that the permission to rewrite anything is ever given. This NEVER happens just because some developer thinks the code sucks. There must be a real problem the management suffers from and a powerful senior technician who can sell his idea. Very rare specimen.

    – Mateusz Stefek
    Jul 6 at 5:16






  • 1





    -1 for "rewrite". joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i "Refactor" is the way to go.

    – ivan_pozdeev
    Jul 8 at 3:23






  • 3





    @ivan_pozdeev While I in general agree that rewrite is something to be avoided if you can, some stuff is just too far gone and refactoring a bad enough mess is far more costly than simply rewriting it from scratch (see: pragmatic programmer).

    – Stig Tore
    Jul 8 at 5:50


















49


















Yes it is reasonable to tell your manager you are not enjoying your work and to ask for something fun.



It is also reasonable for that manager to ask you to stick it out. There is a job that needs to be done and the job can't be all fun all the time.



A good manager will realize that they are burning your usefulness and willingness to work for them and will try to arrange for you to spend some time on different projects but this is no guarantee! If you are the only developer who can do this job you just might be stuck there.



To help this course of action it is a good idea to prepare some thing that you would like to spend your time on: those projects you started, maybe some other project or even a course to improve your skills. This will help turn a request into a Plan.



A bad manager will resent you because "he complains about stupid things", this is unreasonable but you wouldn't be the first to receive pushback.



To prevent this, have a concrete list of things that make the job Not Fun: stupid bugs, repeat tickets, un-commented code. This turns a complaint into Feedback and will make your questions sound more reasonable.






share|improve this answer





















  • 23





    "the job can't be all fun all the time" +1 just for that. If it was all fun, we wouldn't have to be paid to do it.

    – MadHatter
    Jul 6 at 9:01







  • 5





    @MadHatter Conversely, there's a saying that success is finding something you love, and getting paid to do it.

    – Barmar
    Jul 6 at 17:19






  • 7





    @Barmar that is one of those sayings that just lead to disappointment. The people who enjoy every phase of their job are very rare so aiming for that just leads to frustration. It is far better for your general life enjoyment to accept that every job has its speedbumps as long as the road also contains flat bits.

    – Borgh
    Jul 6 at 19:16






  • 2





    @Borgh You can't expect to enjoy every phase. I love computers and have had a long career of people paying me to work with them. While I've occasionally had to do tasks I wasn't enthusiastic about, mostly it's been fun. It's not like digging ditches or hauling garbage, which no one would do if not for needing the money.

    – Barmar
    Jul 6 at 23:13






  • 5





    stupid bugs, repeat tickets, un-commented code. Yeah, but now put yourself in the manager's shoes. They can't do anything about those problems - stupid bugs and bad code exist in the codebase. It's the programmer's job to correct them. Bringing a list like this to a manager is like a janitor complaining about people making a mess all day and wouldn't it be great if they didn't have to keep cleaning it up. Well, that's the job. Fixing those things is the responsibility of whatever developers are currently on staff.

    – J...
    Jul 7 at 17:39


















27



















My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?




No it would not be reasonable. Part of being a programmer is maintaining existing programs whether its adding/removing features or fixing errors. You were lucky to have worked on some projects that you started from scratch but you cannot expect every project to be this way. Sometimes, for a period of time, the business does not need new projects started from scratch ( that is not saying that they never will again ) and they just need to maintain the existing projects.



What you should do is take ownership of your current project. Forget about the fact that it is 6 years old and 5 other programmers worked on it. If it is messy and full of bugs then take the initiative to fix the project. You will certainly look better in the eyes of your manager if you successfully bring the project to a stable state instead of complaining about having to do work on this project and trying to have different work assigned to you.






share|improve this answer





















  • 4





    Sometimes indeed you just have to suck it up and do your job. I can't speak for other countries, but here in the Netherlands there's a huge demand for software developers. Managers and companies in general will try to keep you happy with your job. Expressing you are unhappy with your current project is not at all unreasonable, because it can lead to several things: burn-outs, increased stress, or quitting the job. Employers want to prevent that, and will assist in making and keeping the employee happy.

    – Edwin Lambregts
    Jul 5 at 13:13






  • 5





    Note that having someone who was still in school when the program was designed come along and randomly decide to rewrite large portions of code just because they think it's messy and hard to understand might not be well received by everyone -- I'd "read the room" before proposing this; presentation is everything.

    – A C
    Jul 6 at 4:39






  • 2





    +1 for taking ownership. Maintaining is not fun, I agree. But refactoring is / can be fun. Learn what others did wrong, split it up into senseful parts, then do it the way you think it´s done right. Of course talking about being unnerved by one´s job is always reasonable to tell, though. But in preparation for such a meeting OP should prepare a plan how much better the world could be if it was refactored. If this wish to make the job a good job is rejected, leaving is still a plan B...

    – Jessica
    Jul 6 at 19:54











  • It is reasonable to speak up. Some developers thrive on maintaining legacy code, some thrive on creating new things. Forcing a square peg into a round hole just because the hole needs to be filled is bad management. Who is going to do a better job, the dev that loves legacy dev, or the dev that hates it but is being forced to do it?

    – bob
    Jul 8 at 15:32











  • @EdwinLambregts sure there is demand, but that doesn't mean that there isn't also a massive pool of programmers to choose from. Problem is that most of that pool is low quality programmers unwilling and/or incapable of doing what needs doing. People for example who are unwilling to dig into a large old code base and fixing problems as they pop up... Which btw happens to be something I do like :)

    – jwenting
    Jul 9 at 3:35


















16


















You can always ask, but they can always say no, too.



Unless you have it in your contract that you will only work on projects you like, they can put you on projects as they see fit.



You could document the changes you would want to make (refactoring, writing documentation, ...) and the benefits for the company in terms of time gained through less bugs.



Or you could argue for a new development of the product with better practises. But as long as the old project has paying users somebody has to maintain it and they chose you Pikachu.



You could argue to get more people to do what you are doing (Bus-factor) so that you can work on other projects as well. If these become more important than the legacy project those might become an out.



But again: As long as there are people paying your firm and in extension paying your bosses wages for this project, and your firm isn't inclined to give this up, somebody will have to fix the bugs.



You could quit and work as a freelancer as a last resort. There you can really pick the projects you are working on but be prepared to have to do some projects you don't really like to keep the lights on. Only the best and best-known can cherrypick what they do completely.






share|improve this answer

































    8


















    tl;dr: Be honest with your employer. Tell them you're only interested in greenfield projects. Note however, that making this decision will significantly limit the work you'll get offered, possibly to the point that your services are no longer required.



    One of the most important things in professional software development is collaboration on a shared codebase. Unless you're a rock star soloist, the codebase will always have a history, shaped by past and present colleagues – and possibly also yourself in the past.



    As you've already mentioned, reading code is much more difficult than writing it – which is exactly why this skill is so important. It takes a lot of skill and patience to learn and understand the nooks and crannies of an existing project. It's easier – and granted, more pleasant for the developer – to start things anew, possibly even choosing the technologies and frameworks used.



    Commercial software always serves a business purpose. This means that – unless you're only working with startups or marketing – software should have a reasonable life expectancy. The developers who go the extra mile to familiaze with existing solutions, and especially, existing business interests, are the ones who make themselves valueable – and often difficult to replace.



    As you've pointed out, legacy code isn't always (ever?) easy to work with, bug-free or clean. What I'd suggest you to consider, is to turn things the other way around: Each impossible snippet of spaghetti copy-pasta is an opportunity for a great refactor with unit tests; each bug report is a chance to impress the business and the end users with impeccable customer service.






    share|improve this answer




























    • Good answer. The only thing I'd add is that despite the last paragraph, some devs (like myself), simply will always hate maintaining legacy code. The frustration of navigating an unintelligible mess and spending more down time than up time is just something that some devs can't overcome. So if OP is one of those, then the first paragraph is the best advice for them, and might even wind up meaning applying for a new job, which would then be good.

      – bob
      Jul 8 at 15:35


















    7


















    My team currently maintains two products that came to belong to our company when our company bought out the original developers. The reason these purchases were possible is because the other companies were not doing well financially.



    I work on only one of the two products. Early on it was like being a taxidermist working on road kill. The original coding team should never be allowed to touch computers ever again. My supervisor is responsible for the other product, and it is also a disaster.



    The chief benefit of working on these dumpster fires is that we are getting good solid lessons on how not to do things, and even with three years in industry you are learning something like this from the products you are working on.



    So stop looking at your situation as something that you should not have to deal with, and instead look at it as how you are going to make your company's product better than it was.



    As an easy first step, every time you have to puzzle out what a piece of code does, put comments in the code explaining exactly what the code is doing. It may not help you—although I find that it greatly helps me—but the next person to look at the code won't have to puzzle it out.






    share|improve this answer




























    • In a similar vein, Micheal Feather's 'Working Effectively with Legacy Code' has been an amazing resource, and has aged really well - the theory behind adding 'seams' to your code so you can wrap parts of it in tests so you have confidence in the code behaving as you expect (even if you have to discover what it should do) changes your whole experience with 'legacy code'. And the definition of Legacy code simply being 'code without sufficient tests' applies to some 'greenfield' projects I've seen...

      – Cinderhaze
      Jul 8 at 19:58











    • and quite often that poor code is no worse than the code you yourself created several years ago... And for juniors especially, the code is likely better than what they themselves are creating RIGHT NOW, they just don't realise it because they don't understand code that isn't designed according to the rigid patterns and paradigms that they got poured into their head during programming classes.

      – jwenting
      Jul 9 at 3:37


















    6


















    Lots of great answers already, but adding my £0.02.



    Maintaining older software is more difficult than building something new, it's also a valuable skill in itself.



    Being able to jump into a codebase that has been around for years, with bad or no documentation and featuring lots of different coding styles from the many developers who worked on it is something many employers, particularly in the enterprise world, actively look for.



    If there is no documentation, then write some. If there are no automated tests, then work on refactoring the code so it's testable and write some tests. If the coding styles are all over the place, then research the recommended styles for the language or framework and work on refactoring the codebase to match the recommended coding style.



    Gaining a reputation as being somebody who is happy to work with legacy code, and who does it well, can be as good for your career as working on greenfield projects with the new and shiny frameworks.



    As time goes on, the amount of legacy code in production is only going to increase, and demand for developers who can look after it, fix bugs and add new features is going to increase along with it, as rewriting those applications with new tech is generally considered to be a bad idea for lots of good reasons.



    Good luck!






    share|improve this answer

































      6


















      Legacy maintenance builds the developer's desire for good practice



      I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it.



      I'll use a practical example to make my case. As a consultant, I am often sent into a company/project with code quality issues, where my job is to make things right. As you would suspect, bad code leads to a lot of legacy maintenance.



      It has been my predominant experience that developers who write bad code are in one of two camps:



      • Those who didn't know any better

      • Those who think they are doing the right thing

      The former group is easy to deal with, as they will immediately improve when you show them good practice. The latter group, however, is much harder to convince as they do not see the benefit of good practice, which often takes more effort in the short term. It pays back dividends in the long run, but the latter group often misses that point.



      Almost every developer I've dealt with who was in the latter camp were developers who managed to jump from project to project skipping the maintenance of their own code. Because they were never faced with the fallout from their imperfect design decisions, they were never incentivized to try and avoid these problems from occurring before they happened, when the application was initially being built.



      The solution is simple: developers must take ownership. If you write buggy code, you will deal with the bugs that ensue. If you don't want to spend your time fixing bugs, then it's up to you to write code that does not produce them.

      This creates a very simple incentive for developers to improve themselves, as opposed to being pushed into it against their will and without their understanding of why it is the better approach.



      What I want you to take away from this is that legacy maintenance is essential for developers to remember why they need good practice.

      As an analogy, a general who is in the trenches with his men will make better decisions (for the soldiers) than a general who is sitting comfortably in a palace on the other side of the country. A developer needs to get their hands dirty so that when they are the general (= building the new application) they know what the impact of their design decisions are.




      Cleaning up after others



      You, however, are not faced with your own bugs, but rather those of the people that came before you. I am currently in the same boat, and I do agree with you that this is not a tenable situation.

      Nobody likes legacy maintenance, and it would appear that your manager has not taken into consideration how you solely doing legacy maintenance is both impacting your morale and your personal career development.



      I spent 3 years doing legacy maintenance, but it was a cushy job with an very loose working from home policy. It took me a while to understand that while the work/life balance was not bad, my career was stalling because I was not gaining topical knowledge to the industry. If I had been fired from that job after 5 years, my skillset would be so outdated for other companies that I'd have to scramble to make up for lost time.



      On the other hand, someone has to support this project. So you can't just take a "not me" approach, because every developer will tout the same "not me" approach and then management is liable to just appoint someone to have drawn the short straw (this may be how you ended up in this position to begin with).




      Addressing the issue



      Approach your manager and explain to him that while you understand that the legacy project requires support, it is a drain on morale when you do nothing but deal with the old code. Ask if your manager would consider assigning you to a different (non-legacy) project part time.



      In my experience, most reasonable managers will understand this (you were probably assigned to this because the other 5 developers who left all argued the same point) and will see the benefit of keep you (someone who already knows the legacy project) on the project part time, as opposed to having you leave and needing to find a new developer who doesn't know the legacy project.



      But in my same experience, there are also companies where employee morale is considerably lower on the list of priorities, where they employ a more rigorous "you do what we tell you to do" approach.

      The only advice I can give here is to leave such a toxic environment. Don't let your career waste away working a job you hate for a company who doesn't value your work satisfaction (to a reasonable degree).






      share|improve this answer


























      • Third camp: Developers who are past deadline because management consistently makes promises based on underestimates of the time required for development. Deadlines are the bane of software quality.

        – EvilSnack
        Jul 9 at 3:43












      • @EvilSnack: Hands down, I agree that this is usually how things start out (it's either that or simply a lack of guidance for juniors). But over time, that persistent environment breeds developers who only work like that even at times where they have the luxury of time to do it better. The most common feedback I have to give is that both mgmt and the devs are to blame. Mgmt creates an environment where the devs have learned to use bad practice out of sheer practicality.

        – Flater
        Jul 9 at 8:11












      • @EvilSnack Once, I joined development as an external contractor. After the first day, I asked for the deadline. The answer was: last week. It took a year or so.

        – Volker Siegel
        Jul 9 at 9:25


















      3


















      If you don't like what you're working on, then leave for another company. Programmers are in high demand.



      Make sure you find up-front about the types of working you'll be doing. I won't criticise anyone for leaving in your situation, it sounds awful. But if you were hired knowing you'd be working on this type of project, then it would be in poor taste to complain about it.



      There is rarely much scope for changing your day to day work within a company, those things tend to be long term, and they are almost always inferior to simply finding another job doing something you want to be doing.






      share|improve this answer





















      • 2





        This is very much the right answer. If you only want to do greenfield development your best bets are to either work for a startup, or work for a company doing consulting/contracting work for small businesses where you'd spend a few months making the a website/etc and then the contract would end and you'd go on to do another project for a different customer.

        – Dan Neely
        Jul 5 at 22:33






      • 8





        Other companies will also have legacy code, so changing jobs is no guarantee to fix this at all.

        – Mark Rotteveel
        Jul 6 at 9:57











      • As I said though, work out what you want and discuss in the interview of a the new job what you'll be expected to do. If you're up-front you'll be much less likely to end up in a situation you don't like.

        – NibblyPig
        Jul 8 at 7:57


















      3


















      It depends on the company. In my last job, my company offers IT solutions to government and banks. So everytime it is a new tender and a new project. I belongs to development team, which takes part in bidding, designing and implementing projects. After production release, the maintenance team will take over and will only contact us with issues they cannot handle. So a company of a different nature may be a solution.



      But, you can view your situation in a different light.



      If the software you are maintaining is bad, then fix it. If it is beyond fixing, explains to your supervisor why it is so, and propose a solution.



      What you consider a bad situation, could be instead a chance to show your supervisor what you are capable of.



      If your supervisor sees you in a positive light, you'd have a much better chance to get assigned to the projects you want to do, or persuade him/her to reassign you.



      In my current 2-year contract job, I'm maintaining bad software like you. The original vendor is long gone and code quality is bad. My supervisor is reluctant to big changes as the company culture is very reserved and they hate taking risks. I presented the pros and cons of various options to fix the part I am working on, it took me lots of effort but I eventually won them over. A few months in, my supervisor is talking about offering me a permanent position.



      Heroes rise from the occasion.






      share|improve this answer



































        2


















        Put yourself in the other shoes
        You know your manager, he listen to his team? Is a reasonable manager? Try to satisfy developers needs? Is communicative?
        This is very important, your manager has a role...get the job done, present results. And for that, someone has to take care of the legacy project.



        • Does he has another replacement?

        • Does he has another project more attractive to your preferences that give you motivation, maybe a 50% of your time?.

        • Can he give you green light to recreate some part of the project?

        You don't know for certain.... so, yes, you have to talk to him. Not in a demanding way, no if you like the workplace. But you have to talk to him about your discomfort, because employees leaving is not a good result either, ... no company/manager get benefit for a developer resign. And you are not asking him more money, or less hours, or telecommute, or something that interfere with the company policies/resources. It's something about trying reorganize allocations of the team, it´s more 'doable'. And you are not getting fired for let him know about a discomfort. But the only one that can help to resolve your discomfort is him, if you want to stay there of course.



        Ask him for a short private meeting.
        Be relax, no angry emotions, no demanding tones.
        This is a conversation with a team member that can help you find a solution to a discomfort.



        Even if he does nothing for you, and nothing can be done. It´s not in your hands, you did what you could to be moved. Because if you say nothing and find a new job, in the moment you say to him, the first thing is going to tell you is 'I didn't now you felt this way, we could try to work this out'. When you leave a company for money, you ask a rise first, this is the same, before start to look for jobs, let them a chance to find a solution where both interests get satisfied. Think in a way that you get motivation at the same time you provide value to the team/client






        share|improve this answer

































          2


















          There's a good chance you might benefit from hearing my story, so here goes.



          I was hired at my company to work on one particular project (partly because I was the only guy they interviewed that knew electronics at all, but that ended up being largely irrelevant). On having worked on it for about six months I came to the conclusion the architecture was a total loss despite the codebase being only a year and a half old at that point. I thought at the time I was looking at a three year old codebase and the company had a history of bad source control practices. In fact their source control use was kinda ok (it got better) and the product was made by big bang production.



          I reported by analogy the foundation was cracked and the ground was unstable. In fact a total rewrite was required but it could not be afforded at that time and I knew it. We agreed by analogy that as it became necessary I would ram I-beams through the foundation to serve as pylons. Over the next decade as things broke or became unsustainable or the profiler located hotspots I replaced almost all the original architecture, to the point were now only a couple dozen lines remain. But now the I-beams themselves have cracked and been braced and the house-become-skycraper is showing its age and again become hard to work on and I dread teaching new programmers all that is required to add new tables to the database as no good examples remain. Every explanation for how things work has become a history lesson now.



          I don't work on the product much anymore, but whenever a change needs to be made that breaks the rules of the architecture, I do it, not because only I can do it, but because I know essentially all the rules in my head and therefore can pick the way easiest to maintain the consequences thereof.



          But only now do I have the experience to do actually to it right and design an architecture that can actually be maintained for twenty years or more. Some of the problems are bad decisions of the original architecture where I replaced the implementation with a work-nearly-alike retaining many of the same decisions. Some of the problems are my own bad decisions. And the industry has changed and we want to replace the fat-client architecture with a web architecture. You know what, now's the time. I don't have the full set of skills for a web architecture but I've got most of them and I know where to turn for the rest.



          The choice really has to be yours, but you may have here the place to run I-beams through the foundation. If you choose to do so, you're gonna learn and become strong.






          share|improve this answer

































            2


















            Make sure you know yourself before doing anything drastic



            Three years is still pretty junior, so I wouldn't do anything drastic like changing jobs or careers until you've made sure you know what it is about maintaining legacy code that you don't like. For example, it's possible that you need to learn a new tool or technique, and that you can actually learn to like maintaining legacy code. If you have a mentor, this would be a good thing to discuss with them. If you don't have a mentor, you should try to find one.



            Unhappy = poor performance = career hit = time to change



            Once you're sure it's not you, it's the job, then realize that you will only do your best work if you're happy, or at least satisfied with your job. If you are actively unhappy or hate your job, it's going to show in your work. This will hurt your career in the long run. So you're not doing yourself any favors staying in a situation that actively makes you unhappy (sometimes we don't have any choice, but if you do, and most of the time we do, then you need to make a change).



            What should you do?



            Tell your boss your preferences, and if your boss can't or won't honor them in a reasonable time frame, find a job that can and will. Note that almost no job (including if you're your own boss) will meet your preferences 100% of the time; that's just life. But a good fit is one that is acceptable to you and mixes tasks that you like with some tasks that you can at least tolerate. But if you find yourself hating your job, it's time for a change.



            One last thing



            If you're working long hours or working weekends without adequate breaks, then you could be experiencing burnout, which can make even the most pleasant tasks feel like chores and boring tasks feel unbearable. So part of taking stock of your situation includes making sure that your hatred for your job is really coming from the work and not from burnout-induced stress. If the problem turns out to be burnout, it needs to be addressed differently than if it is simply not liking your job.






            share|improve this answer



































              1


















              Here is a strategy that you could use. But, be careful, this could put you in an unfavorable position with your manager.



              Tell them that certain modules are crap and need to be re-written from scratch, you are unable to band-aid them. He/she might find someone else, or let you re-write. If you can re-write, it is almost like a new project, you should be happy.



              I have seen both sides of this. I have re-written lousy code that would take me longer to understand and fix than re-write. And I have seen people re-write code that I thought was OK and maintainable (and break my budget).






              share|improve this answer





















              • 1





                There has to be a balance. If the project is deployed, then bugs have to be fixed and user concerns have to be addressed. But also, there has to be forward progress in improving code quality and maintainability or the code will become unmaintainable. If forward progress isn't being made (or worse, the code is acquiring more "quick fixes" and getting worse) then more resources need to be assigned. With luck, a good balance between keeping the code working and keeping the code improving can be negotiated with management.

                – David Schwartz
                Jul 5 at 23:08


















              1


















              After a few times I discovered that I begin "hating" some code base, I started researching why.



              And found out that it's because it has some drawbacks that are constantly bothering me and remain unfixed. The bother is thus building up and...



              So the way to elminate that "hate" is to identify and fix the things that are bothering you about that code!



              What is most important, you already know them (since they are bothering you) but didn't care to prioritize.



              You named a few already: "it's not easy to understand code, especially if there's no documentation." When examining the code, you must have identified that these and these parts are sloppy and error-prone; here and here, there are no tests so no way to know if the code is (still) correct in all cases, etc.






              share|improve this answer





















              • 1





                This is good advice, though sometimes what you "hate" is person-years worth of technical debt that one person cannot feasibly fix unfortunately. Which is likely I think for many large legacy codebases. So it may not be avoidable in many situations.

                – bob
                Jul 8 at 15:37











              • @bob still, it's better from psychological POV to fix one thing at a time and feel better than waste your nerve cells doing nothing. Then, technical debt is taxing the ongoing maintenance and is thus only not worth paying off if the product is near its EOL. For OP's case, this doesn't seem to be the case (since they say they are maintaining it on an ongoing basis with no end date in sight).

                – ivan_pozdeev
                Jul 8 at 15:54











              • True. If you're stuck in the situation or while waiting to get out of it, then that's a good strategy (again if you can; sometimes you're told not to touch a particular piece of code). But at the end of the day its best to do work you find satisfying. You'll do the best work and it will show in your career.

                – bob
                Jul 8 at 16:00


















              1


















              I went through this for a long time. It became something unbearable.



              Unfortunately, work consumes most of your day time and it's very disgusting to wake up thinking you'll be around a lot of bad code. It's a bad feeling.



              I love to create and invent; that's why I became a programmer a long time ago. I'm not a genius either, brilliant but rather creative.



              Now that you have experience, quit your job and look for one that better deserves your devotion. I did it 2 months ago and now I can't understand why I didn't do it before.






              share|improve this answer



























                protected by mcknz Jul 7 at 1:31



                Thank you for your interest in this question.
                Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                Would you like to answer one of these unanswered questions instead?














                16 Answers
                16






                active

                oldest

                votes








                16 Answers
                16






                active

                oldest

                votes









                active

                oldest

                votes






                active

                oldest

                votes









                151


















                Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project.



                However, there are things you can do to maybe make your life and future a bit more livable. I'd start with mentally breaking down the current project into modules, and then asking for permission to refactor, or rewrite those, one at a time, in accordance with more stringent coding standards. Make sure to write plenty of tests around anything you write, or improve.



                This should see your work life improving slowly and steadily, as this approach will get your more familiar with the application, improve the readability of parts of it, and make bugs less common.



                How to sell this to the owner/leader/boss will vary widely depending on the corporate structure and personalities involved. But if this really is unbearable for you, and you get no power to improve things, then finding a different kind of job might be for the better.



                In general it seems like consultants will in general work on more recent code, and they do have more flexibility in being moved from one project to another, or to focus primarily on new(ish) applications.



                However, legacy code will always be a part of your chosen profession, and you are going to have to learn to get along with it, and live with that fact.






                share|improve this answer























                • 37





                  Nice answer. Just one small part to add: If you go and rework the code, make sure to also add proper documentation, to not leave the next poor soul in the same situation you find yourself in now. Justify it to your boss(es) by the time lost by anyone new having to first understand wtf is going on in the code, the amount of bugs that produces, etc.

                  – Dirk
                  Jul 5 at 12:46






                • 13





                  I also want to add that refactoring doesn't really need to be something that is a big task unto itself. It should be part of the development process as you go. You'll very rarely be able to take on a week to rewrite a major section of code, but 15 minutes to refactor a bloated function you have to work with as part of a 4 hour task should be considered part of the task.

                  – Derek H
                  Jul 5 at 19:51






                • 4





                  I wouldn’t hope that the permission to rewrite anything is ever given. This NEVER happens just because some developer thinks the code sucks. There must be a real problem the management suffers from and a powerful senior technician who can sell his idea. Very rare specimen.

                  – Mateusz Stefek
                  Jul 6 at 5:16






                • 1





                  -1 for "rewrite". joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i "Refactor" is the way to go.

                  – ivan_pozdeev
                  Jul 8 at 3:23






                • 3





                  @ivan_pozdeev While I in general agree that rewrite is something to be avoided if you can, some stuff is just too far gone and refactoring a bad enough mess is far more costly than simply rewriting it from scratch (see: pragmatic programmer).

                  – Stig Tore
                  Jul 8 at 5:50















                151


















                Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project.



                However, there are things you can do to maybe make your life and future a bit more livable. I'd start with mentally breaking down the current project into modules, and then asking for permission to refactor, or rewrite those, one at a time, in accordance with more stringent coding standards. Make sure to write plenty of tests around anything you write, or improve.



                This should see your work life improving slowly and steadily, as this approach will get your more familiar with the application, improve the readability of parts of it, and make bugs less common.



                How to sell this to the owner/leader/boss will vary widely depending on the corporate structure and personalities involved. But if this really is unbearable for you, and you get no power to improve things, then finding a different kind of job might be for the better.



                In general it seems like consultants will in general work on more recent code, and they do have more flexibility in being moved from one project to another, or to focus primarily on new(ish) applications.



                However, legacy code will always be a part of your chosen profession, and you are going to have to learn to get along with it, and live with that fact.






                share|improve this answer























                • 37





                  Nice answer. Just one small part to add: If you go and rework the code, make sure to also add proper documentation, to not leave the next poor soul in the same situation you find yourself in now. Justify it to your boss(es) by the time lost by anyone new having to first understand wtf is going on in the code, the amount of bugs that produces, etc.

                  – Dirk
                  Jul 5 at 12:46






                • 13





                  I also want to add that refactoring doesn't really need to be something that is a big task unto itself. It should be part of the development process as you go. You'll very rarely be able to take on a week to rewrite a major section of code, but 15 minutes to refactor a bloated function you have to work with as part of a 4 hour task should be considered part of the task.

                  – Derek H
                  Jul 5 at 19:51






                • 4





                  I wouldn’t hope that the permission to rewrite anything is ever given. This NEVER happens just because some developer thinks the code sucks. There must be a real problem the management suffers from and a powerful senior technician who can sell his idea. Very rare specimen.

                  – Mateusz Stefek
                  Jul 6 at 5:16






                • 1





                  -1 for "rewrite". joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i "Refactor" is the way to go.

                  – ivan_pozdeev
                  Jul 8 at 3:23






                • 3





                  @ivan_pozdeev While I in general agree that rewrite is something to be avoided if you can, some stuff is just too far gone and refactoring a bad enough mess is far more costly than simply rewriting it from scratch (see: pragmatic programmer).

                  – Stig Tore
                  Jul 8 at 5:50













                151














                151










                151









                Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project.



                However, there are things you can do to maybe make your life and future a bit more livable. I'd start with mentally breaking down the current project into modules, and then asking for permission to refactor, or rewrite those, one at a time, in accordance with more stringent coding standards. Make sure to write plenty of tests around anything you write, or improve.



                This should see your work life improving slowly and steadily, as this approach will get your more familiar with the application, improve the readability of parts of it, and make bugs less common.



                How to sell this to the owner/leader/boss will vary widely depending on the corporate structure and personalities involved. But if this really is unbearable for you, and you get no power to improve things, then finding a different kind of job might be for the better.



                In general it seems like consultants will in general work on more recent code, and they do have more flexibility in being moved from one project to another, or to focus primarily on new(ish) applications.



                However, legacy code will always be a part of your chosen profession, and you are going to have to learn to get along with it, and live with that fact.






                share|improve this answer
















                Unfortunately maintenance is the rule when working in IT, very rarely are there new projects, and people get reassigned around projects regularly. And while the quality of the code you will have to maintain in your professional life will vary widely, they will never smell the same as a fresh 2-6 month old project.



                However, there are things you can do to maybe make your life and future a bit more livable. I'd start with mentally breaking down the current project into modules, and then asking for permission to refactor, or rewrite those, one at a time, in accordance with more stringent coding standards. Make sure to write plenty of tests around anything you write, or improve.



                This should see your work life improving slowly and steadily, as this approach will get your more familiar with the application, improve the readability of parts of it, and make bugs less common.



                How to sell this to the owner/leader/boss will vary widely depending on the corporate structure and personalities involved. But if this really is unbearable for you, and you get no power to improve things, then finding a different kind of job might be for the better.



                In general it seems like consultants will in general work on more recent code, and they do have more flexibility in being moved from one project to another, or to focus primarily on new(ish) applications.



                However, legacy code will always be a part of your chosen profession, and you are going to have to learn to get along with it, and live with that fact.







                share|improve this answer















                share|improve this answer




                share|improve this answer








                edited Jul 6 at 1:56









                JakeGould

                8,9621 gold badge23 silver badges43 bronze badges




                8,9621 gold badge23 silver badges43 bronze badges










                answered Jul 5 at 9:57









                Stig ToreStig Tore

                1,2451 gold badge5 silver badges8 bronze badges




                1,2451 gold badge5 silver badges8 bronze badges










                • 37





                  Nice answer. Just one small part to add: If you go and rework the code, make sure to also add proper documentation, to not leave the next poor soul in the same situation you find yourself in now. Justify it to your boss(es) by the time lost by anyone new having to first understand wtf is going on in the code, the amount of bugs that produces, etc.

                  – Dirk
                  Jul 5 at 12:46






                • 13





                  I also want to add that refactoring doesn't really need to be something that is a big task unto itself. It should be part of the development process as you go. You'll very rarely be able to take on a week to rewrite a major section of code, but 15 minutes to refactor a bloated function you have to work with as part of a 4 hour task should be considered part of the task.

                  – Derek H
                  Jul 5 at 19:51






                • 4





                  I wouldn’t hope that the permission to rewrite anything is ever given. This NEVER happens just because some developer thinks the code sucks. There must be a real problem the management suffers from and a powerful senior technician who can sell his idea. Very rare specimen.

                  – Mateusz Stefek
                  Jul 6 at 5:16






                • 1





                  -1 for "rewrite". joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i "Refactor" is the way to go.

                  – ivan_pozdeev
                  Jul 8 at 3:23






                • 3





                  @ivan_pozdeev While I in general agree that rewrite is something to be avoided if you can, some stuff is just too far gone and refactoring a bad enough mess is far more costly than simply rewriting it from scratch (see: pragmatic programmer).

                  – Stig Tore
                  Jul 8 at 5:50












                • 37





                  Nice answer. Just one small part to add: If you go and rework the code, make sure to also add proper documentation, to not leave the next poor soul in the same situation you find yourself in now. Justify it to your boss(es) by the time lost by anyone new having to first understand wtf is going on in the code, the amount of bugs that produces, etc.

                  – Dirk
                  Jul 5 at 12:46






                • 13





                  I also want to add that refactoring doesn't really need to be something that is a big task unto itself. It should be part of the development process as you go. You'll very rarely be able to take on a week to rewrite a major section of code, but 15 minutes to refactor a bloated function you have to work with as part of a 4 hour task should be considered part of the task.

                  – Derek H
                  Jul 5 at 19:51






                • 4





                  I wouldn’t hope that the permission to rewrite anything is ever given. This NEVER happens just because some developer thinks the code sucks. There must be a real problem the management suffers from and a powerful senior technician who can sell his idea. Very rare specimen.

                  – Mateusz Stefek
                  Jul 6 at 5:16






                • 1





                  -1 for "rewrite". joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i "Refactor" is the way to go.

                  – ivan_pozdeev
                  Jul 8 at 3:23






                • 3





                  @ivan_pozdeev While I in general agree that rewrite is something to be avoided if you can, some stuff is just too far gone and refactoring a bad enough mess is far more costly than simply rewriting it from scratch (see: pragmatic programmer).

                  – Stig Tore
                  Jul 8 at 5:50







                37




                37





                Nice answer. Just one small part to add: If you go and rework the code, make sure to also add proper documentation, to not leave the next poor soul in the same situation you find yourself in now. Justify it to your boss(es) by the time lost by anyone new having to first understand wtf is going on in the code, the amount of bugs that produces, etc.

                – Dirk
                Jul 5 at 12:46





                Nice answer. Just one small part to add: If you go and rework the code, make sure to also add proper documentation, to not leave the next poor soul in the same situation you find yourself in now. Justify it to your boss(es) by the time lost by anyone new having to first understand wtf is going on in the code, the amount of bugs that produces, etc.

                – Dirk
                Jul 5 at 12:46




                13




                13





                I also want to add that refactoring doesn't really need to be something that is a big task unto itself. It should be part of the development process as you go. You'll very rarely be able to take on a week to rewrite a major section of code, but 15 minutes to refactor a bloated function you have to work with as part of a 4 hour task should be considered part of the task.

                – Derek H
                Jul 5 at 19:51





                I also want to add that refactoring doesn't really need to be something that is a big task unto itself. It should be part of the development process as you go. You'll very rarely be able to take on a week to rewrite a major section of code, but 15 minutes to refactor a bloated function you have to work with as part of a 4 hour task should be considered part of the task.

                – Derek H
                Jul 5 at 19:51




                4




                4





                I wouldn’t hope that the permission to rewrite anything is ever given. This NEVER happens just because some developer thinks the code sucks. There must be a real problem the management suffers from and a powerful senior technician who can sell his idea. Very rare specimen.

                – Mateusz Stefek
                Jul 6 at 5:16





                I wouldn’t hope that the permission to rewrite anything is ever given. This NEVER happens just because some developer thinks the code sucks. There must be a real problem the management suffers from and a powerful senior technician who can sell his idea. Very rare specimen.

                – Mateusz Stefek
                Jul 6 at 5:16




                1




                1





                -1 for "rewrite". joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i "Refactor" is the way to go.

                – ivan_pozdeev
                Jul 8 at 3:23





                -1 for "rewrite". joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i "Refactor" is the way to go.

                – ivan_pozdeev
                Jul 8 at 3:23




                3




                3





                @ivan_pozdeev While I in general agree that rewrite is something to be avoided if you can, some stuff is just too far gone and refactoring a bad enough mess is far more costly than simply rewriting it from scratch (see: pragmatic programmer).

                – Stig Tore
                Jul 8 at 5:50





                @ivan_pozdeev While I in general agree that rewrite is something to be avoided if you can, some stuff is just too far gone and refactoring a bad enough mess is far more costly than simply rewriting it from scratch (see: pragmatic programmer).

                – Stig Tore
                Jul 8 at 5:50













                49


















                Yes it is reasonable to tell your manager you are not enjoying your work and to ask for something fun.



                It is also reasonable for that manager to ask you to stick it out. There is a job that needs to be done and the job can't be all fun all the time.



                A good manager will realize that they are burning your usefulness and willingness to work for them and will try to arrange for you to spend some time on different projects but this is no guarantee! If you are the only developer who can do this job you just might be stuck there.



                To help this course of action it is a good idea to prepare some thing that you would like to spend your time on: those projects you started, maybe some other project or even a course to improve your skills. This will help turn a request into a Plan.



                A bad manager will resent you because "he complains about stupid things", this is unreasonable but you wouldn't be the first to receive pushback.



                To prevent this, have a concrete list of things that make the job Not Fun: stupid bugs, repeat tickets, un-commented code. This turns a complaint into Feedback and will make your questions sound more reasonable.






                share|improve this answer





















                • 23





                  "the job can't be all fun all the time" +1 just for that. If it was all fun, we wouldn't have to be paid to do it.

                  – MadHatter
                  Jul 6 at 9:01







                • 5





                  @MadHatter Conversely, there's a saying that success is finding something you love, and getting paid to do it.

                  – Barmar
                  Jul 6 at 17:19






                • 7





                  @Barmar that is one of those sayings that just lead to disappointment. The people who enjoy every phase of their job are very rare so aiming for that just leads to frustration. It is far better for your general life enjoyment to accept that every job has its speedbumps as long as the road also contains flat bits.

                  – Borgh
                  Jul 6 at 19:16






                • 2





                  @Borgh You can't expect to enjoy every phase. I love computers and have had a long career of people paying me to work with them. While I've occasionally had to do tasks I wasn't enthusiastic about, mostly it's been fun. It's not like digging ditches or hauling garbage, which no one would do if not for needing the money.

                  – Barmar
                  Jul 6 at 23:13






                • 5





                  stupid bugs, repeat tickets, un-commented code. Yeah, but now put yourself in the manager's shoes. They can't do anything about those problems - stupid bugs and bad code exist in the codebase. It's the programmer's job to correct them. Bringing a list like this to a manager is like a janitor complaining about people making a mess all day and wouldn't it be great if they didn't have to keep cleaning it up. Well, that's the job. Fixing those things is the responsibility of whatever developers are currently on staff.

                  – J...
                  Jul 7 at 17:39















                49


















                Yes it is reasonable to tell your manager you are not enjoying your work and to ask for something fun.



                It is also reasonable for that manager to ask you to stick it out. There is a job that needs to be done and the job can't be all fun all the time.



                A good manager will realize that they are burning your usefulness and willingness to work for them and will try to arrange for you to spend some time on different projects but this is no guarantee! If you are the only developer who can do this job you just might be stuck there.



                To help this course of action it is a good idea to prepare some thing that you would like to spend your time on: those projects you started, maybe some other project or even a course to improve your skills. This will help turn a request into a Plan.



                A bad manager will resent you because "he complains about stupid things", this is unreasonable but you wouldn't be the first to receive pushback.



                To prevent this, have a concrete list of things that make the job Not Fun: stupid bugs, repeat tickets, un-commented code. This turns a complaint into Feedback and will make your questions sound more reasonable.






                share|improve this answer





















                • 23





                  "the job can't be all fun all the time" +1 just for that. If it was all fun, we wouldn't have to be paid to do it.

                  – MadHatter
                  Jul 6 at 9:01







                • 5





                  @MadHatter Conversely, there's a saying that success is finding something you love, and getting paid to do it.

                  – Barmar
                  Jul 6 at 17:19






                • 7





                  @Barmar that is one of those sayings that just lead to disappointment. The people who enjoy every phase of their job are very rare so aiming for that just leads to frustration. It is far better for your general life enjoyment to accept that every job has its speedbumps as long as the road also contains flat bits.

                  – Borgh
                  Jul 6 at 19:16






                • 2





                  @Borgh You can't expect to enjoy every phase. I love computers and have had a long career of people paying me to work with them. While I've occasionally had to do tasks I wasn't enthusiastic about, mostly it's been fun. It's not like digging ditches or hauling garbage, which no one would do if not for needing the money.

                  – Barmar
                  Jul 6 at 23:13






                • 5





                  stupid bugs, repeat tickets, un-commented code. Yeah, but now put yourself in the manager's shoes. They can't do anything about those problems - stupid bugs and bad code exist in the codebase. It's the programmer's job to correct them. Bringing a list like this to a manager is like a janitor complaining about people making a mess all day and wouldn't it be great if they didn't have to keep cleaning it up. Well, that's the job. Fixing those things is the responsibility of whatever developers are currently on staff.

                  – J...
                  Jul 7 at 17:39













                49














                49










                49









                Yes it is reasonable to tell your manager you are not enjoying your work and to ask for something fun.



                It is also reasonable for that manager to ask you to stick it out. There is a job that needs to be done and the job can't be all fun all the time.



                A good manager will realize that they are burning your usefulness and willingness to work for them and will try to arrange for you to spend some time on different projects but this is no guarantee! If you are the only developer who can do this job you just might be stuck there.



                To help this course of action it is a good idea to prepare some thing that you would like to spend your time on: those projects you started, maybe some other project or even a course to improve your skills. This will help turn a request into a Plan.



                A bad manager will resent you because "he complains about stupid things", this is unreasonable but you wouldn't be the first to receive pushback.



                To prevent this, have a concrete list of things that make the job Not Fun: stupid bugs, repeat tickets, un-commented code. This turns a complaint into Feedback and will make your questions sound more reasonable.






                share|improve this answer














                Yes it is reasonable to tell your manager you are not enjoying your work and to ask for something fun.



                It is also reasonable for that manager to ask you to stick it out. There is a job that needs to be done and the job can't be all fun all the time.



                A good manager will realize that they are burning your usefulness and willingness to work for them and will try to arrange for you to spend some time on different projects but this is no guarantee! If you are the only developer who can do this job you just might be stuck there.



                To help this course of action it is a good idea to prepare some thing that you would like to spend your time on: those projects you started, maybe some other project or even a course to improve your skills. This will help turn a request into a Plan.



                A bad manager will resent you because "he complains about stupid things", this is unreasonable but you wouldn't be the first to receive pushback.



                To prevent this, have a concrete list of things that make the job Not Fun: stupid bugs, repeat tickets, un-commented code. This turns a complaint into Feedback and will make your questions sound more reasonable.







                share|improve this answer













                share|improve this answer




                share|improve this answer










                answered Jul 5 at 10:00









                BorghBorgh

                9,1846 gold badges24 silver badges31 bronze badges




                9,1846 gold badges24 silver badges31 bronze badges










                • 23





                  "the job can't be all fun all the time" +1 just for that. If it was all fun, we wouldn't have to be paid to do it.

                  – MadHatter
                  Jul 6 at 9:01







                • 5





                  @MadHatter Conversely, there's a saying that success is finding something you love, and getting paid to do it.

                  – Barmar
                  Jul 6 at 17:19






                • 7





                  @Barmar that is one of those sayings that just lead to disappointment. The people who enjoy every phase of their job are very rare so aiming for that just leads to frustration. It is far better for your general life enjoyment to accept that every job has its speedbumps as long as the road also contains flat bits.

                  – Borgh
                  Jul 6 at 19:16






                • 2





                  @Borgh You can't expect to enjoy every phase. I love computers and have had a long career of people paying me to work with them. While I've occasionally had to do tasks I wasn't enthusiastic about, mostly it's been fun. It's not like digging ditches or hauling garbage, which no one would do if not for needing the money.

                  – Barmar
                  Jul 6 at 23:13






                • 5





                  stupid bugs, repeat tickets, un-commented code. Yeah, but now put yourself in the manager's shoes. They can't do anything about those problems - stupid bugs and bad code exist in the codebase. It's the programmer's job to correct them. Bringing a list like this to a manager is like a janitor complaining about people making a mess all day and wouldn't it be great if they didn't have to keep cleaning it up. Well, that's the job. Fixing those things is the responsibility of whatever developers are currently on staff.

                  – J...
                  Jul 7 at 17:39












                • 23





                  "the job can't be all fun all the time" +1 just for that. If it was all fun, we wouldn't have to be paid to do it.

                  – MadHatter
                  Jul 6 at 9:01







                • 5





                  @MadHatter Conversely, there's a saying that success is finding something you love, and getting paid to do it.

                  – Barmar
                  Jul 6 at 17:19






                • 7





                  @Barmar that is one of those sayings that just lead to disappointment. The people who enjoy every phase of their job are very rare so aiming for that just leads to frustration. It is far better for your general life enjoyment to accept that every job has its speedbumps as long as the road also contains flat bits.

                  – Borgh
                  Jul 6 at 19:16






                • 2





                  @Borgh You can't expect to enjoy every phase. I love computers and have had a long career of people paying me to work with them. While I've occasionally had to do tasks I wasn't enthusiastic about, mostly it's been fun. It's not like digging ditches or hauling garbage, which no one would do if not for needing the money.

                  – Barmar
                  Jul 6 at 23:13






                • 5





                  stupid bugs, repeat tickets, un-commented code. Yeah, but now put yourself in the manager's shoes. They can't do anything about those problems - stupid bugs and bad code exist in the codebase. It's the programmer's job to correct them. Bringing a list like this to a manager is like a janitor complaining about people making a mess all day and wouldn't it be great if they didn't have to keep cleaning it up. Well, that's the job. Fixing those things is the responsibility of whatever developers are currently on staff.

                  – J...
                  Jul 7 at 17:39







                23




                23





                "the job can't be all fun all the time" +1 just for that. If it was all fun, we wouldn't have to be paid to do it.

                – MadHatter
                Jul 6 at 9:01






                "the job can't be all fun all the time" +1 just for that. If it was all fun, we wouldn't have to be paid to do it.

                – MadHatter
                Jul 6 at 9:01





                5




                5





                @MadHatter Conversely, there's a saying that success is finding something you love, and getting paid to do it.

                – Barmar
                Jul 6 at 17:19





                @MadHatter Conversely, there's a saying that success is finding something you love, and getting paid to do it.

                – Barmar
                Jul 6 at 17:19




                7




                7





                @Barmar that is one of those sayings that just lead to disappointment. The people who enjoy every phase of their job are very rare so aiming for that just leads to frustration. It is far better for your general life enjoyment to accept that every job has its speedbumps as long as the road also contains flat bits.

                – Borgh
                Jul 6 at 19:16





                @Barmar that is one of those sayings that just lead to disappointment. The people who enjoy every phase of their job are very rare so aiming for that just leads to frustration. It is far better for your general life enjoyment to accept that every job has its speedbumps as long as the road also contains flat bits.

                – Borgh
                Jul 6 at 19:16




                2




                2





                @Borgh You can't expect to enjoy every phase. I love computers and have had a long career of people paying me to work with them. While I've occasionally had to do tasks I wasn't enthusiastic about, mostly it's been fun. It's not like digging ditches or hauling garbage, which no one would do if not for needing the money.

                – Barmar
                Jul 6 at 23:13





                @Borgh You can't expect to enjoy every phase. I love computers and have had a long career of people paying me to work with them. While I've occasionally had to do tasks I wasn't enthusiastic about, mostly it's been fun. It's not like digging ditches or hauling garbage, which no one would do if not for needing the money.

                – Barmar
                Jul 6 at 23:13




                5




                5





                stupid bugs, repeat tickets, un-commented code. Yeah, but now put yourself in the manager's shoes. They can't do anything about those problems - stupid bugs and bad code exist in the codebase. It's the programmer's job to correct them. Bringing a list like this to a manager is like a janitor complaining about people making a mess all day and wouldn't it be great if they didn't have to keep cleaning it up. Well, that's the job. Fixing those things is the responsibility of whatever developers are currently on staff.

                – J...
                Jul 7 at 17:39





                stupid bugs, repeat tickets, un-commented code. Yeah, but now put yourself in the manager's shoes. They can't do anything about those problems - stupid bugs and bad code exist in the codebase. It's the programmer's job to correct them. Bringing a list like this to a manager is like a janitor complaining about people making a mess all day and wouldn't it be great if they didn't have to keep cleaning it up. Well, that's the job. Fixing those things is the responsibility of whatever developers are currently on staff.

                – J...
                Jul 7 at 17:39











                27



















                My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?




                No it would not be reasonable. Part of being a programmer is maintaining existing programs whether its adding/removing features or fixing errors. You were lucky to have worked on some projects that you started from scratch but you cannot expect every project to be this way. Sometimes, for a period of time, the business does not need new projects started from scratch ( that is not saying that they never will again ) and they just need to maintain the existing projects.



                What you should do is take ownership of your current project. Forget about the fact that it is 6 years old and 5 other programmers worked on it. If it is messy and full of bugs then take the initiative to fix the project. You will certainly look better in the eyes of your manager if you successfully bring the project to a stable state instead of complaining about having to do work on this project and trying to have different work assigned to you.






                share|improve this answer





















                • 4





                  Sometimes indeed you just have to suck it up and do your job. I can't speak for other countries, but here in the Netherlands there's a huge demand for software developers. Managers and companies in general will try to keep you happy with your job. Expressing you are unhappy with your current project is not at all unreasonable, because it can lead to several things: burn-outs, increased stress, or quitting the job. Employers want to prevent that, and will assist in making and keeping the employee happy.

                  – Edwin Lambregts
                  Jul 5 at 13:13






                • 5





                  Note that having someone who was still in school when the program was designed come along and randomly decide to rewrite large portions of code just because they think it's messy and hard to understand might not be well received by everyone -- I'd "read the room" before proposing this; presentation is everything.

                  – A C
                  Jul 6 at 4:39






                • 2





                  +1 for taking ownership. Maintaining is not fun, I agree. But refactoring is / can be fun. Learn what others did wrong, split it up into senseful parts, then do it the way you think it´s done right. Of course talking about being unnerved by one´s job is always reasonable to tell, though. But in preparation for such a meeting OP should prepare a plan how much better the world could be if it was refactored. If this wish to make the job a good job is rejected, leaving is still a plan B...

                  – Jessica
                  Jul 6 at 19:54











                • It is reasonable to speak up. Some developers thrive on maintaining legacy code, some thrive on creating new things. Forcing a square peg into a round hole just because the hole needs to be filled is bad management. Who is going to do a better job, the dev that loves legacy dev, or the dev that hates it but is being forced to do it?

                  – bob
                  Jul 8 at 15:32











                • @EdwinLambregts sure there is demand, but that doesn't mean that there isn't also a massive pool of programmers to choose from. Problem is that most of that pool is low quality programmers unwilling and/or incapable of doing what needs doing. People for example who are unwilling to dig into a large old code base and fixing problems as they pop up... Which btw happens to be something I do like :)

                  – jwenting
                  Jul 9 at 3:35















                27



















                My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?




                No it would not be reasonable. Part of being a programmer is maintaining existing programs whether its adding/removing features or fixing errors. You were lucky to have worked on some projects that you started from scratch but you cannot expect every project to be this way. Sometimes, for a period of time, the business does not need new projects started from scratch ( that is not saying that they never will again ) and they just need to maintain the existing projects.



                What you should do is take ownership of your current project. Forget about the fact that it is 6 years old and 5 other programmers worked on it. If it is messy and full of bugs then take the initiative to fix the project. You will certainly look better in the eyes of your manager if you successfully bring the project to a stable state instead of complaining about having to do work on this project and trying to have different work assigned to you.






                share|improve this answer





















                • 4





                  Sometimes indeed you just have to suck it up and do your job. I can't speak for other countries, but here in the Netherlands there's a huge demand for software developers. Managers and companies in general will try to keep you happy with your job. Expressing you are unhappy with your current project is not at all unreasonable, because it can lead to several things: burn-outs, increased stress, or quitting the job. Employers want to prevent that, and will assist in making and keeping the employee happy.

                  – Edwin Lambregts
                  Jul 5 at 13:13






                • 5





                  Note that having someone who was still in school when the program was designed come along and randomly decide to rewrite large portions of code just because they think it's messy and hard to understand might not be well received by everyone -- I'd "read the room" before proposing this; presentation is everything.

                  – A C
                  Jul 6 at 4:39






                • 2





                  +1 for taking ownership. Maintaining is not fun, I agree. But refactoring is / can be fun. Learn what others did wrong, split it up into senseful parts, then do it the way you think it´s done right. Of course talking about being unnerved by one´s job is always reasonable to tell, though. But in preparation for such a meeting OP should prepare a plan how much better the world could be if it was refactored. If this wish to make the job a good job is rejected, leaving is still a plan B...

                  – Jessica
                  Jul 6 at 19:54











                • It is reasonable to speak up. Some developers thrive on maintaining legacy code, some thrive on creating new things. Forcing a square peg into a round hole just because the hole needs to be filled is bad management. Who is going to do a better job, the dev that loves legacy dev, or the dev that hates it but is being forced to do it?

                  – bob
                  Jul 8 at 15:32











                • @EdwinLambregts sure there is demand, but that doesn't mean that there isn't also a massive pool of programmers to choose from. Problem is that most of that pool is low quality programmers unwilling and/or incapable of doing what needs doing. People for example who are unwilling to dig into a large old code base and fixing problems as they pop up... Which btw happens to be something I do like :)

                  – jwenting
                  Jul 9 at 3:35













                27














                27










                27










                My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?




                No it would not be reasonable. Part of being a programmer is maintaining existing programs whether its adding/removing features or fixing errors. You were lucky to have worked on some projects that you started from scratch but you cannot expect every project to be this way. Sometimes, for a period of time, the business does not need new projects started from scratch ( that is not saying that they never will again ) and they just need to maintain the existing projects.



                What you should do is take ownership of your current project. Forget about the fact that it is 6 years old and 5 other programmers worked on it. If it is messy and full of bugs then take the initiative to fix the project. You will certainly look better in the eyes of your manager if you successfully bring the project to a stable state instead of complaining about having to do work on this project and trying to have different work assigned to you.






                share|improve this answer















                My question: would it be reasonable to ask my manager to put me on another project because I really dislike the work I need to do now and how do I tell this?




                No it would not be reasonable. Part of being a programmer is maintaining existing programs whether its adding/removing features or fixing errors. You were lucky to have worked on some projects that you started from scratch but you cannot expect every project to be this way. Sometimes, for a period of time, the business does not need new projects started from scratch ( that is not saying that they never will again ) and they just need to maintain the existing projects.



                What you should do is take ownership of your current project. Forget about the fact that it is 6 years old and 5 other programmers worked on it. If it is messy and full of bugs then take the initiative to fix the project. You will certainly look better in the eyes of your manager if you successfully bring the project to a stable state instead of complaining about having to do work on this project and trying to have different work assigned to you.







                share|improve this answer













                share|improve this answer




                share|improve this answer










                answered Jul 5 at 12:01









                sf02sf02

                26.9k16 gold badges57 silver badges102 bronze badges




                26.9k16 gold badges57 silver badges102 bronze badges










                • 4





                  Sometimes indeed you just have to suck it up and do your job. I can't speak for other countries, but here in the Netherlands there's a huge demand for software developers. Managers and companies in general will try to keep you happy with your job. Expressing you are unhappy with your current project is not at all unreasonable, because it can lead to several things: burn-outs, increased stress, or quitting the job. Employers want to prevent that, and will assist in making and keeping the employee happy.

                  – Edwin Lambregts
                  Jul 5 at 13:13






                • 5





                  Note that having someone who was still in school when the program was designed come along and randomly decide to rewrite large portions of code just because they think it's messy and hard to understand might not be well received by everyone -- I'd "read the room" before proposing this; presentation is everything.

                  – A C
                  Jul 6 at 4:39






                • 2





                  +1 for taking ownership. Maintaining is not fun, I agree. But refactoring is / can be fun. Learn what others did wrong, split it up into senseful parts, then do it the way you think it´s done right. Of course talking about being unnerved by one´s job is always reasonable to tell, though. But in preparation for such a meeting OP should prepare a plan how much better the world could be if it was refactored. If this wish to make the job a good job is rejected, leaving is still a plan B...

                  – Jessica
                  Jul 6 at 19:54











                • It is reasonable to speak up. Some developers thrive on maintaining legacy code, some thrive on creating new things. Forcing a square peg into a round hole just because the hole needs to be filled is bad management. Who is going to do a better job, the dev that loves legacy dev, or the dev that hates it but is being forced to do it?

                  – bob
                  Jul 8 at 15:32











                • @EdwinLambregts sure there is demand, but that doesn't mean that there isn't also a massive pool of programmers to choose from. Problem is that most of that pool is low quality programmers unwilling and/or incapable of doing what needs doing. People for example who are unwilling to dig into a large old code base and fixing problems as they pop up... Which btw happens to be something I do like :)

                  – jwenting
                  Jul 9 at 3:35












                • 4





                  Sometimes indeed you just have to suck it up and do your job. I can't speak for other countries, but here in the Netherlands there's a huge demand for software developers. Managers and companies in general will try to keep you happy with your job. Expressing you are unhappy with your current project is not at all unreasonable, because it can lead to several things: burn-outs, increased stress, or quitting the job. Employers want to prevent that, and will assist in making and keeping the employee happy.

                  – Edwin Lambregts
                  Jul 5 at 13:13






                • 5





                  Note that having someone who was still in school when the program was designed come along and randomly decide to rewrite large portions of code just because they think it's messy and hard to understand might not be well received by everyone -- I'd "read the room" before proposing this; presentation is everything.

                  – A C
                  Jul 6 at 4:39






                • 2





                  +1 for taking ownership. Maintaining is not fun, I agree. But refactoring is / can be fun. Learn what others did wrong, split it up into senseful parts, then do it the way you think it´s done right. Of course talking about being unnerved by one´s job is always reasonable to tell, though. But in preparation for such a meeting OP should prepare a plan how much better the world could be if it was refactored. If this wish to make the job a good job is rejected, leaving is still a plan B...

                  – Jessica
                  Jul 6 at 19:54











                • It is reasonable to speak up. Some developers thrive on maintaining legacy code, some thrive on creating new things. Forcing a square peg into a round hole just because the hole needs to be filled is bad management. Who is going to do a better job, the dev that loves legacy dev, or the dev that hates it but is being forced to do it?

                  – bob
                  Jul 8 at 15:32











                • @EdwinLambregts sure there is demand, but that doesn't mean that there isn't also a massive pool of programmers to choose from. Problem is that most of that pool is low quality programmers unwilling and/or incapable of doing what needs doing. People for example who are unwilling to dig into a large old code base and fixing problems as they pop up... Which btw happens to be something I do like :)

                  – jwenting
                  Jul 9 at 3:35







                4




                4





                Sometimes indeed you just have to suck it up and do your job. I can't speak for other countries, but here in the Netherlands there's a huge demand for software developers. Managers and companies in general will try to keep you happy with your job. Expressing you are unhappy with your current project is not at all unreasonable, because it can lead to several things: burn-outs, increased stress, or quitting the job. Employers want to prevent that, and will assist in making and keeping the employee happy.

                – Edwin Lambregts
                Jul 5 at 13:13





                Sometimes indeed you just have to suck it up and do your job. I can't speak for other countries, but here in the Netherlands there's a huge demand for software developers. Managers and companies in general will try to keep you happy with your job. Expressing you are unhappy with your current project is not at all unreasonable, because it can lead to several things: burn-outs, increased stress, or quitting the job. Employers want to prevent that, and will assist in making and keeping the employee happy.

                – Edwin Lambregts
                Jul 5 at 13:13




                5




                5





                Note that having someone who was still in school when the program was designed come along and randomly decide to rewrite large portions of code just because they think it's messy and hard to understand might not be well received by everyone -- I'd "read the room" before proposing this; presentation is everything.

                – A C
                Jul 6 at 4:39





                Note that having someone who was still in school when the program was designed come along and randomly decide to rewrite large portions of code just because they think it's messy and hard to understand might not be well received by everyone -- I'd "read the room" before proposing this; presentation is everything.

                – A C
                Jul 6 at 4:39




                2




                2





                +1 for taking ownership. Maintaining is not fun, I agree. But refactoring is / can be fun. Learn what others did wrong, split it up into senseful parts, then do it the way you think it´s done right. Of course talking about being unnerved by one´s job is always reasonable to tell, though. But in preparation for such a meeting OP should prepare a plan how much better the world could be if it was refactored. If this wish to make the job a good job is rejected, leaving is still a plan B...

                – Jessica
                Jul 6 at 19:54





                +1 for taking ownership. Maintaining is not fun, I agree. But refactoring is / can be fun. Learn what others did wrong, split it up into senseful parts, then do it the way you think it´s done right. Of course talking about being unnerved by one´s job is always reasonable to tell, though. But in preparation for such a meeting OP should prepare a plan how much better the world could be if it was refactored. If this wish to make the job a good job is rejected, leaving is still a plan B...

                – Jessica
                Jul 6 at 19:54













                It is reasonable to speak up. Some developers thrive on maintaining legacy code, some thrive on creating new things. Forcing a square peg into a round hole just because the hole needs to be filled is bad management. Who is going to do a better job, the dev that loves legacy dev, or the dev that hates it but is being forced to do it?

                – bob
                Jul 8 at 15:32





                It is reasonable to speak up. Some developers thrive on maintaining legacy code, some thrive on creating new things. Forcing a square peg into a round hole just because the hole needs to be filled is bad management. Who is going to do a better job, the dev that loves legacy dev, or the dev that hates it but is being forced to do it?

                – bob
                Jul 8 at 15:32













                @EdwinLambregts sure there is demand, but that doesn't mean that there isn't also a massive pool of programmers to choose from. Problem is that most of that pool is low quality programmers unwilling and/or incapable of doing what needs doing. People for example who are unwilling to dig into a large old code base and fixing problems as they pop up... Which btw happens to be something I do like :)

                – jwenting
                Jul 9 at 3:35





                @EdwinLambregts sure there is demand, but that doesn't mean that there isn't also a massive pool of programmers to choose from. Problem is that most of that pool is low quality programmers unwilling and/or incapable of doing what needs doing. People for example who are unwilling to dig into a large old code base and fixing problems as they pop up... Which btw happens to be something I do like :)

                – jwenting
                Jul 9 at 3:35











                16


















                You can always ask, but they can always say no, too.



                Unless you have it in your contract that you will only work on projects you like, they can put you on projects as they see fit.



                You could document the changes you would want to make (refactoring, writing documentation, ...) and the benefits for the company in terms of time gained through less bugs.



                Or you could argue for a new development of the product with better practises. But as long as the old project has paying users somebody has to maintain it and they chose you Pikachu.



                You could argue to get more people to do what you are doing (Bus-factor) so that you can work on other projects as well. If these become more important than the legacy project those might become an out.



                But again: As long as there are people paying your firm and in extension paying your bosses wages for this project, and your firm isn't inclined to give this up, somebody will have to fix the bugs.



                You could quit and work as a freelancer as a last resort. There you can really pick the projects you are working on but be prepared to have to do some projects you don't really like to keep the lights on. Only the best and best-known can cherrypick what they do completely.






                share|improve this answer






























                  16


















                  You can always ask, but they can always say no, too.



                  Unless you have it in your contract that you will only work on projects you like, they can put you on projects as they see fit.



                  You could document the changes you would want to make (refactoring, writing documentation, ...) and the benefits for the company in terms of time gained through less bugs.



                  Or you could argue for a new development of the product with better practises. But as long as the old project has paying users somebody has to maintain it and they chose you Pikachu.



                  You could argue to get more people to do what you are doing (Bus-factor) so that you can work on other projects as well. If these become more important than the legacy project those might become an out.



                  But again: As long as there are people paying your firm and in extension paying your bosses wages for this project, and your firm isn't inclined to give this up, somebody will have to fix the bugs.



                  You could quit and work as a freelancer as a last resort. There you can really pick the projects you are working on but be prepared to have to do some projects you don't really like to keep the lights on. Only the best and best-known can cherrypick what they do completely.






                  share|improve this answer




























                    16














                    16










                    16









                    You can always ask, but they can always say no, too.



                    Unless you have it in your contract that you will only work on projects you like, they can put you on projects as they see fit.



                    You could document the changes you would want to make (refactoring, writing documentation, ...) and the benefits for the company in terms of time gained through less bugs.



                    Or you could argue for a new development of the product with better practises. But as long as the old project has paying users somebody has to maintain it and they chose you Pikachu.



                    You could argue to get more people to do what you are doing (Bus-factor) so that you can work on other projects as well. If these become more important than the legacy project those might become an out.



                    But again: As long as there are people paying your firm and in extension paying your bosses wages for this project, and your firm isn't inclined to give this up, somebody will have to fix the bugs.



                    You could quit and work as a freelancer as a last resort. There you can really pick the projects you are working on but be prepared to have to do some projects you don't really like to keep the lights on. Only the best and best-known can cherrypick what they do completely.






                    share|improve this answer














                    You can always ask, but they can always say no, too.



                    Unless you have it in your contract that you will only work on projects you like, they can put you on projects as they see fit.



                    You could document the changes you would want to make (refactoring, writing documentation, ...) and the benefits for the company in terms of time gained through less bugs.



                    Or you could argue for a new development of the product with better practises. But as long as the old project has paying users somebody has to maintain it and they chose you Pikachu.



                    You could argue to get more people to do what you are doing (Bus-factor) so that you can work on other projects as well. If these become more important than the legacy project those might become an out.



                    But again: As long as there are people paying your firm and in extension paying your bosses wages for this project, and your firm isn't inclined to give this up, somebody will have to fix the bugs.



                    You could quit and work as a freelancer as a last resort. There you can really pick the projects you are working on but be prepared to have to do some projects you don't really like to keep the lights on. Only the best and best-known can cherrypick what they do completely.







                    share|improve this answer













                    share|improve this answer




                    share|improve this answer










                    answered Jul 5 at 10:10









                    MangocherryMangocherry

                    1,0502 silver badges9 bronze badges




                    1,0502 silver badges9 bronze badges
























                        8


















                        tl;dr: Be honest with your employer. Tell them you're only interested in greenfield projects. Note however, that making this decision will significantly limit the work you'll get offered, possibly to the point that your services are no longer required.



                        One of the most important things in professional software development is collaboration on a shared codebase. Unless you're a rock star soloist, the codebase will always have a history, shaped by past and present colleagues – and possibly also yourself in the past.



                        As you've already mentioned, reading code is much more difficult than writing it – which is exactly why this skill is so important. It takes a lot of skill and patience to learn and understand the nooks and crannies of an existing project. It's easier – and granted, more pleasant for the developer – to start things anew, possibly even choosing the technologies and frameworks used.



                        Commercial software always serves a business purpose. This means that – unless you're only working with startups or marketing – software should have a reasonable life expectancy. The developers who go the extra mile to familiaze with existing solutions, and especially, existing business interests, are the ones who make themselves valueable – and often difficult to replace.



                        As you've pointed out, legacy code isn't always (ever?) easy to work with, bug-free or clean. What I'd suggest you to consider, is to turn things the other way around: Each impossible snippet of spaghetti copy-pasta is an opportunity for a great refactor with unit tests; each bug report is a chance to impress the business and the end users with impeccable customer service.






                        share|improve this answer




























                        • Good answer. The only thing I'd add is that despite the last paragraph, some devs (like myself), simply will always hate maintaining legacy code. The frustration of navigating an unintelligible mess and spending more down time than up time is just something that some devs can't overcome. So if OP is one of those, then the first paragraph is the best advice for them, and might even wind up meaning applying for a new job, which would then be good.

                          – bob
                          Jul 8 at 15:35















                        8


















                        tl;dr: Be honest with your employer. Tell them you're only interested in greenfield projects. Note however, that making this decision will significantly limit the work you'll get offered, possibly to the point that your services are no longer required.



                        One of the most important things in professional software development is collaboration on a shared codebase. Unless you're a rock star soloist, the codebase will always have a history, shaped by past and present colleagues – and possibly also yourself in the past.



                        As you've already mentioned, reading code is much more difficult than writing it – which is exactly why this skill is so important. It takes a lot of skill and patience to learn and understand the nooks and crannies of an existing project. It's easier – and granted, more pleasant for the developer – to start things anew, possibly even choosing the technologies and frameworks used.



                        Commercial software always serves a business purpose. This means that – unless you're only working with startups or marketing – software should have a reasonable life expectancy. The developers who go the extra mile to familiaze with existing solutions, and especially, existing business interests, are the ones who make themselves valueable – and often difficult to replace.



                        As you've pointed out, legacy code isn't always (ever?) easy to work with, bug-free or clean. What I'd suggest you to consider, is to turn things the other way around: Each impossible snippet of spaghetti copy-pasta is an opportunity for a great refactor with unit tests; each bug report is a chance to impress the business and the end users with impeccable customer service.






                        share|improve this answer




























                        • Good answer. The only thing I'd add is that despite the last paragraph, some devs (like myself), simply will always hate maintaining legacy code. The frustration of navigating an unintelligible mess and spending more down time than up time is just something that some devs can't overcome. So if OP is one of those, then the first paragraph is the best advice for them, and might even wind up meaning applying for a new job, which would then be good.

                          – bob
                          Jul 8 at 15:35













                        8














                        8










                        8









                        tl;dr: Be honest with your employer. Tell them you're only interested in greenfield projects. Note however, that making this decision will significantly limit the work you'll get offered, possibly to the point that your services are no longer required.



                        One of the most important things in professional software development is collaboration on a shared codebase. Unless you're a rock star soloist, the codebase will always have a history, shaped by past and present colleagues – and possibly also yourself in the past.



                        As you've already mentioned, reading code is much more difficult than writing it – which is exactly why this skill is so important. It takes a lot of skill and patience to learn and understand the nooks and crannies of an existing project. It's easier – and granted, more pleasant for the developer – to start things anew, possibly even choosing the technologies and frameworks used.



                        Commercial software always serves a business purpose. This means that – unless you're only working with startups or marketing – software should have a reasonable life expectancy. The developers who go the extra mile to familiaze with existing solutions, and especially, existing business interests, are the ones who make themselves valueable – and often difficult to replace.



                        As you've pointed out, legacy code isn't always (ever?) easy to work with, bug-free or clean. What I'd suggest you to consider, is to turn things the other way around: Each impossible snippet of spaghetti copy-pasta is an opportunity for a great refactor with unit tests; each bug report is a chance to impress the business and the end users with impeccable customer service.






                        share|improve this answer
















                        tl;dr: Be honest with your employer. Tell them you're only interested in greenfield projects. Note however, that making this decision will significantly limit the work you'll get offered, possibly to the point that your services are no longer required.



                        One of the most important things in professional software development is collaboration on a shared codebase. Unless you're a rock star soloist, the codebase will always have a history, shaped by past and present colleagues – and possibly also yourself in the past.



                        As you've already mentioned, reading code is much more difficult than writing it – which is exactly why this skill is so important. It takes a lot of skill and patience to learn and understand the nooks and crannies of an existing project. It's easier – and granted, more pleasant for the developer – to start things anew, possibly even choosing the technologies and frameworks used.



                        Commercial software always serves a business purpose. This means that – unless you're only working with startups or marketing – software should have a reasonable life expectancy. The developers who go the extra mile to familiaze with existing solutions, and especially, existing business interests, are the ones who make themselves valueable – and often difficult to replace.



                        As you've pointed out, legacy code isn't always (ever?) easy to work with, bug-free or clean. What I'd suggest you to consider, is to turn things the other way around: Each impossible snippet of spaghetti copy-pasta is an opportunity for a great refactor with unit tests; each bug report is a chance to impress the business and the end users with impeccable customer service.







                        share|improve this answer















                        share|improve this answer




                        share|improve this answer








                        edited Jul 6 at 6:55

























                        answered Jul 6 at 0:04









                        Mick MnemonicMick Mnemonic

                        1814 bronze badges




                        1814 bronze badges















                        • Good answer. The only thing I'd add is that despite the last paragraph, some devs (like myself), simply will always hate maintaining legacy code. The frustration of navigating an unintelligible mess and spending more down time than up time is just something that some devs can't overcome. So if OP is one of those, then the first paragraph is the best advice for them, and might even wind up meaning applying for a new job, which would then be good.

                          – bob
                          Jul 8 at 15:35

















                        • Good answer. The only thing I'd add is that despite the last paragraph, some devs (like myself), simply will always hate maintaining legacy code. The frustration of navigating an unintelligible mess and spending more down time than up time is just something that some devs can't overcome. So if OP is one of those, then the first paragraph is the best advice for them, and might even wind up meaning applying for a new job, which would then be good.

                          – bob
                          Jul 8 at 15:35
















                        Good answer. The only thing I'd add is that despite the last paragraph, some devs (like myself), simply will always hate maintaining legacy code. The frustration of navigating an unintelligible mess and spending more down time than up time is just something that some devs can't overcome. So if OP is one of those, then the first paragraph is the best advice for them, and might even wind up meaning applying for a new job, which would then be good.

                        – bob
                        Jul 8 at 15:35





                        Good answer. The only thing I'd add is that despite the last paragraph, some devs (like myself), simply will always hate maintaining legacy code. The frustration of navigating an unintelligible mess and spending more down time than up time is just something that some devs can't overcome. So if OP is one of those, then the first paragraph is the best advice for them, and might even wind up meaning applying for a new job, which would then be good.

                        – bob
                        Jul 8 at 15:35











                        7


















                        My team currently maintains two products that came to belong to our company when our company bought out the original developers. The reason these purchases were possible is because the other companies were not doing well financially.



                        I work on only one of the two products. Early on it was like being a taxidermist working on road kill. The original coding team should never be allowed to touch computers ever again. My supervisor is responsible for the other product, and it is also a disaster.



                        The chief benefit of working on these dumpster fires is that we are getting good solid lessons on how not to do things, and even with three years in industry you are learning something like this from the products you are working on.



                        So stop looking at your situation as something that you should not have to deal with, and instead look at it as how you are going to make your company's product better than it was.



                        As an easy first step, every time you have to puzzle out what a piece of code does, put comments in the code explaining exactly what the code is doing. It may not help you—although I find that it greatly helps me—but the next person to look at the code won't have to puzzle it out.






                        share|improve this answer




























                        • In a similar vein, Micheal Feather's 'Working Effectively with Legacy Code' has been an amazing resource, and has aged really well - the theory behind adding 'seams' to your code so you can wrap parts of it in tests so you have confidence in the code behaving as you expect (even if you have to discover what it should do) changes your whole experience with 'legacy code'. And the definition of Legacy code simply being 'code without sufficient tests' applies to some 'greenfield' projects I've seen...

                          – Cinderhaze
                          Jul 8 at 19:58











                        • and quite often that poor code is no worse than the code you yourself created several years ago... And for juniors especially, the code is likely better than what they themselves are creating RIGHT NOW, they just don't realise it because they don't understand code that isn't designed according to the rigid patterns and paradigms that they got poured into their head during programming classes.

                          – jwenting
                          Jul 9 at 3:37















                        7


















                        My team currently maintains two products that came to belong to our company when our company bought out the original developers. The reason these purchases were possible is because the other companies were not doing well financially.



                        I work on only one of the two products. Early on it was like being a taxidermist working on road kill. The original coding team should never be allowed to touch computers ever again. My supervisor is responsible for the other product, and it is also a disaster.



                        The chief benefit of working on these dumpster fires is that we are getting good solid lessons on how not to do things, and even with three years in industry you are learning something like this from the products you are working on.



                        So stop looking at your situation as something that you should not have to deal with, and instead look at it as how you are going to make your company's product better than it was.



                        As an easy first step, every time you have to puzzle out what a piece of code does, put comments in the code explaining exactly what the code is doing. It may not help you—although I find that it greatly helps me—but the next person to look at the code won't have to puzzle it out.






                        share|improve this answer




























                        • In a similar vein, Micheal Feather's 'Working Effectively with Legacy Code' has been an amazing resource, and has aged really well - the theory behind adding 'seams' to your code so you can wrap parts of it in tests so you have confidence in the code behaving as you expect (even if you have to discover what it should do) changes your whole experience with 'legacy code'. And the definition of Legacy code simply being 'code without sufficient tests' applies to some 'greenfield' projects I've seen...

                          – Cinderhaze
                          Jul 8 at 19:58











                        • and quite often that poor code is no worse than the code you yourself created several years ago... And for juniors especially, the code is likely better than what they themselves are creating RIGHT NOW, they just don't realise it because they don't understand code that isn't designed according to the rigid patterns and paradigms that they got poured into their head during programming classes.

                          – jwenting
                          Jul 9 at 3:37













                        7














                        7










                        7









                        My team currently maintains two products that came to belong to our company when our company bought out the original developers. The reason these purchases were possible is because the other companies were not doing well financially.



                        I work on only one of the two products. Early on it was like being a taxidermist working on road kill. The original coding team should never be allowed to touch computers ever again. My supervisor is responsible for the other product, and it is also a disaster.



                        The chief benefit of working on these dumpster fires is that we are getting good solid lessons on how not to do things, and even with three years in industry you are learning something like this from the products you are working on.



                        So stop looking at your situation as something that you should not have to deal with, and instead look at it as how you are going to make your company's product better than it was.



                        As an easy first step, every time you have to puzzle out what a piece of code does, put comments in the code explaining exactly what the code is doing. It may not help you—although I find that it greatly helps me—but the next person to look at the code won't have to puzzle it out.






                        share|improve this answer
















                        My team currently maintains two products that came to belong to our company when our company bought out the original developers. The reason these purchases were possible is because the other companies were not doing well financially.



                        I work on only one of the two products. Early on it was like being a taxidermist working on road kill. The original coding team should never be allowed to touch computers ever again. My supervisor is responsible for the other product, and it is also a disaster.



                        The chief benefit of working on these dumpster fires is that we are getting good solid lessons on how not to do things, and even with three years in industry you are learning something like this from the products you are working on.



                        So stop looking at your situation as something that you should not have to deal with, and instead look at it as how you are going to make your company's product better than it was.



                        As an easy first step, every time you have to puzzle out what a piece of code does, put comments in the code explaining exactly what the code is doing. It may not help you—although I find that it greatly helps me—but the next person to look at the code won't have to puzzle it out.







                        share|improve this answer















                        share|improve this answer




                        share|improve this answer








                        edited Jul 9 at 3:05

























                        answered Jul 6 at 4:47









                        EvilSnackEvilSnack

                        9822 silver badges9 bronze badges




                        9822 silver badges9 bronze badges















                        • In a similar vein, Micheal Feather's 'Working Effectively with Legacy Code' has been an amazing resource, and has aged really well - the theory behind adding 'seams' to your code so you can wrap parts of it in tests so you have confidence in the code behaving as you expect (even if you have to discover what it should do) changes your whole experience with 'legacy code'. And the definition of Legacy code simply being 'code without sufficient tests' applies to some 'greenfield' projects I've seen...

                          – Cinderhaze
                          Jul 8 at 19:58











                        • and quite often that poor code is no worse than the code you yourself created several years ago... And for juniors especially, the code is likely better than what they themselves are creating RIGHT NOW, they just don't realise it because they don't understand code that isn't designed according to the rigid patterns and paradigms that they got poured into their head during programming classes.

                          – jwenting
                          Jul 9 at 3:37

















                        • In a similar vein, Micheal Feather's 'Working Effectively with Legacy Code' has been an amazing resource, and has aged really well - the theory behind adding 'seams' to your code so you can wrap parts of it in tests so you have confidence in the code behaving as you expect (even if you have to discover what it should do) changes your whole experience with 'legacy code'. And the definition of Legacy code simply being 'code without sufficient tests' applies to some 'greenfield' projects I've seen...

                          – Cinderhaze
                          Jul 8 at 19:58











                        • and quite often that poor code is no worse than the code you yourself created several years ago... And for juniors especially, the code is likely better than what they themselves are creating RIGHT NOW, they just don't realise it because they don't understand code that isn't designed according to the rigid patterns and paradigms that they got poured into their head during programming classes.

                          – jwenting
                          Jul 9 at 3:37
















                        In a similar vein, Micheal Feather's 'Working Effectively with Legacy Code' has been an amazing resource, and has aged really well - the theory behind adding 'seams' to your code so you can wrap parts of it in tests so you have confidence in the code behaving as you expect (even if you have to discover what it should do) changes your whole experience with 'legacy code'. And the definition of Legacy code simply being 'code without sufficient tests' applies to some 'greenfield' projects I've seen...

                        – Cinderhaze
                        Jul 8 at 19:58





                        In a similar vein, Micheal Feather's 'Working Effectively with Legacy Code' has been an amazing resource, and has aged really well - the theory behind adding 'seams' to your code so you can wrap parts of it in tests so you have confidence in the code behaving as you expect (even if you have to discover what it should do) changes your whole experience with 'legacy code'. And the definition of Legacy code simply being 'code without sufficient tests' applies to some 'greenfield' projects I've seen...

                        – Cinderhaze
                        Jul 8 at 19:58













                        and quite often that poor code is no worse than the code you yourself created several years ago... And for juniors especially, the code is likely better than what they themselves are creating RIGHT NOW, they just don't realise it because they don't understand code that isn't designed according to the rigid patterns and paradigms that they got poured into their head during programming classes.

                        – jwenting
                        Jul 9 at 3:37





                        and quite often that poor code is no worse than the code you yourself created several years ago... And for juniors especially, the code is likely better than what they themselves are creating RIGHT NOW, they just don't realise it because they don't understand code that isn't designed according to the rigid patterns and paradigms that they got poured into their head during programming classes.

                        – jwenting
                        Jul 9 at 3:37











                        6


















                        Lots of great answers already, but adding my £0.02.



                        Maintaining older software is more difficult than building something new, it's also a valuable skill in itself.



                        Being able to jump into a codebase that has been around for years, with bad or no documentation and featuring lots of different coding styles from the many developers who worked on it is something many employers, particularly in the enterprise world, actively look for.



                        If there is no documentation, then write some. If there are no automated tests, then work on refactoring the code so it's testable and write some tests. If the coding styles are all over the place, then research the recommended styles for the language or framework and work on refactoring the codebase to match the recommended coding style.



                        Gaining a reputation as being somebody who is happy to work with legacy code, and who does it well, can be as good for your career as working on greenfield projects with the new and shiny frameworks.



                        As time goes on, the amount of legacy code in production is only going to increase, and demand for developers who can look after it, fix bugs and add new features is going to increase along with it, as rewriting those applications with new tech is generally considered to be a bad idea for lots of good reasons.



                        Good luck!






                        share|improve this answer






























                          6


















                          Lots of great answers already, but adding my £0.02.



                          Maintaining older software is more difficult than building something new, it's also a valuable skill in itself.



                          Being able to jump into a codebase that has been around for years, with bad or no documentation and featuring lots of different coding styles from the many developers who worked on it is something many employers, particularly in the enterprise world, actively look for.



                          If there is no documentation, then write some. If there are no automated tests, then work on refactoring the code so it's testable and write some tests. If the coding styles are all over the place, then research the recommended styles for the language or framework and work on refactoring the codebase to match the recommended coding style.



                          Gaining a reputation as being somebody who is happy to work with legacy code, and who does it well, can be as good for your career as working on greenfield projects with the new and shiny frameworks.



                          As time goes on, the amount of legacy code in production is only going to increase, and demand for developers who can look after it, fix bugs and add new features is going to increase along with it, as rewriting those applications with new tech is generally considered to be a bad idea for lots of good reasons.



                          Good luck!






                          share|improve this answer




























                            6














                            6










                            6









                            Lots of great answers already, but adding my £0.02.



                            Maintaining older software is more difficult than building something new, it's also a valuable skill in itself.



                            Being able to jump into a codebase that has been around for years, with bad or no documentation and featuring lots of different coding styles from the many developers who worked on it is something many employers, particularly in the enterprise world, actively look for.



                            If there is no documentation, then write some. If there are no automated tests, then work on refactoring the code so it's testable and write some tests. If the coding styles are all over the place, then research the recommended styles for the language or framework and work on refactoring the codebase to match the recommended coding style.



                            Gaining a reputation as being somebody who is happy to work with legacy code, and who does it well, can be as good for your career as working on greenfield projects with the new and shiny frameworks.



                            As time goes on, the amount of legacy code in production is only going to increase, and demand for developers who can look after it, fix bugs and add new features is going to increase along with it, as rewriting those applications with new tech is generally considered to be a bad idea for lots of good reasons.



                            Good luck!






                            share|improve this answer














                            Lots of great answers already, but adding my £0.02.



                            Maintaining older software is more difficult than building something new, it's also a valuable skill in itself.



                            Being able to jump into a codebase that has been around for years, with bad or no documentation and featuring lots of different coding styles from the many developers who worked on it is something many employers, particularly in the enterprise world, actively look for.



                            If there is no documentation, then write some. If there are no automated tests, then work on refactoring the code so it's testable and write some tests. If the coding styles are all over the place, then research the recommended styles for the language or framework and work on refactoring the codebase to match the recommended coding style.



                            Gaining a reputation as being somebody who is happy to work with legacy code, and who does it well, can be as good for your career as working on greenfield projects with the new and shiny frameworks.



                            As time goes on, the amount of legacy code in production is only going to increase, and demand for developers who can look after it, fix bugs and add new features is going to increase along with it, as rewriting those applications with new tech is generally considered to be a bad idea for lots of good reasons.



                            Good luck!







                            share|improve this answer













                            share|improve this answer




                            share|improve this answer










                            answered Jul 7 at 13:31









                            JMKJMK

                            8667 silver badges15 bronze badges




                            8667 silver badges15 bronze badges
























                                6


















                                Legacy maintenance builds the developer's desire for good practice



                                I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it.



                                I'll use a practical example to make my case. As a consultant, I am often sent into a company/project with code quality issues, where my job is to make things right. As you would suspect, bad code leads to a lot of legacy maintenance.



                                It has been my predominant experience that developers who write bad code are in one of two camps:



                                • Those who didn't know any better

                                • Those who think they are doing the right thing

                                The former group is easy to deal with, as they will immediately improve when you show them good practice. The latter group, however, is much harder to convince as they do not see the benefit of good practice, which often takes more effort in the short term. It pays back dividends in the long run, but the latter group often misses that point.



                                Almost every developer I've dealt with who was in the latter camp were developers who managed to jump from project to project skipping the maintenance of their own code. Because they were never faced with the fallout from their imperfect design decisions, they were never incentivized to try and avoid these problems from occurring before they happened, when the application was initially being built.



                                The solution is simple: developers must take ownership. If you write buggy code, you will deal with the bugs that ensue. If you don't want to spend your time fixing bugs, then it's up to you to write code that does not produce them.

                                This creates a very simple incentive for developers to improve themselves, as opposed to being pushed into it against their will and without their understanding of why it is the better approach.



                                What I want you to take away from this is that legacy maintenance is essential for developers to remember why they need good practice.

                                As an analogy, a general who is in the trenches with his men will make better decisions (for the soldiers) than a general who is sitting comfortably in a palace on the other side of the country. A developer needs to get their hands dirty so that when they are the general (= building the new application) they know what the impact of their design decisions are.




                                Cleaning up after others



                                You, however, are not faced with your own bugs, but rather those of the people that came before you. I am currently in the same boat, and I do agree with you that this is not a tenable situation.

                                Nobody likes legacy maintenance, and it would appear that your manager has not taken into consideration how you solely doing legacy maintenance is both impacting your morale and your personal career development.



                                I spent 3 years doing legacy maintenance, but it was a cushy job with an very loose working from home policy. It took me a while to understand that while the work/life balance was not bad, my career was stalling because I was not gaining topical knowledge to the industry. If I had been fired from that job after 5 years, my skillset would be so outdated for other companies that I'd have to scramble to make up for lost time.



                                On the other hand, someone has to support this project. So you can't just take a "not me" approach, because every developer will tout the same "not me" approach and then management is liable to just appoint someone to have drawn the short straw (this may be how you ended up in this position to begin with).




                                Addressing the issue



                                Approach your manager and explain to him that while you understand that the legacy project requires support, it is a drain on morale when you do nothing but deal with the old code. Ask if your manager would consider assigning you to a different (non-legacy) project part time.



                                In my experience, most reasonable managers will understand this (you were probably assigned to this because the other 5 developers who left all argued the same point) and will see the benefit of keep you (someone who already knows the legacy project) on the project part time, as opposed to having you leave and needing to find a new developer who doesn't know the legacy project.



                                But in my same experience, there are also companies where employee morale is considerably lower on the list of priorities, where they employ a more rigorous "you do what we tell you to do" approach.

                                The only advice I can give here is to leave such a toxic environment. Don't let your career waste away working a job you hate for a company who doesn't value your work satisfaction (to a reasonable degree).






                                share|improve this answer


























                                • Third camp: Developers who are past deadline because management consistently makes promises based on underestimates of the time required for development. Deadlines are the bane of software quality.

                                  – EvilSnack
                                  Jul 9 at 3:43












                                • @EvilSnack: Hands down, I agree that this is usually how things start out (it's either that or simply a lack of guidance for juniors). But over time, that persistent environment breeds developers who only work like that even at times where they have the luxury of time to do it better. The most common feedback I have to give is that both mgmt and the devs are to blame. Mgmt creates an environment where the devs have learned to use bad practice out of sheer practicality.

                                  – Flater
                                  Jul 9 at 8:11












                                • @EvilSnack Once, I joined development as an external contractor. After the first day, I asked for the deadline. The answer was: last week. It took a year or so.

                                  – Volker Siegel
                                  Jul 9 at 9:25















                                6


















                                Legacy maintenance builds the developer's desire for good practice



                                I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it.



                                I'll use a practical example to make my case. As a consultant, I am often sent into a company/project with code quality issues, where my job is to make things right. As you would suspect, bad code leads to a lot of legacy maintenance.



                                It has been my predominant experience that developers who write bad code are in one of two camps:



                                • Those who didn't know any better

                                • Those who think they are doing the right thing

                                The former group is easy to deal with, as they will immediately improve when you show them good practice. The latter group, however, is much harder to convince as they do not see the benefit of good practice, which often takes more effort in the short term. It pays back dividends in the long run, but the latter group often misses that point.



                                Almost every developer I've dealt with who was in the latter camp were developers who managed to jump from project to project skipping the maintenance of their own code. Because they were never faced with the fallout from their imperfect design decisions, they were never incentivized to try and avoid these problems from occurring before they happened, when the application was initially being built.



                                The solution is simple: developers must take ownership. If you write buggy code, you will deal with the bugs that ensue. If you don't want to spend your time fixing bugs, then it's up to you to write code that does not produce them.

                                This creates a very simple incentive for developers to improve themselves, as opposed to being pushed into it against their will and without their understanding of why it is the better approach.



                                What I want you to take away from this is that legacy maintenance is essential for developers to remember why they need good practice.

                                As an analogy, a general who is in the trenches with his men will make better decisions (for the soldiers) than a general who is sitting comfortably in a palace on the other side of the country. A developer needs to get their hands dirty so that when they are the general (= building the new application) they know what the impact of their design decisions are.




                                Cleaning up after others



                                You, however, are not faced with your own bugs, but rather those of the people that came before you. I am currently in the same boat, and I do agree with you that this is not a tenable situation.

                                Nobody likes legacy maintenance, and it would appear that your manager has not taken into consideration how you solely doing legacy maintenance is both impacting your morale and your personal career development.



                                I spent 3 years doing legacy maintenance, but it was a cushy job with an very loose working from home policy. It took me a while to understand that while the work/life balance was not bad, my career was stalling because I was not gaining topical knowledge to the industry. If I had been fired from that job after 5 years, my skillset would be so outdated for other companies that I'd have to scramble to make up for lost time.



                                On the other hand, someone has to support this project. So you can't just take a "not me" approach, because every developer will tout the same "not me" approach and then management is liable to just appoint someone to have drawn the short straw (this may be how you ended up in this position to begin with).




                                Addressing the issue



                                Approach your manager and explain to him that while you understand that the legacy project requires support, it is a drain on morale when you do nothing but deal with the old code. Ask if your manager would consider assigning you to a different (non-legacy) project part time.



                                In my experience, most reasonable managers will understand this (you were probably assigned to this because the other 5 developers who left all argued the same point) and will see the benefit of keep you (someone who already knows the legacy project) on the project part time, as opposed to having you leave and needing to find a new developer who doesn't know the legacy project.



                                But in my same experience, there are also companies where employee morale is considerably lower on the list of priorities, where they employ a more rigorous "you do what we tell you to do" approach.

                                The only advice I can give here is to leave such a toxic environment. Don't let your career waste away working a job you hate for a company who doesn't value your work satisfaction (to a reasonable degree).






                                share|improve this answer


























                                • Third camp: Developers who are past deadline because management consistently makes promises based on underestimates of the time required for development. Deadlines are the bane of software quality.

                                  – EvilSnack
                                  Jul 9 at 3:43












                                • @EvilSnack: Hands down, I agree that this is usually how things start out (it's either that or simply a lack of guidance for juniors). But over time, that persistent environment breeds developers who only work like that even at times where they have the luxury of time to do it better. The most common feedback I have to give is that both mgmt and the devs are to blame. Mgmt creates an environment where the devs have learned to use bad practice out of sheer practicality.

                                  – Flater
                                  Jul 9 at 8:11












                                • @EvilSnack Once, I joined development as an external contractor. After the first day, I asked for the deadline. The answer was: last week. It took a year or so.

                                  – Volker Siegel
                                  Jul 9 at 9:25













                                6














                                6










                                6









                                Legacy maintenance builds the developer's desire for good practice



                                I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it.



                                I'll use a practical example to make my case. As a consultant, I am often sent into a company/project with code quality issues, where my job is to make things right. As you would suspect, bad code leads to a lot of legacy maintenance.



                                It has been my predominant experience that developers who write bad code are in one of two camps:



                                • Those who didn't know any better

                                • Those who think they are doing the right thing

                                The former group is easy to deal with, as they will immediately improve when you show them good practice. The latter group, however, is much harder to convince as they do not see the benefit of good practice, which often takes more effort in the short term. It pays back dividends in the long run, but the latter group often misses that point.



                                Almost every developer I've dealt with who was in the latter camp were developers who managed to jump from project to project skipping the maintenance of their own code. Because they were never faced with the fallout from their imperfect design decisions, they were never incentivized to try and avoid these problems from occurring before they happened, when the application was initially being built.



                                The solution is simple: developers must take ownership. If you write buggy code, you will deal with the bugs that ensue. If you don't want to spend your time fixing bugs, then it's up to you to write code that does not produce them.

                                This creates a very simple incentive for developers to improve themselves, as opposed to being pushed into it against their will and without their understanding of why it is the better approach.



                                What I want you to take away from this is that legacy maintenance is essential for developers to remember why they need good practice.

                                As an analogy, a general who is in the trenches with his men will make better decisions (for the soldiers) than a general who is sitting comfortably in a palace on the other side of the country. A developer needs to get their hands dirty so that when they are the general (= building the new application) they know what the impact of their design decisions are.




                                Cleaning up after others



                                You, however, are not faced with your own bugs, but rather those of the people that came before you. I am currently in the same boat, and I do agree with you that this is not a tenable situation.

                                Nobody likes legacy maintenance, and it would appear that your manager has not taken into consideration how you solely doing legacy maintenance is both impacting your morale and your personal career development.



                                I spent 3 years doing legacy maintenance, but it was a cushy job with an very loose working from home policy. It took me a while to understand that while the work/life balance was not bad, my career was stalling because I was not gaining topical knowledge to the industry. If I had been fired from that job after 5 years, my skillset would be so outdated for other companies that I'd have to scramble to make up for lost time.



                                On the other hand, someone has to support this project. So you can't just take a "not me" approach, because every developer will tout the same "not me" approach and then management is liable to just appoint someone to have drawn the short straw (this may be how you ended up in this position to begin with).




                                Addressing the issue



                                Approach your manager and explain to him that while you understand that the legacy project requires support, it is a drain on morale when you do nothing but deal with the old code. Ask if your manager would consider assigning you to a different (non-legacy) project part time.



                                In my experience, most reasonable managers will understand this (you were probably assigned to this because the other 5 developers who left all argued the same point) and will see the benefit of keep you (someone who already knows the legacy project) on the project part time, as opposed to having you leave and needing to find a new developer who doesn't know the legacy project.



                                But in my same experience, there are also companies where employee morale is considerably lower on the list of priorities, where they employ a more rigorous "you do what we tell you to do" approach.

                                The only advice I can give here is to leave such a toxic environment. Don't let your career waste away working a job you hate for a company who doesn't value your work satisfaction (to a reasonable degree).






                                share|improve this answer














                                Legacy maintenance builds the developer's desire for good practice



                                I just want to add the perspective of a lead developer, because as a developer I agree with not wanting to maintain legacy code, but as a lead developer I do not advocate for any developer avoiding it.



                                I'll use a practical example to make my case. As a consultant, I am often sent into a company/project with code quality issues, where my job is to make things right. As you would suspect, bad code leads to a lot of legacy maintenance.



                                It has been my predominant experience that developers who write bad code are in one of two camps:



                                • Those who didn't know any better

                                • Those who think they are doing the right thing

                                The former group is easy to deal with, as they will immediately improve when you show them good practice. The latter group, however, is much harder to convince as they do not see the benefit of good practice, which often takes more effort in the short term. It pays back dividends in the long run, but the latter group often misses that point.



                                Almost every developer I've dealt with who was in the latter camp were developers who managed to jump from project to project skipping the maintenance of their own code. Because they were never faced with the fallout from their imperfect design decisions, they were never incentivized to try and avoid these problems from occurring before they happened, when the application was initially being built.



                                The solution is simple: developers must take ownership. If you write buggy code, you will deal with the bugs that ensue. If you don't want to spend your time fixing bugs, then it's up to you to write code that does not produce them.

                                This creates a very simple incentive for developers to improve themselves, as opposed to being pushed into it against their will and without their understanding of why it is the better approach.



                                What I want you to take away from this is that legacy maintenance is essential for developers to remember why they need good practice.

                                As an analogy, a general who is in the trenches with his men will make better decisions (for the soldiers) than a general who is sitting comfortably in a palace on the other side of the country. A developer needs to get their hands dirty so that when they are the general (= building the new application) they know what the impact of their design decisions are.




                                Cleaning up after others



                                You, however, are not faced with your own bugs, but rather those of the people that came before you. I am currently in the same boat, and I do agree with you that this is not a tenable situation.

                                Nobody likes legacy maintenance, and it would appear that your manager has not taken into consideration how you solely doing legacy maintenance is both impacting your morale and your personal career development.



                                I spent 3 years doing legacy maintenance, but it was a cushy job with an very loose working from home policy. It took me a while to understand that while the work/life balance was not bad, my career was stalling because I was not gaining topical knowledge to the industry. If I had been fired from that job after 5 years, my skillset would be so outdated for other companies that I'd have to scramble to make up for lost time.



                                On the other hand, someone has to support this project. So you can't just take a "not me" approach, because every developer will tout the same "not me" approach and then management is liable to just appoint someone to have drawn the short straw (this may be how you ended up in this position to begin with).




                                Addressing the issue



                                Approach your manager and explain to him that while you understand that the legacy project requires support, it is a drain on morale when you do nothing but deal with the old code. Ask if your manager would consider assigning you to a different (non-legacy) project part time.



                                In my experience, most reasonable managers will understand this (you were probably assigned to this because the other 5 developers who left all argued the same point) and will see the benefit of keep you (someone who already knows the legacy project) on the project part time, as opposed to having you leave and needing to find a new developer who doesn't know the legacy project.



                                But in my same experience, there are also companies where employee morale is considerably lower on the list of priorities, where they employ a more rigorous "you do what we tell you to do" approach.

                                The only advice I can give here is to leave such a toxic environment. Don't let your career waste away working a job you hate for a company who doesn't value your work satisfaction (to a reasonable degree).







                                share|improve this answer













                                share|improve this answer




                                share|improve this answer










                                answered Jul 8 at 8:40









                                FlaterFlater

                                3,4321 gold badge13 silver badges18 bronze badges




                                3,4321 gold badge13 silver badges18 bronze badges















                                • Third camp: Developers who are past deadline because management consistently makes promises based on underestimates of the time required for development. Deadlines are the bane of software quality.

                                  – EvilSnack
                                  Jul 9 at 3:43












                                • @EvilSnack: Hands down, I agree that this is usually how things start out (it's either that or simply a lack of guidance for juniors). But over time, that persistent environment breeds developers who only work like that even at times where they have the luxury of time to do it better. The most common feedback I have to give is that both mgmt and the devs are to blame. Mgmt creates an environment where the devs have learned to use bad practice out of sheer practicality.

                                  – Flater
                                  Jul 9 at 8:11












                                • @EvilSnack Once, I joined development as an external contractor. After the first day, I asked for the deadline. The answer was: last week. It took a year or so.

                                  – Volker Siegel
                                  Jul 9 at 9:25

















                                • Third camp: Developers who are past deadline because management consistently makes promises based on underestimates of the time required for development. Deadlines are the bane of software quality.

                                  – EvilSnack
                                  Jul 9 at 3:43












                                • @EvilSnack: Hands down, I agree that this is usually how things start out (it's either that or simply a lack of guidance for juniors). But over time, that persistent environment breeds developers who only work like that even at times where they have the luxury of time to do it better. The most common feedback I have to give is that both mgmt and the devs are to blame. Mgmt creates an environment where the devs have learned to use bad practice out of sheer practicality.

                                  – Flater
                                  Jul 9 at 8:11












                                • @EvilSnack Once, I joined development as an external contractor. After the first day, I asked for the deadline. The answer was: last week. It took a year or so.

                                  – Volker Siegel
                                  Jul 9 at 9:25
















                                Third camp: Developers who are past deadline because management consistently makes promises based on underestimates of the time required for development. Deadlines are the bane of software quality.

                                – EvilSnack
                                Jul 9 at 3:43






                                Third camp: Developers who are past deadline because management consistently makes promises based on underestimates of the time required for development. Deadlines are the bane of software quality.

                                – EvilSnack
                                Jul 9 at 3:43














                                @EvilSnack: Hands down, I agree that this is usually how things start out (it's either that or simply a lack of guidance for juniors). But over time, that persistent environment breeds developers who only work like that even at times where they have the luxury of time to do it better. The most common feedback I have to give is that both mgmt and the devs are to blame. Mgmt creates an environment where the devs have learned to use bad practice out of sheer practicality.

                                – Flater
                                Jul 9 at 8:11






                                @EvilSnack: Hands down, I agree that this is usually how things start out (it's either that or simply a lack of guidance for juniors). But over time, that persistent environment breeds developers who only work like that even at times where they have the luxury of time to do it better. The most common feedback I have to give is that both mgmt and the devs are to blame. Mgmt creates an environment where the devs have learned to use bad practice out of sheer practicality.

                                – Flater
                                Jul 9 at 8:11














                                @EvilSnack Once, I joined development as an external contractor. After the first day, I asked for the deadline. The answer was: last week. It took a year or so.

                                – Volker Siegel
                                Jul 9 at 9:25





                                @EvilSnack Once, I joined development as an external contractor. After the first day, I asked for the deadline. The answer was: last week. It took a year or so.

                                – Volker Siegel
                                Jul 9 at 9:25











                                3


















                                If you don't like what you're working on, then leave for another company. Programmers are in high demand.



                                Make sure you find up-front about the types of working you'll be doing. I won't criticise anyone for leaving in your situation, it sounds awful. But if you were hired knowing you'd be working on this type of project, then it would be in poor taste to complain about it.



                                There is rarely much scope for changing your day to day work within a company, those things tend to be long term, and they are almost always inferior to simply finding another job doing something you want to be doing.






                                share|improve this answer





















                                • 2





                                  This is very much the right answer. If you only want to do greenfield development your best bets are to either work for a startup, or work for a company doing consulting/contracting work for small businesses where you'd spend a few months making the a website/etc and then the contract would end and you'd go on to do another project for a different customer.

                                  – Dan Neely
                                  Jul 5 at 22:33






                                • 8





                                  Other companies will also have legacy code, so changing jobs is no guarantee to fix this at all.

                                  – Mark Rotteveel
                                  Jul 6 at 9:57











                                • As I said though, work out what you want and discuss in the interview of a the new job what you'll be expected to do. If you're up-front you'll be much less likely to end up in a situation you don't like.

                                  – NibblyPig
                                  Jul 8 at 7:57















                                3


















                                If you don't like what you're working on, then leave for another company. Programmers are in high demand.



                                Make sure you find up-front about the types of working you'll be doing. I won't criticise anyone for leaving in your situation, it sounds awful. But if you were hired knowing you'd be working on this type of project, then it would be in poor taste to complain about it.



                                There is rarely much scope for changing your day to day work within a company, those things tend to be long term, and they are almost always inferior to simply finding another job doing something you want to be doing.






                                share|improve this answer





















                                • 2





                                  This is very much the right answer. If you only want to do greenfield development your best bets are to either work for a startup, or work for a company doing consulting/contracting work for small businesses where you'd spend a few months making the a website/etc and then the contract would end and you'd go on to do another project for a different customer.

                                  – Dan Neely
                                  Jul 5 at 22:33






                                • 8





                                  Other companies will also have legacy code, so changing jobs is no guarantee to fix this at all.

                                  – Mark Rotteveel
                                  Jul 6 at 9:57











                                • As I said though, work out what you want and discuss in the interview of a the new job what you'll be expected to do. If you're up-front you'll be much less likely to end up in a situation you don't like.

                                  – NibblyPig
                                  Jul 8 at 7:57













                                3














                                3










                                3









                                If you don't like what you're working on, then leave for another company. Programmers are in high demand.



                                Make sure you find up-front about the types of working you'll be doing. I won't criticise anyone for leaving in your situation, it sounds awful. But if you were hired knowing you'd be working on this type of project, then it would be in poor taste to complain about it.



                                There is rarely much scope for changing your day to day work within a company, those things tend to be long term, and they are almost always inferior to simply finding another job doing something you want to be doing.






                                share|improve this answer














                                If you don't like what you're working on, then leave for another company. Programmers are in high demand.



                                Make sure you find up-front about the types of working you'll be doing. I won't criticise anyone for leaving in your situation, it sounds awful. But if you were hired knowing you'd be working on this type of project, then it would be in poor taste to complain about it.



                                There is rarely much scope for changing your day to day work within a company, those things tend to be long term, and they are almost always inferior to simply finding another job doing something you want to be doing.







                                share|improve this answer













                                share|improve this answer




                                share|improve this answer










                                answered Jul 5 at 12:23









                                NibblyPigNibblyPig

                                1,4302 gold badges9 silver badges13 bronze badges




                                1,4302 gold badges9 silver badges13 bronze badges










                                • 2





                                  This is very much the right answer. If you only want to do greenfield development your best bets are to either work for a startup, or work for a company doing consulting/contracting work for small businesses where you'd spend a few months making the a website/etc and then the contract would end and you'd go on to do another project for a different customer.

                                  – Dan Neely
                                  Jul 5 at 22:33






                                • 8





                                  Other companies will also have legacy code, so changing jobs is no guarantee to fix this at all.

                                  – Mark Rotteveel
                                  Jul 6 at 9:57











                                • As I said though, work out what you want and discuss in the interview of a the new job what you'll be expected to do. If you're up-front you'll be much less likely to end up in a situation you don't like.

                                  – NibblyPig
                                  Jul 8 at 7:57












                                • 2





                                  This is very much the right answer. If you only want to do greenfield development your best bets are to either work for a startup, or work for a company doing consulting/contracting work for small businesses where you'd spend a few months making the a website/etc and then the contract would end and you'd go on to do another project for a different customer.

                                  – Dan Neely
                                  Jul 5 at 22:33






                                • 8





                                  Other companies will also have legacy code, so changing jobs is no guarantee to fix this at all.

                                  – Mark Rotteveel
                                  Jul 6 at 9:57











                                • As I said though, work out what you want and discuss in the interview of a the new job what you'll be expected to do. If you're up-front you'll be much less likely to end up in a situation you don't like.

                                  – NibblyPig
                                  Jul 8 at 7:57







                                2




                                2





                                This is very much the right answer. If you only want to do greenfield development your best bets are to either work for a startup, or work for a company doing consulting/contracting work for small businesses where you'd spend a few months making the a website/etc and then the contract would end and you'd go on to do another project for a different customer.

                                – Dan Neely
                                Jul 5 at 22:33





                                This is very much the right answer. If you only want to do greenfield development your best bets are to either work for a startup, or work for a company doing consulting/contracting work for small businesses where you'd spend a few months making the a website/etc and then the contract would end and you'd go on to do another project for a different customer.

                                – Dan Neely
                                Jul 5 at 22:33




                                8




                                8





                                Other companies will also have legacy code, so changing jobs is no guarantee to fix this at all.

                                – Mark Rotteveel
                                Jul 6 at 9:57





                                Other companies will also have legacy code, so changing jobs is no guarantee to fix this at all.

                                – Mark Rotteveel
                                Jul 6 at 9:57













                                As I said though, work out what you want and discuss in the interview of a the new job what you'll be expected to do. If you're up-front you'll be much less likely to end up in a situation you don't like.

                                – NibblyPig
                                Jul 8 at 7:57





                                As I said though, work out what you want and discuss in the interview of a the new job what you'll be expected to do. If you're up-front you'll be much less likely to end up in a situation you don't like.

                                – NibblyPig
                                Jul 8 at 7:57











                                3


















                                It depends on the company. In my last job, my company offers IT solutions to government and banks. So everytime it is a new tender and a new project. I belongs to development team, which takes part in bidding, designing and implementing projects. After production release, the maintenance team will take over and will only contact us with issues they cannot handle. So a company of a different nature may be a solution.



                                But, you can view your situation in a different light.



                                If the software you are maintaining is bad, then fix it. If it is beyond fixing, explains to your supervisor why it is so, and propose a solution.



                                What you consider a bad situation, could be instead a chance to show your supervisor what you are capable of.



                                If your supervisor sees you in a positive light, you'd have a much better chance to get assigned to the projects you want to do, or persuade him/her to reassign you.



                                In my current 2-year contract job, I'm maintaining bad software like you. The original vendor is long gone and code quality is bad. My supervisor is reluctant to big changes as the company culture is very reserved and they hate taking risks. I presented the pros and cons of various options to fix the part I am working on, it took me lots of effort but I eventually won them over. A few months in, my supervisor is talking about offering me a permanent position.



                                Heroes rise from the occasion.






                                share|improve this answer
































                                  3


















                                  It depends on the company. In my last job, my company offers IT solutions to government and banks. So everytime it is a new tender and a new project. I belongs to development team, which takes part in bidding, designing and implementing projects. After production release, the maintenance team will take over and will only contact us with issues they cannot handle. So a company of a different nature may be a solution.



                                  But, you can view your situation in a different light.



                                  If the software you are maintaining is bad, then fix it. If it is beyond fixing, explains to your supervisor why it is so, and propose a solution.



                                  What you consider a bad situation, could be instead a chance to show your supervisor what you are capable of.



                                  If your supervisor sees you in a positive light, you'd have a much better chance to get assigned to the projects you want to do, or persuade him/her to reassign you.



                                  In my current 2-year contract job, I'm maintaining bad software like you. The original vendor is long gone and code quality is bad. My supervisor is reluctant to big changes as the company culture is very reserved and they hate taking risks. I presented the pros and cons of various options to fix the part I am working on, it took me lots of effort but I eventually won them over. A few months in, my supervisor is talking about offering me a permanent position.



                                  Heroes rise from the occasion.






                                  share|improve this answer






























                                    3














                                    3










                                    3









                                    It depends on the company. In my last job, my company offers IT solutions to government and banks. So everytime it is a new tender and a new project. I belongs to development team, which takes part in bidding, designing and implementing projects. After production release, the maintenance team will take over and will only contact us with issues they cannot handle. So a company of a different nature may be a solution.



                                    But, you can view your situation in a different light.



                                    If the software you are maintaining is bad, then fix it. If it is beyond fixing, explains to your supervisor why it is so, and propose a solution.



                                    What you consider a bad situation, could be instead a chance to show your supervisor what you are capable of.



                                    If your supervisor sees you in a positive light, you'd have a much better chance to get assigned to the projects you want to do, or persuade him/her to reassign you.



                                    In my current 2-year contract job, I'm maintaining bad software like you. The original vendor is long gone and code quality is bad. My supervisor is reluctant to big changes as the company culture is very reserved and they hate taking risks. I presented the pros and cons of various options to fix the part I am working on, it took me lots of effort but I eventually won them over. A few months in, my supervisor is talking about offering me a permanent position.



                                    Heroes rise from the occasion.






                                    share|improve this answer
















                                    It depends on the company. In my last job, my company offers IT solutions to government and banks. So everytime it is a new tender and a new project. I belongs to development team, which takes part in bidding, designing and implementing projects. After production release, the maintenance team will take over and will only contact us with issues they cannot handle. So a company of a different nature may be a solution.



                                    But, you can view your situation in a different light.



                                    If the software you are maintaining is bad, then fix it. If it is beyond fixing, explains to your supervisor why it is so, and propose a solution.



                                    What you consider a bad situation, could be instead a chance to show your supervisor what you are capable of.



                                    If your supervisor sees you in a positive light, you'd have a much better chance to get assigned to the projects you want to do, or persuade him/her to reassign you.



                                    In my current 2-year contract job, I'm maintaining bad software like you. The original vendor is long gone and code quality is bad. My supervisor is reluctant to big changes as the company culture is very reserved and they hate taking risks. I presented the pros and cons of various options to fix the part I am working on, it took me lots of effort but I eventually won them over. A few months in, my supervisor is talking about offering me a permanent position.



                                    Heroes rise from the occasion.







                                    share|improve this answer















                                    share|improve this answer




                                    share|improve this answer








                                    edited Jul 6 at 12:52

























                                    answered Jul 6 at 12:45









                                    KC WongKC Wong

                                    1304 bronze badges




                                    1304 bronze badges
























                                        2


















                                        Put yourself in the other shoes
                                        You know your manager, he listen to his team? Is a reasonable manager? Try to satisfy developers needs? Is communicative?
                                        This is very important, your manager has a role...get the job done, present results. And for that, someone has to take care of the legacy project.



                                        • Does he has another replacement?

                                        • Does he has another project more attractive to your preferences that give you motivation, maybe a 50% of your time?.

                                        • Can he give you green light to recreate some part of the project?

                                        You don't know for certain.... so, yes, you have to talk to him. Not in a demanding way, no if you like the workplace. But you have to talk to him about your discomfort, because employees leaving is not a good result either, ... no company/manager get benefit for a developer resign. And you are not asking him more money, or less hours, or telecommute, or something that interfere with the company policies/resources. It's something about trying reorganize allocations of the team, it´s more 'doable'. And you are not getting fired for let him know about a discomfort. But the only one that can help to resolve your discomfort is him, if you want to stay there of course.



                                        Ask him for a short private meeting.
                                        Be relax, no angry emotions, no demanding tones.
                                        This is a conversation with a team member that can help you find a solution to a discomfort.



                                        Even if he does nothing for you, and nothing can be done. It´s not in your hands, you did what you could to be moved. Because if you say nothing and find a new job, in the moment you say to him, the first thing is going to tell you is 'I didn't now you felt this way, we could try to work this out'. When you leave a company for money, you ask a rise first, this is the same, before start to look for jobs, let them a chance to find a solution where both interests get satisfied. Think in a way that you get motivation at the same time you provide value to the team/client






                                        share|improve this answer






























                                          2


















                                          Put yourself in the other shoes
                                          You know your manager, he listen to his team? Is a reasonable manager? Try to satisfy developers needs? Is communicative?
                                          This is very important, your manager has a role...get the job done, present results. And for that, someone has to take care of the legacy project.



                                          • Does he has another replacement?

                                          • Does he has another project more attractive to your preferences that give you motivation, maybe a 50% of your time?.

                                          • Can he give you green light to recreate some part of the project?

                                          You don't know for certain.... so, yes, you have to talk to him. Not in a demanding way, no if you like the workplace. But you have to talk to him about your discomfort, because employees leaving is not a good result either, ... no company/manager get benefit for a developer resign. And you are not asking him more money, or less hours, or telecommute, or something that interfere with the company policies/resources. It's something about trying reorganize allocations of the team, it´s more 'doable'. And you are not getting fired for let him know about a discomfort. But the only one that can help to resolve your discomfort is him, if you want to stay there of course.



                                          Ask him for a short private meeting.
                                          Be relax, no angry emotions, no demanding tones.
                                          This is a conversation with a team member that can help you find a solution to a discomfort.



                                          Even if he does nothing for you, and nothing can be done. It´s not in your hands, you did what you could to be moved. Because if you say nothing and find a new job, in the moment you say to him, the first thing is going to tell you is 'I didn't now you felt this way, we could try to work this out'. When you leave a company for money, you ask a rise first, this is the same, before start to look for jobs, let them a chance to find a solution where both interests get satisfied. Think in a way that you get motivation at the same time you provide value to the team/client






                                          share|improve this answer




























                                            2














                                            2










                                            2









                                            Put yourself in the other shoes
                                            You know your manager, he listen to his team? Is a reasonable manager? Try to satisfy developers needs? Is communicative?
                                            This is very important, your manager has a role...get the job done, present results. And for that, someone has to take care of the legacy project.



                                            • Does he has another replacement?

                                            • Does he has another project more attractive to your preferences that give you motivation, maybe a 50% of your time?.

                                            • Can he give you green light to recreate some part of the project?

                                            You don't know for certain.... so, yes, you have to talk to him. Not in a demanding way, no if you like the workplace. But you have to talk to him about your discomfort, because employees leaving is not a good result either, ... no company/manager get benefit for a developer resign. And you are not asking him more money, or less hours, or telecommute, or something that interfere with the company policies/resources. It's something about trying reorganize allocations of the team, it´s more 'doable'. And you are not getting fired for let him know about a discomfort. But the only one that can help to resolve your discomfort is him, if you want to stay there of course.



                                            Ask him for a short private meeting.
                                            Be relax, no angry emotions, no demanding tones.
                                            This is a conversation with a team member that can help you find a solution to a discomfort.



                                            Even if he does nothing for you, and nothing can be done. It´s not in your hands, you did what you could to be moved. Because if you say nothing and find a new job, in the moment you say to him, the first thing is going to tell you is 'I didn't now you felt this way, we could try to work this out'. When you leave a company for money, you ask a rise first, this is the same, before start to look for jobs, let them a chance to find a solution where both interests get satisfied. Think in a way that you get motivation at the same time you provide value to the team/client






                                            share|improve this answer














                                            Put yourself in the other shoes
                                            You know your manager, he listen to his team? Is a reasonable manager? Try to satisfy developers needs? Is communicative?
                                            This is very important, your manager has a role...get the job done, present results. And for that, someone has to take care of the legacy project.



                                            • Does he has another replacement?

                                            • Does he has another project more attractive to your preferences that give you motivation, maybe a 50% of your time?.

                                            • Can he give you green light to recreate some part of the project?

                                            You don't know for certain.... so, yes, you have to talk to him. Not in a demanding way, no if you like the workplace. But you have to talk to him about your discomfort, because employees leaving is not a good result either, ... no company/manager get benefit for a developer resign. And you are not asking him more money, or less hours, or telecommute, or something that interfere with the company policies/resources. It's something about trying reorganize allocations of the team, it´s more 'doable'. And you are not getting fired for let him know about a discomfort. But the only one that can help to resolve your discomfort is him, if you want to stay there of course.



                                            Ask him for a short private meeting.
                                            Be relax, no angry emotions, no demanding tones.
                                            This is a conversation with a team member that can help you find a solution to a discomfort.



                                            Even if he does nothing for you, and nothing can be done. It´s not in your hands, you did what you could to be moved. Because if you say nothing and find a new job, in the moment you say to him, the first thing is going to tell you is 'I didn't now you felt this way, we could try to work this out'. When you leave a company for money, you ask a rise first, this is the same, before start to look for jobs, let them a chance to find a solution where both interests get satisfied. Think in a way that you get motivation at the same time you provide value to the team/client







                                            share|improve this answer













                                            share|improve this answer




                                            share|improve this answer










                                            answered Jul 5 at 21:45









                                            AferrercrafterAferrercrafter

                                            213 bronze badges




                                            213 bronze badges
























                                                2


















                                                There's a good chance you might benefit from hearing my story, so here goes.



                                                I was hired at my company to work on one particular project (partly because I was the only guy they interviewed that knew electronics at all, but that ended up being largely irrelevant). On having worked on it for about six months I came to the conclusion the architecture was a total loss despite the codebase being only a year and a half old at that point. I thought at the time I was looking at a three year old codebase and the company had a history of bad source control practices. In fact their source control use was kinda ok (it got better) and the product was made by big bang production.



                                                I reported by analogy the foundation was cracked and the ground was unstable. In fact a total rewrite was required but it could not be afforded at that time and I knew it. We agreed by analogy that as it became necessary I would ram I-beams through the foundation to serve as pylons. Over the next decade as things broke or became unsustainable or the profiler located hotspots I replaced almost all the original architecture, to the point were now only a couple dozen lines remain. But now the I-beams themselves have cracked and been braced and the house-become-skycraper is showing its age and again become hard to work on and I dread teaching new programmers all that is required to add new tables to the database as no good examples remain. Every explanation for how things work has become a history lesson now.



                                                I don't work on the product much anymore, but whenever a change needs to be made that breaks the rules of the architecture, I do it, not because only I can do it, but because I know essentially all the rules in my head and therefore can pick the way easiest to maintain the consequences thereof.



                                                But only now do I have the experience to do actually to it right and design an architecture that can actually be maintained for twenty years or more. Some of the problems are bad decisions of the original architecture where I replaced the implementation with a work-nearly-alike retaining many of the same decisions. Some of the problems are my own bad decisions. And the industry has changed and we want to replace the fat-client architecture with a web architecture. You know what, now's the time. I don't have the full set of skills for a web architecture but I've got most of them and I know where to turn for the rest.



                                                The choice really has to be yours, but you may have here the place to run I-beams through the foundation. If you choose to do so, you're gonna learn and become strong.






                                                share|improve this answer






























                                                  2


















                                                  There's a good chance you might benefit from hearing my story, so here goes.



                                                  I was hired at my company to work on one particular project (partly because I was the only guy they interviewed that knew electronics at all, but that ended up being largely irrelevant). On having worked on it for about six months I came to the conclusion the architecture was a total loss despite the codebase being only a year and a half old at that point. I thought at the time I was looking at a three year old codebase and the company had a history of bad source control practices. In fact their source control use was kinda ok (it got better) and the product was made by big bang production.



                                                  I reported by analogy the foundation was cracked and the ground was unstable. In fact a total rewrite was required but it could not be afforded at that time and I knew it. We agreed by analogy that as it became necessary I would ram I-beams through the foundation to serve as pylons. Over the next decade as things broke or became unsustainable or the profiler located hotspots I replaced almost all the original architecture, to the point were now only a couple dozen lines remain. But now the I-beams themselves have cracked and been braced and the house-become-skycraper is showing its age and again become hard to work on and I dread teaching new programmers all that is required to add new tables to the database as no good examples remain. Every explanation for how things work has become a history lesson now.



                                                  I don't work on the product much anymore, but whenever a change needs to be made that breaks the rules of the architecture, I do it, not because only I can do it, but because I know essentially all the rules in my head and therefore can pick the way easiest to maintain the consequences thereof.



                                                  But only now do I have the experience to do actually to it right and design an architecture that can actually be maintained for twenty years or more. Some of the problems are bad decisions of the original architecture where I replaced the implementation with a work-nearly-alike retaining many of the same decisions. Some of the problems are my own bad decisions. And the industry has changed and we want to replace the fat-client architecture with a web architecture. You know what, now's the time. I don't have the full set of skills for a web architecture but I've got most of them and I know where to turn for the rest.



                                                  The choice really has to be yours, but you may have here the place to run I-beams through the foundation. If you choose to do so, you're gonna learn and become strong.






                                                  share|improve this answer




























                                                    2














                                                    2










                                                    2









                                                    There's a good chance you might benefit from hearing my story, so here goes.



                                                    I was hired at my company to work on one particular project (partly because I was the only guy they interviewed that knew electronics at all, but that ended up being largely irrelevant). On having worked on it for about six months I came to the conclusion the architecture was a total loss despite the codebase being only a year and a half old at that point. I thought at the time I was looking at a three year old codebase and the company had a history of bad source control practices. In fact their source control use was kinda ok (it got better) and the product was made by big bang production.



                                                    I reported by analogy the foundation was cracked and the ground was unstable. In fact a total rewrite was required but it could not be afforded at that time and I knew it. We agreed by analogy that as it became necessary I would ram I-beams through the foundation to serve as pylons. Over the next decade as things broke or became unsustainable or the profiler located hotspots I replaced almost all the original architecture, to the point were now only a couple dozen lines remain. But now the I-beams themselves have cracked and been braced and the house-become-skycraper is showing its age and again become hard to work on and I dread teaching new programmers all that is required to add new tables to the database as no good examples remain. Every explanation for how things work has become a history lesson now.



                                                    I don't work on the product much anymore, but whenever a change needs to be made that breaks the rules of the architecture, I do it, not because only I can do it, but because I know essentially all the rules in my head and therefore can pick the way easiest to maintain the consequences thereof.



                                                    But only now do I have the experience to do actually to it right and design an architecture that can actually be maintained for twenty years or more. Some of the problems are bad decisions of the original architecture where I replaced the implementation with a work-nearly-alike retaining many of the same decisions. Some of the problems are my own bad decisions. And the industry has changed and we want to replace the fat-client architecture with a web architecture. You know what, now's the time. I don't have the full set of skills for a web architecture but I've got most of them and I know where to turn for the rest.



                                                    The choice really has to be yours, but you may have here the place to run I-beams through the foundation. If you choose to do so, you're gonna learn and become strong.






                                                    share|improve this answer














                                                    There's a good chance you might benefit from hearing my story, so here goes.



                                                    I was hired at my company to work on one particular project (partly because I was the only guy they interviewed that knew electronics at all, but that ended up being largely irrelevant). On having worked on it for about six months I came to the conclusion the architecture was a total loss despite the codebase being only a year and a half old at that point. I thought at the time I was looking at a three year old codebase and the company had a history of bad source control practices. In fact their source control use was kinda ok (it got better) and the product was made by big bang production.



                                                    I reported by analogy the foundation was cracked and the ground was unstable. In fact a total rewrite was required but it could not be afforded at that time and I knew it. We agreed by analogy that as it became necessary I would ram I-beams through the foundation to serve as pylons. Over the next decade as things broke or became unsustainable or the profiler located hotspots I replaced almost all the original architecture, to the point were now only a couple dozen lines remain. But now the I-beams themselves have cracked and been braced and the house-become-skycraper is showing its age and again become hard to work on and I dread teaching new programmers all that is required to add new tables to the database as no good examples remain. Every explanation for how things work has become a history lesson now.



                                                    I don't work on the product much anymore, but whenever a change needs to be made that breaks the rules of the architecture, I do it, not because only I can do it, but because I know essentially all the rules in my head and therefore can pick the way easiest to maintain the consequences thereof.



                                                    But only now do I have the experience to do actually to it right and design an architecture that can actually be maintained for twenty years or more. Some of the problems are bad decisions of the original architecture where I replaced the implementation with a work-nearly-alike retaining many of the same decisions. Some of the problems are my own bad decisions. And the industry has changed and we want to replace the fat-client architecture with a web architecture. You know what, now's the time. I don't have the full set of skills for a web architecture but I've got most of them and I know where to turn for the rest.



                                                    The choice really has to be yours, but you may have here the place to run I-beams through the foundation. If you choose to do so, you're gonna learn and become strong.







                                                    share|improve this answer













                                                    share|improve this answer




                                                    share|improve this answer










                                                    answered Jul 8 at 3:11









                                                    JoshuaJoshua

                                                    6135 silver badges12 bronze badges




                                                    6135 silver badges12 bronze badges
























                                                        2


















                                                        Make sure you know yourself before doing anything drastic



                                                        Three years is still pretty junior, so I wouldn't do anything drastic like changing jobs or careers until you've made sure you know what it is about maintaining legacy code that you don't like. For example, it's possible that you need to learn a new tool or technique, and that you can actually learn to like maintaining legacy code. If you have a mentor, this would be a good thing to discuss with them. If you don't have a mentor, you should try to find one.



                                                        Unhappy = poor performance = career hit = time to change



                                                        Once you're sure it's not you, it's the job, then realize that you will only do your best work if you're happy, or at least satisfied with your job. If you are actively unhappy or hate your job, it's going to show in your work. This will hurt your career in the long run. So you're not doing yourself any favors staying in a situation that actively makes you unhappy (sometimes we don't have any choice, but if you do, and most of the time we do, then you need to make a change).



                                                        What should you do?



                                                        Tell your boss your preferences, and if your boss can't or won't honor them in a reasonable time frame, find a job that can and will. Note that almost no job (including if you're your own boss) will meet your preferences 100% of the time; that's just life. But a good fit is one that is acceptable to you and mixes tasks that you like with some tasks that you can at least tolerate. But if you find yourself hating your job, it's time for a change.



                                                        One last thing



                                                        If you're working long hours or working weekends without adequate breaks, then you could be experiencing burnout, which can make even the most pleasant tasks feel like chores and boring tasks feel unbearable. So part of taking stock of your situation includes making sure that your hatred for your job is really coming from the work and not from burnout-induced stress. If the problem turns out to be burnout, it needs to be addressed differently than if it is simply not liking your job.






                                                        share|improve this answer
































                                                          2


















                                                          Make sure you know yourself before doing anything drastic



                                                          Three years is still pretty junior, so I wouldn't do anything drastic like changing jobs or careers until you've made sure you know what it is about maintaining legacy code that you don't like. For example, it's possible that you need to learn a new tool or technique, and that you can actually learn to like maintaining legacy code. If you have a mentor, this would be a good thing to discuss with them. If you don't have a mentor, you should try to find one.



                                                          Unhappy = poor performance = career hit = time to change



                                                          Once you're sure it's not you, it's the job, then realize that you will only do your best work if you're happy, or at least satisfied with your job. If you are actively unhappy or hate your job, it's going to show in your work. This will hurt your career in the long run. So you're not doing yourself any favors staying in a situation that actively makes you unhappy (sometimes we don't have any choice, but if you do, and most of the time we do, then you need to make a change).



                                                          What should you do?



                                                          Tell your boss your preferences, and if your boss can't or won't honor them in a reasonable time frame, find a job that can and will. Note that almost no job (including if you're your own boss) will meet your preferences 100% of the time; that's just life. But a good fit is one that is acceptable to you and mixes tasks that you like with some tasks that you can at least tolerate. But if you find yourself hating your job, it's time for a change.



                                                          One last thing



                                                          If you're working long hours or working weekends without adequate breaks, then you could be experiencing burnout, which can make even the most pleasant tasks feel like chores and boring tasks feel unbearable. So part of taking stock of your situation includes making sure that your hatred for your job is really coming from the work and not from burnout-induced stress. If the problem turns out to be burnout, it needs to be addressed differently than if it is simply not liking your job.






                                                          share|improve this answer






























                                                            2














                                                            2










                                                            2









                                                            Make sure you know yourself before doing anything drastic



                                                            Three years is still pretty junior, so I wouldn't do anything drastic like changing jobs or careers until you've made sure you know what it is about maintaining legacy code that you don't like. For example, it's possible that you need to learn a new tool or technique, and that you can actually learn to like maintaining legacy code. If you have a mentor, this would be a good thing to discuss with them. If you don't have a mentor, you should try to find one.



                                                            Unhappy = poor performance = career hit = time to change



                                                            Once you're sure it's not you, it's the job, then realize that you will only do your best work if you're happy, or at least satisfied with your job. If you are actively unhappy or hate your job, it's going to show in your work. This will hurt your career in the long run. So you're not doing yourself any favors staying in a situation that actively makes you unhappy (sometimes we don't have any choice, but if you do, and most of the time we do, then you need to make a change).



                                                            What should you do?



                                                            Tell your boss your preferences, and if your boss can't or won't honor them in a reasonable time frame, find a job that can and will. Note that almost no job (including if you're your own boss) will meet your preferences 100% of the time; that's just life. But a good fit is one that is acceptable to you and mixes tasks that you like with some tasks that you can at least tolerate. But if you find yourself hating your job, it's time for a change.



                                                            One last thing



                                                            If you're working long hours or working weekends without adequate breaks, then you could be experiencing burnout, which can make even the most pleasant tasks feel like chores and boring tasks feel unbearable. So part of taking stock of your situation includes making sure that your hatred for your job is really coming from the work and not from burnout-induced stress. If the problem turns out to be burnout, it needs to be addressed differently than if it is simply not liking your job.






                                                            share|improve this answer
















                                                            Make sure you know yourself before doing anything drastic



                                                            Three years is still pretty junior, so I wouldn't do anything drastic like changing jobs or careers until you've made sure you know what it is about maintaining legacy code that you don't like. For example, it's possible that you need to learn a new tool or technique, and that you can actually learn to like maintaining legacy code. If you have a mentor, this would be a good thing to discuss with them. If you don't have a mentor, you should try to find one.



                                                            Unhappy = poor performance = career hit = time to change



                                                            Once you're sure it's not you, it's the job, then realize that you will only do your best work if you're happy, or at least satisfied with your job. If you are actively unhappy or hate your job, it's going to show in your work. This will hurt your career in the long run. So you're not doing yourself any favors staying in a situation that actively makes you unhappy (sometimes we don't have any choice, but if you do, and most of the time we do, then you need to make a change).



                                                            What should you do?



                                                            Tell your boss your preferences, and if your boss can't or won't honor them in a reasonable time frame, find a job that can and will. Note that almost no job (including if you're your own boss) will meet your preferences 100% of the time; that's just life. But a good fit is one that is acceptable to you and mixes tasks that you like with some tasks that you can at least tolerate. But if you find yourself hating your job, it's time for a change.



                                                            One last thing



                                                            If you're working long hours or working weekends without adequate breaks, then you could be experiencing burnout, which can make even the most pleasant tasks feel like chores and boring tasks feel unbearable. So part of taking stock of your situation includes making sure that your hatred for your job is really coming from the work and not from burnout-induced stress. If the problem turns out to be burnout, it needs to be addressed differently than if it is simply not liking your job.







                                                            share|improve this answer















                                                            share|improve this answer




                                                            share|improve this answer








                                                            edited Jul 8 at 15:51

























                                                            answered Jul 8 at 15:44









                                                            bobbob

                                                            3,7861 gold badge8 silver badges29 bronze badges




                                                            3,7861 gold badge8 silver badges29 bronze badges
























                                                                1


















                                                                Here is a strategy that you could use. But, be careful, this could put you in an unfavorable position with your manager.



                                                                Tell them that certain modules are crap and need to be re-written from scratch, you are unable to band-aid them. He/she might find someone else, or let you re-write. If you can re-write, it is almost like a new project, you should be happy.



                                                                I have seen both sides of this. I have re-written lousy code that would take me longer to understand and fix than re-write. And I have seen people re-write code that I thought was OK and maintainable (and break my budget).






                                                                share|improve this answer





















                                                                • 1





                                                                  There has to be a balance. If the project is deployed, then bugs have to be fixed and user concerns have to be addressed. But also, there has to be forward progress in improving code quality and maintainability or the code will become unmaintainable. If forward progress isn't being made (or worse, the code is acquiring more "quick fixes" and getting worse) then more resources need to be assigned. With luck, a good balance between keeping the code working and keeping the code improving can be negotiated with management.

                                                                  – David Schwartz
                                                                  Jul 5 at 23:08















                                                                1


















                                                                Here is a strategy that you could use. But, be careful, this could put you in an unfavorable position with your manager.



                                                                Tell them that certain modules are crap and need to be re-written from scratch, you are unable to band-aid them. He/she might find someone else, or let you re-write. If you can re-write, it is almost like a new project, you should be happy.



                                                                I have seen both sides of this. I have re-written lousy code that would take me longer to understand and fix than re-write. And I have seen people re-write code that I thought was OK and maintainable (and break my budget).






                                                                share|improve this answer





















                                                                • 1





                                                                  There has to be a balance. If the project is deployed, then bugs have to be fixed and user concerns have to be addressed. But also, there has to be forward progress in improving code quality and maintainability or the code will become unmaintainable. If forward progress isn't being made (or worse, the code is acquiring more "quick fixes" and getting worse) then more resources need to be assigned. With luck, a good balance between keeping the code working and keeping the code improving can be negotiated with management.

                                                                  – David Schwartz
                                                                  Jul 5 at 23:08













                                                                1














                                                                1










                                                                1









                                                                Here is a strategy that you could use. But, be careful, this could put you in an unfavorable position with your manager.



                                                                Tell them that certain modules are crap and need to be re-written from scratch, you are unable to band-aid them. He/she might find someone else, or let you re-write. If you can re-write, it is almost like a new project, you should be happy.



                                                                I have seen both sides of this. I have re-written lousy code that would take me longer to understand and fix than re-write. And I have seen people re-write code that I thought was OK and maintainable (and break my budget).






                                                                share|improve this answer














                                                                Here is a strategy that you could use. But, be careful, this could put you in an unfavorable position with your manager.



                                                                Tell them that certain modules are crap and need to be re-written from scratch, you are unable to band-aid them. He/she might find someone else, or let you re-write. If you can re-write, it is almost like a new project, you should be happy.



                                                                I have seen both sides of this. I have re-written lousy code that would take me longer to understand and fix than re-write. And I have seen people re-write code that I thought was OK and maintainable (and break my budget).







                                                                share|improve this answer













                                                                share|improve this answer




                                                                share|improve this answer










                                                                answered Jul 5 at 22:50









                                                                Mattman944Mattman944

                                                                1416 bronze badges




                                                                1416 bronze badges










                                                                • 1





                                                                  There has to be a balance. If the project is deployed, then bugs have to be fixed and user concerns have to be addressed. But also, there has to be forward progress in improving code quality and maintainability or the code will become unmaintainable. If forward progress isn't being made (or worse, the code is acquiring more "quick fixes" and getting worse) then more resources need to be assigned. With luck, a good balance between keeping the code working and keeping the code improving can be negotiated with management.

                                                                  – David Schwartz
                                                                  Jul 5 at 23:08












                                                                • 1





                                                                  There has to be a balance. If the project is deployed, then bugs have to be fixed and user concerns have to be addressed. But also, there has to be forward progress in improving code quality and maintainability or the code will become unmaintainable. If forward progress isn't being made (or worse, the code is acquiring more "quick fixes" and getting worse) then more resources need to be assigned. With luck, a good balance between keeping the code working and keeping the code improving can be negotiated with management.

                                                                  – David Schwartz
                                                                  Jul 5 at 23:08







                                                                1




                                                                1





                                                                There has to be a balance. If the project is deployed, then bugs have to be fixed and user concerns have to be addressed. But also, there has to be forward progress in improving code quality and maintainability or the code will become unmaintainable. If forward progress isn't being made (or worse, the code is acquiring more "quick fixes" and getting worse) then more resources need to be assigned. With luck, a good balance between keeping the code working and keeping the code improving can be negotiated with management.

                                                                – David Schwartz
                                                                Jul 5 at 23:08





                                                                There has to be a balance. If the project is deployed, then bugs have to be fixed and user concerns have to be addressed. But also, there has to be forward progress in improving code quality and maintainability or the code will become unmaintainable. If forward progress isn't being made (or worse, the code is acquiring more "quick fixes" and getting worse) then more resources need to be assigned. With luck, a good balance between keeping the code working and keeping the code improving can be negotiated with management.

                                                                – David Schwartz
                                                                Jul 5 at 23:08











                                                                1


















                                                                After a few times I discovered that I begin "hating" some code base, I started researching why.



                                                                And found out that it's because it has some drawbacks that are constantly bothering me and remain unfixed. The bother is thus building up and...



                                                                So the way to elminate that "hate" is to identify and fix the things that are bothering you about that code!



                                                                What is most important, you already know them (since they are bothering you) but didn't care to prioritize.



                                                                You named a few already: "it's not easy to understand code, especially if there's no documentation." When examining the code, you must have identified that these and these parts are sloppy and error-prone; here and here, there are no tests so no way to know if the code is (still) correct in all cases, etc.






                                                                share|improve this answer





















                                                                • 1





                                                                  This is good advice, though sometimes what you "hate" is person-years worth of technical debt that one person cannot feasibly fix unfortunately. Which is likely I think for many large legacy codebases. So it may not be avoidable in many situations.

                                                                  – bob
                                                                  Jul 8 at 15:37











                                                                • @bob still, it's better from psychological POV to fix one thing at a time and feel better than waste your nerve cells doing nothing. Then, technical debt is taxing the ongoing maintenance and is thus only not worth paying off if the product is near its EOL. For OP's case, this doesn't seem to be the case (since they say they are maintaining it on an ongoing basis with no end date in sight).

                                                                  – ivan_pozdeev
                                                                  Jul 8 at 15:54











                                                                • True. If you're stuck in the situation or while waiting to get out of it, then that's a good strategy (again if you can; sometimes you're told not to touch a particular piece of code). But at the end of the day its best to do work you find satisfying. You'll do the best work and it will show in your career.

                                                                  – bob
                                                                  Jul 8 at 16:00















                                                                1


















                                                                After a few times I discovered that I begin "hating" some code base, I started researching why.



                                                                And found out that it's because it has some drawbacks that are constantly bothering me and remain unfixed. The bother is thus building up and...



                                                                So the way to elminate that "hate" is to identify and fix the things that are bothering you about that code!



                                                                What is most important, you already know them (since they are bothering you) but didn't care to prioritize.



                                                                You named a few already: "it's not easy to understand code, especially if there's no documentation." When examining the code, you must have identified that these and these parts are sloppy and error-prone; here and here, there are no tests so no way to know if the code is (still) correct in all cases, etc.






                                                                share|improve this answer





















                                                                • 1





                                                                  This is good advice, though sometimes what you "hate" is person-years worth of technical debt that one person cannot feasibly fix unfortunately. Which is likely I think for many large legacy codebases. So it may not be avoidable in many situations.

                                                                  – bob
                                                                  Jul 8 at 15:37











                                                                • @bob still, it's better from psychological POV to fix one thing at a time and feel better than waste your nerve cells doing nothing. Then, technical debt is taxing the ongoing maintenance and is thus only not worth paying off if the product is near its EOL. For OP's case, this doesn't seem to be the case (since they say they are maintaining it on an ongoing basis with no end date in sight).

                                                                  – ivan_pozdeev
                                                                  Jul 8 at 15:54











                                                                • True. If you're stuck in the situation or while waiting to get out of it, then that's a good strategy (again if you can; sometimes you're told not to touch a particular piece of code). But at the end of the day its best to do work you find satisfying. You'll do the best work and it will show in your career.

                                                                  – bob
                                                                  Jul 8 at 16:00













                                                                1














                                                                1










                                                                1









                                                                After a few times I discovered that I begin "hating" some code base, I started researching why.



                                                                And found out that it's because it has some drawbacks that are constantly bothering me and remain unfixed. The bother is thus building up and...



                                                                So the way to elminate that "hate" is to identify and fix the things that are bothering you about that code!



                                                                What is most important, you already know them (since they are bothering you) but didn't care to prioritize.



                                                                You named a few already: "it's not easy to understand code, especially if there's no documentation." When examining the code, you must have identified that these and these parts are sloppy and error-prone; here and here, there are no tests so no way to know if the code is (still) correct in all cases, etc.






                                                                share|improve this answer














                                                                After a few times I discovered that I begin "hating" some code base, I started researching why.



                                                                And found out that it's because it has some drawbacks that are constantly bothering me and remain unfixed. The bother is thus building up and...



                                                                So the way to elminate that "hate" is to identify and fix the things that are bothering you about that code!



                                                                What is most important, you already know them (since they are bothering you) but didn't care to prioritize.



                                                                You named a few already: "it's not easy to understand code, especially if there's no documentation." When examining the code, you must have identified that these and these parts are sloppy and error-prone; here and here, there are no tests so no way to know if the code is (still) correct in all cases, etc.







                                                                share|improve this answer













                                                                share|improve this answer




                                                                share|improve this answer










                                                                answered Jul 8 at 3:35









                                                                ivan_pozdeevivan_pozdeev

                                                                4182 silver badges9 bronze badges




                                                                4182 silver badges9 bronze badges










                                                                • 1





                                                                  This is good advice, though sometimes what you "hate" is person-years worth of technical debt that one person cannot feasibly fix unfortunately. Which is likely I think for many large legacy codebases. So it may not be avoidable in many situations.

                                                                  – bob
                                                                  Jul 8 at 15:37











                                                                • @bob still, it's better from psychological POV to fix one thing at a time and feel better than waste your nerve cells doing nothing. Then, technical debt is taxing the ongoing maintenance and is thus only not worth paying off if the product is near its EOL. For OP's case, this doesn't seem to be the case (since they say they are maintaining it on an ongoing basis with no end date in sight).

                                                                  – ivan_pozdeev
                                                                  Jul 8 at 15:54











                                                                • True. If you're stuck in the situation or while waiting to get out of it, then that's a good strategy (again if you can; sometimes you're told not to touch a particular piece of code). But at the end of the day its best to do work you find satisfying. You'll do the best work and it will show in your career.

                                                                  – bob
                                                                  Jul 8 at 16:00












                                                                • 1





                                                                  This is good advice, though sometimes what you "hate" is person-years worth of technical debt that one person cannot feasibly fix unfortunately. Which is likely I think for many large legacy codebases. So it may not be avoidable in many situations.

                                                                  – bob
                                                                  Jul 8 at 15:37











                                                                • @bob still, it's better from psychological POV to fix one thing at a time and feel better than waste your nerve cells doing nothing. Then, technical debt is taxing the ongoing maintenance and is thus only not worth paying off if the product is near its EOL. For OP's case, this doesn't seem to be the case (since they say they are maintaining it on an ongoing basis with no end date in sight).

                                                                  – ivan_pozdeev
                                                                  Jul 8 at 15:54











                                                                • True. If you're stuck in the situation or while waiting to get out of it, then that's a good strategy (again if you can; sometimes you're told not to touch a particular piece of code). But at the end of the day its best to do work you find satisfying. You'll do the best work and it will show in your career.

                                                                  – bob
                                                                  Jul 8 at 16:00







                                                                1




                                                                1





                                                                This is good advice, though sometimes what you "hate" is person-years worth of technical debt that one person cannot feasibly fix unfortunately. Which is likely I think for many large legacy codebases. So it may not be avoidable in many situations.

                                                                – bob
                                                                Jul 8 at 15:37





                                                                This is good advice, though sometimes what you "hate" is person-years worth of technical debt that one person cannot feasibly fix unfortunately. Which is likely I think for many large legacy codebases. So it may not be avoidable in many situations.

                                                                – bob
                                                                Jul 8 at 15:37













                                                                @bob still, it's better from psychological POV to fix one thing at a time and feel better than waste your nerve cells doing nothing. Then, technical debt is taxing the ongoing maintenance and is thus only not worth paying off if the product is near its EOL. For OP's case, this doesn't seem to be the case (since they say they are maintaining it on an ongoing basis with no end date in sight).

                                                                – ivan_pozdeev
                                                                Jul 8 at 15:54





                                                                @bob still, it's better from psychological POV to fix one thing at a time and feel better than waste your nerve cells doing nothing. Then, technical debt is taxing the ongoing maintenance and is thus only not worth paying off if the product is near its EOL. For OP's case, this doesn't seem to be the case (since they say they are maintaining it on an ongoing basis with no end date in sight).

                                                                – ivan_pozdeev
                                                                Jul 8 at 15:54













                                                                True. If you're stuck in the situation or while waiting to get out of it, then that's a good strategy (again if you can; sometimes you're told not to touch a particular piece of code). But at the end of the day its best to do work you find satisfying. You'll do the best work and it will show in your career.

                                                                – bob
                                                                Jul 8 at 16:00





                                                                True. If you're stuck in the situation or while waiting to get out of it, then that's a good strategy (again if you can; sometimes you're told not to touch a particular piece of code). But at the end of the day its best to do work you find satisfying. You'll do the best work and it will show in your career.

                                                                – bob
                                                                Jul 8 at 16:00











                                                                1


















                                                                I went through this for a long time. It became something unbearable.



                                                                Unfortunately, work consumes most of your day time and it's very disgusting to wake up thinking you'll be around a lot of bad code. It's a bad feeling.



                                                                I love to create and invent; that's why I became a programmer a long time ago. I'm not a genius either, brilliant but rather creative.



                                                                Now that you have experience, quit your job and look for one that better deserves your devotion. I did it 2 months ago and now I can't understand why I didn't do it before.






                                                                share|improve this answer
































                                                                  1


















                                                                  I went through this for a long time. It became something unbearable.



                                                                  Unfortunately, work consumes most of your day time and it's very disgusting to wake up thinking you'll be around a lot of bad code. It's a bad feeling.



                                                                  I love to create and invent; that's why I became a programmer a long time ago. I'm not a genius either, brilliant but rather creative.



                                                                  Now that you have experience, quit your job and look for one that better deserves your devotion. I did it 2 months ago and now I can't understand why I didn't do it before.






                                                                  share|improve this answer






























                                                                    1














                                                                    1










                                                                    1









                                                                    I went through this for a long time. It became something unbearable.



                                                                    Unfortunately, work consumes most of your day time and it's very disgusting to wake up thinking you'll be around a lot of bad code. It's a bad feeling.



                                                                    I love to create and invent; that's why I became a programmer a long time ago. I'm not a genius either, brilliant but rather creative.



                                                                    Now that you have experience, quit your job and look for one that better deserves your devotion. I did it 2 months ago and now I can't understand why I didn't do it before.






                                                                    share|improve this answer
















                                                                    I went through this for a long time. It became something unbearable.



                                                                    Unfortunately, work consumes most of your day time and it's very disgusting to wake up thinking you'll be around a lot of bad code. It's a bad feeling.



                                                                    I love to create and invent; that's why I became a programmer a long time ago. I'm not a genius either, brilliant but rather creative.



                                                                    Now that you have experience, quit your job and look for one that better deserves your devotion. I did it 2 months ago and now I can't understand why I didn't do it before.







                                                                    share|improve this answer















                                                                    share|improve this answer




                                                                    share|improve this answer








                                                                    edited Jul 8 at 18:28









                                                                    David K

                                                                    28.7k21 gold badges101 silver badges137 bronze badges




                                                                    28.7k21 gold badges101 silver badges137 bronze badges










                                                                    answered Jul 6 at 19:09









                                                                    mario diazmario diaz

                                                                    191 bronze badge




                                                                    191 bronze badge


















                                                                        protected by mcknz Jul 7 at 1:31



                                                                        Thank you for your interest in this question.
                                                                        Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                                                        Would you like to answer one of these unanswered questions instead?



                                                                        Popular posts from this blog

                                                                        Tamil (spriik) Luke uk diar | Nawigatjuun

                                                                        Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

                                                                        Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?