-3

Fluff work All 3 positions I have done had a form of fluff work 1- Virtually unending “Jiras” or bugs due to crappy code on legacy systems 2- Operational burdens of owning online services 3- Setting up portable build systems

The problem with fluff work is that nobody wants to do it. My strategy was to reduce the amount of time I need to spend on fluff by becoming good at it. This approach didn’t work because I usually end up getting more and more because I am good at it.

So my question is, how do you handle fluff?

closed as unclear what you're asking by Dukeling, DarkCygnus, DJClayworth, gnat, IDrinkandIKnowThings Oct 19 '17 at 0:42

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • fluff? I would have said that was work nor directly related to the main product updating the quality management system - is English not your first language you might want to edit the q to use a better description – Neuromancer Oct 18 '17 at 18:59
  • 5
    If you're not happy with your job, speak to your manager or find another one. If you don't voice your objection, of course they'll give you a lot of the work you do well that no-one else wants to do. – Dukeling Oct 18 '17 at 19:14
  • All true dev jobs have this type of work once things are in production. It is generally more critical to do this than new dev. Just because you dislike this work does not mean it is fluff. Your boss needs to spread the work more equitably and not let jerks get away with avoiding it. – HLGEM Oct 18 '17 at 20:43
11

What you're describing as "fluff work" is actually a critical task in any business. My own boss breaks down our work into two categories "new development" (exciting projects everyone wants a piece of), or "keeping the lights on". Fluff work falls into the second category (such as creating domain classes for all those all programs that read data using SQL statements instead of ORM's).

Ideally, the systems would be so well written and robust that there wouldn't be a large amount of such maintenance going on, but the reality is usually a little more dour.

Ideally, everyone would pitch in, or at the very least the manager would assign that work equitably. If that's not the case, the the problem is not so much the existence of fluff work, but the way the team is run.

As to how to handle it? Do the work. Share the work. Keep the lights on.

If no one else is pitching in, it shouldn't bother you. Just keep working on "fluff" at your own pace, and let the chips fall where they may. If you find yourself becoming the designated "fluff guy", tell your boss that you'd like to work on other projects more often.

Do keep in mind that often times the reward for a job well done is more work.

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