Live data from Hacker News

Doing nothing at work

seangoedecke.com

11–20 of 168 posts

Re: Doing nothing at work

#11

Earlier quoted context omitted.

Don’t you? You can always say no verbally or with non-delivery. Are you working under a continuous and immediate threat of dismissal?

When customers that pay you a lot of money demand resolution to issues from your higher ups, you sort of have to. Especially true if their product is not working.

It has to be a really really small place for "you're the only person we can say yes with" to be a fair note on a request. That doesn't mean there aren't plenty of people stuck with such jobs at bigger places, but it doesn't make it any more reasonable an excuse and pretty much still boils down to constant fear of being dismissed if you say no in the end.

Re: Doing nothing at work

#12
post #2

This is written as if you have actual control over the volume of work given to you and/or deadlines.

Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have.

One common misconception the article touches on, for example, is that Jira tickets represent latent task assignments, such that you should always be working on some specific Jira ticket and immediately pick up a new one when you finish or are awaiting review on the last one. That's not how the most successful engineers work, and often it's not even really what management wants.

Re: Doing nothing at work

#13
post #2

This is written as if you have actual control over the volume of work given to you and/or deadlines.

Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have. One common misconception the article touches on, for example, is that Jira tickets represent latent task assignments, such that you should always be working on some specific Jira ticket and immediately pick up a new one when you finish or are awaiting…

Picking up Jira tickets could be a good way to accomplish the other goals. Suppose the ticket has a request from a user you don't chat with, it's a good time to go chat with them. Maybe you don't understand a part of the code base. Looking into a Jira ticket related to that part gives you a reason to read through it. If there's lots of tickets related to a subsystem, you might have a conversation with the product owner about what direction they're taking it. What you might not want to do is accept responsibility for the ticket until it's time to actually hammer it out.

Re: Doing nothing at work

#14
post #2

This is written as if you have actual control over the volume of work given to you and/or deadlines.

Don’t you? You can always say no verbally or with non-delivery. Are you working under a continuous and immediate threat of dismissal?

> Are you working under a continuous and immediate threat of dismissal?

Definitely! It's been that way everywhere I've ever worked. Unless you are churning out code at maximum speed then it's only a matter of time before you get fired.

Re: Doing nothing at work

#15

Earlier quoted context omitted.

Don’t you? You can always say no verbally or with non-delivery. Are you working under a continuous and immediate threat of dismissal?

> Are you working under a continuous and immediate threat of dismissal? Definitely! It's been that way everywhere I've ever worked. Unless you are churning out code at maximum speed then it's only a matter of time before you get fired.

You may not like hearing this - setting boundaries is a skill, and a difficult one to learn. It's also one of the most valuable skills for you, especially you personally, to learn, based on this comment.

Re: Doing nothing at work

#16
post #2

This is written as if you have actual control over the volume of work given to you and/or deadlines.

Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have. One common misconception the article touches on, for example, is that Jira tickets represent latent task assignments, such that you should always be working on some specific Jira ticket and immediately pick up a new one when you finish or are awaiting…

> Most software engineers in my experience have quite a lot of control, and a large component of growing in your career is learning to perceive the control that you have.

I've found that most of that autonomy comes with trust, and that trust gets unlocked via good relationships, and good relationships get unlocked by a history of good communication.

You are 100% correct that every person has agency, the trick is to get yourself into a social dynamic where it is acceptable to assert it.

Re: Doing nothing at work

#17
Also applies to research. Keep leeway to open yourself up for collaborations and you might score lots of easy wins even as you struggle with your 'main' project (it also makes you a more well-rounded, sociable scientist)

Re: Doing nothing at work

#18

Earlier quoted context omitted.

It's surprising how often people dig their own grave.

You can say no thats too much work load, we're understaffed or its too tight of a timeliness for the results. But understand the ecosystem. People make promises that arent entirely dependent on them to be able to deliver

If your boss promises something that will take 150% of you capacity for the week does it make any difference whether you put in 80% or 100%?

Re: Doing nothing at work

#20
post #6

Thank you for this. I'm new to SWE. How to know when it is time to leave an organization versus sticking it out?

So many factors are envolved in this that it is hard to begin the answer. I would spend some time discovering the main points and answer them.

One that is very important: Do you have another opportunity to accept? There is nothing better to get a job than being employed.

If you do have a offer, consider if you take; but if you don't, try to get one while you are employed and jump ship when it's a better one; repeat.

Post reply on HN