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.

  • 72
    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.
    – artjom
    Commented Jun 12, 2012 at 7:15
  • 15
    10% new development? You're lucky. But it doesn't sound like that's the real issue. Commented Jun 12, 2012 at 9:23
  • 207
    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. Commented Jun 12, 2012 at 12:15
  • 102
    @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.
    – rtperson
    Commented Jun 12, 2012 at 13:28
  • 141
    "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.
    – Ramhound
    Commented Jun 12, 2012 at 19:57

28 Answers 28


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.

  • 9
    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.. Commented Jun 12, 2012 at 6:41
  • 56
    @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.
    – maple_shaft
    Commented Jun 12, 2012 at 11:44
  • 5
    '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. Commented Jun 12, 2012 at 13:46
  • 53
    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.
    – user7519
    Commented Jun 12, 2012 at 13:55
  • 6
    @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.
    – Phil
    Commented Jun 12, 2012 at 14:33

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

  • 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
    Commented Jun 12, 2012 at 17:37
  • @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. Commented Jun 12, 2012 at 18:37
  • @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.
    – Diego
    Commented Jul 29, 2012 at 21:53

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.

  • 4
    @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
    – Diego
    Commented Jul 29, 2012 at 21:58

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.

  • '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.) Commented Jun 12, 2012 at 13:55

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.
  • 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.
    – CyberFonic
    Commented Jun 14, 2012 at 6:33
  • +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.
    – Jennifer S
    Commented Jun 15, 2012 at 14:31
  • 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.
    – Sean
    Commented Oct 11, 2013 at 12:45
  • 1
    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. Commented May 22, 2014 at 13:36

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.

  • 11
    +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
    – artjom
    Commented Jun 12, 2012 at 8:13
  • 10
    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! Commented Jun 12, 2012 at 14:38
  • @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
    Commented Jun 12, 2012 at 15:38
  • 2
    @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. Commented Jun 12, 2012 at 15:42
  • @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.
    – user14886
    Commented Jun 14, 2012 at 9:39

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
    +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...
    – Krista K
    Commented Jun 12, 2012 at 16:19
  • 5
    @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 :-) Commented Jun 13, 2012 at 8:38
  • @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. ;)
    – Krista K
    Commented Jun 13, 2012 at 22:49
  • @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. Commented Jun 14, 2012 at 4:45
  • @PéterTörök That someone may not listen. Also all tasks may have the same priority. Sometimes FIFO queue is most effective.
    – Jan Kotek
    Commented Jun 14, 2012 at 22:17

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. Commented Jun 13, 2012 at 8:55
  • 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 :amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/… Being conservative is a bad idea.... Commented Jun 12, 2014 at 21:00

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.


The situation you are facing is nearly (if not totally) the same for many freshers.

This happens in the initial phases of a career. Here is the catch: We have to overcome this issue and prove our value to the company (be it medium-sized or MNC). We should be able to make decisions about what the circumstances demand us to do. So there is nothing harm in putting efforts in the job, provided you get noticed for it and stand as an individual for your work. If you are worth, the company will notice! Adios and best of luck.

  • Thanks for your reply vaibhav, It seems unfortunate if this is truly the case for starters. This situation is really making me depressed, I was kind off hoping to hear that this isnt the same for every starter, it might be diffrent based on location, At the moment I live in North Europe. Commented Jun 12, 2012 at 6:30
  • 1
    Its not same for many fresher, actually I think its bad management to overuse one person so hard (7 support projects and 2 new projects on 1 person ? are you freaking kidding me... ) and dont expect that company can notice your worth, cause some companies just doesn't care about they employers or they just think - if you doesn't talk with then about points you dont like then its okay and you are fully satisfied.
    – artjom
    Commented Jun 12, 2012 at 7:19

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.


I have received this email five years ago from one of my friend.

Email body:    

A newly joined trainee engineer asks his boss "what is the meaning of Appraisal?"

Boss: "Do you know the meaning of resignation?"

Trainee: "Yes I do"

Boss: "So let me make you understand what an appraisal is by comparing it with resignation"

Comparison study: Appraisal and Resignation
|       Appraisal                 |       Resignation                |
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |

Trainee: "Yes boss enough, now I understood my future. For an appraisal I will have to resign ... !!!"

  • 4
    +1 True enough, threatening to resign is a common characteristic in people who get promoted
    – Andomar
    Commented Jun 14, 2012 at 8:38

If I were you, I would spend some late hours after work rebuilding the application for free. It would probably be a fun task. When you finish it, show it to your boss. If it works and you're doing maintenance on it, he should have nothing to worry about. This will make your job much easier and would open the eyes of the higher ups to your potential in the company.

I'm a full time college student working a part time internship for US$10 an hour. I do QA stuff that's boring, repetitive, and easy. I consider myself to be extremely lucky, because I know one day this will open doors to bigger and better places.

  • 2
    I like this answer because it encourages people in situations like @TiredProgrammer to show some initiative and make the job their own. As someone who has has worked in full-time (granted, for a limited period of time) I would like to add that there is a limit to how much you're willing to put into a job you don't enjoy. Also, if you find your managers do not appreciate this kind of effort then you definitely should start looking for positions at different companies where they know how to manage technically minded people like you.
    – acattle
    Commented Jun 12, 2012 at 17:07
  • 10
    Don't work for free, especially not for this type of work! It'll never be recognized unless your boss can read code and he/she is a Good Boss. Unless you've got vested interest in this company or the company does charity work, don't work for free. It's a bad investment. Commented Jun 12, 2012 at 18:38
  • 2
    "If it works" - how are you going to prove it? Rewriting the code without consent, and not being able to convince your boss that the new version works as well as (or better than) the original can get you in deep trouble. So unless you have a management-approved way to prove correctness of the program quickly, repeatedly and without noticeable costs (like a comprehensive set of automated unit / system tests), don't do this. Small refactorings, one step at a time, are OK, but again, you need unit tests to prove that you haven't broken anything. Commented Jun 13, 2012 at 9:07

Yes, you will always have to maintain applications, written both by you and other people. The only exception is if you write a program which never, ever needs any maintenance. So you better get good at maintenance.

I think there is a subtle hint in your question of a flaw in your approach. That is, that fixing bugs does not involve improving code.

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.

I can't believe someone has told you "you must fix bugs without improving the code." This is both difficult and impossible. What you can't do is re-write the application just because you don't like, or find it hard to understand, the approach used in the existing code-base.

My advice is to learn to refactor. Any time you are fixing a bug, you have an opportunity to improve at least some of the code. How much of the code-base gets refactored depends on what the bug is and how good or bad the code is. But if you're fixing bugs and knowingly leaving code smells all over the place, then you're not doing your job and you're building up technical debt.

Some bugs are actually fixed simply by refactoring, and sometimes it's useful to refactor in order to help you understand code. This is because refactoring ought to improve maintainability and coherence of the code.

When I estimate a bug fix, I will usually make a decision about whether a major refactor will be the best way to do it, and take that into account. The same with unit tests. Both these things should be part of the way you write code, not something optional which involves extra time.

So you shouldn't be asking "can I improve the code when I fix the bug?" Because you should be anyway. You shouldn't be asking "can I use refactoring to fix the bug?" Because if the code which is causing the application to bug out is in dire need of refactoring, you should do it anyway. You shouldn't be asking "can I write unit tests when I fix this bug?" Because you should write a regression test before you even start trying to fix the bug.

NB: I feel some attribution for this answer should go to Jeff Atwood, seeing as I linked 3 of his articles.


This one is all about money. My guess is that as a starter, you are probably too kind for customers who've already gotten more than they paid for.

Learn to quote a price for new requests. This is far from easy and customers will often try you out. If you can, enlist the help of an experienced project/product manager.

Once you think in terms of money, communicating with management becomes a lot easier. If your current customers provide full time money, you should not pick up new projects. But you'll understand that management will still try to bully you into doing them.

If you are indeed valuable to the company, you'll gain bargaining power. You can ask them to hire more people, get fewer new projects, help you reduce maintenance load, or increase your salary.


It should not be the decision of your employer to micromanage you to the extent, that you are prohibited from improving the existing code. Use your own professional judgement. When you are estimating work, I would factor in additional time to allow for some refactoring, if it will increase productivity in the future.

Anyway, it seems like you aren't effectively communicating with your employer.

  1. You have evidence that refactoring will save money. Draft a proposal for a refactoring project and demonstrate how much time and money the business could save. Outline precisely what changes you would make to the code, and how long it would take.

  2. Keep an accurate log to record how much time you spend on coding, meetings, and answering emails. This will protect you if you fall behind schedule.

  3. Slow down. This may seem a little counter intuitive, but your time will only be abused if you do everything quickly. People will respect your time more if you do less. For example, I would only check email once or twice per day. Otherwise, you risk burnout.

  4. Considering your pay rate, it isn't worth getting a headache over. Make sure you leave on time every day. Don't put in extra hours without additional compensation. The exception is if there are good advancement options, or if the reputation of the company will greatly boost your resume, then you will just have to suck it up.

Without knowing more, I would just suggest that you try to be more open with your managers. Maybe start increasing your task estimates. Constantly remind them about how busy your workload is. Also, you should meet with your boss and explain that you would like a salary increase within the next six months, and ask how you could improve your performance in order to achieve this pay increase.

Good luck.


In my experience the academic world or the first 6-12 months of a tech-oriented start-up are the only two reliable areas where you'll encounter a true blank slate. They both carry their own costs but if you love to code and are often horrified by the quality of the code you find out in the wild, you should start pointing your career in one of these directions.

  • 1
    Yes, at least in my experience. Lots of posts say, "Oh, you'll have to do support early in your career," but the reality is that support work is quite common unless you are in an arena where you are specialized in green field projects (consultants, students, and possibly key players in a software company). For lots of other businesses, once they have working software, it's maintenance or enhancement mode until they decide to move off that software, which could be a decade or more.
    – Bernard Dy
    Commented Jun 14, 2012 at 1:15

Try talking with your employers and see if you can solve this out. It sounds like you're way over your head on this, and it has nothing to do with being a bad programmer.

Smaller web companies tend to have a lot of projects going on at the same time, which in many ways leaves you in a though spot. Either try to make the best of your situation, or try to find a new job if you think you can. I promise there are better coding jobs out there, so don't let this first one scare you off.

Good luck, and I hope both you and your co-workers understand the gravity or your efforts!

Personal experience

Like many here I also recognize your situation. I basically got my first coding job with a low salary and had to maintain a lot of built code with a poor structure. At first I found it funny to learn new stuff, but when I in the end had lots of projects to maintain, new projects to make and a white board which grew bigger and bigger every day with points I wasn't done with I realized that it wasn't working.

After putting up with it for two years, I quit and found another coding job a couple of months later which fits me perfectly.

Anyway, many times it's not only your projects that might be the issue. I find myself more comfortable on a workplace when I get acknowledged and respected for my work. The problem with the situation that you're in is that your employers might only notice the bugs which arise from created projects, and not the time you take to remove all the other bugs.


If you want more money, you can often get it. I managed to negotiate my salary in under two years to a raise of 33%.

Basically, think about the value of your work and how much the company needs you. If they can't afford to give you the salary you've earned, then the company either needs to looks at their expenses or realize that their business isn't working.

And as mentioned by many here, and I agree, you're a very valueable piece of the company puzzle. Hell, you're probably the only one that can solve that puzzle. :)

  • Regarding the Salary thing, I want to say, this kind of work which involves more maintenance work makes the developer very important as they know a lot about codes and structures, so they will not let an experienced developer to leave easily.
    – 000
    Commented Jun 13, 2012 at 0:21

Since I can't comment yet because I'm a lurker on this Stack Exchange site, I will just add to the information on here.

  1. Since you are just starting out, your salary isn't going to be stellar unless you went to work for a big company like Microsoft, Amazon or something akin. But it shouldn't be that of a grocery employee! Don't put up with that for long, gain experience doing what you are doing and move on when a better opportunity arises.

  2. For an entry level gig this is kind of normal. Your workload is too high, but the type of work is expected. To become a better developer you must learn from others' mistakes. The more you see, the better you become. But that implies you are looking for things to learn from, not learning bad habits...

  3. The ratio of maintenance to project work should shift over time. If it isn't, that means the company you work for doesn't realize how to keep a good developer; they intend to have you do the same thing day in and day out. Make a yearly goal for yourself as to where you would like to be, salary and job expectations wise, and move accordingly.

4) If you aren't happy, leave! Life is too short to deal with stupid people.

All the best.


You start using an issue tracker to keep track of your todo list.

This will not only help you with keeping track of what is critical, but it will help the users and your boss with seeing what your current workload is.

Also, should they ever hire a second developer (or you quit and your replacement now takes up your workload) this will help in managing the workload, and you'll be able to avoid stepping on each others toes.


The only way to break this chain is to develop new infrastructures that are designed for flexibility and are full unit+integration tested.

If you manage to sell this to the management (sign other developers and managers on to the concept in 1:1 meetings), then you can slowly reach a state, where most of the applications' code is in the infrastructure and it is easy to expand and maintain, whereas the actual applications are light weighted and can be written pretty quickly.

The development of the infrastructure may enable at first replacing parts of existing applications and after a while (may take a few years) replacing entire applications.

In the long run it can reduce development time of new applications and maintenance time of future existing applications drastically.

The new development will require at least 80% dedication (preferably more) with a team of more that one developer (a few minds are better than one). All the developers will need to be able to think creatively and to break existing preconceptions.

Try defining and high-level designing such a new infrastructure, then present the definition to your peers and to management.

As of your working conditions, ask to lead a new infrastructure team that deals with these issues (based on your definitions and design) and bring on new developers to maintain the old stuff while you assist them if necessary (up to 10-20% of the time). If the management agrees to the idea, you can ask to renegotiate your terms. Be prepare to find another job if they refuse. (Remember, your job requires skills, knowledge and experience, you are not as easy to replace as they are paying you to believe.)


Is your manager aware of all these change requests (maintenance requests)? Does s/he realise that your time is taken up sifting through such requests that you have no authority to sanction? Or do you just make changes everytime a manager asks you?

It seems to me like your first port of call is to put it all on your manager's desk. No one should be coming to you directly. Issues should come through whoever fields such - usually a support team. It is normal that you support your code for a short handover period - usually a week or so. Changes should be costed and charged (transfer charging) in any company that would class itself as "medium size", and this it seems is being bypassed (no wonder they are flooding you - you are like the slut at the prom).

There should be a proper request procedure for both raising issues and change requests. Support/maintenance is about fixing bugs and issues (that fit with the original specification, but fail because of a bug in the code or an outside event - such as a power down or corrupt upstream system, etc.).

If your company offers none of this and expects you to cope and be responsible for this myriad of random requests, then seriously you need to consider moving on. Pay is always poor at the bottom - in my first programming job (almost 25 years ago) I spent 8 years for the same company and my pay went up little (although it was always much higher than a cashier!). Within 2 years of leaving I had doubled it - and two years after that I was taking home over ten times what I started at (but was then an independant contractor). As always, earn you spurs, learn your trade, and jump ship to warmer surroundings.


Perhaps you're in a position to go to a manager and say: "Look, I'll be frank with you. My pay is terrible, I could get N times this as an entry level programmer at X.

I am doing way too much stuff with A, B and C. I can't maintain this. Honestly, and no offense intended, I'm going to walk out of this room with this either fixed, or with my resignation letter left with you. Now that this is all out in the air, how can we work together to make this right?"


The answer is to try and explain it in terms that can be understood;

  • It's like oil changes. They aren't urgent.... but must be done regularly none the less
  • paint over rust and it'll look great. Until it bleeds through
  • build a new roof patio roof desk without strengthing supports. It will work for a while maybe. Then it will collapse and hurt people and you will be responsible.
  • a/c is great. A window unit is great for one or two room. Trying to put 146 window unit air-conditioners in an aartment building and you will have... problems.
  • Teaching 5 kids is fine. 10's not too bad. But there ARE limits. Try informally teaching 75 kids and you will see this.

If these are not resonating. Leave - THE DAY YOU GET AN OFFER ON WRITING, not the next day! Once you HAVE a new job, leave with ZERO notice. Literally just don't come in that day. But make sure you have a colleague or two who know what you did. This will actually help the company out, if the company can be helpd, by showing them that their disrespect and arrogance comes at a price. Last company I was at THREE OF THE FOUR TECH'S LEFT WITHIN 6 MONTHS WITH NO JOB TO GO TO. It made a statement at least and gave the leaving person once good chance to say, 'yeah, nice bs you say every day but you are so full of it, I'm not even giving you the satisfaction of my notice.

Finally, do know that this stae of affairs was the NORM and the standard 20 years ago before agile, tdd, bdd and refactoring became more then norm. You may be talking with senior people who immediately respond "well I have done this myself and it worked fine, blah, blah, blah." Well, s ure horses and carriages worked well 150 years ago. In technology areas, techniques from 20 years ago are as outdated as transportation from 150 years ago. If they reject this fine. Just know that they will never hire any decent current technology developers who will stick around. They will get the worst of the worst and it will hurt their business terribly. If they depend on technology and can't adapt they will fail and ultimately that may be the best reward for you. It's just that it may take a while as dysfuntional organizations can continue for a long time.


It sounds like your management fundamentally does not respect you or understand your work load.

You should not be implementing every feature request that comes through. Your manager should act as a buffer between you and incoming requests (except perhaps the most simple of break/fix requests). Then he or she should sit down with you and determine the feasibility and priority for any approved requests.

Also, you should be making probably 2x (at least) what they're paying you.

It sounds like they probably really need at least 1 more developer to work alongside you, but with what they're paying you that sounds pretty unlikely.

If they are unwilling to adequately pay you or help you manage your workload, I'd be looking for a new job. You want to work someplace where you're part of a team, and where your management works with you to complete your projects. Get off that sinking ship as soon as you can.

Being a hero on a team of one is only going to burn you out.


I'm only a student (still) but that's pretty normal (from my internship experience). That's what you get when working in support and web applications.

I'd advise you to understand what the client (manager) wants before starting coding. That could be tricky because sometimes they don't know it themselves so work with them till they agree on something. Make sure you both agree on the final solution before you code it.

Also if you are a maintainer you can pretty much change anything in the code - just make sure it doesn't change the behaviour or introduce bugs. I expect managers do not 'allow' you to change anything because they are used to and happy with how it is now and they don't want to pay for any new changes.

Finally, don't worry if you can't handle something because you're doing something else. I'd advise you to let people know that you are overwhelmed with work and their request will take time. If you don't managers would just think you're lazy. Do let them know you already have work and they might hire more people. There is no other way for them to know that the work is too much for a single person.


This is a project management problem. Use some kind of project management to decide what is of highest priority to work on.

a) You need a backlog of items to work on. You put your plan for improving the code in the backlog.

b) All the bugs go into the backlog

c) The backlog gets prioritized.

d) You do it all in priority order.

Bugs may very well be a higher priority, but if once you fix all that you have cycles to spend on new features or on refactoring design.

It's easiest if you just do refactoring improvements incrementally, as you pass over sections that have issues/bugs to fix. Then you can tell management, "I had to fix A, but B was fundamentally broken and I had to do solution C to fix it all so that D will be easier/cheaper in the future" Where A=The bug, B=The anti-pattern, C=Solution, D=Future Gains

If you can't justify work as an investment worth doing, business people will never accept it.


This is business as usual. You will be exploited as long as you keep working there it seems. It's in the company's best interest to continue going with this model rather than to make you feel happy in what you are doing. When it comes down to it, they don't really care. It's about creating reliable code for them and if you are a one-man-band, they are certainly making bank of you. Why would they change?

The good news in all this is you are a VIP to them even if they don't know it. What I suggest to do is to line up some more opportunities before jumping ship then grab them by the balls and demand a higher salary. If not move to a better opportunity. In my opinion, you should be finding some more exciting work soon. Aim as high as you can. Once you get to a developer shop, you will be much happier like Google or some fun startup where there is a collaborative developer culture where you will truly feel happy.

What I did personally was to use a head hunter contractor organization and quickly got many great experiences under my belt, moving from one to another while still maintaining a steady employment from my contractor. It keeps you from getting bored and challenges you. Eventually, in my spare time I built up some small business which blossomed into actual business, and then I jumped ship from doing contract work.


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