DEV Community

Fa'rath Shba 🚀
Fa'rath Shba 🚀

Posted on

I'm doing 90% maintenance and 10% development, is this normal?

During one of my internships I found I spent a lot of time doing bug fixes. You have to realize that as an entry level employee you aren't going to get the sexiest work, you're going to get the grunt work no one else wants. It's unfortunate, but it's how it is at every job.

Additionally, you have to realize that to a company, having code that works is more important than having code that is clean. From your company's perspective, you changing the existing structure is money wasted on redoing something that is already done and potentially introducing even more errors. Usually these types of companies aren't computer/software companies so no sufficiently high manager has the technical background to know that sometimes you need to do these major overhauls. That said, if your company is run by technically competent people and they understand the value of good code, you may get more leeway, although sometimes you need to choose your battles (the main purpose of a business is still to make money, after all).

That said, you are not unreasonable in wanting to be able to leave your mark on the software and wanting more meaningful work. It is also unfortunate that you have to deal with so many projects at once while fielding requests from so many different managers.

As a programmer, it is a fact of life that you will spend more time maintaining and modifying other people's code than you will writing your own from scratch. If this is a problem for you then perhaps you should stick to developing as a hobby and pursue a different career. If you are OK with maintaining code, but you feel you are not being used effectively or are being overwhelmed, then that is a matter you need to discuss with your manager. If your problems are more serious than that or if you feel like your managers don't know how to effectively manage your skill set then it would be a good idea to consider finding a position at a different company. Given your stated low salary, this is probably your best course of action.

Discussion (2)

Collapse
jonrandy profile image
Jon Randy

As a programmer, it is a fact of life that you will spend more time maintaining and modifying other people's code than you will writing your own from scratch

I've never found this to be the case over 26 years doing this professionally. Maybe I've just been lucky. I'm usually writing new code

Collapse
shymi profile image
shymi • Edited on

My 2 cents after working for a startup, big corpo for which the software was a secondary income source and currently a mid-sized company whose software is the only income source. I have spent in which one of them around the same amount of time(around 3 years).

  • the only place, where I have done mostly development of new features(around 60-70% of the time) was the startup. After the initial version of the main features was done we went mostly into support mode;
  • in the two other companies - it was mostly support jobs. There's a tricky time vs benefit decisions, which should be made, especially in old monolith projects. Most of the newer features had to rely on existing ones and there was a constant itch to fix the code a bit, but most of the projects I've worked on had terrible documentation or non-existent one(or even worse - multiple docs for the same thing, neither of which up to date), which meant that you can't be sure what will happen if you touch X(there's a reason for the jokes around comments like "Don't touch or you'll break everything"). Additionally with old projects there are functionalities, which are long forgotten, but interconnected with other ones and usually there's are 1-2 customers, which are using them and want them to work and you find out you did an oopsie long after the client has upgraded to the newer version(big no-no if the upgrade time of the environment is several months);
  • with time more and more security issues rise for web applications, which are open to the world - another thing to be maintained;
  • upgrading used libraries for performance/security benefits is not always straight forward(especially bumping to a newer major version) - code refactoring or even trying to find wtf happened and some other library stopped behaving correctly because of a transitive dependency upgrade may be needed(this was a huge headache in the big corpo - constant using of maven's tree command and browsing through library versions was a pain in the behind);
  • in the 3 companies, there weren't any linting tools used so the code was a mess. In the corpo - they added long into the projects' life scanning tools, which enforced some good practices(usually yoinked straight out of Effective Java) and they forced us to dedicate some time to refactor old code;