Doing nothing at work

https://www.seangoedecke.com/doing-nothing-at-work/

by Sukram21 • 1 month ago

497 162 1 month ago

seangoedecke.com

jazz9k• 1 month ago

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

tonyedgecombe2• 1 month ago

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

whattheheckheck2• 1 month 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

holografix• 1 month 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?

galleywest200• 1 month 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.

harimau777• 1 month 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.

SpicyLemonZest• 1 month 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.

projektfu• 1 month 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.

gorjusborg• 1 month 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.

qazxcvbnmlp• 1 month ago

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

QuantumNoodle• 1 month 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.

patmcc• 1 month ago

You sort of do; stop doing work above a certain volume, stop meeting deadlines. This will have consequences, which may include a) firing or b) better volume and deadlines, depending on a number of factors.

wiseowise4• 1 month ago

Are you working in mines of Uganda? No? Then you do have actual control.

deterministic• 1 month ago

You control how fast you work and what you tell your manager(s) about how long the work will take.

You need to learn to manage your manager(s). Google it.

icedchai• 1 month ago

If you're lucky, the managers are clueless and you can easily pad your estimates by 2 to 3x and still appear incredibly productive. The trick is pacing yourself.

SpecStudioHN• 1 month 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.

erelong• 1 month 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

tjadfsaj• 1 month 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?

lgcmo• 1 month 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.

thewileyone2• 1 month 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.

hilariously5• 1 month ago

Yes, the old rule is you are either earning or learning, if you are not doing either you should be out.

Early career pick learning and exposure to different technologies, processes, and company organizations.

That being said, this job market is pretty bad for the youngins so unless you are top 1% of noobs I would say focusing on stability and learning would be my north stars in the next 3 years.

cloche2• 1 month ago

If you're being treated poorly and it's causing you stress, leave.

It's going to take time to earn trust from peers and your manager to start getting more meatier work. If you're early career, I think 2 years is a good guideline. Many places hiring someone for their second job will expect you to be leaving your first job around 2-ish years. 2 years gives you the chance to take on larger projects and see the results of your work and get feedback about things you've pushed to production.

You probably shouldn't stay at your first job more than 3 or 4 years. The second job change is the hardest. It's when you realize that different companies do and value things differently. Staying too long at your first job will make it tougher to adjust. It's also good to get exposure to new ways of working while you're still agile enough to soak it up.

If you've left more than 2 or 3 jobs within 2 years it starts to look like a red flag.

o_nate• 1 month 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.

martin-uk-2• 1 month 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.

hilariously5• 1 month ago

Yep, if you want to run a sustainable business you don't look to fire on all cylinders all the time, but that's the rub, almost no owners are looking to run a sustainable business anymore.

Most people either want hypergrowth idiocy or to be bought by the people doing hypergrowth idiocy.

Setting consistent expectations means you can plan, you can actually reasonably budget, you can have predictability in your business dealings - if you are trying to run a good business these are all real features instead of "puts out more code that might or might not make us money, but at least we were pulling all nighters and adding perceived meaning to our lives!"

Sohcahtoa82• 1 month ago

take your estimate of how long it will take to do something and double it before communicating to your manager/users.

Yeah, but did you take Hofstadter's Law into account?

It always takes longer than you expect, even when you take into account Hofstadter's law.

https://en.wikipedia.org/wiki/Hofstadter%27s_law

Tcepsa• 1 month ago

NEVER take Hofstadter's law into account!!!!

throwaway67678• 1 month 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)

thewileyone2• 1 month 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.

codewarrior2000• 1 month 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.

martin-uk-2• 1 month 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.

hilariously5• 1 month ago

If you want to collapse just run a system at 100% for baseline, there's no slack, there's no capacity to meet new demands, you're just running a permanent failure mode if there's any perturbation in the system.

xnx• 1 month ago

Efficiency is the enemy of resiliency.

bumby7• 1 month ago

This is only true if you define efficiency as the inverse of redundancy. Sometimes efficiency is gained by reducing waste, not redundancy

stuxnet79• 1 month ago

Except ... the collapse never happens. Once your engineers burn out or age out you just hire fresh meat and the cycle repeats. The issue I have with these types of articles (and books like Peopleware / Slack) is they never provide any actual metrics that may convince the beancounters to try a different approach.

annoyingnoob• 1 month ago

Age out?

hilariously5• 1 month ago

Your systems just continue working at full capacity when all your engineers burn out and you hire new people who know nothing? Huh, that's a new one to me.

NoSalt3• 1 month ago

I've been "Doing nothing" at work for a couple of weeks now, and it's freaking me out. Yes, I have asked for tasking, but the guy in charge is ... I just don't know.

M95D• 1 month ago

Could you fix some bugs? Please?

NoSalt3• 1 month ago

The testers have the latest build, and have not reported any bugs. I don't even know if the project I am working on is even going to be funded after a few more months. I am just in this sort of limbo that really sucks.

wiseowise4• 1 month ago

Why? The moment you touch the code you become responsible for it. Can't count how many times I fixed something on a goodwill and then became responsible for it.

gib444• 1 month ago

As someone who's been there and let their skills atrophy and had his career slide backwards...act on that freaking-you-out feeling sooner rather than later.

black3r3• 1 month ago

I love having no task assigned. Means I finally have time to do code maintenance. Upgrading dependencies, fixing bugs (there are always some), clearing TODOs left in code, improving performance, improving dev tooling or monitoring configuration, cleaning up unused code, improving documentation, ...

And the best part is that since it's not an assigned task, nobody is waiting for it, so I'm under zero pressure.

Sadly it doesn't happen that much as we're always pushing for more new features out.

benbristow3• 1 month ago

In SCRUM though if that stuff isn't in the sprint you'll probably get backlash from QAs as it needs testing etc, or questioned why you're bringing in that stuff.

Easier to sit back and not do anything.

dilyevsky• 1 month ago

Tom DeMarco had a whole book about this approach: https://www.penguinrandomhouse.com/books/39276/slack-by-tom-...

garrickvanburen2• 1 month ago

fantastic book.

hintymad2• 1 month ago

Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts.

Not to be sarcastic but just to offer an observation: in a sufficiently large or bureaucratic organization, preventing an incident from happening can rarely get you any credit or visibility. Such achievement falls into the bucket of "what you're supposed to do". So, those who navigate company dynamics well would rather let the incident happen and then be loud on the follow-up action items. The trick is not to turn an incident into a diaster, so it's a dedicate act.

tormeh• 1 month ago

I learned this early in a conservative org. Preventing things is risky. Just keep the solution ready for when things go wrong because then you'll get approval.

cloche2• 1 month ago

Never waste the opportunity a good crisis presents

sergeym• 1 month ago

I've had this in my career also, I've had a solution that was deemed too risky to release by management but would have prevented an outage, but when an outage actually happened that was the first thing they wanted to try and it worked gloriously. I'm thinking that if it was released prior to the incident it would have not have had the same impact on my career.

justonceokay• 1 month ago

Anecdotally I know of an engineer in the Excel team. They would keep around a list of low priority security bugs. When they wanted to do improvements on the system they would attach it to one of the security bugs “nearby“ because the change would become approved much more easily than just fixing the problem itself.

nitwit0052• 1 month ago

The examples of high impact all seem like things unlikely to receive recognition.

If you save a sales deal, they'll cheer the sales staff. And pay them a commission, which you will receive no part of.

skmurphy• 1 month ago

And start to build a relationship with sales that, at least in a B2B firm, can be of significant benefit.

CobrastanJorji2• 1 month ago

Also, disaster is a good signal to the higher ups that there are problems in your org. If you keep putting out every fire with heroics, your boss will know (maybe), but his boss's boss's boss will see that your org is doing great and everything is all code green.

If you let a few things burn down, your boss's boss's boss will notice the fire, and things may improve. It's perhaps the easiest way you have of communicating with them.

themaninthedark• 1 month ago

What if my boss's boss is the root cause of the fires and he just blames the "team" if his boss ever sees a hint the of issues?

hintymad2• 1 month ago

Yeah, communicating upwards about potential issues and what you're doing about them is essential. When a disaster strikes, you'll look like a sage in the eyes of the higher ups.

bauldursdev• 1 month ago

Can't solve a problem that doesn't exist yet

mjklin• 1 month ago

It’s about what people notice. In town governments I’ve heard of cutting popular programs that will provoke an outcry only to get credit for reinstating them, while possibly smuggling through other actions that are necessary but unpopular.

johnnycool• 1 month ago

Many carears are made and bonuses paidout with heroesim trick.

johnbcoughlin3• 1 month ago

I read the section you quoted as being about saving the day in an incident that's already in progress.

rokhayakebe• 1 month ago

This goes beyond work. A self made friend told me "if you are always working when will you have time to make money?" We all need free mental space to think.

garrickvanburen2• 1 month ago

The metaphor that changed my perspective came from the book, "The Power of Full Engagement", paraphrasing "you're behaving as if you're a world-class endurance athlete without an off season - stop it."

mwhite• 1 month ago

I know this is a code about me behaving as if I went to a world-class university for undergrad. I could have gotten into almost any world class university, so that's what I do.

ge96• 1 month ago

Haha that's me right now, I'm enjoying it, I used to be gung ho wanting to be somebody but now it's fun coasting

I've been focused on going out/socializing more which is unfortunately distracting me in life, all I can think about is going out getting laid

skybrian• 1 month ago

This sounds a lot like being on call. If you like that kind of work, why not be an SRE instead? Maybe there also need to be people “on call” for responding to other kinds of events, though?

It also sounds a lot like getting pulled into meetings. People complain about it, but sometimes that’s the job.

macNchz• 1 month ago

I’ve had a half-written blog post in this vein for a while now using a fantasy RPG analogy: if you play a character that uses mana in any of these games, you’ll learn fairly quickly that using it all up all the time on trivial battles and running around empty leaves you with none when you genuinely need it.

Your mental energy deployed at work is not so dissimilar: keeping some in the tank gives you the option to deploy it strategically, rather than risking your health (burnout) when something unexpected comes up.

If you join a group in one of these games with a player who is bad at managing their mana, you’ll also find that they’re not such great teammates, either.

asdff• 1 month ago

One thing I've noticed myself, if you are not sufficiently challenged for a while it can be extremely difficult to surmount the next challenge. Peak "abilities" for me in whatever categories has always been when I had enough work in front of me to just chug away like a machine, and enough trust where I didn't need to stop and constantly explain myself but could just work uninterrupted towards the goal. Skills would grow like wildfire and tasks would be completed sooner than expected.

Unfortunately very few jobs are structured to take advantage of that. So many blockers and distractions from you getting into actual deep work.

supriyo-biswas• 1 month ago

At my previous job, the most productive time was when I was serving my notice after resignation, I got 6 months worth of work done in two. Without all the status updating meetings, "quick questions", overtime due to incidents, and whatnot, I got a lot done.

It was a bit ironic though, as most of the work I did during that time was ultimately shelved, as I can tell by looking up public DNS entries, probably due to other people exiting or the team being reorganized.

boogieknite• 1 month ago

or if youre like me you end an RPG with like 29 ethers that using early would have made life a lot less grindy

12_throw_away• 1 month ago

Sigh. This article is obviously completely correct, but I don't think the people who actually need to read it will care.

Running anything at constant 100% utilization means you are going to be working in crisis mode all of the time. Even in factory labor, the Toyota Way is several decades old now, and it involves making sure everyone has at least a little breathing room to step back and think about what they're doing. And obviously this is even more important for "knowledge workers" or anyone whose output requires any amount of creativity.

High functioning organizations have a good (not too much, but not too little) amount of slack in their work pipelines. Pretty sure there is not a single person with an MBA (or, lol, any consultants) that knows this anymore.

gnunicorn• 1 month ago

Yeah, same sentiment here. I agree that some more people need to be told to relax a little in our field, but on the other side, the product and project managers are constantly looking to ensure maximum utility, especially in startups and high pressure environments. And looking around with the large number of companies that laid off people in the last year or two, I see fewer devs having the choice to push back when that happens. It really reads like the author is in the comfortable position of a staff or principle engineer without a direct manager and gets to decide what their day and week looks like and pick what they work on. I am afraid fewer and fewer have that luxury...

wiseowise4• 1 month ago

I also believe that being too helpful leaves you vulnerable to predators. Tech companies are full of people who want to extract uncompensated work from software engineers4. This is different from work that arrives via normal channels, and for which you’re compensated by promotions, bonuses (and just your normal salary). I’m talking about work that arrives via backchannels, from people who don’t have the ability or willingness to ensure that work is formally recorded under your name. For instance, a product manager from another organization messaging you to say “you’re so good at querying data, would you mind pulling some statistics for me about X?”, or an engineer from another team asking you to “pair” on a piece of work that will ultimately involve you writing all the code and them quietly submitting the change under their own name.

Put this in a frame.

bumby7• 1 month ago

Eh, I think it depends on how engaged your supervisor is. One of the last people I want to work with is the “it’s not my job” guy. I want to work with people who see a problem and offer a solution, whether it’s in their job description or not.

If you’re not being recognized for your work that’s a leadership problem. Stiff arming work feels like a way towards an ossified lumbering work culture.

boringg• 1 month ago

Startup vs incumbent

calvinmorrison2• 1 month ago

unless you're contracted (fixed bid) working on jobs then you're getting paid hourly, salary, whatever... boss tells you to stand around and shoot the shit, thats what you do. I dont know why people think 'not my job' is a relevant answer... the job is what they tell you to do...

fridder• 1 month ago

My pushback isn’t the credit part it is when they try to spring things on you directly instead of going through normal channels. A lack of planning on someone’s part is not automatically an emergency on my part. I see this far more often than credit stealing

ranger207• 1 month ago

what you should put in a frame is "put in a ticket"

moduspol• 1 month ago

I mean it's true, but I don't see it as so black and white. Even more than I'm looking out directly for my own compensation, I'm also incentivized to help the company itself succeed, so it can make sense to help out with small requests that won't get you a parade.

Likewise, there may come a day when I need something from coworkers, and when it comes, I'd appreciate enthusiastic help instead of being swatted away and told to go through the "proper" channels (which could take much longer).

m463• 1 month ago

hmmm...

At good companies, they have a culture, and people help each other out.

Like lunch-table talk that helps people understand things.

But yeah, maybe not doing hours of work for someone.

elevation• 1 month ago

willingness to ensure that work is formally recorded under your name

Where I work the title "Principal Engineer" is a coveted, well compensated, and rarely achieved. Those I've worked with are all highly effective and personable, but I interviewed one about how he achieved the title at his previous company.

His strategy had been to help people and actively give away the credit. In 1 on 1s or in meetings with multiple layers of managers, he would consistently emphasized the value of his other team mate's work. This ingratiated him with his team; years later, when a high dollar project was behind schedule and several key engineers had quit, he carried the project to victory with some late nights, and was awarded the title+raise at his next review. While the key project pushed him over the edge, he wasn't the only engineer there working late nights. He credits his promotion to the goodwill he'd built during his tenure by actively giving others credit.

wiseowise4• 1 month ago

I know a guy who did all what you've listed and the only thing he received was a burnout.

pjc50• 1 month ago

This is one of those things where you have to be aware of the Prisoner's Dilemma; to a certain extent you can elevate a place by better pro-social behavior, or forming a pro-social clique within it, but you need to be aware if/when other people are playing Defect against you.

(one such way to retaliate against defectors is similar workplace anti-social behavior. For example if someone asks you to do something off the books, you can agree and then just flake on them and not actually do it, while hinting that if it was in the ticketing system it would be prioritized)

sharadov2• 1 month ago

Unfortunately this can work both ways - if it's a low politics environment yes, it will work to the engineer's advantage but in environments rife with politicking, people will be quick to swoop in and take credit and at the same time give 2 hoots about throwing you under the bus.

casey2• 1 month ago

Software allows clever people in a lucky position to benefit from the massive amount of work people have done before them. You should remain discipline so that when you do get your opportunity you don't add on to the garbage pile.

zem2• 1 month ago

the bit about glue work is interesting, because in my time working for megacorps this has been an explicit part of the annual performance review (google called it "citizenship" which I think captured the essence of it - basically "what work did you do to make things better for the rest of the company").

on one hand it does seem a bit messed up - this was not in my "job description", so it was technically unpaid work that was nevertheless a formal part of my expectations. but on the other hand I really liked working in an environment where everyone spent some of their time and effort to improve things for everyone.

also making it an explicit requirement for everyone to do at least attempted to circumvent the more toxic culture of "I am a rockstar engineer and I'm busy doing important things, someone else can do the glue work". not to mention that "someone else" usually ended up being a woman, and that she was almost certainly getting paid less than said rockstar engineer.

the OP's implication is that the company should have formally hired someone to do all the glue work, but it is usually made up of enough diverse pieces that it would be practically impossible to hire a single person to do it - e.g. what sort of job title would cover "write documentation, interview software engineers, and organise a team off-site"? but those were all tasks that needed to be done and the citizenship requirement let the burden be distributed more fairly.

I think a better way to put it is not "don't do glue work" but "don't be the only chump doing unrewarded glue work", i.e. to push for a company culture where everyone is expected to do some of it and where it is formally recognised as work.

johnbcoughlin3• 1 month ago

That does sound nice. I think the author would say that if it's part of your annual performance review, then you are being paid to do it. That's the real test, not the job description, which can't be expected to describe every single thing you end up doing once employed.

singpolyma32• 1 month ago

This is mostly all true. At my last corporate job I definitely did this and it was very good for my career.

It also made me hate my life.

TheAndruu• 1 month ago

Working a corporate job is more like a marathon than a sprint.

singpolyma32• 1 month ago

If you want to keep doing it forever I guess? It's a choice

rznicolet• 1 month ago

This reminds me very much of Buffer Time from Star Trek: Lower Decks, but applies pretty well to a lot of life. No slack = no margin for error or the unexpected...

Apocryphon• 1 month ago

It's kind of refreshing to see a "pontificating about what it means to be a SWE" blog post that doesn't have anything to do with the industry impact of LLMs. Like it's 2013 again.

palerdot• 1 month ago

Right. Maybe HN should add tags `Classic HN` to posts like this. Or we could flag it as `Classic HN` lol ...

jeffrallen• 1 month ago

I wanted to love this, but:

Most incidents resolve on their own.

This is most definitely not true.

gdevic• 1 month ago

Great recipe for mediocrity. Do not follow OPs advice. (Source: 23+ years at NVIDIA).

dominicq• 1 month ago

Lmao cringe, 23 years at NVIDIA is supposed to be, what, a credential?

lbrito• 1 month ago

HN-tier flex lol

Arainach6• 1 month ago

This is a good post, but once again incentives rear their ugly head.

Second, preventing or mitigating an incident early (even by just knowing the right feature flag to turn off) can save huge amounts of money: both immediate lost revenue during the incident and future lost revenue from customers who would have pulled their business or refused to sign pending contracts.

Time and time again at many companies, including well-reputed ones, I have seen that preventing issues gets you no recognition, but building a giant pile of kindling and then putting out the inevitable fire will get you recognition twice. Even in "good" orgs.

I've never been able to commit to the game theory politics enough to intentionally ship garbage fast and take that credit - I take too much pride in my work - but I have spent 5+ years managing and growing a framework designed to eliminate classes of issues that plagued the last version of our product and watched as partner teams who ship garbage code and cause outages get public credit for fixing those outages and my team, despite attempting to advocate, get no credit for not having such outages because you can't measure that.

derangedHorse• 1 month ago

The game theory should make is that those teams that recurring lay lose customers due to issues will be punished accordingly. If they aren’t, then maybe the problems that result from shipping fast don’t impact customer retention as much as might think.

Arainach6• 1 month ago

This works across small entities like companies with distinct customers and budgets.

It does not work for large corporations with pools of billions of dollars and various incentives to staying within the ecosystem. It's impossible to measure the contribution of one feature team to perception and retention of something like "Microsoft Intune" or "Google Chrome", and without the ability to measure that no effective check on those teams.

PrimalPower• 1 month ago

Exactly game theory is that is that everyone make more as a "Senior" or "Mid-Level" in a wealthy/successful org over a "Staff" or "Senior" at a poorer one with less customers.

Of course, game theory implies "infinite games" and of course the real world doesn't operate like that.

And large bureaucratic orgs collapse under their own weight, and the enshittification is the norm despite the number of paying customers.

JohnMakin• 1 month ago

Not necessarily. Not every job is shipping features that are visible to customers, or even to management.

You see this pattern of "make fire, put it out, get rewarded" a lot on devops type teams, almost always by the lead (IME). Often it is very difficult to determine customer impact of these types of events, especially if monitoring/alerting is lacking (very common), and even if it isn't, often these same teams have the ability to turn those knobs any way they want anyway.

dj_axl• 1 month ago

Thread.sleep(100000) everywhere until it breaks. Then lo and behold you have fought fires longly and bravely until midnight on Friday after the release. Don't ask me why it's rewarded, and, of course every now and then they switch to rewarding different things.

yurishimo• 1 month ago

That might work until someone else in the org gets curious and checks the git history… I suppose some clever obfuscation might be enough to get around that but then at that point you’re basically writing malware for your own product…

jiggawatts2• 1 month ago

Correct multi-threaded code is... sss... hard.

Much easier to liberally sprinkle mutex locks and "Thread.Sleep(1000); // Quick fix" everywhere until the problems almost always go away!

Meanwhile the guy screaming that this is eldritch madness and can't ever work is "not a team player" because the guy that wrote the code was a hero for applying yet another layer of band aids to the gaping wounds.

rightbyte• 1 month ago

get no credit for not having such outages because you can't measure that.

Well from a philosophical point I would argue that you can measure the weight of nothing too.

prolly97• 1 month ago

With the way you're framing your opposition, I agree with you. But I'd like to add some nuance. Parts of building a product or a set of features is about search, rather than great engineering. Sometimes it's better to build two good-enough features to figure out which one is valuable to the user, rather than building one solid* one. I've always been in the "let's fuck around and find out" camp. I appreciate that someone with a different attitude built git! Just saying that there's a balance here, which will depend on the degree to which you're in the middle of a search problem.

*solid in a pure engineering sense - availability, maintainability, chance of leaking the users' nudes etc.

jongjong• 1 month ago

Yes, this is completely true unfortunately but not the only way.

A good honest approach is just to build a few complex but essential tools so that other engineers have to keep coming back to you. It's a good way to stay relevant. You become really good at identifying misuses of that particular tool and it makes you look way smarter than you are when you can identify bugs in other people's code in mere seconds. This tends to happen naturally as you become more familiar with all the common gotchas that people tend to run into when using your tool.

Ideally you want your tools to be reliable and useful but complex... That way, whenever other devs run into bugs while using your tool, they keep coming back to you and you can point out their mistakes. The mistakes must be almost always be on their side for the strategy to work; this is key. Your code has to be rock solid.

If they find a genuine bug in your code, hopefully a small edge case, you have to be very humble and apologetic about it and you should praise the developer in the team meeting for identifying this complex bug.

This approach is better than getting credit for fixing your own buggy code; that only works with management and junior devs but other senior engineers will hate you.

The approach of building complex but reliable tools gets you credit over and over (often much more than twice) and the approval you get from other devs eventually finds its way to managers' ears. Smart leaders know that this is a better signal than flashy demos.

The leaders who just dish out praise onto specific devs for producing prototypes quickly tend to learn their mistake sooner or later. Many young founders tend to go through this phase though when they praise superficialties.

tayo422• 1 month ago

Not totally true. You can measure page amounts per team or how heavy oncall is.

Arainach6• 1 month ago

You can't prove that "this work caused us to not get paged" versus "that work is unnecessary and you wouldn't have been paged regardless".

Even when you can, you can't prove the impact. As a real example, our team has extensive presubmit infrastructure to catch and block some classes of configuration error that have caused customer data corruption in the past. There have been CLs which were caught by those presubmits and meant that we didn't have outages, but there's no dollar amount tied to an outage that didn't exist.

Meanwhile, team X did something similar that caused data corruption, had N customers affected for such a period of time, scrambled to root cause, roll back, and restore from backups, getting customers back up and online. Look how responsive and great they are!

netcoyote2• 1 month ago

One of the tricks that we can use as good managers is code ownership. The folks who wrote the code are the ones who get to fix the bugs in the code.

While they’re busy fixing their own problems, the teams that wrote outage-free code get first dibs on writing new systems.

On the (online game) teams I worked on there are an infinite number of new & exciting systems needed, so this approach means that the best developers are the ones building them.

FromTheFirstIn• 1 month ago

Great as long as no one ever leaves, but the second someone does suddenly I’m being punished for owning their idiocy. And people are always leaving

_doctor_love• 1 month ago

That’s an extremely game centric point of view. Game devs more than just about anyone else are strongly identified with their code and have an artist attitude about. In a non game environment the psychology is different.

nitwit0052• 1 month ago

The concept of the responsible party bearing the costs is a good one, but if we're honest about who that is, it's often going to be company leadership.

The person who made the breaking change is often diligently following instructions to get it done as soon as possible.

johnbcoughlin3• 1 month ago

The quoted section is about stepping in early with the right knowledge to fix an incident that's in progress. That is, putting out the fire.

Arainach6• 1 month ago

It begins with `preventing or` before talking about mitigating/fixing. There's no such thing as "preventing early" in firefighting.

rgavuliak• 1 month ago

Ultimately the management should care about what brings in the most revenue. A feature that brings low revenue but has no fire is something no-one cares about. If you have a ton of revenue and no bugs, you likely can get recognition.

originalvichy• 1 month ago

As a person who has worked in many customer-facing jobs, the worst trap I faced numerous times is befriending a paying client. It becomes insanely difficult to say no to a client when hired as an expert for their assistance, when they are a genuinely pleasant person.

It’s made worse when they are not a decision-maker, but someone who gets forced to push me to do something. As a trusted expert, it’s easy to say no to bad ideas when the client is the one doing them, but when the orders come from their boss who you never interact with, you’re placed in a position where you either appear as a useless cost, or a yes-man who’ll leave behind a monstrosity.

I sometimes envy some of you guys who worked primarily internal gigs where you could at least try to reason with someone up the chain.

black3r3• 1 month ago

I probably spend even more than 20% of my time away from the computer these days. AI is great for this. I task Claude with something and while it's working I have the time to think about next steps, I can take a walk outside, have a coffee, talk with coworkers about my ideas, ... I'm paid to think, not to sit behind a computer.

There are people who say it's better to have multiple claude code instances crunching different stuff at the same time, and using the waiting time to prompt up another one. This might result in opening up more PRs faster but in the end it's not more productive. Context switching takes time, it divides your attention so your work is more sloppy and less thought through, and driving your brain too much makes you tired which again results in more mistakes. Having to compensate for this negates the productivity gains by finishing more grunt work faster.

3uler• 1 month ago

This makes me never want to work on large engineering teams ever again.

sghiassy2• 1 month ago

Come join Meta. Everything here runs at 120% haha

HDBaseT• 1 month ago

No thanks.

benbristow3• 1 month ago

Meanwhile performance of Meta projects runs at 20% full of bugs.

benbristow3• 1 month ago

And just like that Messenger has gone down right on cue.

sghiassy2• 1 month ago

I thought my sarcasm was apparent

malkosta• 1 month ago

What about just getting work done because you like to code, and not giving a damn about what others think because we will get rich anyways…I wonder why people are always trying to win instead of just having fun.

ensocode• 1 month ago

This is basically Covey's "sharpen the saw" for knowledge workers. [1]

When you're cutting trees, sharpening the saw looks like you're not working. When you're doing software or organizational work, figuring out what actually matters can also look like you're not working.

The hard part is distinguishing between thoughtful idleness and ordinary procrastination. [1] https://www.franklincovey.com/books/the-7-habits-of-highly-e...

bob1029• 1 month ago

One thing I recommend for engineers new to on-call is to avoid rushing: take a few breaths before joining the call or before speaking, and in general try to “think in slow motion”.

The more difficult it becomes to remain silent, the more likely it is that silence is the correct action.

Ego is a hell of a drug. I've been on some calls where things go sideways in prod infrastructure simply because of incessant yapping about things that are tangentially related to the tasks at hand.

Being clever tends to be a lot easier than being the other things, especially now that we have chatgpt and friends.

zuzuleinen• 1 month ago

"The more difficult it becomes to remain silent, the more likely it is that silence is the correct action."

Love this!

onemanfleet• 1 month ago

AI agents are already heavily reducing workloads, which gives workers even more time to take a step back, take some time, and pounce on a solution to a more critical problem.

steve_adams_86• 1 month ago

A form of 'doing nothing' I've embraced is just watching my coworkers who I support do their work and listening to them. Listening is very active, so it's not doing nothing, but it's keeping my hands off of the keyboard and preventing me from rabbit-holing on optimizing something or otherwise spiraling like we all tend to.

The result is that I often know what I should do better than I would have. Make a point of talking to the people you solve problems for, get your hands dirty, and create that domain understanding that you need. You'll likely produce less code, but it'll be more useful.

Or, in some cases, you'll write more. But it'll be for something you never would have realized you needed had you not 'done nothing'.

The key for me was allowing myself to get out of the engineer mindset and into the mindsets my coworkers need to do their jobs, being less interesting in fixing and solving, and more interested in getting a holistic understanding of the required work and how it fits into our team and org and with our partners and so on.

I'm fortunate enough to work somewhere where this isn't only permitted, but it's encouraged. The problem spaces are often highly niche and complex too, so the need for developers knowing what their users are doing is especially important.

I do think it applies anywhere, though. Even in my own personal projects. Do less, observe and experiment, use the software, let things incubate. Then do the work once the mental model has settled in a way you know is better than it was.

throwaway2037• 1 month ago

    > For instance, I believe that engineers should generally avoid glue work2. Most glue work - making sure people talk to each other, updating docs for work you’re not leading, volunteering to address technical debt - reflects the fact that the organization is not explicitly prioritizing this work. If they were, you wouldn’t need to volunteer for it. Either that’s fine, or it’s a big mistake.

Woah, this some bold advice. In my mind, I don't want to be on the same team as this person... as they are always and only thinking about themselves.

pengaru• 1 month ago

If everyone in the team behaves this way there's no substrate creating opportunities for people like this to capitalize on.

I often fall into this role, and historically have made some quite large impacts because of it. But I take issue with TFA's position of doing nothing being a critical component of being effective and available to attack these problems.

I'm practically never doing nothing when employed. But I'm often looking like nothing is being done through the lens of ticket-oriented accounting. If the author means doing nothing by the metrics, ok, I can agree with them there. But it better be because you're too busy down in the weeds becoming one with the product and grokking details of created messes past and present.

If you're literally doing nothing, you won't be positioned well to understand the implementation details, and you won't be positioned well politically/socially within the org to thrive and be genuinely appreciated by your peers.

This is a complicated precarious path to take if you have any intention of lasting in the org. It's difficult to not accumulate enemies with every win you take at the expense of everyone else being too busy being the substrate you're scavenging. Management and your peers must come to appreciate you're filling a critical void, but the void is implicit and unaccounted for, making this tricky - it's built on trust.

They can see your selective work as exploitation while they take up the slack you create. From their perspective they're overworked because people like you don't do enough to balance the workload.

You need to be recognized as an enabler, the one minding the details, omnipresent - not AWOL doing nothing. Catching the fuckups early, preventing incidents while the green-field chaos monkeys carry on. The win is for the team, and you're effectively being a self-directed janitor cleaning messes nobody knew existed.

The reward for this role, as it really is otherwise somewhat thankless, is the autonomy. It's a management failure when these people get put on a pedestal and promoted more than the people doing the grunt work. That creates animosity within the ranks.

disclaimer: not a manager, not a lead, but often the guy in the corner course-correcting and fixing/preventing horribly broken customer-impacting mistakes. These are just some observations based on decades of startups and in recent years FAANG experience as an SDE.

eviks• 1 month ago

you’re just picking up tickets from the backlog, crushing them, then picking up the next one), you’ll miss your chance to do high-impact work in two ways.
Second, if you perpetually look busy, your manager won’t want to volunteer for you.... "oh, Sean has capacity to help out here, let me tag him in”

That's rather primitive, does the author not realize that you can simply change priorities and just drop the working on the current "low impact keeping me busy ticket"???

Similarly,

You won’t be chatting with people who are working on other things, or reading team updates, or keeping an eye on ongoing incidents.

That's not doing nothing! Just like writing those team updates isn't doing nothing because it's not a "ticket". I bet literally your job description is not limited to "do tickets"

Doing nothing at work

Related Stories