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?

  • 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

16 Answers 16

150

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.

  • 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.

  • 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.

  • 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.

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.

  • 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.

  • 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!

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).

  • 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.

  • 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.

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

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.

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.

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).

  • 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.

  • 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.

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?

Not the answer you're looking for? Browse other questions tagged or ask your own question.