How to get motivated to work on tasks that don't help you improve

Question

To me there are two aspects of any task assigned to a developer in a software project. These are not exclusive, so a task can be (for example) 40% aspect 1 and 60% aspect 2:

1. Tasks requiring you to learn new things or improve your existing understanding on them. Doing this will improve you as a developer and gained knowledge/experience is transferable, either to other areas in the same project or to other projects.
2. Tasks which are specific to the project or even to one very small area of it. Doing them may only improve you as a particular developer on that project. Even then, gained knowledge/experience is only useful in that specific part of the project, therefore useless, unless there will be many tasks in the future focused on that same part.

I don't have a problem working on tasks which are entirely type 2, since they are part of the job, but when there are other team members who have already spent a lot of time on those specific areas, me doing them seems like a waste of time and resources for everyone. This absolutely kills my motivation. Especially in a project close to finishing, when it is clear that there won't be any more tasks regarding those areas.

This may be useful to share knowledge among the team, e.g. if someone quits, others would be able to take over, but anyone can spend a few days to figure out a code. Doing it upfront is like paying for some accident that has not happened yet or may actually never occur.

Answer 1

I understand that it's not nice being pigeonholed; I've been there myself, working on legacy projects that really aren't relevant to today's technology, architecture or methodologies. If left alone, I probably would have ended up being the "legacy code guy," so I talked to my manager and said that I want to do other things in addition to working on legacy stuff. So step 1 for you I think is to raise something similar to your manager.

There will always be tasks at work that you don't want to do, but they won't take care of themselves, and eventually, someone has to do them. However, it's not fair for this to be one person's sole responsibility, so you are perfectly entitled to ask to work on other things, as long as you accept your share of the overall responsibility, just like every good employee does when they choose to work for an employer.

In terms of how to motivate yourself during those times when you are stuck doing things you don't want to, here are some tips that work for me:

• If the code is bad, think of it as an exercise in learning how not to write your future software.
• Remember that any work you do as a software developer is relevant experience for you. You don't always have to be using the latest technology fad, or learning entirely new concepts in order to grow professionally; any coding you do will contribute to you becoming a better developer.
• If it's something really horrible and tedious (and I don't have to use my brain too much), I listen to thrash metal and just power through it.
• During long periods where you don't get to work on interesting stuff, if you're serious about becoming a good software developer, then study in your own time. Read books, do personal projects, contribute to some open-source projects, etc.

Lastly, your point about sharing knowledge is valid. Your next point about it being a waste of time isn't valid, though - as you said, it's

paying for some accident that didn't happen yet or may not even happen ever

You said it yourself; it's not guaranteed that these experienced developers will always be around, so it's in the company's best interest to make sure that enough people know about these products to be able to keep them going should people leave (or, as is increasingly the case with legacy code, die).

Answer 2

It probably started by one of those "other members, who spent a lot of time there" saying they wish to work on other tasks also, plus bus factor is a good argument as well.

I've used several strategies, depending on task type, amount, time expected etc.:

1. Boring manual task? Instead of doing a simple task 100+ times for the next 5 hours, I will find a way to automate it (or semi-automate at least). It may end up taking 8 hours, but its a) more fun, b) less error-prone (almost always), c) reusable (cos we know the one-time problems have a tendency to raise from the dead repeatedly), d) if nothing else, you practiced your scripting skills and next task will be easier & more effective [using your words, you just moved the task to group 1]
2. Turn it into a competition. Measure something and try to beat it continuously. Surely helps if you are not the only one doing the job.
3. Try to find fun within the task itself. This is very dependable on the task and its type. If you are working on messed-up legacy code, show your colleague the funny parts "Hey Pete, just working on , when you open that class in IDE, the linter looks like one big scrollbar." If you get to work on that often, you can make a (monthly) competition for "worst/craziest/ugliest code found" or something of the kind.
4. Works for rather short tasks - play loud (trashy) music, turn the brain off and get it done.
5. Remember you learn the most from the bad things. I've always known it is an antipattern to log and throw an exception in java. Seeing actual log of this will make you remember/understand it way, way more (and forever). I've ranted about some maven hacks being hard to understand. Then I saw ant scripts. Suddenly I no longer complain.
6. Make the task bigger by including parts from the first group: Buggy part of the code? Write (unit) tests. Legacy hell? Do a bit of refactoring. [modern workflows should help you justify the time spent there]
7. Make inner peace: If I have to work on something I don't like, it helps me to write an email afterwards about the issue, how should it be done properly etc. Even if I know the chances of success are zero, I will do so. When it blows again, I will write a follow-up on that email. [and possibly have fun of how are people avoiding the issue, making excuses etc.]
8. Similar to previous, I will create tasks for everything that is wrong with and keep em in backlog, then agree it is low priority, but never close unless resolved. [helps with other stuff also]
9. The "feeling good" way - works for problems etc. For me it feels good to be "the guy who knows" and others come for help or being the "saved a day guy" or simply being a good teammate and taking one for the team (like volunteering for a task everybody hates and using any method to make it more fun and if possible, get rid of that).
10. Take regular breaks to keep sanity.

Note: There are literally hundreds of ways, based on task's type (legacy code bug, legacy code feature, manual clicking, manual data fix/es, report creation, learning unpopular/old technology), expected time of completion (5 minutes of crazy clicking, 1 hour of hard thinking, 3 months of investigation, ...) etc.

Answer 3

How to get motivated to work on tasks that doesn't help you improve

Even if your current task has no possibility for you to improve ( I doubt it), by completing these tasks you free up time to work on tasks that will help you improve.

So if your only purpose for doing work at your company is to improve, your motivation should be finish "non-improving" task A so that you can work on "improving" task B.

Answer 4

Think of ways how your routine work could be automated. Use the feelings of frustration and dullness as an ignition system for your discovery of automation methods.