Ask HN: Unable to detach emotionally from work?

Focus on being "good at your job" not at "making everything better" or whatever you're doing now.

What you think of as doing extra work also ends up causing extra work for other people. You say "Attemtps to communicate with other teams to sync and improve processes were also shutdown... because it's not my responsibility and the team leads felt threatened" - it's almost certainly not that your team lead "felt threatened" (wtf?) but because you caused an extra hassle for them by causing confusion among your coworkers about the processes and practices for communication, documentation or decision-making.

Your time spent "fixing a lot of small things" that nobody cares about means other people have to code review, QA test, merge, deploy etc your work, which as you stated, was not scheduled/prioritized/desired.

An important part of being a team is playing your role, which includes not interfering with other people doing theirs. You see yourself as an unappreciated hero picking up the slack for everyone else, but everyone else sees you as an unpredictable wildcard causing confusion and extra work. Just focus on doing your job well and let the whole team thrive.

> What you think of as doing extra work also ends up causing extra work for other people

This is a very good point but none of the things you mentioned are happening to other people (code review, QA, merge, deploy). Maybe that clarifies the kind of environment I'm working with.

In any case, I understand that even if more work is not being done, more stress is being caused because people just assume things will break in unimaginable ways. I can appreciate how that would be a problem for others.

> everyone else sees you as an unpredictable wildcard causing confusion and extra work

Thanks for the harsh truth. Would you say the kind of work I'm doing has a place in any other type of company? Or at all?

Anecdotal(worked for me and a friend):

Find another activity (hobby, sports, taking care of someone, meditation, side-project, anything) and gradually have it replace work in your head.

You won't be able to "detach from work" because the mind (especially in people who like to think) doesn't work this way. You'll have to expel it/push it out.

Any time you catch yourself thinking about work in an emotional way, or outside your office hours, force yourself to shut it down and think about the other activity you chose as replacement.

This process took me years but it's really been worth the effort.

That seems like the best action for me. Thanks!

Don't do extra things. Let the sprints guide you. Try to make your code better. The place doesn't want you to do these cleanup tasks without them being approved in a sprint. So next sprint meeting suggest it and only do it if it gets approved.

I feel the planning done by management doesn't let me feel proud about the work I'm doing. That's the emotional component I'm struggling with.

I've been told the things I raise as necessary to be done "will be done in the future" but they never are and I'm not given good reasons for why not. Most of the time it's because people don't consider them important (see my other comment for examples).

So I kind of rebel against that in a way and, while I think my output is better, I'm not appreciated for that and worse, might get reprimanded.

You need to first understand why you are getting passive-aggressive responses. Just because you think you are doing "other things that no one cares about", it doesn't mean it aligns with what your Manager/Team/Company needs from you to ensure you are effective at the job you were hired for.

Superstars in a team are easy to spot. They not only get their stuff done but do other things that help the bottomline. Problem is that sometimes you may think you are helping the team by doing other things, but you are probably doing it at the cost of your own work.

You are being micro-managed, it's worth comparing your current work environment to what you were told it would be like when you hired on.

If there is a large difference between the position description and reality then you may be able to push back with the hiring manager so that you are given more autonomy to prioritize tasks during sprints.

Ideally your management should be asking you to first do items in set X and then giving you time to work on tasks that you prioritize.

This is why I prefer Kanban over Scrum as Kanban doesn't limit the set of tasks per sprint as Scrum does.

It's funny that you mention that because we used to do Kanban and switched to Scrum because that was what all other teams were doing, and "it helps with the reports".

I think I see a lot of tech debt and I want to solve it. I'll admit there are situations where I'm purely being extra zealous and I shouldn't and I'm trying to work on that.

I agree with the micro-management part too. If at least we were aligned and I was micro-managed for doing things management and I agree on, it wouldn't feel so bad. But the way things are right now, I feel like I might get fired for doing extra work, which is a first for me.

I don't necessarily think you're being micromanaged, but I can tell you I dislike agile and one of the reasons for that is because despite what people say, it's segmented as shit and typically prevents you from doing good work.

And when I say it prevents you from doing good work, I mean it. The last company I was at did scrum and I found it difficult to even call someone up to have a chat about things without blowback. My "PM", aka manager, insisted that he was a requirements gathering bot, and any attempt at requirements gathering that didn't go through him was promptly shut down. And by shut down I mean 2 weeks into the job I had a meeting with someone about a new feature and 15 minutes into it this "PM" magically shows up and completely derails the conversation. nothing got done. The next day I recieve an email from the manager of the person I had the meeting with declaring that all meetings going forward would have her in it. When I questioned why with my manager I was quietly pulled off of that project, and I watched the other developer on it come back from every single meeting over the next 2-3 months repeatedly saying he still had no idea what they wanted.

It was like trying to develop in a straight jacket. The final straw for me is when I had asked some questions over an email and the VP over that department didn't like the questions and told my direct manager to write me up over it (he told me this directly). That was on a thursday, I had an offer for 20 hours/week by the end of friday (enough to live on), and basically told them to go fuck themselves. I made it very clear to them that it only took me a day and they're not going to keep any talent acting like that.

On the flip side, I've been working on another project as a freelancer for the past 8 months (with a break in the middle) with another developer, and this guy just wreaks havoc on everything he touches. Just last week I looked at something else he did, sat back and said out loud "how is it that I disagree with literally every decision you make?".

This guy would rewrite everything I wrote. He would take the idea and just restructure because he wanted to. Only, in such an overengineered manner that I'm just kind of miffed at what he's doing. I remember after about the 3rd month I just called the owner of the project up and straight up told him they need to stop paying me because he's _literally_ rewritten every piece of code I've written. I told them in no uncertain terms that I would take _no_ responsibility for the quality of the work because none of it was actually mine, they're just paying for everything twice. I straight up told them they need to get rid of the guy.

fast forward to 8 months and that same owner asked me to come back on board and told me directly that the company was going to be paying the cost of having this man work on their stuff and they're planning on releasing him. Why? Because a 2-4 week project isn't stable 8 months later and it's actively put their business in danger.

So I'm now working 40 hours a week and have completely replaced the income from that shitty company.

My point is this: I've seen both sides of it and just w/i the last year. You need to do serious thinking to determine which side of this coin you're on, and make the changes you need to make.

If you're in a company like that, get the hell out because you're too good and you're going to hate your life there. If you're like that man, you need to be kept in check and grown because you're not experienced enough to be left to your own devices without actively putting businesses at risk.

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?

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

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.

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.

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.