_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
HTML Visit Hacker News on the Web
COMMENT PAGE FOR:
HTML Doing nothing at work
pengaru wrote 5 hours 35 min 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.
throwaway2037 wrote 9 hours 34 min 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.
steve_adams_86 wrote 1 day 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.
onemanfleet wrote 1 day 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.
bob1029 wrote 1 day 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 wrote 6 hours 25 min ago:
"The more difficult it becomes to remain silent, the more likely it
is that silence is the correct action."
Love this!
ensocode wrote 1 day 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.
HTML [1]: https://www.franklincovey.com/books/the-7-habits-of-highly-eff...
malkosta wrote 1 day 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.
sghiassy wrote 1 day ago:
Come join Meta. Everything here runs at 120% haha
benbristow wrote 1 day ago:
Meanwhile performance of Meta projects runs at 20% full of bugs.
sghiassy wrote 1 day ago:
I thought my sarcasm was apparent
benbristow wrote 1 day ago:
And just like that Messenger has gone down right on cue.
HDBaseT wrote 1 day ago:
No thanks.
3uler wrote 1 day ago:
This makes me never want to work on large engineering teams ever again.
black3r wrote 1 day 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.
originalvichy wrote 1 day 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.
Arainach wrote 1 day 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.
johnbcoughlin wrote 1 day 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.
Arainach wrote 1 day ago:
It begins with `preventing or` before talking about
mitigating/fixing. There's no such thing as "preventing early" in
firefighting.
netcoyote wrote 1 day 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.
nitwit005 wrote 21 hours 41 min 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.
_doctor_love wrote 1 day 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.
netcoyote wrote 18 hours 31 min ago:
That's a great point, and a fair criticism!
FromTheFirstIn wrote 1 day 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
DiskoHexyl wrote 1 day ago:
Especially the kinds of people people who tend to create such
monstrosities- they either move up or move on (to the next
victim)
tayo42 wrote 1 day ago:
Not totally true. You can measure page amounts per team or how heavy
oncall is.
Arainach wrote 1 day 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!
tayo42 wrote 1 day ago:
You can have before and after data and track trends. How did you
know the issues was wide spread in the first place. You must have
some proof somewhere.
The impact is how many outages overall. If you only prevent one
outage then maybe it's not that meaningful.
Your last paragraph, your right that happens in the short term.
In the long term those teams get reputations for being a shit
show, there will be high turnover, good engineers won't transfer
in, people's compentaencies start to get questioned, other teams
will avoid working with that team and develop their own
solutions, and higher up people will start to look at what's
going on.
Arainach wrote 1 day ago:
> those teams get reputations for being a shit show,
Reputations with who? The VPs who rotate in and out every few
years (if you're lucky enough to go a few years between reorgs)
for a new title and salary bump?
> there will be high turnover, good engineers won't transfer
in,
On the contrary, many people want to work on the team that gets
visibility where people can actually get promoted rather than
having to justify their existence constantly
jongjong wrote 1 day 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.
prolly97 wrote 1 day 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.
rightbyte wrote 1 day 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.
dj_axl wrote 1 day 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.
jiggawatts wrote 1 day 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.
yurishimo wrote 1 day 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â¦
derangedHorse wrote 1 day 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.
JohnMakin wrote 1 day 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.
PrimalPower wrote 1 day 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.
Arainach wrote 1 day 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.
jiggawatts wrote 1 day ago:
The most spectacular instance of this I've seen is Jeffrey Snover
getting demoted for "forcing" PowerShell onto Microsoft.
Meanwhile from a customer perspective its the only good thing
about Windows Server and the only reason I haven't pushed for
100% Linux adoption everywhere I work!
See:
HTML [1]: https://corecursive.com/building-powershell-with-jeffrey...
gdevic wrote 1 day ago:
Great recipe for mediocrity. Do not follow OPs advice. (Source: 23+
years at NVIDIA).
lbrito wrote 1 day ago:
HN-tier flex lol
dominicq wrote 1 day ago:
Lmao cringe, 23 years at NVIDIA is supposed to be, what, a
credential?
jeffrallen wrote 1 day ago:
I wanted to love this, but:
> Most incidents resolve on their own.
This is most definitely not true.
Apocryphon wrote 1 day 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.
rznicolet wrote 1 day 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...
singpolyma3 wrote 1 day 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 wrote 1 day ago:
Working a corporate job is more like a marathon than a sprint.
singpolyma3 wrote 1 day ago:
If you want to keep doing it forever I guess? It's a choice
zem wrote 2 days 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.
johnbcoughlin wrote 1 day 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.
casey2 wrote 2 days 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.
wiseowise wrote 2 days 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.
elevation wrote 1 day 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.
sharadov wrote 1 day 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.
pjc50 wrote 1 day 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)
wiseowise wrote 1 day ago:
I know a guy who did all what you've listed and the only thing he
received was a burnout.
bravetraveler wrote 1 day ago:
Now you know two, hello. I'd take those nights back, the credit
(hah), and peace of mind in an instant. Short of the learning
experience, I regret nearly every bit. The good will I built
was... useless to say the least.
I got the bump in the end. How? Finding new company, both
literally and figuratively. Overextension/sacrifice played no
part and I'd like a refund, were it possible.
sharadov wrote 1 day ago:
More often true than not!
m463 wrote 1 day 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.
moduspol wrote 1 day 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).
ranger207 wrote 1 day ago:
what you should put in a frame is "put in a ticket"
bumby wrote 2 days 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.
fridder wrote 1 day 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
bumby wrote 1 day ago:
I can see that. The counterpoint is that it can create
bureaucratic bloat.
If the proper channel means coordinating with finance to allocate
money, get it assigned to labor codes, and reflected in my
bi-monthly time allotment, I think I'd rather just jump the job
and get it done this week than get it properly assigned two
months from now. It does require a certain amount of cover and
trust within an organization, though.
Arainach wrote 1 day ago:
I've never worked somewhere where the proper channels meant
"coordinate with finance", but "file a bug/feature request to
track this work and time time spent on it" should be standard.
If it's not worth 5 minutes for the requester to do that, it's
not worth however long it would take me.
This makes it easier to query and show what you've done in a
time period. It makes it easier to go through the list of your
assigned tasks and understand where it fits in the priority
order.
bumby wrote 1 day ago:
Sure, but the HN crowd cuts much wider than just people
working on mobile business apps.
calvinmorrison wrote 2 days 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...
bumby wrote 2 days ago:
I do agree with you, and most jobs have a "and other duties as
assigned" for that reason.
But I'll equivocate by saying there are exceptions. If you work a
union gig (technically a contract), you have to be careful to
stay in your lane unless you want a grievance filed. If you are a
licensed engineer and your boss tells you to design/stamp
something outside your domain of competence, you have a duty to
say no. But that kind of stuff is the exception.
calvinmorrison wrote 1 day ago:
Yes I sincerely doubt that the court of opinion, or the real
court, would see the difference between "I use MySQL not MSSQL!
you cant make me write this analysis" versus sometihng
understandable like, you are a for example, a aging and lovable
secretary who is being tasked to clean radioactive material
from a jobsite because there are no calls coming in.
As for unions - yeah thats what got them kicked out of the
convention center. Only certified electricians are smart enough
to plug in laptops into sockets!
bumby wrote 1 day ago:
I don't think you need that dramatic of a strawman for the
point. I think a more plausible one in a grey area could be a
structural engineer who has experience in low rise commercial
buildings being asked to quickly approve a steel scaffolding
for a concert venue in the coming weekend. To the
uninitiated, it may seem like a reasonable request but to
those in the domain it's far enough outside the area of
competence to be questionable.
boringg wrote 2 days ago:
Startup vs incumbent
argee wrote 1 day ago:
Or, "we're in this together" vs "every man for himself".
Seems insane that the latter can even be a functional business,
but monopolistic profit can enable all sorts of tomfoolery.
12_throw_away wrote 2 days 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 wrote 2 days 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...
macNchz wrote 2 days 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.
boogieknite wrote 1 day 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
asdff wrote 2 days 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 wrote 2 days 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.
skybrian wrote 2 days 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.
ge96 wrote 2 days 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
garrickvanburen wrote 2 days 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 wrote 19 hours 26 min 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.
rokhayakebe wrote 2 days 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.
hintymad wrote 2 days 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.
johnbcoughlin wrote 1 day ago:
I read the section you quoted as being about saving the day in an
incident that's already in progress.
johnnycool wrote 1 day ago:
Many carears are made and bonuses paidout with heroesim trick.
mjklin wrote 2 days 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.
bauldursdev wrote 2 days ago:
Can't solve a problem that doesn't exist yet
CobrastanJorji wrote 2 days 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.
hintymad wrote 2 days 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.
themaninthedark wrote 2 days 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?
CobrastanJorji wrote 1 day ago:
Your great grandboss will not look favorably upon your grandboss
passing blame downhill. Disasters are (hopefully) always the
fault of the person in charge, which is why you'll notice that
your bosses are unusually involved with meetings about how to
avoid more disasters.
nitwit005 wrote 2 days 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 wrote 2 days ago:
And start to build a relationship with sales that, at least in a
B2B firm, can be of significant benefit.
tormeh wrote 2 days 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.
justonceokay wrote 1 day 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.
sergeym wrote 2 days 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.
cloche wrote 2 days ago:
Never waste the opportunity a good crisis presents
dilyevsky wrote 2 days ago:
Tom DeMarco had a whole book about this approach:
HTML [1]: https://www.penguinrandomhouse.com/books/39276/slack-by-tom-de...
garrickvanburen wrote 2 days ago:
fantastic book.
NoSalt wrote 2 days 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.
black3r wrote 1 day 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.
benbristow wrote 1 day 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.
black3r wrote 1 day ago:
Majority of the things I've mentioned don't need QA. Improving
performance of an existing code is fine as long as it passes the
existing test suite. Dev tooling / Monitoring is for devs only.
Unused code is unused, just needs review from another dev to
confirm. Documentation is for devs only.
And I work on the backend in a smaller company these days. Our
backend code doesn't pass through QA, we just write tests and
another backend coder reviews the tests if new tests are written.
QA only handles frontend.
gib444 wrote 2 days 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.
M95D wrote 2 days ago:
Could you fix some bugs? Please?
wiseowise wrote 2 days 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.
NoSalt wrote 2 days 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.
hiq wrote 1 day ago:
I would try to learn some new tech. Definitely not something you
can do in a vacuum with no goal for months in a corporate
setting, but e.g. learning more about a programming language you
already use, or some libraries, some tooling, you can easily
spend a few weeks.
After that, yes it'd make sense to find something else.
hilariously wrote 2 days 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.
stuxnet79 wrote 2 days 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.
hilariously wrote 2 days 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.
kaikai wrote 1 day ago:
Your baseline capacity is always lower than it would be with
experienced, fully trained, happy engineers. It seems normal
because the system doesnât support anything better.
annoyingnoob wrote 2 days ago:
Age out?
xnx wrote 2 days ago:
Efficiency is the enemy of resiliency.
bumby wrote 2 days ago:
This is only true if you define efficiency as the inverse of
redundancy. Sometimes efficiency is gained by reducing waste, not
redundancy
nevdka wrote 1 day ago:
Redundancy is easy to misclassify as waste, particularly for
someone who has incentives to find more âwasteâ they can cut
and claim credit for.
bumby wrote 1 day ago:
I would add it's also easy to misclassify when dealing with
high-risk, low-probability events. The fact that someone hasn't
witnessed something happen in their entire career can lead them
to think any mitigation against that event is waste.
codewarrior2000 wrote 4 days 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- wrote 3 days 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.
thewileyone wrote 4 days 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.
throwaway67678 wrote 5 days 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)
o_nate wrote 5 days 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.
Sohcahtoa82 wrote 1 day 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.
HTML [1]: https://en.wikipedia.org/wiki/Hofstadter%27s_law
Tcepsa wrote 1 day ago:
NEVER take Hofstadter's law into account!!!!
martin-uk- wrote 3 days 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.
hilariously wrote 2 days 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!"
zem wrote 2 days ago:
AI has made this way worse - now the thinking is "well, the agent
is doing all the work, why can't the engineers make sure it is
running on all cylinders all the time, churning out useful code"
tjadfsaj wrote 5 days 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?
cloche wrote 2 days 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.
thewileyone wrote 4 days 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.
hilariously wrote 2 days 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.
lgcmo wrote 5 days 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.
erelong wrote 5 days 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
SpecStudioHN wrote 5 days 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.
jazz9k wrote 5 days ago:
This is written as if you have actual control over the volume of work
given to you and/or deadlines.
deterministic wrote 1 day 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 wrote 1 day 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.
wiseowise wrote 2 days ago:
Are you working in mines of Uganda? No? Then you do have actual
control.
patmcc wrote 2 days 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.
QuantumNoodle wrote 4 days 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.
qazxcvbnmlp wrote 5 days ago:
Your communication with stakeholders about your work ends up having
more of an impact than your rate of work output.
SpicyLemonZest wrote 5 days 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.
gorjusborg wrote 5 days 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.
RobRivera wrote 2 days ago:
Aahhh.
Proactive vs reactive
hilariously wrote 2 days ago:
This was voted down because? I would say after you exceed jr
level programming this has been true for the last 20 years of my
career.
projektfu wrote 5 days 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.
holografix wrote 5 days 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?
harimau777 wrote 5 days 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.
Schiendelman wrote 5 days 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.
galleywest200 wrote 5 days 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.
zamadatix wrote 5 days 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.
tonyedgecombe wrote 5 days ago:
It's surprising how often people dig their own grave.
whattheheckheck wrote 5 days 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
tonyedgecombe wrote 5 days 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%?
whattheheckheck wrote 3 days ago:
Business will take everything you give. Theyre bean counters
will be always calculating when it costs more to hire and
onboard a new dev than to let you take your time....
DIR <- back to front page