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

  • I have just recently started my career as a web developer for a medium sized company. As soon as I started I got the task of expanding an existing application (badly coded, developed by multiple programmers over the years, handles the same tasks in different ways, zero structure).

    So after I had successfully extended this application with the requested functionality, they gave me the task to fully maintain the application. This was of course not a problem, or so I thought. But then I got to hear I wasn't allowed to improve the existing code and to only focus on bug fixes when a bug gets reported.

    From then on I have had three more projects just like the above, that I now also have to maintain. And I got four projects where I was allowed to create the application from scratch, and I have to maintain those as well.

    At this moment I'm slightly beginning to get crazy from the daily mails of users (read managers) for each application I have to maintain. They expect me to handle these mails directly while also working on two other new projects (and there are already five more projects lined up after those). The sad thing is I have yet to receive a bug report on anything that I have coded myself. For that I have only received the occasional let's-do-things-180-degrees-different change requests.

    Anyway, is this normal? In my opinion I'm doing the work equivalent of a whole team of developers.

    Was I an idiot when I initially expected things to be different?

    I guess this post has turned into a big rant, but please tell me that this is not the same for every developer.

    P.S. My salary is almost equal if not lower than that of a cashier at a supermarket.

    As I see major problems here is underpaid salary (this hits motivation real hard) and multitasking - 7 projects to support and 2 new projects to write sounds really awful to me. I suggest you need to discuss both those points with management to find a solution which allow you feels much less exhausted and demotivated.

    I can totally relate. Maybe this cheers you up a little (my daily work): http://i50.tinypic.com/j8ipvp.png

    @John Nevermore 3k+ lines classes makes me soooo sad :)

    10% new development? You're lucky. But it doesn't sound like that's the real issue.

    @JohnNevermore that made my day a little better(tip: don't imagine that code in VB.NET, oh wait it's too late x_x)

    @JohnNevermore I once handled a 9k line Cobol program. 3k line java is nothing. Most of the code are unreadable.

    I'm still waiting for someone to say, "I just started working at this company and took over work on this existing application, and it's really cleanly coded, easy to understand, and a breeze to make changes to." I don't think such a thing exists.

    Let us know how things improve. i think a lot of people could benifit from your experiences in this instance. hang in there pal

    @ScottWhitlock - It happened to me once. I was asked to make changes to a fairly complex codebase. Halfway through my task I realized that the code was at a level of clean I'd rarely seen. Responsibilities were clearly defined, the logic was easy to navigate. The coder who wrote it had gone the extra mile to make her system maintainable. As a result, my fix took about half the time I was expecting. I promptly went to management and sang that coder's praises, told them she was a better programmer than she had been given credit for, etc.

    @JohnNevermore At least you don't have to work in VB.NET with a 15,000 line class. http://oi50.tinypic.com/rusenn.jpg

    @TiredProgrammer, Are you the only developer there? If so I would suggest maybe finding a place where you'd be part of a team. Software engineering and development can be a lot more interesting there than by yourself :)

    @JohnNevermore there are better ways to code that. Refactor it! If you can't figure out a way, there's a Stack Exchange site for that. People who tollerate bad codebases are as bad as those who write them.

    I swear we've had this exact sort of question before...don't see such a question in the related list though

    @ScottWhitlock I can also confirm it happens, though I think it may also be a relative thing. If you're used to seeing awful code and someone presents you with code that's maybe not super-clean, but at least well-commented, tested, and works as intended, you may find yourself feeling quite positive about it.

    "My salary is almost equal if not lower then that of a cashier at a supermarket." - **Find a new job and give them your 2 week notice. Being paid min wage is crazy. Do NOT accept a wage increase at this to company they do not appreciate you.**

    @rtperson I try to write such code and sometimes just for the fact that I'll feel really happy if someday some programmer working on my code really feels grateful about this and drops me a thank you mail. But nobody did it so far :( , so I have doubts about whether I do a good enough job.

    Look at getting some kind of ticket system (Jira, Mantis, Bugzilla, etc). That will greatly help you keep track of bug reports and change requests. You can have a definitive list of open tasks and you can be sure your business users agree that a task has been closed when you are done on it. You can also use this to demonstrate how many small requests you deal with and show your current workload.

    @ScottWhitlock I wanted to tell you that about 6 years ago I joined a team that worked on a specific product which was not only really clean coded, but also very sophisticated and smart, easy to change/add behavior and to sum it up - a pure pleasure!

    @TiredProgrammer Are there other developers there or are you the only one?

    You should mention if you're at a software firm, or a company where software is supporting their main business. In both cases it's a mix, but in the latter case, the support burden is generally higher. It's also higher earlier in your career. That said, nobody can put you into the job you want better than you - if the pay and work sucks, learn what you can and go somewhere else. Life's too short, and you have marketable skills. If you were a comparative literature expert, I'd say suck it up.

    "My salary is almost equal if not lower then that of a cashier at a supermarket" = you are getting screwed. And based on the quality of previous code, I'm guessing other's have gotten screwed before you.

    Leave. Why waste your time in such a crappy situation when there are thousands of high paying jobs in other places!?

    IEEE (SWEBOK) says that in maintenance projects, your effort is almost 60% in just understanding than actually implementing any thing for real.

    Entry level to senior, most jobs consist of working with horrible code.

    There is a lot of long answers but the thing I don't understand why are you trying to justify your discomfort with the opinions of other people.

    I see people have given some good points already. My two cents: fight for your right - if you see a possible long-term gain by refactoring code then tell them. Make them understand it's good for the company in terms of maintenance cost, bug fix reduction and potential gains in development. I'm sure you can think of more.. :) also, you should consider introducing a task management system which you and your company uses to assign and administer your tasks. Good luck:) [i would've written an answer but need rep on programmers.stackexch

    I would hire you and you could work from home to if you want. Just quit.

    When did you start? Sounds like the job I left in early May, hopefully you aren't my replacement!

    This question is not about salaries. It is about whether or not the job of a programmer includes maintaining code, and if it's a reasonable expectation that it makes up 90% of the work of a programmer. The answer is definitely yes, programmers maintain code. If TiredProgrammer wants answers about management or salaries, he should ask about that.

    As someone in their first programming job, the best thing I have done is work with management to create a bug tracking sheet (in Sharepoint), a change request form, and a reasonable development process that requires sign off from key people, testing, and requirements gathering. It's best to create a first version of these and iterate on them until they work well for everyone. Admittedly you probably need receptive management for this.

    "My salary is almost equal if not lower than that of a cashier at a supermarket." - is this common in the programming industry?

    @AndrewGrimm only if you are junior, its your first job eg a school leaver. Uni grads would get double what a cashier gets on their first job, if not more. I am in the uk.

    @TiredProgrammer It's definitely normal that you have to maintain code, and quite a lot of it. Most of programmers' jobs require a high level of maintenance and a relatively low level of research and innovation. Although improving existing code would pay off in the long run, such practice is frequently rejected by companies as they don't see value in it. It's the Programmer's job to evolve and be able to communicate the benefits of the suggested improvements so that the company accepts it. In short, you can make your life easier, but you must show your employer what he's going to get from it.

    Can't believe how many upvoted answers happily tells you that yeah-you-don't-always-have-what-you-want-in-life-yada-yada. So : * Pick hamster or similar to log what's your typical day. Find some guy to whom you can give feedback. * Think about the experience you get. If it's none, you're just screwing your career, it will get harder and harder to get another job. * labor market is two-way. Employers choose the content of the job but you still choose the employer.

    One good bit of advice would be to learn to identify and articulate *exactly* what makes the code bad. You will learn the most from your experience if you o this.

    better to quit this job.. working with smarter people than you & good environment is important at your first programming experience

    @sunglim where can you find such cases? It is sad to get into company where top devs say `"I don't know Perl/etc"` when the real problem is that they do not know basic Unix file permissions or similar basic thing, a bit frustrated.

    @TiredProgrammer This is completely normal for an Entry Level Programmer. But, with all the experience you have now, that no longer describes you. You could go to management about your your pay, but they hired you at that rate for a reason. And, it's been worked on by many others for the same reason; they don't want to pay for good development. Its probably time to leave for better opportunities. Unfortunately, that is how you usually advance in your career.

    For all those telling you to put in your 2 weeks notice and get out of there, well, I'd say to not be that aggressive. I've got numerous programmer and IT friends that can't even get back into the industry right now. They'd kill (probably not literally, but I dunno, some have been out of work for a couple years now) for even cashier level pay at this point. Don't leave one job until you've got the next one in the bag.

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

    Thank you for your reply, I'm starting to see that the grass isn't greener on the other side. This situation is making me miserable I'm even scared of clicking on the "send/receive" button in outlook. I might very well quit and try to start something for my own. Or I could always become a cashier..

    @TiredProgrammer The grass can be greener trust me. Just because most jobs entail adding new features to existing applications doesn't meant that they can't be a good job. There are jobs where you are not overworked, that have realistic project schedules, you are occasionally allowed to rewrite poorly written modules, follow good practices, you will be respected, and where you will be paid well above a cashier. I guarantee that you will not always be making so little money in your career. Stick with it.

    'From your company's perspective, you changing the existing structure is money wasted on redoing something that is already done'- personally I strongly disagree with this.

    @TiredProgrammer For what it's worth, starting out on your own is far better, but do not think it's anywhere near easy. The main difference is that you can be more motivated, and (generally) choose what tasks to prioritize yourself. However you can also end up spending a lot of your time on non-coding management tasks, which increase with your workload.

    this is a very realistic and pragmatic answer, the company is not in business to make the programmers happy writing perfectly "clean" code, they are in the business of making money. If that means maintaining old poorly constructed stuff then that is the business, these are the "slum lords" of the software industry. You don't see old apartment buildings that are **profitable** being torn down just because they don't meet some subjective standard of some building maintenance person! They get torn down and rebuilt when they aren't profitable anymore. Plain and simple.

    @JarrodRoberson Yes, the business doesn't like the idea of changing something that works. However some companies have reasonable people in charge who listen to developers; if you're able to communicate that long-term maintainability and cost savings will improve if you're allowed to do some code cleanup, they may _request_ that you spend some time refactoring the existing codebase. Any agile shop will recognize this and require it.

    I'm in a similar (although not that bad) situation, so I can understand TiredProgrammer's point of view. I approve what Jarrod Roberson is saying: if I spend 8 hours a week handling bug report for a certain tool, and rewriting it would need 24 hours, it's a *logical* decision to rewrite it. Yet, managers are averse to everything which does not yield immediate results, so we're stuck trying to have the concept through...

    I just want to be cleat that I am not trying to paint programming as a career in a negative light. I did it, I enjoyed it, but in the end I decided I'd rather pursue a masters in a new topic. That is not to say that because your current job is bad you will never enjoy programming. Like any job, there will be parts you don't like, Only you can decide if those parts are worth the parts you do like. @nicodemus13 that specifically is from the perspective of some not-so-technically-open-minded employers I've had. While your experience may vary, I stand by my statement.

    @nicodemus13 - I also disagree with the attitude, but unfortunately acattle is probably right about it being the *company's* attitude.

    I think this is a good explanation of **your company's attitude** toward software development. It's not a universal attitude, though it may be common enough. Sounds like you could be satisfied somewhere with a more results-oriented management style (i.e which doesn't forbid you from refactoring existing code) and/or provides a more reasonable project load.

    @nicodemus13 You disagree that this is how the company sees it?

    I decided to change my wording a bit. It sounded like I was saying EVERY company is like that, and that was not my intent. I've worked in good companies and I've worked in bad companies. Even good companies are still a business and want to make money so you don't get free reign to do whatever you want, but at least the have people who will listen to your suggestions, understand your reasoning, understand the pros and cons, and can make satisfying decisions.

    @KirkBroadhurst, acattle, DaveE: Sorry, I assumed that this was the opinion of acattle, as we as most employers. I meant that I strongly disagree with the notion. Most companies indeed, do 'see' it this way. However, putting lunatics in charge of the asylum isn't too helpful... it's strange how much non-technical people decide on technical results.

    @maple_shaft I know this is *completely off topic* but working in third world countries does not equal less pay. You get paid according to your market costs. How much does it cost to rent a 3 bed room + Hall + kitchen flat in Pittsburgh ? I am sure it costs a little more than 450 USD per month. how much does a decent meal cost ? its 4 bucks here in Pune, India for a couple of rotis, a chicken dish, salad and a sweet dish. I am sorry to bring this upon you, but these *third world* remarks really hurt man.

    @RitwikG That isn't what I meant about amount of money but what I meant to say was that if a developer is making as much money as a cashier then there is something seriously wrong with that country. Surely developers in Pune make at least double what a cashier makes. I can understand how that might be offensive, so I removed that from my comment. In the future if you take offense to any comment then feel free to flag the comment for moderator review, we are fair.

    @maple_shaft Actually I think the OP's problem is his employer and not his country, but I understand what you were trying to say; thanks foe explaining. And btw, the problem with India and probably for other developing nations is that non-professional workers (cashiers, manual laborers, salesmen, factory workers, pizza delivery guys) get paid about 1/20th - 1/50th of a professional worker like a programmer, lawyer, engineer or doctor. That happens because there is a surplus of unskilled manpower, mainly since we are plagued with ginormous populations. Sorry I took the discussion too far.

    @acattle "it is a fact of life that you will spend more time maintaining and modifying other people's code". Well, it depends on the technologies you are proficient with. If you are an expert on a platform that is roughly 2 years old, you will have new from scratch projects. If you are an expert in Cobol, you will mostly maintain.

    @MisterSmith While I understand your point, I deliberately said "maintaining and modifying" because in industry you ussually work in a team. Even if you're tasked with creating a new feature you're still likely to need to modify other people's code to integrate your changes. Being able to understand and modify other people's code is a highly important skill. Almost as important as being able to write code that others and understand and modify. Outside of school, software development is a collaborative effort. That was the point I was trying to make.

  • It sounds like management has a problem managing your workload and prioritizing tasks. You should talk to your manager and make them understand that you are overloaded and you can't do effective work if everyone keeps bombarding you with requests which they want fulfilled immediately.

    That makes you jump from one task and project to another, wasting a lot of time switching gears in your mind. For effective software development work, one should be able to immerse oneself into a task and focus fully on it. The more interruptions one gets, the more time is wasted by context switching. Research shows that it takes about 15 minutes to immerse and get to the state of flow where our mind works the most efficiently. If you get interruptions every 15 minutes, you never get to flow, which is a tremendous waste for both you and the company.

    So you should try to negotiate a more sensible working mode with your manager. This should include prioritizing the incoming requests and planning ahead to some extent. All user requests should be maintained in a list, ordered by priorities. And the priorities should not be decided by the requester (as naturally everyone thinks his/her request is the most important on earth), neither by you, but by someone with enough business knowledge and overview of the whole range of products you are maintaining (the product owner).

    Ideally, all incoming requests should be entered into an issue tracker like JIRA or Mantis. Or at least mailed to the product owner, not you. And he/she should deal with all the complaints from the users too over "why is my request not ready yet?!", allowing you to focus on the development work. If this is unattainable, you should at least negotiate some windows of time when you look at incoming requests and deal with them, reserving an uninterruptible portion of your time solely for development.

    If this is possible, the next step could be to plan ahead to some extent. That is, estimate the time needed to implement the top priority requests, then schedule your time into sprints, which may be one or more weeks each, and allocate enough tasks to the next sprint to cover your time.

    You probably want to keep a portion of your time for incoming emergency requests, but the rest can be planned ahead. And you may also prefer to organize work on different projects into separate "streaks", that is, to work on project A on Monday, project B on Tueday-Wednesday, project C on Thursday morning and D on afternoon, etc., to further reduce context switching.

    This way you have a rough idea of what you are to do in the next one or few weeks. Moreover, this gives a roadmap to your clients too: they can see when they get which request implemented. You may or may not want to mention the word "agile" to your manager here - this is basically agile development, but some people oppose agile without actually knowing what it is :-)

    Note that even if your current position seems low valued by your company, the more projects you are maintaining, the more negotiating power you have.

    Finding and training a new hire to maintain all these projects takes considerable time ( = money) for the company. And you may rightly point out that your code is so much better than the legacy parts of these applications, so it is not a given that they can easily find a candidate of similar capabilities for the same amount of money. Not to mention that if they don't improve working conditions, they will make the next guy get fed up and quit just as fast as you... Try to make them understand that it is in their own best interest to keep you, and to keep you happy where you are :-) This may give you some power to negotiate the above conditions, and/or request a pay raise.

    How much negotiating power you have - that is a big question. Your management may or may not be open to these ideas, and may or may not respect you enough to take your pleas seriously. But if you play your cards well, you have a chance. And if they refuse... you can always look for a better workplace. This situation isn't the same for every starter, although (sadly) your experiences are fairly typical. But there really are better workplaces out there. The quality of workplace is only loosely correlated with geographical location, but my feeling is that in Northern Europe you have higher than average chances. So if you can't get your current conditions noticeably improved, you should start looking immediately, before you get completely fed up, and burnt out.

    It is immensely better to look for a job while you still have one, so you need not accept the first offer just because you need money immediately. Eventually you will find a better place :-)

    Absolutely agree with you about management problem... like I write before 7 support project and 2 new projects sounds like programming hell to me :)

    Good point and it worth to try ! However, my experience tells me that it often fail, so have a plan B too.

    I whole-heartedly agree with Peter. If you can't change your job, change your job.

    Here is my abbreviated rant/riff on priorities: (1) A priority assignment should be a (real) number in the open interval (0, 1). Values which are closer to 1 are more important. (2) A prioritized task is a task specification with an associated priority assignment. (3) A task list is a collection of prioritized tasks with the property that no two tasks in the list have the same priority.

    @leed25d, I don't think it is necessary to take this so scientifically :-) In my experience, it almost always suffices to have a rough ordering on the tasks / stories. Since each sprint takes a batch of stories, and (usually) ordering within a sprint doesn't matter much, the main issue is to decide which tasks should go into this, the next, ... sprint, for which a rough ordering is quite enough.

    Although your answer is big, it's easy to read and follow. +1

    @cometbill +1 for sharing the same philosophy. I came out with something even broader, when I found myself working in a terrible environment with mediocre developers. I told my manager "I either change the environment, or I'll change environment". At the end, I did the latter.

  • P.S. My salary is almost equal if not lower then that of a cashier at a supermarket.

    Heh I wanted to write something about how to negotiate until I read that. Now all I can say is leave! Assuming that's half of what a developer with a degree usually earns. And assuming that things improve and they give you immediately a 10% increase you can figure out yourself how long it takes to get there. It also looks like you do not learn anything on the job and you don't seem to be surrounded by brilliant engineers there, so it's a waste of time.

    Lol I got the good answer and nice answer for that!

    Half? That's less than 1/3.

    @Nils +1. I still remember when I was hired as the sole person responsible for the mission critical project of a company, fresh from High School (I never went to college). After one month of DIY-training (instead of the eight that were planned) I delivered three projects and improved existing application in dozens of places. Then I discovered that I was earning less than an apprentice mechanic in their factory. I asked for a raise, they laughed at me. So I gave them my notice, and I got covered by insults when they saw it. Never sell yourself cheap, you won't get rewarded unless you ask for it

  • I was also in a similar situation, and I can tell you that if you stay on that track it never ends. Management will keep shoveling it at you, because... they can.

    There are a few additional thoughts that I have on this topic.

    1. Do what you love. If you don't love it, prepare yourself for making the attempt to find what it is that you might love.

    2. Communication. Communicate clearly your inabilities to deliver to unrealistic expectations. In my similar experience the architect (who did the most shoveling) said, "you have to manage others expectations of you."

    3. Burnout. If you have not experienced burnout, do not tempt fate. It sucks your life and soul out of your mind. Despite your best effort, your working purpose becomes grey, dreary and meaningless. I impart this advice because you must, at all costs, avoid burnout.

    4. Training. Here is the silver lining. Your training and experience, while frustrating, and perhaps underpaid, is in fact, very valuable to your career. This is your saving grace to realize this because you can soak up as much learning as possible and delay any inevitable glass ceiling.

    Focus on what talents and skills you are growing... These will carry you through the next opportunities of your career.

    Thank you very much for this reply this is great advice, I'm very afraid that I am close to your point 3.

    'Management will keep shoveling it at you, because... they can.'- I would suggest that they are doing this because they can't do their own jobs and it's easier to push the blame down if things dont' work out. Not that that helps you, except it may make it easier in future to identify managers who can't manage (i.e. most of them.)

    +1 for the training angle. This is probably the only positive that you can get out of this situation, and perhaps getting much better at time management.

  • You're dealing with multiple issues here... Let's start with the obvious...

    Is This Normal?

    Hell no. But... is it common? Unfortunately, yes.

    Regarding Bug-Fixing Frustration

    While that doesn't excuse the rest of the mess you have to deal with and the multiple projects they overload you with, I just want to make a quick note that the "bug-fix" only approach, while frustrating for you as a developer, can be a perfectly sensible approach for the company and its management.

    Surface for More Bugs and Costs

    The more code you touch, the more likely you are to introduce bugs, even if your intent is to improve it. That means extended dev time, test time, and costs. And if it slips through to a service release with a medium to high-defect, that's a big mess for them.

    Noise / Fog in your Logs

    From an SCM-perspective, it also makes a bit of sense if you work directly off a service release's branch, as you want to have a clean view of changes relating to bugfixing. If there are 15 commits with thousands of changes surrounding a bugfix that actually required maybe a 1 line code change, it's a tad annoying.

    So, being a new hire, it's even more sensible to ask you to refrain from refactoring and/or enhancing the software, and quite OK in my sense to be as "surgical" as possible with your bugfixes. It just keeps headaches at bay.

    Can You do Something About It?

    Now, it does NOT mean that there would be ways of achieving both sanity of the code and sanity of the involved people's minds. Being junior, they should have someone review your changes, especially bugfixes, and make sure they are approved before making it to the service release builds. That would prevent or limit radical changes, and be safer.

    The Project From Hell

    Crap Code, Herd of Programmers, Duplication, Crap Architecture

    Again, devil's advocate here, but just showing that your initial request contains a few non-consequential bits.

    My point is this: I really really really rarely took over a codebase that wasn't in this state. And on the off-chance that I did, they were recently started projects or prototypes that had been kick-started by pretty stellar programmers. But the astonishingly vast majority of them looked like crap, and a scary number of these were actual crap. Even the ones started by good or great programmers can end up being crap, deadlines and other engagements helping...

    Welcome to real-life industrial software engineering!

    And you know what's fun? It's often way worse in the web-development world. Enjoy! :)

    Too Many Projects & Requests, Not Enough Hands & Time

    The problem lies here probably in:

    • your management (maybe unconsciously) abusing you,
    • your colleagues (maybe unconsciously) abusing you,
    • your (maybe unknowingly) not covering your ass and fighting your battles enough.

    Your managers should be aware that you are working on too many projects to manage. If they aren't, make sure they are ASAP. Make also sure they know it wasn't all a pick-nick in the park and that you felt pressured, and that it needs to stop.

    Try to have a look around and make sure your colleagues do not deflect more tasks and projects on you, directly (by really saying "X will be able to take care of that") or indirectly ("I'm not the right person for this, find someone else" -> ends up being you).

    Personal anecdote here: I did an internship a few years back, and just on my very last day, when I got my evaluation, my boss told me, despite being very satisfied with my work overall, that one of the managers had the feeling I had been unloading some "not so fun tasks" on another intern when they would have expected me to pick them up. I was mortified of having them felt let down, and at the idea that I would look like I was slacking off, when my intent was the exact opposite: I was trying to grab the harder tasks and have the other younger intern deal with less hair-pulling issues. Little did I realize that, had I been in his position, I would have been bored by the lack of challenge and probably felt the way he did. The point is, you need to communicate to make sure nobody makes false assumptions about 3 very distinct things:

    • what you can do,
    • what you want to do,
    • and what you are willing to do.

    So it's also partly your fault for letting it become this way. But it's normal, it's a lesson everybody needs to learn. It holds in two letters: N - O.

    You usually employ it as a prefix for a more lengthy but not so much more charged answer: No, I can't do this. No, I don't know how to do this. No, I'm not sure I'm the right person for this. No, I've never done that.

    At first, it's very easy to feel like you can just say "yes, I'll (eventually) do it", and pile things up and get them done, maybe by putting some extra hours in. That's all wrong. You need to understand that your time is, after your skills, your most valuable asset, to you and to your company. If it is misused, it impacts projects, deadlines, and budgets. As simple as that.

    Also, it looks a bit worrying that you would have too many people to report to. It's OK to have multiple customers to deal with, and multiple project owners or even principal stakeholders you need to communicate with. But, overall, especially as you're a new hire, you should mostly report to a few managers only (and most likely only your direct manager, and possibly a lead or senior developer). How did it get this way? I don't know. It can be an organizational issue at your company, or it can be the result of you doing a favor and of then being contacted directly, and failing to say "no". Or it can be that your direct manager as issues with dispatching tasks, for all I know (I'm really guessing, but the pattern are recognizable and well-known).

    I'd recommend you do the following rather quickly: go talk to your direct manager in person, explain that other managers might be a bit pushy, or (probably less whiny) that you have too many stuff piling on from too many people, and that you need his input (and possibly theirs as well) to know which ones to prioritize.

    180-degrees Change Requests

    These are another big issue. They're probably not your fault, but you can try to help them address it.

    "180-degress change requests", as you beautifully and acurately call them, are a clear sign that requirements are fuzzy from the get go, and that nobody tries hard enough to have them chiseled and cleared up over time.

    That's usually when someone needs to get on the phone (or better, on their feet), and grab stakeholders by the hand and tell them clearly: "that's where we are, that's where you want us to go, do you confirm we're heading in the right direction?". It's OK to not get clear answers at the beginning, but the more time passes, the clearer they should become, or this project is a disaster waiting to happen.

    Usually I'd say grab all the stakeholders within reach, put them in a room, drive them through litigious issues and incrementally try to resolve these - and get priorities while you're at it. However in your case, this may not be your call to make already. But you mention they really gave you the responsibility of the projects; so if that's really the case, then do take responsibility and do that. And DO NOT shy away from saying "we CAN'T do that", or even "we WON'T do that". It's really important to limit the scope of a project.

    If there's no scope, there are no clear-cut requirements at the end of the discussion.

    E-mail Overload

    People tend to behave differently based on the communication medium they use. Personally, though I'm a rather soft-spoken person (and have been working mostly in foreign countries, so I also end up not liking to talk on the phone to much), I'd favor in order of preference based on productivity:

    • talking to people face-to-face,
    • talking to people on the phone,
    • talking to people via IM,
    • talking to people via email.

    E-Mails are nice for tracking, for getting confirmations, for sending notes.

    For scheduling, planning and discussing problematic points, they're close to useless. Go knock on the guy's door until he/she opens it and sit down with a notepad and a copy of your documentation to clarify things. Once you're done, then send an email and ask for confirmation. If it comes back with a negative answer or a slightly hidden attempt at sneaking something else in the envelope, go make the siege of your interlocutor's office again.

    This is software engineering. It's often more productive when you don't type away on a keyboard, and can actually cut down upfront on the crap you'll need to deal with.

    Doing a Team's Worth of Work

    Are you doing the equivalent of a team's worth of work? Maybe.

    Are you doing the equivalent of your team's worth of work? Probably not.

    What I mean is that your team is probably busy working, and you are overworked. And that's the issue: you're overloaded with things that should be pushed out of the current project timelines, or given to someone with time on their hands.

    Was I an idiot when I initially expected things to be different?

    No; just new to the party. It's like a first hung-over or relationship. You'll get over it.

    I guess this post has turned into a big rant, but please tell me that this is not the same for every developer.

    This is the same for every developer in chaotic organizations, be them startups or well-established giants, and with no experience or confidence to get things to move one bit to tip your chances of survival on the right side of the scale.

    P.S. My salary is almost equal if not lower then that of a cashier at a supermarket.

    I did decent salaries on jobs that would appear crappy. It's not the number on the check that counts, it's the context. What you do, your age, where you live and work, etc...

    That being said, if you are grossly underpaid, working too much, and not entirely junior, go ask for that raise or get a new job!

    It's simple:

    • if they value what you do, they'll gladly agree to a raise,
    • if they don't, future in this company doesn't look very rosy (for you, at least, which is what matters), so don't feel bad about leaving.

    Be aware that asking for a raise is a good thing, even though you wouldn't be enclined to think so at first. It proves you keep track of what you do, and hints that you keep an eye on other option while still being willing to stay onboard. And it's a good thing to get used to request them, as they are like job interviews or bargaining in general: it's something that requires practice, and they don't fall from the sky if you don't reach for them yourself. Some companies will distribute raises regularly without being requested to, but that's only because they are clever enough to know that it keeps you half-happy and less willing to change, and they want to cut the grass under your foot (most people would feel a bit uneasy about upping a raise offer they've been offered directly).

    How to proceed with this request is a bit out of the scope of THIS project right here, so I won't go into the details. But I'd recommend you prepare a record of your SCM commit IDs, of your fixed bugs and achievements, and that you also prepare reports comparing them to the team's overall effort. This way:

    • you can measure for yourself if you effectively did a lot more than your peers or not,
    • you can stand your ground if they say your request is not justified.

    +1 for good advice - heck, the sheer amount of effort you put into writing this down justifies an upvote :-)

    @PéterTörök: Thanks. This is a CW question, there are no reputation points involved. I just liked the question.

    Great answer! The management would appear to have no understanding of software development issues. I bet they drive their cars with the low oil light flashing and on bald tyres. When you're that badly paid, maybe looking for a better job is the best strategy.

    @CyberED: Thanks. Looking for a better job might indeed be an option, though here we don't exactly know the salary, the location, and many other factors.

    +10 for the face to face communication. Many people will just send an email without thinking too much about their request. When you are face to face with them, they realize you are 1) taking them seriously, so they are more likely to take you seriously, 2) trying to determine what you want and why, and 3) probably going to explain why or why not this is a good idea. 4) a short in-person conversation can accomplish WAY more than a gaggle of emails.

    @JenniferS: Thanks. Totally agree with you on all points. It's usually a great time-saver, and a very good way of taking control of your project.

    Good answer, but I would add use email to arrange that face to face. It isn't reasonable for everyone in an office to be able to interrupt everyone else whenever they like. Context switching has costs.

    Love this answer. "The Project From Hell" this is so true "Welcome to real-life industrial software engineering!" I have never worked on a significant project anywhere, be it public sector, corporate, or start-up that was not already a mess. Save one, and I would describe that as a shock.

  • In addition to other people's comments:

    1. Yes, it is normal for an entry level employee to be given the jobs nobody else wants to do.

    2. You should see this as a building block for your future career.

    So what should you do? In order to prove youself as a professional developer you need to ensure your work is structured and planned, otherwise you may find it hard to build on the good things you're currently doing - so you should try to do things like the following (if you're not already).

    1. Log your work accurately, for each project. So if you spend one hour fixing a bug on project A, log this time. This will be useful to show to your manager if you want to discuss workloads.

    2. Write unit tests. You mention some of the projects you maintain are full of bugs, so my guess is that there are few (if any) unit tests. For each bug report, write a unit test which replicates the bug, then fix the bug. This will help ensure no regressions occur, improve the quality of the code, and serve as a platform on which to refactor the code if you're given the chance (for example, it could help you convince the stakeholders that rewriting some parts could improve quality without introducing new bugs, due to the unit test suite).

    3. Look for a new job - you work on many projects at once, you have written code from scratch, and you have probably experienced the entire project lifecycle - these are all good experiences for applying elsewhere.

    +1 for unit testing. While I totally agree with you about writing unit test which replicates bugs, you need to convince management before writing those test, cause tests could be time consuming

    I don't think it should be considered "normal" that entry level employees get jobs nobody else wants to do. I sure don't allow that in my team - I don't want the new people to be demotivated before they even start. And besides, those rotten jobs are often done much more efficiently by someone who has experience in the tools and shortcuts. Regexp find/replace, Python scripts to modify large quantities of project files.... you know the drill!

    @MadKeithV it's not good to give new starters things nobody else wants to do, but I think the OPs situation of just being given bugs to fix is relatively normal (although the OP clearly has too heavy a workload) . Existing employees fight over the best projects and management would much rather retain good people by giving them the best projects. And fixing bugs can be a good way to understand how the code fits together. Not saying it's best management practice, this is just an observation.

    @david_001 - at my company we don't fight over the best projects - we round-robin so that everyone gets a fair shot at the "cool" things and everyone gets their fair share of the duller "maintenance" jobs. I might even do a bit more than my share of the maintenance because I actually like it... but I'm weird that way.

    @artjom the key to solve that issue, is as *best* you can, before writing any new code, is write the tests firsts. Though that could be difficult if your maintaining code; in which case, write the test before solving the bug.

  • Your situation is a bit edgy, yet still normal. But the way you handle it is very bad. Here is what you need to do:

    • Try to confront your boss. You should have some proof (numbers) of how much time the bad code base actually costs. If he does not understand stuff like technical debt, stop mentioning it. It would wreck your head, and you could be marked as a 'bad attitude' guy. It is not your job to teach your boss to do his work.

    • Maintain your own backlog (kanban). When new tasks comes put it at end, and tell estimated time of completion.

    • Increase your response time, check your email only twice day. Typically before lunch and just before you leave. (Checking email should not be followed by coding, as it may wreck your head).

    • Make small code improvement as part of each task. It is simply your job to improve code, skills and tools you are using. It will also boost your moral in the long term.

    • No project switching during the day. Today you are simply working on project X, and you will start other task for Y tomorrow.

    • Allocate one hour per day for gate keeping. It means small tasks which are trivial to do. If this task takes longer than 10 minutes (no mater what the reason is), it goes into the backlog and you notify the manager it will be delayed.

    Now comes the hard part. Currently managers do not communicate with each other, and just assume you will finish their own project with maximal priority. This brings a lot of stress on your head, because you are in middle of arguments. You need to force managers to start coordinating your work. At the end you should have a nice & simple backlog and managers should bully each other without you.

    So let's do some simple role playing. There are three managers and projects (Xavier with project X, Yvonne with project Y and Zed with project Z). You have a backlog for two weeks, 5 days for X and 5 days for Y.

    • Z asks you to do some task (1 day)
    • You respond that it will be done in 11 days.
    • Z responds that it is simple task and should not take more then one day (notice that Z applies small pressure).
    • You respond that you are currently working for X and latter for Z. You can do her work after that.
    • Z responds you should do his task immediately anyway (increased pressure, direct violation of X and Y territory).
    • You respond that doing her task would delay work for X and Y. He should ask them first. You also CC X and Y.

    Now there are two ends:

    • Managers will start barking at each other, many emails, probably some meetings... You should stay away and let the winner assign you a task.

    • Nothing will happen, Z will ask you two days latter where his task is. You answer that you are working for X currently, and he did not mention anything about project Z. Again CC X.

    Now this type of behaviour can get you fired. But your situation is unsustainable, and you will probably quit soon anyway. This solution only works if managers are competing against each other (very usual). You should also keep records of your work (backlog), in case somebody would complain, that you are slacking off.

    +1, I love the pitting new work requests against other people already in line. Create a ticket system... you determine who has priority until the ONE person who decides your pay chooses to change the priorities. I would do something snarky like buy a number machine and sign...

    @ChrisK, it is not the developer's responsibility to prioritize user requests. And especially in such a tense situation, making such decisions could quickly get the OP in trouble. IMO the only politically sensible solution here is to escalate to the closest person with enough authority to defend his/her decisions against the competing managers. (And if there is no such person in sight, flee asap :-)

    @Péter Török I have met few developers who worked in a large enough organization where your **very sensible** response was possible. I sadly have the feeling the OP is in a free-for-all melee kind of workplace. The ones whose workplace is that stable do not post here. ;)

    @ChrisK, since the OP talks about several projects and managers, this sounds like a fairly large organization to me. Which indeed doesn't mean it is necessarily a sensible and organized place. But there is always *someone* who ultimately makes the decisions.

    @PéterTörök That _someone_ may not listen. Also all tasks may have the same priority. Sometimes FIFO queue is most effective.

    @JanKotek, indeed, this *may* be the case. My point is simply that you won't *know* this without asking and communicating. All tasks having the same priority is theoretically possible, but I have never seen such a case in real life, and don't expect to either.

  • Seven years ago I was doing pretty much 100% maintenance work for a while and wrote an article about it: The Art of Maintenance Programming. One part you may find useful:

    1. Get to Like It

    How can anyone like maintenance programming? Developers dream of being chief architects in their teams, and when they end up maintaining existing software, it feels almost like punishment. It doesn’t have to be: maintenance programming has its own set of challenges, and requires a lot of creativity, adaptability, patience, discipline, and good communication. It can be good for your career as well: having bombastic entries like “Architected n-tier 24/7 enterprise application” in your resume looks nice, but employers actually value people who solve problems; and maintenance programming can be a good chance to demonstrate your problem-solving skills.

    +1 for the positive side of maintenance. Have been doing that most of my career and yes, it *can* be (made) fun. Having seen how an initially shiny new product looks like several years after the glorious version 1 (the original architect having long since left the project) gives you an extremely important perspective on how (not) to design and build usable, maintainable, robust software. Sensible employers do value those who can actually keep the engines running smoothly - or even better, can fix and stabilize a sinking ship while out on the open sea.

    Reading your article: 7. Be Conservative its a straight way to make your code even worst. Code has to be changed regularly and improved in that way. This book can explain some aspect of wroking with the legacy code :http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 Being conservative is a bad idea....

  • Your problem sounds like sommething you hear more often about. It appears to be a job that could easily fit on The Daily WTF.

    A lot of organisations focus more on sales or feature pushing than on quality. What those companies fail to see is that there is more than external qualities of a piece of software. Ward Cunningham coined the term technical debt.

    You might also want to read Steve McConnell on technical debt. He has some interesting points. In a Google Tech Talk, Ken Swaber talks about agile software development. A good part is about a story similar to yours. He talks about a software project that has become "braindead" after 10 years of programming by various programmers without ever doing any refactoring. I think that if you see this video you'll see a lot of similarities to what you describe.

    Any software system will degrade in quality when it is being expanded on. In fact in order to survice it will have to. The Lehman Laws explain this principle quite well. Ultimately it will boil down to the following question: "How do I convince your boss to do refactoring?".

    How I approached a similar problem:

    • I confronted my boss and explained that code quality degrades when we keep developing (Lehman Laws).
    • I tried to explain my boss the concept of technical debt. And that the way he lets you to work is a way that will cost him money in the long run.
    • In order to actually show him how severe the problem was, I have (in my own time) done a static code analysis. Bosses don't understand software, but they understand numbers. Although code metrics have their flaws it is good to have something measurable you can talk about. Try to find out what normal readings are for these metrics, and you will be surprised when you compare this to your own codebase.
    • If nothing helps and nothing changes, the only thing you can do is explain that a certain new feature will require some rework of other parts of your codebase. Explain that if you have duplicate code and they want to change something that the costs of a change duplicate as well.
    • A common answer to the previous point will be that no-one has asked and thus not paid for this rework. That "perhaps" this rework is superfluous. You will have to explain that software will always have to change. Like the Lehman Laws say; it will have to change in order to remain in use. If not, other programs who did change will always outlive. It is those who expect change and can adapt to change that will survive. This is what agile software development is all about. (Wikipedia)

    My boss nowadays uses the concept of technical debt to explain to our customers that we sometimes need to rework parts of the software we build. Just to prove that - if you have a reasonable boss, it is possible to change things for the better.

  • In my opinion, a company that prohibits refactoring is not worth working for. Refactoring is an essential software development skill, and version control tools make it very easy to develop changes in isolation without corrupting the 'trunk' (in case a refactor actually does break something). As Uncle Bob says (paraphrased): "You should haven't to ask to be a professional and do your job right."

    Maintenance programming should never mean perpetuating bad code.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM