Doing Nothing at Work

Posted by Sukram21 1 day ago

Comments

Comment by codewarrior2000 5 hours ago

It's a good practice to run at 80% utilization and it helps if you are not being managed by people with an overseer mentality, who demand 100% from you all day, everyday. They are the ones who misinterpret the look of software engineers working in relaxed silent repose as lazy idleness. That's why remote work is the best thing to allow me to keep some utilization in reserve and to keep my sanity.

Doing a little bit of "glue work" can make you indispensable and also a hero to your team if it makes everyone's work life a whole lot better and no one else knows how to do it.

Comment by martin-uk- 2 hours ago

I'd argue 80% is high. This also varies between Devs. The way I learn, think about things, struggle to get started etc, means my 80% is no way near say, another colleagues' level who's simply stronger technically. Factor in any degree of NT tendency, and one person's 80 is anothers' 120.

Comment by o_nate 1 day ago

There's a lot of wisdom in this. In addition to reserving some capacity for when true high-value work comes along, I think software engineering is not the type of job that you can do well if you're constantly busy. Trying to write some code as quickly as possible seldom yields the best design. This article doesn't get into another important aspect of this, which is how to get away with working at 80% capacity without getting in trouble with your manager. This takes a bit of care around communication and estimation of work. One of the first good pieces of advice that I got from older seasoned developers when I started my first real programming job has stayed with me to this day: take your estimate of how long it will take to do something and double it before communicating to your manager/users. As you get more experienced that ratio can come down to maybe 1.5x instead of 2x, but the principle still applies.

Comment by martin-uk- 2 hours ago

Kent Beck (maybe in Good News Factory but also in talks) that his team would never commit to more than half what they think they can get done. This is a good way to sustainability. And that's the optimization and precedent to set; that we are here for the long term, delivering steadily at a sustainable pace. It's a long game, and over promising only runs down trust, which is your biggest means too getting the space we need as Devs. Under promise, build trust that we can do what we say, earn the space we need to not burn out. Honestly the more senior I get (Lead), boundary setting and preserving my attention; not burning out, _is_ the job. Because there are myriad ways to do this to yourself.

Comment by thewileyone 14 hours ago

I've argued the same for 30+ years. Having some slack is healthy so that teams can be simultaneously proactive and reactive to issues. Even the best athletes do not train or compete 24/7.

Comment by tjadfsaj 1 day ago

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

Comment by thewileyone 14 hours ago

If you're still learning or giving opportunities to learn new things, stick it out. If you're stagnating and not allowed to learn new things, it's time to leave.

For the first 10 years or so, this is relevant. After that you can figure out what you really want to do.

Comment by lgcmo 1 day ago

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.

Comment by erelong 1 day ago

It sounds like you could have a little "buffer time" where you "do nothing" to prevent burnout when you need that free time for something that pops up and to take adequate breaks to pace yourself cognitively speaking

Otherwise I don't see why you couldn't do lower value tasks with flexibility to abandon them if something higher value comes up

Comment by jazz9k 1 day ago

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

Comment by tonyedgecombe 1 day ago

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

Comment by whattheheckheck 1 day ago

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

Comment by tonyedgecombe 1 day ago

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%?

Comment by QuantumNoodle 23 hours ago

I've worked roles where our priorities shift with the wind. Many times it is for good reason, like a strategic customer to get a foothold in a market. Other times it is just because management hyped up some effort. All's this to say, nod saying you will do it then just go about your day doing focusing on the actual priorities. Don't let workload mount up bc deadlines are all made up.

Comment by qazxcvbnmlp 1 day ago

Your communication with stakeholders about your work ends up having more of an impact than your rate of work output.

Comment by holografix 1 day ago

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

Comment by harimau777 1 day ago

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

Comment by Schiendelman 1 day ago

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.

Comment by galleywest200 1 day ago

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.

Comment by zamadatix 1 day ago

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.

Comment by SpicyLemonZest 1 day ago

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.

Comment by gorjusborg 1 day ago

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

Comment by projektfu 1 day ago

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.

Comment by throwaway67678 1 day ago

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)

Comment by SpecStudioHN 1 day ago

doing LOTS of nothing can also be a huge power move. i was in software development, technical writing contracting in Silicon Valley back in the 80s. i stepped away to do something completely different for 40 years. curiosity in AI brought me back. the background acquired from my exploration of an apparently unrelated field enabled me to develop some very advanced software concepts relevant to the problems with AI, and implement them in working code.