3

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. Task requires 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. Task is very specific to the project or even to one very small area of it. Doing it 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 the same part.

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

This may be useful to disperse knowledge among the team so if someone quits, others can take over, but anyone can spend a few days to figure out a code, doing it upfront is paying for some accident that didn't happen yet or may not even happen ever. If you do this now you just guarantee paying the cost.

Improve this question
3
  • 2
    Why would other people need to do the grunt work that you don't like? Have you ever considered that the "other team members who worked a lot on these specific areas" don't like it either?
    – Mark Rotteveel
    Nov 16, 2020 at 12:17
  • @MarkRotteveel What I'm talking about is not grunt work at all. There are areas that I wrote, when somebody works on them would take 5x time it would take for me and learning that part won't add any experience or knowledge to them, I believe there is no reason for them to do it as long as I don't leave.
    – uylmz
    Nov 16, 2020 at 13:12
  • 1
    @uylmz I suspect you've hit the nail on the head there without realising it - duplicating knowledge and experience across multiple team members is good practice precisely because people leave, get sick, die, that sort of thing.
    – motosubatsu ♦
    Nov 16, 2020 at 14:35

2 Answers 2

Reset to default
2

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

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .