[tjchear]

It's in my experience that when one elects to keep themselves busy with A instead of B, it's because they're more adept at A than at B. Doing B requires one to get out of their comfort zone, and doing A let's them believe they're making progress while avoiding having to think about B.

Now that's just me, maybe it's different for you.

If I may ask: how are the sprint tasks different from the other small things you feel compelled to do?

[throwawayzza]

>B requires one to get out of their comfort zone, and doing A let's them believe they're making progress while avoiding having to think about B

There's definitely some of that.

>If I may ask: how are the sprint tasks different from the other small things you feel compelled to do?

Sprint tasks are almost always about new features. The other tasks are more about maintenance and tech debt.

For example, my Sprint task will be about feature X. When I'm adding tests for X, I realize this particular repo has been neglected and is using very outdated dependencies, not following CI best practices we're using everywhereetc. So doing all that slows me down but I feel it's the right thing to do. Others disagree and don't see any problem with that.

Or our monitoring system started to spill out false positives a lot (or I took a look at that just this week), and I need to adjust things so the oncall doesn't keep being woken up unnecessarily. Or worse, they just keep pushing the ignore button.

Or the code I'm working on is using a database that's behind updates and is missing security updates.

There's a lot of yak shaving if I'm to look at the whole thing and feel proud about it.

[tjchear]

Hey, that's the mark of a great engineer. I'm sorry your peers did not see the value in what you do.

My armchair diagnosis is you and your company are a poor fit for each other at this phase of the company. You have probably already surmised that you'd do better at large corporations or companies not focused on growth, but on greasing and sustaining their existing products.

Since you mention that you can't quit this job, there are several options you can consider:

1. Internal transfer to another team, if possible.

2. Start looking for other opportunities that are more aligned with what you do.

3. Be mindful of priorities and timelines. Visualize and draw the timeline on a piece of paper if you have to, and understand that it's physically impossible to do both new feature and the small tasks, and still meet the deadline. Hopefully doing so helps you to see the big picture as the company sees it, and lets you override your compulsion. Write this down on a sticky note as a reminder and stick it on your monitor if you have to.

[trilinearnz]

I agree with this. The OP is demonstrating a level of conscientiousness, professionalism and self-agency that a lot of companies would like from their developers who only do what they are told to do. See: Theory X and Theory Y management (don't want to work vs. want to work).

However my only addition to what the poster above mentioned, is be wary of the perils of the consequences of continually updating dependencies as this can be a never-ending spiral. If your organisation lacks the labour to maintain projects properly, your efforts may well be more sensibly allocated towards the greenfields areas you are being asked to focus on.

[itronitron]

If working on feature X involves cleaning up its dependencies and general build process then that is part of the work to complete feature X.

If one of your peers has a problem with that then it's worth considering how they learned of the additional work you put in.

If they are snooping through your commit logs or comments then that is creepy. If you are telling them then I encourage you to be more selective with the information that you share.

There is an art to making commits such that other team members aren't riled by 'off the books' code cleaning.