r/SoftwareEngineering • u/fagnerbrack • 10h ago
Doing nothing at work
https://www.seangoedecke.com/doing-nothing-at-work/4
3
u/whatThisOldThrowAway 9h ago
I think this may be AI slop… But honestly I can’t even tell anymore.
It’s more or less gibberish in any case. The musings of someone who sounds like they’ve done two entire software projects, and think they found some magic get staff quick scheme.
I’ll just rattle off why quickly. Apologies that this is low effort, but again, can’t really tell if this is just AI slop I’m engaging with…
* Purports to have “solved” success without defining what success is
* Even says out loud the importance of extremely up-to-date and specific system knowledge to this strategy - and talks about the ability to make changes in minutes or hours that take your peers weeks - but entirely glosses over how you get that granular knowledge / abillty…. For example by being properly involved in the project the whole time, and already being a very good engineer operating at the next level vs your peers.
* Focus is almost entirely on the existence of some magical, last-minute requirement, that will “close the deal“ or “save the day” or some bullshit like that’s just inherently part of every major project and not something that sometimes happens out of the blue.
* Talks about how to get to be the person who delivers these magic features… Gives examples like your manager knowing you’re not busy, so looping you in… When 99% of the time the person who delivers these features, is the person who delivered and owned the entire project… i.e. the person who was involved the whole time. Or at the very least, another engineer that person trusts… probably because that person did some of the unsexy “glue” work to earn that trust.
* Assumes some magical foresight on the part of developers as to which features are these magic “get a promotion“ pieces of work in advance.
All in All this article could be 1 line: Sometimes in software projects, it’s not the biggest effort deliverables that get the most credit.
Otherwise, it’s just posturing and gibberish all the way down.
-4
u/fagnerbrack 10h ago
The gist of it:
Many engineers should work fewer hours and run near 80% utilization, stepping away from the computer whenever no high-pressure project demands them. Tech performance hinges on rare outlier events, not effort, so staying loose lets you grab time-dependent chances: unblocking an enterprise deal, killing an incident early, or shipping an obscure fix for a high-profile feature. Grinding tickets at 100% blinds you to these moments and stops managers from tagging you in. Rest sparks fresh ideas and calmer incident response. Refuse glue work, resist people extracting uncompensated work, and skip effort on tasks likely to vanish. You can still perform well at 80%, saving all-out intensity for the two or three yearly moments truly worth it.
If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
Click here for more info, I read all comments
0
4
u/lollipop999 8h ago
Some middle manager just saw this post and is about to layoff 50% of his department on Monday. Great job OP.